There are obviously ways to create other systems such as perhaps "base81" etc, since you can do anything you want if you create a custom encoding algorithm. Many are control characters such as NULL etc. The answer for that is that base64 is the best we can find, since the lower 128 ASCII characters aren't all printable. You may think "Why not base128 (7 bits of input = 8 bits of output), at just 14% size growth when encoding?". So yes, Base64 always increases data size by 33% (plus some potential padding by the = characters that are sometimes added at the end of the base64 output). And if we divide 8bits/6bits we see where the 33% growth comes from, as mentioned at the top of this post. Or, described another way, every Base64 character (which is 1 byte (8 bits)) encodes 6 bits of real data.
#Ihex vs hex full
So 24 bits (3 full 8-bit bytes of input) / 6 bits (base64 alphabet) = 4 bytes of base64. How are those represented in binary? With 000000 (0) to 111111 (63).īingo! Each base64 character represents 6 bits of input data using a single output byte (a single character such as "Z", etc). Why that magic "24 bits" number? Well, base 64 represents the numbers 0 to 63. H.G.H.G.I was curious how on EARTH base64 can convert 3 input bytes into 4 output bytes for just 33% space growth (whereas hex converts 1 input byte into 2 output bytes for 100% space growth). Lets ask radare2 if the size 122560 is right > ifįile ihex://SMOK_X_CUBE_II_firmware_v1.07.hex
Python seems to deliver us the correct bytes Lets cook a python unhexlify :\>cat makebin.py To the developers of radare if you read this can you check if rax2 -s works properly in windows if input is file it seems it suffers from unix / windows line ending quirks (windows seems to convert the binary 0x0A to 0x0d 0x0a when using the redirection operator :\>rax2 -s bin This doesn't work as it should deliver us half the input size but it is higher than that also the inversion rax2 -S is_original doesn't get us the original input back Lets convert the hex pairs to binary rax2 -s bin
Lets check out if sed magic worked we should have 32 characters per line if it worked concatenated into one big string :\>wc out Sed substitute the first nine characters and last two character and rip off the line endings \r\n.
#Ihex vs hex code
So that leaves 3830 lines as code data xxīased on the above details we can carve the bytesĭelete the first, last. The last but one line denotes start linear address record type 0x05 and EIP = 0xc1 checksum matches (100 - (0xc1 + 0x05 + 0x04 ) ) = 0x36 The last line 3833 denotes end of file record type 0x01
#Ihex vs hex 32 bit
Record type is = 0x04 (extended linear address 32 bit format)Īnd it stays as is until another record 04 is encountered lets check if the file contains another record 04 :\>grep -in. Grep -ivn :10 SMOK_X_CUBE_II_firmware_v1.07.hexĭissecting the first line line1 data size = 0x02 The file consists of 3833 lines out of which 3830 lines have a record length of 0x10 wc SMOK_X_CUBE_II_firmware_v1.07.hexģ833 3833 172401 SMOK_X_CUBE_II_firmware_v1.07.hex It seems each line in the ihex file starts with a colon :Įach of the above are hexpairs ie BYTE E8 will be 0x45 0x38 in the file 3A 31 30 30 30 30 30 30 30 45 38 30 45 30 30 :10000000E80E00
#Ihex vs hex pdf
Intel seems to have published the specs of ihex file format i got hold of one pdf from microsym named intelhex.pdf dont know if any latest version are available this is my first brush with ihex or arm for that matter Hexadecimal Object File Format Specification Revision A January 6, 1988 If you were wondering how did radare2 get the 4885460c at address 0xxxxc1 :\>rahash2 -a md5 SMOK_X_CUBE_II_firmware_v1.07.hex
#Ihex vs hex how to
SYS_V commented that it should be -b16 and posted an answer with ample details how to proceed from the end of my answer to a tangible result here is the link to that thread how to find usefull info from a bin file :\>ls -l Note the command in radare2 in my original answer uses switch -b32 Radare2 supports these ihex files directly
0 kommentar(er)
