[Leland Flynn] did a great job of picking apart the firmware image for a Westell 9100EM FiOS router. Unfortunately he didn’t actually find the information he was looking for. But he’s not quite done poking around yet either. If you have never tried to make sense of an embedded Linux firmware image this serves as a great beginner’s example of how it’s done.
He was turned on to the project after port scanning his external IP and finding a random login prompt which he certainly didn’t set up. Some searching led him to believe this is some kind of back door for Verizon to push automatic firmware updates to his router. He figured why not see if he could yank the credentials and poke around inside of the machine?
He started by downloading the latest firmware upgrade. Running ‘hexdump’ and ‘strings’ gives him confirmation that the image is based on Linux. He’s then able to pick apart the package, getting at just the filesystem portion. His persistence takes him through extracting and decompressing three different filesystems. Even though he now has access to all of those files, broken symlinks meant a dead-end on his login search.
18 thoughts on “Dissecting A Firmware Image”
Awesome! hopefully a good WRT firmware will be developed for this. the wireless compatibility with some devices is horrible and will crash this router. it has to be power cycled to get the LAN going again. i think there’s a mini-pci card in there that should be tinkered with and possibly gain the ability to replace it.
The source for that router’s firmware is open source :)
I would assume only the non-vender source version. I’d be surprised if it included the verizon changes
When I had FiOS, one of the CDs that came with the router had the source code on it. I doubt the Verizon specific services are there, but it never hurts to look.
He needs to follow the boot process. Broken links are often files that are created / loaded from nvram etc at boot.
Also once you get on x86, vendors use stuff like the award VS 2010 framework to do ROMs and use custom packers and boot-block decryption routines; I’ve seen mobo BIOS images you had to actually brute even if you dump from shadow..
It is a bit more likely that the login credentials for that prompt would be stored on non-volatile memory or a section of flash that is reserved for parameters.
even thought the site works fine without it
Indeed, it’s the kind of thing that actually makes you committed to not enabling it.
indeed, just fire up firebug and chear the entire section.
ontopic: really nice writeup. there are some other articles that are worth reading there too.
offtopic: why doesn’t HaD have a option to edit the comments when my sessionid and ip are the same?
The “open source” web page clearly states “This product was specifically designed for Verizon and all support for this product is handled directly by Verizon.” so the source on that page SHOULD match the Verizon router.
Almost identical to http://www.devttys0.com/2011/05/reverse-engineering-firmware-linksys-wag120n/ posted here: http://hackaday.com/2011/05/30/reverse-engineering-embedded-device-firmware/
If you can find the passwd or shadow file, don’t bother trying to decrypt the password. Just replace the password hash with something that you DO know. This has a nice advantage that you can close the backdoor also. :-) If the firmware has some sort of CRC check or it’s signed then you might have trouble flashing it though.
Q: Why do we ‘Reverse Engineer” a Firmware/NVRAM Dump?
A: We’re HACKERS!
“binwalk” (http://code.google.com/p/binwalk/) from/dev/ttyS0 (http://www.devttys0.com) is really useful for this kind of work.
yes, that’s what he uses. did you even read the blog?
actually some replies on his site helped out and now he has the login credentials.
So no dead end on his login-search.
Please be kind and respectful to help make the comments section excellent. (Comment Policy)