Hardware hacking tutorial: Reversing and emulating firmware

September 1, 2017
reversing hardware hacking infosec embedded

The idea

In a previous tutorial, we’ve talked about how embedded devices can have vulnerabilities inside, and one way to detect them, and to protect yourself from them, is to check them out by yourself.

This will be focusing on the same idea, just without dumping the firmware yourself. Perhaps it is a new firmware update you want to flash to your device, and you have the file on your PC.

The procedure will be pretty much the same, but only this time, instead of dumping the firmware on or own, online available firmware will be used, that a series of D-Link routers use, from DIR-300s to DIR-600s. It will be extracted using Binwalk, in order to find vulnerable parts of the web administration system, and to emulate the firmware on a virtual machine, since testing out possible found exploits against real routers would be illegal

Used tools

Firmware analysis software: Firmadyne, FMK, Binwalk, FAT

During the firmware reverse engineering part of this tutorial a number of software available will be used for emulation, analysis and debugging of firmware.


Firmadyne was created by a group of researchers from the Carnegie Mellon University and Boston University, led by Daming D. Chen. According to them:

FIRMADYNE is an automated and scalable system for performing emulation and dynamic analysis of Linux-based embedded firmware.(D. Chen, n.d..)1

In their paper Towards Automated Dynamic Analysis for Linux-based Embedded Firmware published on the Network and Distributed System Security Symposium (NDSS), they say they’ve tested the system on over 23 thousand firmware images, being able to extract under 10 thousand of them and show on a control set of 1971 images that over 43% of them were vulnerable to at least one exploit. (D. Chen et al., 2016.) 2


The Firmware-Mod-Kit (FMK) was created by Craig Heffner (/dev/ttyS0) and Jeremy Collake. According to its Wiki:

The Firmware Mod Kit allows for easy deconstruction and reconstruction of firmware images for various embedded devices.(FMK Wiki, n.d..) 3


Binwalk is another tool made by Craig Heffner (/dev/ttyS0), and according to him:

Binwalk is a fast, easy to use tool for analysing, reverse engineering, and extracting firmware images.

Firmware Analysis Toolkit

The Firmware Analysis Toolkit (FAT) combines Firmadyne, FMK, Binwalk and a couple of more systems and toolkits to automatize the process of firmware emulation. It was made by Attify for their training course “Offensive IoT Exploitation”.

According to Atiffy:

FAT is a toolkit built in order to help security researchers analyse and identify vulnerabilities in IoT and embedded device firmware.(Attify Github, 2017.) 4

The attack

Emulating the firmware

 Firmadyne and FAT firmware emulation

The firmware emulation process is pretty straightforward using Firmadyne and the Firmware Analysis Toolkit. A Python script is run that asks for the path to the firmware that needs to be emulated, and then takes care of the rest.

Unpacking the firmware

Binwalk extracting D-Link firmware

The procedure is same as before, the -e flag is used to extract the given binary file. As seen above, there isn’t anything immediately obvious that could be of interest, like the case was with the Mikrotik firmware that was dumped, so it’s necessary to take a look around for possible vulnerabilities. It can, however, be seen that the router is running a custom Linux OS and that there is a Squashfs filesystem, that Binwalk should have unpacked.

The filesystem should be accessible just like any Linux OS filesystem by opening the folder Binwalk created and navigating to the squashfs-root folder.

Squashfs root filesystem of the router

Looks like Binwalk managed to unpack the firmware without any problems, and the root directory of the filesystem can be accessed. The question is, what is the best place to start with, since it is a relatively large number of files to search through.

Perhaps it’s best to start by looking for the obvious, using grep. The obvious being substring occurrences such as ‘private key’ or ‘telnet’ or ‘admin’ or anything related to security, authentication. The files that contain a match should be made a priority to look through. Very often, vulnerabilities and hidden embedded secrets will be found this way.

 "grep -iRn 'telnet' . " results

Grep has revealed something peculiar. System.sh, the script which runs on system start up starts a telnet daemon using a script file found in the /misc/ folder. It starts the telnet daemon using the telnetd command, using the -l flag to execute login on an incoming telnet connection, the -u flag to specify the username and password in the format ‘username:password’, -i to run as a inetd service.

The interesting part is the username and password one, since it would be nice to have a telnet username and password for a telnet daemon that starts up automatically by default on a whole series of routers.

Contents of the telnetd.sh script

Opening the telnet daemon start up script, it’s easy to see that the script uses a variable called image_sign as the password for the telnet login. The content of the variable is acquired by reading the contents of the file image_sign, stored in the /etc/config/ folder, which is presumably unique to the current version of the image, the firmware.

 Obtaining the password using cat

The password is obviously not random, it’s rather made using the version of the router that runs the software, in this case the DIR-300 router, version B.

That means that not only this router is vulnerable to the attack, but for an example, a DIR-600, version C router should be possible to access by just changing the last part of the password to dir300c.

But, it’s enough that even the DIR-300 series is accessible using the found username and password (Alphanetworks:wrgn23_dlwbr_dir300b).

Since a similar exploit was found on the last router, the Mikrotik one, this isn’t that interesting. Sure, it’s fine finding some hardcoded OpenSSH keys or default telnet login credentials, but there other vulnerabilities out there. Since access to the web application used to manage the router is possible, it can be analysed to see if there are any more vulnerabilities lurking around.

 Contents of the www folder

As expected, there is a lot of files to go through for the web application. The first usual step taken is to check if some files are accessible without logging into the router.

One such file that may seem of interest is DevInfo.php, which returns miscellaneous information about the device, but shouldn’t be accessible to the public nonetheless.

 DevInfo.php results in a browser

Sure enough, it is accessible without actual authorization, but the information it provides is not of much consequence. But if one script is accessible to the public without proper authorization, there might be more, and some of them might be not so harmless.

There is no easy way of determining this, so the best approach is to try and identify some possible targets by their name, and briefly look through them. Soon enough, the model folder is found, which contains a file called __show_info.php.

Contents of the __show_info.php script

The interesting part of the script, which isn’t that obvious on the first sight (hence the red rectangle), is that it checks if there is a GET parameter called REQUIRE_FILE sent to the script. If it is not empty, the script will proceed to get the contents of the file, using the PHP require function starting at the root of the filesystem.

The require function is similar to the include function, found in many languages. Bluntly speaking, it just appends the contents of the ‘required’ file to the position where the function is called.

If the script works as said, what is stopping someone from just requiring the file in which the username and password for the system are stored? Since the PHP script is run by the server, the system, permissions shouldn’t be a problem.

Getting the httpasswd file using the show_info script

Requesting the contents of the file /var/etc/httpasswd, in which the username and password for the web application are stored, the result is actually successful.

It’s not even hashed using any crypto algorithm, it’s returned back in plain text.

Just to prove that this doesn’t only work for the default username and password, let’s go ahead and change the password to: “PlaintextVerySecure” and try it again.

Checking for the changed password

Unfortunately for all the D-Link users out there, it works. After logging into the admin panel of the web application, a malicious attacker can virtually do anything he wants.

From opening a telnet backdoor to MITM attacks. Speaking of D-Link users, it is possible to see how many of them are running this particular vulnerable version of the firmware and the http server (Mathopd/1.5p6) using Shodan.

Vulnerable D-Link routers on Shodan

At the time of writing, there were 14,871 vulnerable routers out there to this attack, and most, if not all can be accessed using the Shodan provided ip addresses.

  1. Dominic Chen, Carnegie Mellon University on Github. (n.d.). Firmadyne FAQ. Retrieved August 22, 2017, from: https://github.com/firmadyne/firmadyne [return]
  2. Daming D. Chen, Manuel Egele, Maverick Woo, David Brumely, Carnegie Mellon University and the Boston University. (2016). Towards Automated Dynamic Analysis for Linux-based Embedded Firmware. Retrieved August 22, 2017, from: https://github.com/firmadyne/firmadyne/blob/master/paper/paper.pdf [return]
  3. Firmware Mod Kit, Google Code. (n.d.). Firmware Mod Kit – Documentation. Retrieved August 22, 2017, from: https://code.google.com/archive/p/firmware-modkit/wikis/Documentation.wiki [return]
  4. Aditya Gupta, Attify on Github. (2017). Firmware Analysis Toolkit. Retrieved August 22, 2017, from: https://github.com/attify/firmware-analysis-toolkit [return]

Tempest attacks using a DVB-T stick

February 6, 2018
sdr infosec tut tempest

Hardware hacking tutorial: Dumping and reversing firmware

September 1, 2017
reversing hardware hacking infosec embedded

Hardware hacking tutorial: Interfacing with debug ports

August 31, 2017
reversing hardware hacking infosec embedded
comments powered by Disqus