ANALYSIS OF SMCDSP-200/205 FIRMWARE

The firmware contains a large image file that turns out to be a concatenation of a few gzip-files and a checksum:

LEN=$(wc -c < dsp205-1.0.0988.01.bin)
dd if=dsp205-1.0.0988.01.bin of=fcodec.out.gz bs=65536 count=2
dd if=dsp205-1.0.0988.01.bin of=ic.img.gz bs=65536 skip=2 count=1
dd if=dsp205-1.0.0988.01.bin of=voip.img.gz bs=1 skip=$[3*65536] count=$[$LEN-3*65536-8]
dd if=dsp205-1.0.0988.01.bin of=trailer.bin bs=1 skip=$[LEN-8] count=8

gunzip fcodec.out.gz
gunzip ic.img.gz
gunzip voip.img.gz

The 8 bytes trailer in old firmware 1.0.0457.00 for DSP200:

0013d010                                 43 32 30 31 32 42  |          C2012B|
0013d020  32 42                                             |2B|
0013d022

So it reads C2012B2B and could simply be printed.

The 8 bytes trailer in new firmware 1.0.0.988.01 for DSP200:

0013cff0              45 39 41 42  33 32 46 36              |    E9AB32F6|
0013cffc

So this reads E9AB32F6 and could simply be printed.

The 8 bytes trailer in new firmware 1.0.0.988.01 for DSP205:

0013cfc0                       36  43 45 30 37 38 45 41     |       6CE078EA|
0013cfcf

So this reads 6CE078EA and could simply be printed.

Clearly,

  1. The last 8 bytes contain a bit of extra information
  2. It looks like this information a 32-bit number in ASCII hex
  3. The most sensible information here would be a checksum
  4. It is highly probable that this is a CRC-32 checksum

So, to try the checksum, we reuse $LEN to get everything before it:

LEN=$(wc -c < dsp205-1.0.0988.01.bin)
dd if=dsp205-1.0.0988.01.bin of=presum.bin bs=1 skip=0 count=$[$LEN-8]

Then, using the check CRC-32 tool from http://www.gregroelofs.com/greg_software.html

../check-4.3/check presum.bin
presum.bin                       CRC-32 = 6ce078ea, size = 1298375 bytes

Clearly, the trailing 8 bytes represent the CRC-32 of the previous content, printed as uppercase hex digits in ASCII, without trailing newline, so "%08X".

ANALYSING FCODEC.OUT

As was to be expected, this contains little of interest. It is probably manually crafted assembler code.

ANALYSING VOIP.IMG

Analyse the strings in voip.img with:

strings voip.img

This reveals a text start of uCos. The uC/OS is an RTOS that is described on http://en.wikipedia.org/wiki/MicroC/OS-II and on http://micrium.com/page/products/rtos/os-ii

ANALYSING IC.IMG

The ic.img contains long texts to be displayed as menus during manufacturing and testing. It appears to be the bootloader:

Interestingly, the many diagnostic routinges in ic.img will be good sources for scraps of code that would otherwise be lost in much more complicating code.

CHIPS ON THE BOARD

The following chips are available on the board:

CONNECTORS ON THE BOARD

JP2 is an RS-232 interface running at 3V3. Thanks to Jeroen for helping me figure out what it did with his splendid autobaud converter.

Surprise, surprise! Even though the device uses a 70 ns NOR flash, it does not run programs straight from it. Instead, it gunzips a program at a time, loads the result into DRAM and jumps to that form.

That means that this device may actually be able to run fullblown Linux. That would be strange, though, given that a firmware can be directly matched to the hardware. It is much nicer to use the impressive space to have it do more useful things in the telephony area, where it matters in terms of end-user experience.