Projects and Development > Hardware Dorkery
Belkin F5D6230-3 Router
FyberOptic:
I have this old Belkin F5D6230-3 router laying here, and decided it might be worth mucking around with. I don't think I'd ever be able to put DD-WRT or OpenWRT on it, but it seems like it might be viable for just my own tinkering. And who knows, I might get something worthwhile out of it one day! The firmware that's in it is pretty much garbage from what I can tell, and we've never used this router in an actual network for more than like a day because of such. So anyhoo, I figured I'd just make a topic here and post the info I have as I get it, for anyone else that might stumble onto this one day that might find it useful.
From what I've deduced, it's very very similar to the Linksys BEFW11S4. Most of the parts are the same or similar, the boards are just different. But the BEFW11S4 is labeled as not being compatible with OpenWRT, which leaves me to believe the Belkin here never would be either, since they're so similar.
In the OpenWRT hardware compatibility list, the D-Link DI-614+ also sounds like it might have similar hardware, but I haven't looked into it much yet.
Here's some of the components from the Belkin that I've looked up:
S3C4510B01-QER0 = ARM7 cpu (and a 50mhz oscillator nearby)
EM638325TS-6 = 8MB SDRAM
TE28F800 = 1MB Flash (probably explains the biggest reason OpenWRT isn't supported)
88E6050-RJJ = 10/100 Ethernet Switch With Internal RAM
LF8731 = 10 BASE-T/100 BAST-TX Transformer Module
RTL8019AS = 10Mbit Full Duplex Ethernet controller with SRAM
91.EP213.002 217CP10746 - Unknown brand PCMCIA wifi card (802.11B) with dual-antennas hard-wired
If you check out this site (translated from French), you can see what I meant about many of the components being the same or similar with the BEFW11S4. I'll take some pictures of the pcb in the Belkin soon.
The Belkin has a couple of headers, one of which actually has the header pins installed. I believe this one is a serial port, but they lead to a place on the board where no chip is installed (likely a level converter, since the S3C4510B has built-in UARTS). Yet oddly, the other header is lacking the pins, and is very clearly a JTAG connector. There's even a couple of locations down along the bottom of the board where apparently a parallel connector and serial connector can be mounted on the board, and some spots where other chips aren't installed, so maybe they had a few different models using the same board with various features. I'll have to look into it more.
Anyhoo, the JTAG appears to be the standard 14-pin ARM pinout:
1 - Vddh (+3.3v)2 - Vss (ground)3 - nTRST4 - Vss (ground)5 - TDI6 - Vss (ground)7 - TMS8 - Vss (ground)9 - TCK10 - Vss (ground)11 - TDO12 - nRESET (optional)13 - Vddh (+3.3v)14 - Vss (ground)
I tested the voltage of the Vddh's and they are in fact 3.3v. And all the grounds are definately ground, since it can be confirmed visually right away (which is what made me suspect JTAG in the first place). Though due to the voltage, I figure this means one needs some kind of buffered JTAG cable in order to talk to it with a parallel port, unfortunately.
I think the OS is VxWorks, because there's a Wind River Systems copyright string in the firmware for this model (that you can get from Belkin's site). The firmware image itself must be compressed, because there aren't really many other strings to be found in it. There also appears to be a header at the top of some sort (preventing you from uploading other firmwares via the web interface), but it's not the same as the Belkin Extended Header Format (see this white paper for info on that). It's somewhat similar though, at least in a couple spots, it seems. The first four bytes are some unknown stuff, but the next four seem to be the size of the image itself (least-significant byte first). If we follow the extended format, the next four are the CRC. Following that is the zero-terminated string "WirelessBelkin" (which differs from the extended format's structure).
Now how large the header actually is, I don't know. Possibly 27 bytes, like the extended one. From looking at the bytes in the file, this is quite possibly true, since following that string is a series of bytes with the value 0xCC. As for the size of the image found earlier in the header, if we assume the image starts at 0x1B, then that leaves us some extra bytes at the end. In the extended format, this is for an NVRAM section. But I couldn't find anything even close to resembling the NVRAM header, so I really don't know at this point what's what. It doesn't help that it's compressed. I saw someone mention somewhere that one particular firmware was in ARJ, but I don't even remember what that was for. But at least it's a start, perhaps.
I tried using a TFTP client to put a firmware update on it, but nothing happens, so I figure that method is out. We're likely stuck with either the updater in the web interface, or the JTAG connector.
I think that's about all I know for the time being!
Altzan:
Holy cow, I didn't understand half of that.
FyberOptic:
--- Quote from: Altzan on September 28, 2007, 07:22:36 am ---Holy cow, I didn't understand half of that.
--- End quote ---
It's okay, I made it all up.
Here's more:
The header doesn't seem to be 27 bytes after all. Or if it is, there's something else after it. After disassembling a bunch of the code, it seems it actually starts at 0x50 (80 decimal). This is also confirmed by the fact that in the firmware image I have, which is 708384 bytes large, the bytes from 0x0004-0x0007 in the header (the image size value) equals 708304. The difference between those sizes of course being 80, which cooberates my assumption that the actual image starts after the first 80 bytes.
Actually, here's the header, which I prolly shoulda pasted in the first post:
--- Code: ---00000000h: 02 00 00 00 D0 CE 0A 00 7F 5E B1 05 57 69 72 65 ; ....ÐÎ..^±.Wire
00000010h: 6C 65 73 73 42 65 6C 6B 69 6E 00 CC CC CC CC CC ; lessBelkin.ÌÌÌÌÌ
00000020h: CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC ; ÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌ
00000030h: CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC ; ÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌ
00000040h: CC CC CC CC CC CC CC CC CC CC CC CC EC 2F 00 00 ; ÌÌÌÌÌÌÌÌÌÌÌÌì/..
--- End code ---
As for that ARJ compression thing I mentioned, that's probably totally wrong. More poking on the web reveals that VxWorks likely uses zlib. I scanned the binary for the normal gzip header, and tried truncating the file at each of these locations to see if it'd open, but nope. I then found out that gzip and zlib formats are a bit different: zlib doesn't use the same header, it uses only two bytes, which are dynamic, making it much harder to just scan a file for the start of a compressed area. zlib "archives" also end in an Adler-32 checksum. Here's the zlib RFC for reference.
FyberOptic:
I wrote a Perl script trying to see if I could match the assumed CRC value in the header (bytes 8-11) to the image data below, but nothing so far. I tried incrementing the start position in the firmware (even starting at byte 0 just in case), each time running it all through CRC8/CRC16/CRC32/CRCCCITT, but nothing matched. I tried reversing the byte order of the possible CRC, and even inverting the bits like the Belkin Extended Header format suggests. But nope. So I'm currently at a loss on that.
I did figure out for sure that the actual image contains zlib compression structures, from the find-zlib script I found on the internet. I was already pretty sure anyway from what I read about VxWorks, and also from some of the strings in the data. But finding the compressed kernel inside the image is another story. Since they're using a modified zlib, they might not even put an adler32 or any crc-like verifications at the end of the compressed kernel image, meaning I might never know if I got it out unless I just happened to notice strings in the result. So at this point I have no idea how to get the compressed kernel out short of disassembling all the ARM code in the firmware that inflates it at router startup. But the problem there is that I don't know where this code begins executing. There might be some form of boot loader in the router that offsets where this firmware sits. Who knows.
EDIT: Here's images of it, but they didn't come out very good. Probably because I was trying to block the flash again to keep it from blinding them, since my camera won't let me turn flash off without doing slow exposure. Click for larger.
EDIT2:
Here's some better close-ups. You can actually read the components on these:
http://www.fybertech.net/images/belkin/belkin_F5D6230-3_close1.jpg
http://www.fybertech.net/images/belkin/belkin_F5D6230-3_close2.jpg
http://www.fybertech.net/images/belkin/belkin_F5D6230-3_close3.jpg
FyberOptic:
I totally extracted the VxWorks kernel + whatever else was with it from the firmware image. I had a Perl script which worked very much like the CRC search one, incrementing the starting position in the firmware image and attempting to decompress from there, repeating this over and over. But for the longest time I had no luck, but that was due to me using zlib's "inflate" function, when I really needed to be using "uncompress". The latter is more of a raw method, where as the former had some extra header bytes and stuff to identify what it was more.
But yeah, I extracted it and started disassembling the kernel. There's lots of strings and text and such in it, including all the HTML pages for the web interface. Though I dunno if a lot of this is hard-compiled right in with the kernel, or if there's some form of filesystem in play. But maybe poking around in this firmware will help figure out some stuff about the hardware.
Next I want to make a JTAG interface to my parallel port in order to download the memory contents, to get a better idea of the structure. Hell, I still don't know where the ROM is located, since the ram is apparently at 0x1000, because that's where the firmware uncompresses to and runs the kernel from. A JTAG interface would also let me update the flash chip without needing the web interface uploader (in other words, I'd never have to figure that CRC stuff out from the firmware image header). It also allows for some debugging aspects, but I dunno if I'd ever use those.
Anyway I'd write more about what I found out about making the JTAG cable, but my hand hurts so maybe next time!
Navigation
[0] Message Index
[#] Next page
Go to full version