I had some time over the holiday to dust off the SD14 firmware project. I was able to mostly decode the CMbP sections in the firmware. I’m not sure yet what they represent, but I’m able to understand most of the information in the section.

First, lets look at the CMbP Section starting at offset 0×518 in s14v101.bin. (I’m picking an easy one on purpose) You can use my parsebin.pl script to extract the section. I’ve copied the section here.

0000:0510 | 45 46 41 55  4C 54 00 00  43 4D 62 50  00 00 01 00 | EFAULT..CMbP....
0000:0520 | B8 00 00 00  14 00 00 00  20 00 00 00  43 4F 4E 44 | ¸....... ...COND
0000:0530 | 5F 52 45 53  00 00 00 00  06 00 00 00  58 00 00 00 | _RES........X...
0000:0540 | 00 00 00 00  09 00 00 00  14 00 00 00  18 00 00 00 | ................
0000:0550 | 1F 00 00 00  24 00 00 00  2C 00 00 00  31 00 00 00 | ....$...,...1...
0000:0560 | 39 00 00 00  3F 00 00 00  4F 00 00 00  57 00 00 00 | 9...?...O...W...
0000:0570 | 56 61 72 69  61 62 6C 65  00 52 45 53  4F 4C 55 54 | Variable.RESOLUT
0000:0580 | 49 4F 4E 00  3D 48 49 00  52 45 53 5F  48 49 00 3D | ION.=HI.RES_HI.=
0000:0590 | 4D 45 44 00  52 45 53 5F  4D 45 44 00  3D 4C 4F 57 | MED.RES_MED.=LOW
0000:05A0 | 00 52 45 53  5F 4C 4F 57  00 3D 46 55  4C 4C 00 52 | .RES_LOW.=FULL.R
0000:05B0 | 45 53 5F 48  49 20 52 45  53 5F 46 55  4C 4C 00 44 | ES_HI RES_FULL.D
0000:05C0 | 65 66 61 75  6C 74 00 52  45 53 5F 48  49 00 31 30 | efault.RES_HI.10

From parsebin.pl, we can see that the section is supposed to be 0xB8 bytes long. Just taking a quick look, we see the section starts with the following:

0000:0518 | 43 4D 62 50  00 00 01 00  B8 00 00 00 14 00 00 00 | CMbP....¸.......

There is the Section Identifier (CMbP), some value (0×00010000) and then 0×000000B8 - Our section length! We’ve got our first couple pieces of concrete information on the section, the section identifier and the length.

We don’t know what the 0×00010000 is yet. And the next byte, 0×00000020 is also unknown at this point. We see a string next however with a value of “COND_RES.” Next are a bunch of WORDS (4 bytes) then more strings. The strings start with “Variable” and “Resolution” and then what look like pairs of strings follow after that. For example, the string pair would be “=HI” and “RES_HI” followed by “=MED” and “RES_MED” The strings appear to be related, hence I’m calling them pairs for now untill I figure things out better. We can see this, but lets try to figure out how it is decoded.

First, start off with “COND_RES” It ends on a 4 byte boundary, but this might be coincidence. Especially considering most strings are usually null terminated (e.g. end with 0×00). Also, thinking logically, why would a string have to be a  multiple of 4? This would be required if it were to end on a 4 byte boundary. My suspicion is that the string ends with the WORD which is null terminated, so this string would have an additional 0×00000000. Lets confirm by looking at the equivalent string in the first two  CMbP sections (at offsets 0×26C and 0×2B0)

0000:0280 | 52 65 71 75  69 72 65 64  48 61 72 64  77 61 72 65 | RequiredHardware
0000:0290 | 00 00 00 00  01 00 00 00  38 00 00 00  00 00 00 00 | ........8.......

...

0000:02C0 | 24 00 00 00  53 68 6F 6F  74 69 6E 67  4D 6F 64 65 | $...ShootingMode
0000:02D0 | 73 00 00 00  01 00 00 00  34 00 00 00  00 00 00 00 | s.......4.......

Hm. “RequiredHardware” also appears to end on a 4 byte boundry. But, “ShootingModes” does not - it ends with 0×73000000.Lets look at one more section, at 0×300:

0000:0310 | 24 00 00 00  43 4F 4E 44  5F 45 56 41  4C 5F 53 54 | $...COND_EVAL_ST
0000:0320 | 41 54 45 00  03 00 00 00  44 00 00 00  00 00 00 00 | ATE.....D.......

Ah, the string “COND_EVAL_STATE” also ends in 0×00 on a 4 byte boundry. You can confrim with the rest of the CMbP sections that this string will always end on 0×00, padded with 0×00s to the next 4 byte boundry. So, we’ve got something akin to a section title now.

Next up are those string pairs we discussed earlier. Before we get to that however, we should take a look at the WORDS that separate our section title from these string pairs. Here they are (Hex : Decimal):

• 0×00 : 0
• 0×06 : 6
• 0×58 : 88
• 0×00 : 0
• 0×09 : 9
• 0×14 : 20
• 0×18 : 24
• 0×1F : 31
• 0×24 : 36
• 0×2C : 44
• 0×31 : 49
• 0×39 : 57
• 0×3F : 63
• 0×4F : 79
• 0×57 : 87

Interesting. Starting at 0×09, the numbers are all increasing. Remember the first string in this next group is “Variable?” Counting the NULL (0×00), “Variable” is 9 bytes long. The next value is 0×14 or 20 bytes long. The next string is “RESOLUTION” - counting the NULL that is 11 bytes long, not 20. But! 20 - 9 = 11. In other words, the string “RESOLUTION” ends 20 bytes after the beginning the the string group. The next number is 0×18 or 24 in decimal. Sure enough, the string “=HI” ends at an offset of 0×18 from the start of the string group.

There we have it, most of the information in the CMbP section has been decoded. The following is a summary of the section structure:

Length    Description
0×04        Section Identifier (= CMbP)
0×04        Unknown (Section Version? =0×00 01 00 00 could be minor/major)
0×04        Section Length
0×04        Unknown
0×04         Unknown
Variable    Section Title (length multiples of 0×4, must end in 0×00)
0×04        Unknown
0×04        Unknown
0×04        Unknown (all 0×00’s)
Variable   String Ending offset (must start with 0×00, each has length of 0×4)
Variable    Strings.

I’ve updated the parsebin.pl script to decode and store the CMbP sections. I’m going to clean the script up a bit and post the output and script a bit later on.

Categories: SD14 Firmware Hacking