Hiya, I have this old Belkin F5D6230-3 that I've been messing around with, and unfortunately it seems nobody has documented it yet that I can tell.  It's probably for good reason, since it only has 1MB of Flash and 8MB ram from what I've found inside, and the components are very similar and some even identical to the Linksys BEFW11S4, possibly making it a clone.  If this is the case, the Linksys one is unsupported, which means I'm out of luck for an official OpenWRT port.

However, I still want to mess with this thing, just for the challenge itself.  Unfortunately, the only ways I can tell so far to flash it are a JTAG header (3.3v, which apparently means no direct connection to the parallel port), and the uploader in the web interface.  The latter sounds easiest, so that's what I was messing around with.  I even considered flashing the Linksys' firmware onto it to see if it would work, but the web interface firmware images require a header.

So that's what I've been focusing on the last couple days, is how to decypher the header.  It doesn't match the Belkin Extended Header format that I saw for the more modern Belkins.  At least one part of it does though, which is the actual image size.  Using that, I was able to determine that the header is possibly 80 bytes (or at least the header + some other junk), since that's the difference between the size value in the header and the apparent start of ARM code in the firmware file (since I tried decompiling).

Actually, I'm just reiterating a lot of stuff I already typed out elsewhere, if anyone's interested:  http://www.fybertech.com/forums/index.php?topic=799

The image file itself seems to be VxWorks, which I know nothing about.  But it seems to be compressed using zlib from what I can find out.  And scanning the file with find-zlib confirms zlib structures inside.  I tried to find the actual compressed kernel/firmware in the image, but no luck.  It's like a needle in a haystack until I go digging through disassembled code.  And I can only assume the firmware gets launched at 0x0000 in the router, which makes it hard to test in any emulator.  I tried qemu's arm emulator, but it only loads kernels, putting them at like 0x100000.  I'd like to dig through their kernel more to learn more about how this router works, if I could just get it out.

My focus though is currently the CRC in the firmware header.  I think the four bytes following the image size in the header are the CRC, just like in the Belkin Extended Header format.  Yet I've run the image through CRC8/CRC16/CRC32/CRCCCITT (the latter just since it was in the same Perl module), and my Perl script increments the starting byte of the image to do a pass of each CRC type, trying to match it to that possible CRC value from the header, but to no avail.  I also tried switching the byte order of the possible CRC, and even inverting the bits like I saw mentioned for the Extended, but still no match.

So I'm mostly wondering if anyone has any idea what sort of method the CRC might be done in?  Or better yet, does anyone know the older Belkin firmware header structure?  I put a dump of the bytes in the link I mentioned above, if one needs to see it.

EDIT:  I put some photos of the board in the other link now finally.

(Last edited by FyberOptic on 29 Sep 2007, 21:21)

Hey awesome, I was able to get the kernel image uncompressed after all.  I had a Perl script working similar to the CRC search I had been doing, using zlib to attempt decompressing the firmware image, incrementing the starting byte for each pass, etc.  But I was using 'inflate' the whole time, which is why I had no luck.  I used 'uncompress' instead and totally found + extracted it. 

But I still have that overall CRC problem in the firmware image header, so even if I do actually change anything in it, I can't upload it back to the web interface.

(Last edited by FyberOptic on 30 Sep 2007, 09:08)