CodeDump : DissectingSMC

CodeDump :: Categories :: PageIndex :: RecentChanges :: RecentlyCommented :: Login/Register

Dissecting the SMC2804WBRP-G


Introduction


The SMC2804WBRP-G is a product of SMC, it is a wireless broadband router and has the following options:
Unfortunately it had some disadvantages which I couldn't live very well with:
Nevertheless it had served me well. I've upgraded to a Linksys WRT54G, so I can afford to play with this old Barricade G. My ultimate goals are simple, I wan't to learn (and share as much as I can from it) and I'd like to see it run a real operating system.

List of images


Below is a list of images that will be used during the text, in the text only the thumbnail will be referenced.

Hardware


Model specification

The frontpanel of the router says Barricade G, 54Mbps Wireless Cable/DSL Broadband Router SMC2804WBRP-G. The labels on the bottom specify the partnumber as 751.0123 and define the supplier part description as SMC2804WBRP-G EU. And it uses a 9V at 1A adapter which output is DC.

The arcadyan connection

The mainboard contiains several stickers, but these three are interesting:
image
The sticker that is hidden by the wire contains the text: WG4005B-17 EU below the barcode. Now when you search google for wg4005b you get to the homepage of a company called Arcadyan. And this company offers a 802.11g wireless gateway with printer server. It's datasheet can be found here. Do the features look familiar to you ? They certainly do to me.

The package

These are the top, front, botttom and back view of the router. All you need to do to open the router is remove the four rubber feet which hide the screws. After that you can click the front and the back panel off. After that you can remove the top cover and you'll see the mainboard. You can simply take the mainboard and turn it around because it is not connected at all.

The mainboard

A very high detailed picture of the mainboard can be seen here. The central chip is the CPU, below the cpu you can see the SDRAM chip. The wlan card is the plugged in card on the right. Between the ram chip and the wlan is the flash chip containing the firmware. Between the cpu and the wlan card is a connector. This connecter will be either JTAG or a serial connection. You can clearly see the antenna connections running to the output on the back. At the back you can see from the left to the right: an antenna connector, space for an additional power connector, the power connector, the reset button, the usb connector, space for a uart to rs232 chip and space for a male db9 connector, the connectors for the hub and last but not least the second antenna connector. The frontside only shows the connectors for the status LED's. The backside of the mainboard shows nothing interesting. It only contains some SMD capacitors and resitors that are between the cpu and the outside world (the rj 54 connectors and the connection to the wlan card mainly).
image

The CPU

The ADM5120 (Admtek) is a product of Infineon. On their homepage they describe the product as having the following parameters:
Linux-mips.org has an excellent page on this SoC (System on Chip). That page also contains links to the chips datasheets. I have mirrored some of these datasheets locally:

image

Memory

The SDRAM chip has this type: W986432DH-6 which is a 512K words x 4 banks x 32 bits SDRAM (= 8 megabyte 64 megabit) chip produced by Winbond which runs at 166Mhz

Flash

The flash chip is an MX29LV160ABTC-90 which is a 16 megabit/ 2 megabyte flash chip with 90 ns access time. Normally this chip is covered with a label stating the firmware version. But in the image below I removed the label.

image
WLAN

The WLAN is based on Arcadyan's WN4401A mini pci card which is PRISM 54 based.
image

The J1 quest, uart versus JTAG

When you look at the datasheet of the ADM5120 (links: see higher) you will notice the chip has support for:
Many boards on the internet have two connectors on them. On connector leads to a uart which can be used for a serial connection and one connection leads to a JTAG interface which enables you to do hardware debugging. If I ever want to see any other output from the router than the (limited) webinterface I must be able to get some serial connection on the board and have it connected to the serial port of my computer. Since I have no strong background in elektronics I will try to be as clear as possible hoping that somebody else will be able to learn something from this. Everything I will mention in this section is located in the following part of the mainboard:
image
First try to locate the following items on the image:
The top center of this image also shows some missing items (items not soldered onto the board)

What SMC gives us: Firmware

When you go to the SMC site and you enter your partnumber you will see you can download the firmware. Go to the site, click on support, enter your partnumber (located on the back of the box. I've downloaded (and uploaded) the most recent version of this firmware. It hasn't been updated in nine months, so I guess it won't be updated anymore either. So in order to follow the examples in this pages you can download version version 2.08 of the firmware here (the file size is little more than 700 kilobyte).
Now the easiest way to know what we're dealing with:
helios@neurotic:/tmp$ unzip AA\\smc2804wbrp-g-v208.zip 
Archive:  AA\smc2804wbrp-g-v208.zip
  inflating: README-IMPORTANT.txt    
  inflating: SMC2804WBRP-G_RNv2_08.txt  
  inflating: smc2804wbrp-g-v2.08.bin  
helios@neurotic:/tmp$ file smc2804wbrp-g-v2.08.bin 
smc2804wbrp-g-v2.08.bin: Zip archive data, at least v2.0 to extract

The .bin file is the file that gets uploaded to the router (by using the webinterface):
helios@neurotic:/tmp$ file smc2804wbrp-g-v2.08.bin     
smc2804wbrp-g-v2.08.bin: Zip archive data, at least v2.0 to extract
helios@neurotic:/tmp$ unzip smc2804wbrp-g-v2.08.bin 
Archive:  smc2804wbrp-g-v2.08.bin
warning [smc2804wbrp-g-v2.08.bin]:  196608 extra bytes at beginning or within zipfile
  (attempting to process anyway)
  inflating: soho.bin   
   helios@neurotic:/tmp$ file soho.bin 
soho.bin: data

But hey, what are those 196 missing kilobyte ? ... Anyhow, when look at a Hexdump of that file we notice the following padding alike structures in three parts of the file.

0001c130 00 00 00 00 00 00 00 00 00 a4 81 00 00 00 00 70 |.........ц.....p|
0001c140 66 73 2e 69 6d 67 55 54 05 00 03 3a a7 2e 42 55 |fs.imgUT...:Д.BU|
0001c150 78 00 00 50 4b 05 06 00 00 00 00 01 00 01 00 42 |x..PK..........B|
0001c160 00 00 00 11 c1 01 00 00 00 ff ff ff ff ff ff ff |....┴....       |
0001c170 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |                |
*
00028000 00 00 a0 e1 6c f3 9f e5 00 00 00 00 00 00 00 00 |.. рlз.т........|
00028010 00 00 00 00 01 00 00 80 01 00 00 00 4c 4d 38 36 |............LM86|
00028020 02 00 00 80 06 00 00 00 32 2e 35 2e 32 2e 30 00 |........2.5.2.0.|
00028030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|


0002f260 aa ff 50 78 a5 7a 03 00 8f 59 f8 09 80 1a 17 65 |ф PxЦz...YЭ....e|
0002f270 00 da d7 31 84 c6 d0 b8 82 00 c3 29 b0 5a 77 1e |.┌О1.клИ..├)░Zw.|
0002f280 11 7b 02 cb a8 fc 6d d6 2c 05 91 00 00 00 00 00 |.{.╦еЧmо,.......|
0002f290 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |                |
*
0002fff0 ff ff ff ff 00 f8 02 00 78 56 34 12 e6 33 79 bd |    .Э..xV4.Т3yй|
00030000 50 4b 03 04 14 00 00 00 08 00 00 76 69 32 1e 90 |PK.........vi2..|
00030010 7a 61 7e df 08 00 f0 c9 17 00 08 00 15 00 73 6f |za~▀..­╔......so|
00030020 68 6f 2e 62 69 6e 55 54 09 00 03 20 9c 2e 42 00 |ho.binUT... ..B.|


000bdfd0 00 f0 c9 17 00 08 00 0d 00 00 00 00 00 00 00 00 |.­╔.............|
000bdfe0 00 a4 81 00 00 00 00 73 6f 68 6f 2e 62 69 6e 55 |.ц.....soho.binU|
000bdff0 54 05 00 03 20 9c 2e 42 55 78 00 00 50 4b 05 06 |T... ..BUx..PK..|
000be000 00 00 00 00 01 00 01 00 43 00 00 00 b9 df 08 00 |........C...╣▀..|
000be010 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff |..              |
000be020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |                |
*
000bfff0 ff ff ff ff 00 fc 08 00 78 56 34 12 72 6d c4 19 |    .Ч..xV4.rm─.|
000c0000 42 52 4e 57 00 00 00 00 00 00 |BRNW......|
000c000a

helios@neurotic:/tmp$ ls -l smc2804wbrp-g-v2.08.bin 
-rw------- 1 helios helios 786442 2005-03-09 12:17 smc2804wbrp-g-v2.08.bin

So what does this means ? Well the firmware file consists of a file that has a fixed size. And padding happens at the end.
So the two archives are concatted together alongwith some padding and some headers. The first file (second will be called pfs.img and the second one soho.bin. The 0xFF's are padding. The 12 bytes from 0xbfff4 till 0xbffff are probably a CRC checksum, and lat but nog least a signature has been added. In this case {'B', 'R', 'N','W,0 ,0,0,0,0,0}. HRI homepage shows an analysis and hosts a piece of code capable of generating such files. Most things are kept the same with this format but some details have changed. First is the signature which is different (nog very surprising since we're talking about different hardware here). The odd thing is that the middle piece is missing. The piece between 0x28000 and 0x30000. According to HRI the image should take up the first 0x30000 bytes. Judging from the 'signature', 12 bytes prior to the 0x30000 and 0xC0000 the part between 0x28000 and 0x30000 actually seems to belong to the first zipfile (pfs.img). HRI defines the 12 magic bytes as follows:
So now we should be capable in seperating the two files. The first file goes from 0x0 until 0x2f280 (193152). And the second file from 0x30000 (196608) until 0xbe012 (8888258):
helios@neurotic:/tmp$ dd if=smc2804wbrp-g-v2.08.bin of=soho.zip  bs=1 skip=196608
589834+0 records in
589834+0 records out
589834 bytes (590 kB) copied, 1.76819 seconds, 334 kB/s
helios@neurotic:/tmp$ unzip -t soho.zip 
	Archive:  soho.zip
	testing: soho.bin                 OK
No errors detected in compressed data of soho.zip.
helios@neurotic:/tmp$ unzip soho.zip 
Archive:  soho.zip
  inflating: soho.bin     
  helios@neurotic:/tmp$ file soho.bin 
soho.bin: data

Unfortunately things are not as easy for the pfs.img. I tried to seperate the two files both manually at several candidate locations. I tried a Perl oneliner I stole from the internet but everything I tried resulted in a corrupted zipfile. So I tried to look at the file in another tool (I know it's a Windows tool and I'm not proud of it either). I opened the .bin file in winrar which detected pfs.img as archive contents extracting failed but when I tried to repair the archive I ended up with a zipfile from which I could successfully extract pfs.img. But when comparing a hexdump of the head of the firmware file and a hexdump of the repaired archive we can see changes are minimal and only the trailer of the zipfile has changed:

< 0001c110 01 50 4b 01 02 17 03 14 00 00 00 08 00 6b 7c 69 |.PK..........k|i|
< 0001c120 32 91 9d dc 25 d7 c0 01 00 df 1e 09 00 07 00 0d |2..▄%О└..▀......|
< 0001c130 00 00 00 00 00 00 00 00 00 a4 81 00 00 00 00 70 |.........ц.....p|
< 0001c140 66 73 2e 69 6d 67 55 54 05 00 03 3a a7 2e 42 55 |fs.imgUT...:Д.BU|
< 0001c150 78 00 00 50 4b 05 06 00 00 00 00 01 00 01 00 42 |x..PK..........B|
< 0001c160 00 00 00 11 c1 01 00 00 00 ff ff ff ff ff ff ff |....┴....       |
< 0001c170 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |                |


> 0001c110 01 50 4b 01 02 34 e6 14 00 00 00 08 00 6b 7c 69 |.PK..4Т......k|i|
> 0001c120 32 91 9d dc 25 d7 c0 01 00 df 1e 09 00 07 00 15 |2..▄%О└..▀......|
> 0001c130 00 00 00 00 00 00 00 20 00 80 81 00 00 00 00 70 |....... .......p|
> 0001c140 66 73 2e 69 6d 67 55 54 09 00 03 3a a7 2e 42 00 |fs.imgUT...:Д.B.|
> 0001c150 cc 2d 42 55 78 04 00 eb 03 01 02 50 4b 05 06 00 |╠-BUx..в...PK...|
> 0001c160 00 00 00 01 00 01 00 4a 00 00 00 11 c1 01 00 00 |.......J....┴...|
> 0001c170 00 |.|
> 0001c171

Starting from this data I found that fhe following did succeed:
helios@neurotic:/tmp$ dd if=smc2804wbrp-g-v2.08.bin of=pfs.zip bs=1 count=115049 ; unzip -t pfs.zip
115049+0 records in
115049+0 records out
115049 bytes (115 kB) copied, 0.379454 seconds, 303 kB/s
Archive:  pfs.zip
	testing: pfs.img                  OK
No errors detected in compressed data of pfs.zip.

So at this point we were able to extract pfs.img which is a zipfile containing pfs.img (the pseudo filesystem) which takes up the region 0x0 to 0x28000 and soho.bin a zipfile containing the kernel which takes up the region 0x30000 until 0xC0000. Aha, we have located a gap, and the gutfeeling that a third file exists might be correct.
This looks like the only part not begin a zip (I suspect it is the bootload, and I also suspect it contains a zip. I try to extract it with:
helios@neurotic:/tmp$ dd if=smc2804wbrp-g-v2.08.bin of=other bs=1 skip=163840 count=32768
32768+0 records in
32768+0 records out
32768 bytes (33 kB) copied, 0.18911 seconds, 173 kB/s

Anyhow this file looks uncompressed and I suspect it is a bootloader of some kind, hexdump of other contains the following parts that looks interesting:

00000000 00 00 a0 e1 6c f3 9f e5 00 00 00 00 00 00 00 00 |.. рlз.т........|
00000010 00 00 00 00 01 00 00 80 01 00 00 00 4c 4d 38 36 |............LM86|
00000020 02 00 00 80 06 00 00 00 32 2e 35 2e 32 2e 30 00 |........2.5.2.0.|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 04 00 00 80 05 00 00 00 00 00 1a 00 00 03 00 03 |................|
00000050 00 03 00 00 1b 00 01 00 01 00 01 00 01 01 00 80 |................|
00000060 0a 00 00 00 03 00 00 00 00 02 02 00 90 7c 02 00 |.............|..|
00000070 64 04 01 ff 0f 08 fb 00 02 04 0b 16 0c 12 18 24 |d.. ..ч........$|
00000080 30 48 60 6c 00 00 00 00 00 00 00 00 ff 00 00 ff |0H`l........ .. |
00000090 05 00 00 00 af 9b 00 00 00 00 00 00 00 00 00 00 |....»...........|
000000a0 00 00 00 00 00 00 00 00 56 65 72 73 69 6f 6e 20 |........Version |
000000b0 32 2e 35 2e 32 2e 30 20 62 75 69 6c 74 20 6f 6e |2.5.2.0 built on|
000000c0 20 54 68 75 20 4d 61 72 20 34 20 31 36 3a 30 35 | Thu Mar 4 16:05|
000000d0 3a 30 33 20 43 45 54 20 32 30 30 34 20 62 79 20 |:03 CET 2004 by |
000000e0 69 6e 6c 62 75 69 6c 64 40 74 69 78 50 41 43 4b |inlbuild@tixPACK|
000000f0 50 41 43 4b 50 41 43 4b 7c 02 9f e5 00 00 80 e5 |PACKPACK|..т...т|

But now it gets really odd. When searching for inlbuild@tix on google I end up at various sites but the most interesting is this one which has a listing of various PRISM 54 firmware drivers. When we download this files and compare it to the one we extracted:
helios@neurotic:/tmp$ hexdump -C 2.5.2.0.arm > dump.arm
helios@neurotic:/tmp$ hexdump -C other > dump.other
helios@neurotic:/tmp$ diff dump.arm dump.other 
1773,1774c1773,1776
< 00007290  90 72 00 00                                       |.r..|
< 00007294
---
> 00007290  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |                |
> *
> 00007ff0  ff ff ff ff 00 f8 02 00  78 56 34 12 e6 33 79 bd  |    .Э..xV4.Т3yй|
> 00008000

This file is the driver needed for the onboard wlan card. See prism54.org. The chip says ISL 3880IK and this file seems to be a part of the windows driver for that chip.
So these files are perfect matches (You haven't forgetten the magic 0x12345678 header haven't you ?). So at this point let's summarize. We took a good look at the SMC provided firmware and were able to extract three files:

References

Valid XHTML 1.0 Transitional :: Valid CSS :: Powered by Wikka Wakka Wiki 1.1.6.0
Page was generated in 0.1507 seconds