Analyzing Web Interfaces of Embedded Devices

By cyberphob1a

Yes, I’m referencing GnuCitizen again. This time their article is about analyzing web interfaces in embedded devices.

I’d like to expand their article a little bit by explaining how to make this a lot easier, by simply extracting the firmware and having a more direct look at their web interface. As an example, I’ll simply use my WLAN router, a Motorola WR850G.

OK, so let’s just say you have the firmware of the embedded device (in this case e.g by downloading it from their website). Once you extract the exe file, you get the firmware itself, which is usually either a .TRX or a .BIN file. For the WR850G it’s WR850_6.1.4.trx (6.1.4 is the version of the firmware). The trx file contains a complete image of the flash ROM on the device, which can normally be easily extracted. Motorola has a custom header of 8 bytes, which we need to get rid of (some googling tells us so). We can use dd for that:

$ dd if=WR850_6.1.4.trx of=WR850G_6.1.4.stripped.trx bs=8 skip=1

A great set of tools is the Firmware Modification Toolkit and if you’re into analyzing firmware, I strongly recommend you download and install it. It supplies a program called extract_firmware.sh, which gets us to the file system contained in the firmware.

$ ./extract_firmware.sh WR850_6.1.4_stripped.trx WR850G/
./extract_firmware.sh v0.50 beta, (c)2006 Jeremy Collake
Checking for updates ...
You have the latest version of this kit.
LINUX system detected. Compatibility ok.
Testing file system of WR850G/ ...
Building tools ...
Build seems successful.
Preparing working directory ...
Removing any previous files ...
Creating directories ...
Extracting firmware ...
Firmware appears extracted correctly!
Now make changes and run build_firmware.sh.

$ l -al WR850G/
drwxr-xr-x  5 root root 4096 2008-02-14 20:49 .
drwxr-xr-x  5 root root 4096 2008-02-14 20:49 ..
drwxr-xr-x  2 root root 4096 2008-02-14 20:49 image_parts
drwxr-xr-x  2 root root 4096 2008-02-14 20:49 installed_packages
drwxr-xr-x 12  root root 4096 2008-02-14 20:49 rootfs

$ cd WR850G/rootfs/
$ l
drwxr-xr-x 12  502  246 4096 2008-02-14 20:49 .
drwxr-xr-x  5 root root 4096 2008-02-14 20:49 ..
drwxrwxr-x  2  502  246 4096 2008-02-14 20:49 bin
drwxrwxr-x  2  502  246 4096 1970-01-01 01:00 dev
drwxrwxr-x  2  502  246 4096 2008-02-14 20:49 etc
drwxr-xr-x  3  502  246 4096 2008-02-14 20:49 lib
drwxrwxr-x  2  502  246 4096 1970-01-01 01:00 mnt
drwxrwxr-x  2  502  246 4096 1970-01-01 01:00 proc
drwxr-xr-x  2  502  246 4096 2008-02-14 20:49 sbin
drwxrwxr-x  2  502  246 4096 1970-01-01 01:00 tmp
drwxrwxr-x  5  502  246 4096 2008-02-14 20:49 usr
lrwxrwxrwx  1  502  246    7 2008-02-14 20:49 var -> tmp/var
drwxr-xr-x  2  502  246 4096 2008-02-14 20:49 www

Here we go, the complete file system of my Motorola WR850G WLAN Router. If you prefer, you can also directly mount the CramFS:

$ cd ../image_parts/
$ l
drwxr-xr-x 2 root root    4096 2008-02-14 20:49 .
drwxr-xr-x 5 root root    4096 2008-02-14 20:49 ..
-rw-r--r-- 1 root root 1036892 2008-02-14 20:49 cramfs-image-x_x
-rw-r--r-- 1 root root  626056 2008-02-14 20:49 segment1

$ mkdir /mnt/router
$ mount -o loop cramfs-image-x_x /mnt/router/
$ l /mnt/router/
drwxrwxr-x 1 502 246 432 1970-01-01 01:00 bin
drwxrwxr-x 1 502 246   0 1970-01-01 01:00 dev
drwxrwxr-x 1 502 246  48 1970-01-01 01:00 etc
drwxr-xr-x 1 502 246  72 1970-01-01 01:00 lib
drwxrwxr-x 1 502 246   0 1970-01-01 01:00 mnt
drwxrwxr-x 1 502 246   0 1970-01-01 01:00 proc
drwxr-xr-x 1 502 246 300 1970-01-01 01:00 sbin
drwxrwxr-x 1 502 246   0 1970-01-01 01:00 tmp
drwxrwxr-x 1 502 246  64 1970-01-01 01:00 usr
lrwxrwxr-x 1 502 246   7 1970-01-01 01:00 var -> tmp/var
drwxr-xr-x 1 502 246 636 1970-01-01 01:00 www
$ cd /mnt/router/www

$ l *.asp
-rw-r--r-- 1 502 246  5961 1970-01-01 01:00 filter.asp
-rw-r--r-- 1 502 246  2856 1970-01-01 01:00 firmware.asp
-rw-r--r-- 1 502 246  4653 1970-01-01 01:00 forward.asp
-rw-r--r-- 1 502 246 20192 1970-01-01 01:00 index.asp
-rw-rw-r-- 1 502 246  3329 1970-01-01 01:00 internal.asp
-rw-r--r-- 1 502 246 12466 1970-01-01 01:00 lan.asp
-rw-r--r-- 1 502 246  1781 1970-01-01 01:00 mp.asp
-rw-r--r-- 1 502 246 22691 1970-01-01 01:00 security.asp
-rw-r--r-- 1 502 246  2050 1970-01-01 01:00 status.asp
-rw-r--r-- 1 502 246 23225 1970-01-01 01:00 wan.asp
-rw-r--r-- 1 502 246 44436 1970-01-01 01:00 wireless.asp
-rw-r--r-- 1 502 246  3625 1970-01-01 01:00 wizard.asp

I’ll not go into analyzing the web interface, but things like URL fuzzing are now no longer required. I probably should add that the main program, that does all the magic (apply.cgi) is a binary and therefor a little bit more work to analyze, but having a binary is better than having nothing at all.

If you’re able to extract other file systems from firmware files, it would be great if you could drop me a comment!

Picture of spider web by MR+G

Tags: , , , , , , , , , , ,

5 Responses to “Analyzing Web Interfaces of Embedded Devices”

  1. tk Says:

    Excellent post! I have seen another tool that does the same thing looking for the “magic numbers” of gzip headers in .BIN files…

  2. A. Williams Says:

    Great post indeed! In the aforementioned example how would you go about analyzing the apply.cgi binary?

    Thanks and keep up the good work!

  3. cyberphob1a Says:

    Hey, thanks for your comment.

    At first, for a superficial analysis, I usually just run a strings command over the binary. This can tell you what parameters are parsed by the binary.

    For a more thorough analysis, you should use a disassembler/debugger like IDA Pro. I know it’s a little pricy (web page currently says USD 515.-), but it’s worth the investment. It can disassemble code for practically all platforms and has great features for reverse engineering. Alternativly, there’s also a freeware version, which is a little bit older. For standard binary analysis it should be enough.

    Also check out some guides on reverse engineering in general.

    HTH. and thanks again for reading!

  4. spenser Says:

    You asked for a comment from others who have extracted firmware filesystems.

    So, here you go :)

    Right now, the main machine is chewing through a piped tar of hda6 on a high end enterprise firewall. The name is not mentioned because they can get a mite testy about “their” software. Even though, it is in fact Redhat 9. The problem is that in the latest series they disabled root console access. Even from the serial port. Now, if someone can physically connect to the serial port, not allowing root access is not going to save you. But, it can be mighty handy for other uses. Furthermore, what admin is happy about being locked out of any box under their care?

    In this case, another linux security expert has written about trying to mount the image under vmware. Ahem, it’s easier than that. Just take out the CF and put it into an old CF usb adapter and load up a finnix cd. Then back it up, map it, and start working. Some very strange scripts in there.

  5. StustixMeete Says:

    Thank you

Leave a Reply