Deprecated: Assigning the return value of new by reference is deprecated in /home/mmerry/mattmerry.com/blog/wp-settings.php on line 512

Deprecated: Assigning the return value of new by reference is deprecated in /home/mmerry/mattmerry.com/blog/wp-settings.php on line 527

Deprecated: Assigning the return value of new by reference is deprecated in /home/mmerry/mattmerry.com/blog/wp-settings.php on line 534

Deprecated: Assigning the return value of new by reference is deprecated in /home/mmerry/mattmerry.com/blog/wp-settings.php on line 570

Strict Standards: Declaration of Walker_Page::start_lvl() should be compatible with Walker::start_lvl(&$output) in /home/mmerry/mattmerry.com/blog/wp-includes/classes.php on line 1199

Strict Standards: Declaration of Walker_Page::end_lvl() should be compatible with Walker::end_lvl(&$output) in /home/mmerry/mattmerry.com/blog/wp-includes/classes.php on line 1199

Strict Standards: Declaration of Walker_Page::start_el() should be compatible with Walker::start_el(&$output) in /home/mmerry/mattmerry.com/blog/wp-includes/classes.php on line 1199

Strict Standards: Declaration of Walker_Page::end_el() should be compatible with Walker::end_el(&$output) in /home/mmerry/mattmerry.com/blog/wp-includes/classes.php on line 1199

Strict Standards: Declaration of Walker_PageDropdown::start_el() should be compatible with Walker::start_el(&$output) in /home/mmerry/mattmerry.com/blog/wp-includes/classes.php on line 1244

Strict Standards: Declaration of Walker_Category::start_lvl() should be compatible with Walker::start_lvl(&$output) in /home/mmerry/mattmerry.com/blog/wp-includes/classes.php on line 1391

Strict Standards: Declaration of Walker_Category::end_lvl() should be compatible with Walker::end_lvl(&$output) in /home/mmerry/mattmerry.com/blog/wp-includes/classes.php on line 1391

Strict Standards: Declaration of Walker_Category::start_el() should be compatible with Walker::start_el(&$output) in /home/mmerry/mattmerry.com/blog/wp-includes/classes.php on line 1391

Strict Standards: Declaration of Walker_Category::end_el() should be compatible with Walker::end_el(&$output) in /home/mmerry/mattmerry.com/blog/wp-includes/classes.php on line 1391

Strict Standards: Declaration of Walker_CategoryDropdown::start_el() should be compatible with Walker::start_el(&$output) in /home/mmerry/mattmerry.com/blog/wp-includes/classes.php on line 1442

Strict Standards: Redefining already defined constructor for class wpdb in /home/mmerry/mattmerry.com/blog/wp-includes/wp-db.php on line 306

Deprecated: Assigning the return value of new by reference is deprecated in /home/mmerry/mattmerry.com/blog/wp-includes/cache.php on line 103

Strict Standards: Redefining already defined constructor for class WP_Object_Cache in /home/mmerry/mattmerry.com/blog/wp-includes/cache.php on line 431

Deprecated: Assigning the return value of new by reference is deprecated in /home/mmerry/mattmerry.com/blog/wp-includes/query.php on line 61

Deprecated: Assigning the return value of new by reference is deprecated in /home/mmerry/mattmerry.com/blog/wp-includes/theme.php on line 1109

Strict Standards: Declaration of Walker_Comment::start_lvl() should be compatible with Walker::start_lvl(&$output) in /home/mmerry/mattmerry.com/blog/wp-includes/comment-template.php on line 1266

Strict Standards: Declaration of Walker_Comment::end_lvl() should be compatible with Walker::end_lvl(&$output) in /home/mmerry/mattmerry.com/blog/wp-includes/comment-template.php on line 1266

Strict Standards: Declaration of Walker_Comment::start_el() should be compatible with Walker::start_el(&$output) in /home/mmerry/mattmerry.com/blog/wp-includes/comment-template.php on line 1266

Strict Standards: Declaration of Walker_Comment::end_el() should be compatible with Walker::end_el(&$output) in /home/mmerry/mattmerry.com/blog/wp-includes/comment-template.php on line 1266

Strict Standards: Redefining already defined constructor for class WP_Dependencies in /home/mmerry/mattmerry.com/blog/wp-includes/class.wp-dependencies.php on line 31

Strict Standards: Redefining already defined constructor for class WP_Http in /home/mmerry/mattmerry.com/blog/wp-includes/http.php on line 61

Strict Standards: Non-static method WP_Http_ExtHTTP::test() should not be called statically, assuming $this from incompatible context in /home/mmerry/mattmerry.com/blog/wp-includes/http.php on line 94

Strict Standards: Non-static method WP_Http_Curl::test() should not be called statically, assuming $this from incompatible context in /home/mmerry/mattmerry.com/blog/wp-includes/http.php on line 97

Strict Standards: Non-static method WP_Http_ExtHTTP::test() should not be called statically, assuming $this from incompatible context in /home/mmerry/mattmerry.com/blog/wp-includes/http.php on line 142

Strict Standards: Non-static method WP_Http_Streams::test() should not be called statically, assuming $this from incompatible context in /home/mmerry/mattmerry.com/blog/wp-includes/http.php on line 145

Warning: Cannot modify header information - headers already sent by (output started at /home/mmerry/mattmerry.com/blog/wp-settings.php:512) in /home/mmerry/mattmerry.com/blog/wp-includes/feed-rss2.php on line 8
Matt Merry » SD14 Firmware Hacking http://www.mattmerry.com/blog MattMerry.com Thu, 19 Feb 2009 01:19:06 +0000 http://wordpress.org/?v=2.7 en hourly 1 © matt@mattmerry.com () matt@mattmerry.com() MattMerry.com matt@mattmerry.com No no http://www.mattmerry.com/blog/wp-content/plugins/podpress/images/powered_by_podpress.jpg Matt Merry http://www.mattmerry.com/blog 144 144 Update to Parsebin and sections.txt http://www.mattmerry.com/blog/2009/02/01/update-to-parsebin-and-sectionstxt http://www.mattmerry.com/blog/2009/02/01/update-to-parsebin-and-sectionstxt#comments Sun, 01 Feb 2009 20:30:46 +0000 Matt Merry http://www.mattmerry.com/blog/?p=59 With the three new sections decoded and a change I’ve made to the sections.txt file, I figure its time to share the code with whomever wants it. The updates in this version are:

  • Parses CMbP Sections
  • Parses CMbH Sections
  • Parses CMbT Sections
  • Adds support for identifying section by unique ID in secitons.txt
  • Drops support for counting section occurrences in sections.txt
  • Lots of ugly unformatted output

To specify the identifier for a section, add the integer representation for the identifier after the section name in sections.txt. If you look at the sections.txt file included below, you’ll see a ID specified for the FBIN secton. This is to help the script identify sections for now, untill all the sections are IDed and parseable. The string “FBIN “occurs in several places in the file though there is only one occurace of FBIN that represents a section identifier. Hence, the support for including a section identifier (which is the 4 bytes following the section name)

You can download the new script here.

]]>
http://www.mattmerry.com/blog/2009/02/01/update-to-parsebin-and-sectionstxt/feed
CMbT Sections http://www.mattmerry.com/blog/2009/02/01/cmbt-sections http://www.mattmerry.com/blog/2009/02/01/cmbt-sections#comments Sun, 01 Feb 2009 19:40:23 +0000 Matt Merry http://www.mattmerry.com/blog/?p=56 So, the CMbT section is pretty easy as well. The section is basically comprised of a Title or variable name string and then the value. It appears that these are all some sort of test stings. There is one interesting lesson learned from CMbT sections. If you recall, in my post about FBIN section, it looked like FBIN was part of a CMbT section. We’ll look a little closer, but first the layout for the CMbT section:

CMbT Section:
The following is given in order of occurance
Length    Description
0×04        Section Identifier (= CMbT)
0×04        Unknown (Section Version? =0×00 01 00 00 could be minor/major)
0×04        Section Length
0×04         Unknown
0×04        Unknown (possibly related to overall string length? its close)
Variable    Title String.
0×04        The string length
Variable    the string

The title string appears to represent the name of a variable and the string appears to be the value of that variable. There are very few of these CMbT sections, and the text in each indicates that these are some sort of test strings. Here is a list of the variable/value pairs:

CamsettingsInfo: Camsettings-F13-SD14-PP
CalibrationInfo: This is a sample calibration camfile, used for debugging SD7 cameras. In production cameras (and ones which have really been calibrated), it will contain more interesting data specific to each camera.
ColorspaceTestText:      Colorspace is sRGB!
ContentSummary:  Sample Calibration for 3rdES SD7
ColorspaceTestText:      Colorspace is sRGB-Enhanced!
ColorspaceTestText:      Colorspace is AdobeRGB!

Now, lets take a closer look at one CMbT section, again this is in the s14v101.bin file. The section begins at 0×048c30:

0004:8C30 | 43 4D 62 54  00 00 01 00  4C 00 00 00  14 00 00 00 | CMbT....L.......
0004:8C40 | 28 00 00 00  43 6F 6C 6F  72 73 70 61  63 65 54 65 | (...ColorspaceTe
0004:8C50 | 73 74 54 65  78 74 00 00  1C 00 00 00  43 6F 6C 6F | stText......Colo
0004:8C60 | 72 73 70 61  63 65 20 69  73 20 73 52  47 42 2D 45 | rspace is sRGB-E
0004:8C70 | 6E 68 61 6E  63 65 64 21  00 00 00 00  46 42 49 4E | nhanced!....FBIN
0004:8C80 | 02 00 01 00  18 00 00 00  2E 4F AE B1  0E 00 00 00 | .........O®±....

In red is the section length = 0×4c. Adding this to the position of the start of the section 0×048C30 + 0×4C = 0×47C7C. This means the values in blue are not part of the CMbT section! FBIN is its own section, we can add this to the sections.txt file.

So, it appears that these are test texts, but we did learn that FBIN is its own section. As we saw before, the FBIN section contains the Xilinx bit file that describes the programming of the FPGA.

]]>
http://www.mattmerry.com/blog/2009/02/01/cmbt-sections/feed
CMbH Sections Decoded http://www.mattmerry.com/blog/2009/01/29/cmbh-sections-decoded http://www.mattmerry.com/blog/2009/01/29/cmbh-sections-decoded#comments Fri, 30 Jan 2009 07:08:42 +0000 Matt Merry http://www.mattmerry.com/blog/?p=52 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?

]]>
http://www.mattmerry.com/blog/2009/01/29/cmbh-sections-decoded/feed
CMbP Sections Decoded http://www.mattmerry.com/blog/2009/01/10/cmbp-sections-decoded http://www.mattmerry.com/blog/2009/01/10/cmbp-sections-decoded#comments Sat, 10 Jan 2009 21:47:47 +0000 Matt Merry http://www.mattmerry.com/blog/?p=38 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.

]]>
http://www.mattmerry.com/blog/2009/01/10/cmbp-sections-decoded/feed
Milestone 1: SD14 FPGA Code Decoded http://www.mattmerry.com/blog/2008/06/13/milestone-1-sd14-fpga-code http://www.mattmerry.com/blog/2008/06/13/milestone-1-sd14-fpga-code#comments Sat, 14 Jun 2008 07:03:15 +0000 Matt Merry http://www.mattmerry.com/blog/2008/06/13/milestone-1-sd14-fpga-code Well, we broke down the FBIN file into some sections and validated that the section identifiers were correct by locating the size following the section identifiers. I’m assuming at this point that the section sizes are part of section headers, and I don’t know how long the headers are. Thats all about to change.

I’ve found the FPGA code that is executed on the Xilinx chip on the SD14 and it is possible to reverse engineer it to both a layout and an Verilog file. Let me explain this first milestone in my hack of the Sigma SD14 :-)

First off, we’ll examine the largest BINS section in the FBIN file. I’ll work again with the broken down s14v101.fbin file as generated in my previous post. This is the section that we want:

13:	0×001e4508		1983752	0×00076e40	486976

Lets look at the first few bytes as hex and text, and then I’ll explain some things. the first few bytes are:

42 49 4E 53 24 00 00 00 00 FF 30 00 00 00 00 00 BINS$....ÿ0.....
20 00 00 00 04 00 00 00 00 00 00 00 76 B7 80 AC  ...........v·.-
00 00 00 00 00 09 0F F0 0F F0 0F F0 0F F0 00 00 .....   .ð.ð.ð.ð..
01 61 00 08 73 64 37 2E 6E 63 64 00 62 00 0B 33 .a..sd7.ncd.b..3
73 32 30 30 74 71 31 34 34 00 63 00 0B 32 30 30 s200tq144.c..200
36 2F 31 31 2F 30 32 00 64 00 09 31 38 3A 30 35 6/11/02.d.      18:05
3A 30 37 00 65 00 01 FF 88 FF FF FF FF AA 99 55 :07.e..ÿ.ÿÿÿÿª.U
66 30 00 80 01 00 00 00 07 30 01 60 01 00 00 00 f0.......0.`.... 

The green values are the hexadecimal, and the blue values are the strings. Now, we can see the BINS tag starts things off, and checking the size…wait a minute! the size is wrong! What? Well, then, what comes next? To find out, we had better figure out whatever sd7.ncd is. SD7?? Yup. there is more than one reference to the SD7 in the overall firmware file :-)

Lets see if we can find anything else in that string that will help us. How about 3S200. Hm, the Xilinx chip is a XC3S200. Jackpot! A quick google confirms. NCD files are Xilinx design files. That gets us somewhere. I have the feeling that this is the file that the FPGA loads as the design. Another quick google turns up a page on FPGA-Faq.com that is entitled “Tell me about bit files.” Bit files are the FPGA’s firmware file, quoting from FPGA-Faq.com:

The Xilinx .bit format is pretty simple.  It uses keys and lengths to
divide the file.

Here is an example.  Below is a hex dump from the beginning of a .bit file:

00000000:  00 09 0f f0 0f f0 0f f0 0f f0 00 00 01 61 00 0a  *………….a..*

00000010:  78 66 6f 72 6d 2e 6e 63 64 00 62 00 0c 76 31 30  *xform.ncd.b..v10*

00000020:  30 30 65 66 67 38 36 30 00 63 00 0b 32 30 30 31  *00efg860.c..2001*

00000030:  2f 30 38 2f 31 30 00 64 00 09 30 36 3a 35 35 3a  */08/10.d..06:55:*

00000040:  30 34 00 65 00 0c 28 18 ff ff ff ff aa 99 55 66  *04.e..(…….Uf*

Oh, this looks just like the section that was found in the SD14 firmware file! Reading more at FPGA-FAQ.com, we see that there should be an “a”, “b”, “c”, “d”, and “e” sections, and sure enough, our “a” identifier is at offset 0X076e72 in s14v101.fbin. You can easily find the rest of the sections yourself.

We just found the FPGA code that runs on the Sigma SD14!

Googling turns up a bunch of info for these Xilinx Bin files. Here is a program to decode the headers. Here is some info on how this can be converted into a C header file. Good thing Sigma is cheap and didn’t use the more advanced 3A FPGA or we’d have to deal with this crap.

The greatest piece of info I found however was this brilliant site on a debit utility to turn a BIN file into a netlist. For those of you who don’t know, a netlist is the list of circuit elements that make up the circuit. In this case, it takes the bin file and generates a list of logic gates for the circuit. This will also give a visual representation of the circuit, and even contains information on how to convert this back into verilog. Verilog is very easy to simulate (I’d imagine that a Xilinx bin file is as well) :-)

Next steps: Convert the SD14 Xilinx bin file into a netlist, generate a graphical representation of the circuit, and convert it back to verilog.

]]>
http://www.mattmerry.com/blog/2008/06/13/milestone-1-sd14-fpga-code/feed
FBin File http://www.mattmerry.com/blog/2008/06/12/fbin-file http://www.mattmerry.com/blog/2008/06/12/fbin-file#comments Fri, 13 Jun 2008 06:38:53 +0000 Matt Merry http://www.mattmerry.com/blog/2008/06/12/fbin-file  So a quick recap was dumping the largest CMbT section from the s14v101.bin file. I removed what I thought to be the header (everything before FBIN). I renamed this file s14v101.fbin.

Now, I’ll use the parsebin script to dump all the BINS sections. How do I know to do this? I took a look at the file and found a handful of occurrences of the string “BINS”.

So, the steps, create a new sections.txt file that contains one section: “BINS”. Call it fbinsections.txt. Now, run this through the parsebin.pl file like this:

./parsebin.pl s14v101.fbin fbinsec.txt > info-fbin-101.txt

This gets us the follwing information:

*****************************************************
BINS:
*****************************************************
Num	Hex Length	Dec Length	Hex Position	Dec Position
0:	0x00000a4c		2636	0x00000018	24
1:	0x000002a0		672	0x00000a64	2660
2:	0x000001a0		416	0x00000d04	3332
3:	0x00063c54		408660	0x00000ea4	3748
4:	0x00003db0		15792	0x00064af8	412408
5:	0x00000fc0		4032	0x000688a8	428200
6:	0x00000024		36	0x00069868	432232
7:	0x000002f4		756	0x0006988c	432268
8:	0x00000034		52	0x00069b80	433024
9:	0x00000230		560	0x00069bb4	433076
10:	0x000001a4		420	0x00069de4	433636
11:	0x0000bef8		48888	0x00069f88	434056
12:	0x00000fc0		4032	0x00075e80	482944
13:	0x001e4508		1983752	0x00076e40	486976

Interesting. 14 sections of greatly varying length. A sanity check right about now would be a good idea. Lets see if we can make any sense of this quickly. We can examine the BINS 0×069b80, dumping the hex:

 42 49 4E 53 34 00 00 00 00 03 40 FF 00 00 00 00 .....

It continues, but I chose to leave the rest off. The text in  red is “BINS”. According to parsebins.pl, the hexadecimal length of this section is 0×34. Hey, there is the length!! I’ll leave it as a homework assignment to verify the rest of the sections. Looks like we’ve found an embedded file type, that has at least some structure. What are all the sections? Whats that really big BINS section? We’ll leave that for next time.

]]>
http://www.mattmerry.com/blog/2008/06/12/fbin-file/feed
CMbT http://www.mattmerry.com/blog/2008/06/12/cmbt http://www.mattmerry.com/blog/2008/06/12/cmbt#comments Fri, 13 Jun 2008 06:15:32 +0000 Matt Merry http://www.mattmerry.com/blog/2008/06/12/cmbt So, as I mentioned in the last post, there were some large sections in the bin files that require further investigation. The output of the parsebin script shows these sections. The most interesting to me is the large CMbT section. Lets look at s14v101.bin first. from parsebin:

*****************************************************
CMbT:
*****************************************************
Num	Hex Length	Dec Length	Hex Position	Dec Position
0:	0x00000040		64	0x000001d8	472
1:	0x00000040		64	0x00048b54	297812
2:	0x00000044		68	0x00048bbc	297916
3:	0x0025b318		2470680	0x00048c30	298032
4:	0x0000004c		76	0x002a3fe0	2768864
5:	0x000000f4		244	0x002a402c	2768940

Hm. that 4th CMbT section is the one I want. Using parsebin to dump this section to its own file:

./parsebin.pl -p CMbT -d 298032 s14v101.bin

This will generate a file called “s14v101.bin-CMbT-298032.” Lets open this. The section starts off like this (plane text):

CMbT....L.......(...ColorspaceTestText......Colorspace is sRGB-Enhanced!....FBIN.........O®±....dn..BINSL
.... ÿ.... ...,..8+.Õ 

Woa. Whats that? We see a couple possible tags. There is that FBIN tag. then BINSL? Hm. FBIN=Firmware Bin?? I have the suspicion that there is a header associated with the original CMbT section, then there is an embedded file, an “FBIN” file. Searching this file for BINS and I get several hits.  Letsuse parsebin to break this up too. First thing first though, lets remove everything before “FBIN” and save this as its own file. I’ll call this file s14v101.fbin.

]]>
http://www.mattmerry.com/blog/2008/06/12/cmbt/feed
DP1 Quick look http://www.mattmerry.com/blog/2008/06/12/dp1-quick-look http://www.mattmerry.com/blog/2008/06/12/dp1-quick-look#comments Thu, 12 Jun 2008 21:35:39 +0000 Matt Merry http://www.mattmerry.com/blog/2008/06/12/dp1-quick-look So Sigma released an updated DP1 firmware today. Couple this with some interesting shots of the insides of the DP1 and turns out that there is a Xilinx chip and a custom ASIC (the Sigma TRUE) on the DP1. Way to go Sigma, custom ASICs, nice. According to the DP1 firmware, the Xilinx chip is a XC3s200 - same as the SD14. The firmware is also made with the same CamXML2Bin program, looks like Foveon release this? Don’t know.

You might wonder how I was able to determine the Xilinx chip from the firmware. We’ll, I’ve made incredible progress in the last couple days, I’ll try to write about it tonight.

]]>
http://www.mattmerry.com/blog/2008/06/12/dp1-quick-look/feed
Perl Parser http://www.mattmerry.com/blog/2008/06/08/perl-parser http://www.mattmerry.com/blog/2008/06/08/perl-parser#comments Sun, 08 Jun 2008 21:42:57 +0000 Matt Merry http://www.mattmerry.com/blog/2008/06/08/perl-parser I love perl. Its great for parsing files, even binary files. The ParseBin.zip zip file contains a perl script I wrote (releasing under GPL 2.0).

The script file basically attempts to parse the binary file, looking for sections. It will keep track of section location and size, print out information on the section, print individual section types and even dump or ignore sections at a given location. The command line arguments to the script are:

./parsebin.pl [-h -s [-i Location] [-p Section] [-d Location]] BINFILE  SECFILE
        -s: Print Strings as well
        -i [Location]: Ignore (dont print) the section at [Location]. Can be used multiple times.
        -p [Section]: print a section. ALL for all. Can be used multiple times
        -d [Location]: Dump the section at location to a new file. 

Its not pretty but it works for now. This will evolve to allow individual sections to be diffed between different firmware versions. For now, its a tool to investigate the firmware sections. The sections.txt file I use contains CMbP, CMbT, CMbM and CMbH, each on their own line.

The Section Info zip file contains the dumps of the script when ran against the s14v101.bin and s14v102.bin files. The sections look pretty smiliar. There are a couple large sections that I’ll want to look at closer. The -d option to the script will help here.

]]>
http://www.mattmerry.com/blog/2008/06/08/perl-parser/feed
Strings in Version 1.01 http://www.mattmerry.com/blog/2008/06/08/strings-in-version-101 http://www.mattmerry.com/blog/2008/06/08/strings-in-version-101#comments Sun, 08 Jun 2008 20:47:14 +0000 Matt Merry http://www.mattmerry.com/blog/2008/06/08/strings-in-version-101  Lets take a look at the strings in the ver 1.01 SD14 firmware file.

We can dump the strings using the strings program:

$ strings s14v101.bin > s14v101.strings.txt

This dumps all the strings in the s14v101.bin file to the s14v101.strings.txt file. Open that text file. You see right near the top:

 Converted using Foveon CamXML2Bin 1.2.15.2924 Release (Mar 20 2007 16:31:42)

This is located at offset 0×00016C in the original file. Looks like they use some tool to take an XML file and convert it to a bin file. Googling this name does no good, it looks to be an internal proprietary tool.

Directly below that we see the text “CMbH”. In two more lines, we see “CMbT”, then “CMbM.” You can grep the strings file for all occurrences of CMb*

$ grep “^CMb.” s14v101.strings.txt > sections.txt

Taking a look at this, we can see that there are four unique CMb* sections:

  • CMbT
  • CMbH
  • CMbM
  • CMbP

I’m thinking that these are the section identifiers we are looking for. the next step would be to break the binary file up based on these sections and to collect some basic data on these sections. Spend some time looking into the strings, these sections may not be the only ones.

We can grep for all the 4 character stings that are on one line in the strings  file. Lets try this:

$ grep “^….$” s14v101.strings.txt > sections.txt

There are lots of mishits here. a quick glance makes me want to look into the following more closely:

  • SETN
  • SETH
  • FBIN
  • BINS
  • SIFC
  • SIFD
  • MCMN
  • MCBT
  • EXEC

Also, of interest from the strings file:

  • SECi
  • SECp
  • SECc
  • FOVb

Hey, those are the sections in the X3F files :-) And:

Update MCDSP bootstrap code from CF.
Update BFDSP bootstrap code from CF.
Reprogram FPGA code from CF.
Update CAMCPU firmware from CF. 

Looks like code for all the processors can be updated via the CF card! Awesome!

 Starting debug console.  (type HELP for help)

I want access to this debug console. The software fror it appears to be included in te firmware. There is lots you can do with this, just take a look at all he descriptions for the possible commands!

The next step will be to break down the firmware into sections based on the CMb* tags. I’ll also take a closer look at the other sections.

]]>
http://www.mattmerry.com/blog/2008/06/08/strings-in-version-101/feed