The CMbH Sections are pretty short and simple, so I’ll just get to the layout. There are two interesting things to note in these very short sections. The section basically costains a String value and some other unknown, interesting value. Now sure what the number is, an offset, index, size, perhaps a literal value, but its interesting. I’ll be looking at this more closely.

For now, here is the layout of the section:

CMbH Section:
The following is given in order of occurance
Length    Description
0×04        Section Identifier (= CMbP)
0×04        Unknown (Section Version? =0×00 01 00 00 could be minor/major)
0×04        Unknown
0×04         Unknown
0×04        Section Length
Variable    Single String.

Now, The 1st unknown value is the interesting one. Here is a table  of the strings and the interesting unknowns for your reading pleasure:

Title                     Value
********************************
RES_HI                    0x04b8
ISO_400                   0x03b8
BASE                      0x6a60
ISO_800                   0x04fc
COLORSPACE_SRGB_ENHANCED  0x007c
COLORSPACE_SRGB           0x0064
RES_FULL                  0x00c4
SETUP                     0x04f0
SETUP                     0x015c
ISO_200                   0x03b8
EXP_DEFAULT               0x0068
COLORSPACE_ADOBERGB       0x006c
ISO_100                   0x03b8
RES_MED                   0x04b8
EXP_BULB                  0x00a8
RES_LOW                   0x04cc
ISO_1600                  0x0500
BASE                      0x45874
ISO_3200                  0x0500
LONG_EXP                  0x01dc

Why are there two bases? And why are they so large?

Categories: SD14 Firmware Hacking
No Comments »

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
No Comments »