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.

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.

I once put together my own decoder for the X3F files and I recall that the file was broken down into sections. The sections were all labeled (i.e. FOVb, SECd, ect). Perhaps this file is the same. This seems to be in line with first observations that there are string sections and data sections. This also somewhat aligns with some other executable file formats.

My plan is to:

1. Dump the strings for a firmware version and look for hints.
2. Look for section identifiers in the firmware.
3. Attempt to break the firmware down into sections
4. Compare various firmware versions to each other based on sections.

The approach will use the first few versions of firmware for investigation/comparison. I’ll leave a couple versions, version 1.06 and the two 1.07s, uninvestigated as an unknown baseline to test my final product.

At Offset 0×093993 we find:

THe BF561 manual notes that a larger lock count may be necessary when changing the voltage significantly

Complete with typo and all. I thought those Sigma guys were Japanese, what are they doing typing their notes in English? Perhaps its easier. Perhaps there is another reason. That would be a reference to the Blackfin  BF 561 DSP. The DSP is a dual core chip with a “High data throughput tailored for the needs of imaging and consumer multimedia applications.” Looks like we found our chip.

The Blackfin site has links for all the technical documentation and even development evironments for the BF561. Get reading, this is the brains behind the camera. But is it the only chip?

Not quite. Looking near the end of the file (offset 0×0DFAC8), we see the following:

SDK for DSC: Copyright (c) 2003 MegaChips Corporation

Further down, we that perhaps this is called the DSC 131. You can also see references to an FPGA throughout the file. Neither of these chips are FPGAs, so there is at least another chip in there we don’t have an ID for.

Lets go Googling. This page from Planet Analog is interesting. It tells us that the SD14 has inside:

• Foveon X3 14.1 MPixel sensor
• ASDP BF651 Blackfin DSP
  
• Xilinx Spartan-3 XC3S200 FPGA
• Analog Devices AD9228 A2D converter
• 4 Samsung K4S511632D-UC75 (512Mb SDRAMs)
• MegaChips DSC-3H
• 2 Samsung K4S561632H-UC75 (256 Mb SDRAM)
• Toshiba TC58FVM6B5BTG65 (64 Mbit NOR flash)
• Casio LCD

A couple observations from this:

• The FPGA must be loaded with some sort of executable. Can they update this?
• This camera has 2.5Gb of RAM!
• What is run on the  MegaChips chip?
• Whats run on the  Blackfin?
• How is it all coordinated? I’d suspect that there is some form of OS on this camera.
• How is all of this “booted?”

At least the observations from the firmware are confirmed