How to hack your firmware – this might seem like a complex topic. In some cases it is, but nowadays, this is not always the case.
Some unix skills and just a bit of social engineering might be enough to make your company or home insecure.
There are several ways through which a company or a person might have received a compromised device:
- A company receives a demo hardware from the company in the mail, why not trying it?
- The guy in the shop decided he wants to monitor his customers, how about quickly removing the seal and compromise the firmware?
- The website sending firmware updates has been compromised (either from your side, for example through dns poisoning) or on their page
- The firmware was downloaded from a strange internet source
There might be a few reasons more, but let’s get hands on and see how easy firmware hacking could be!I am trying this on my Arduino Yun, as it is using OpenWRT + squashfs. Squashfs is nowadays very used (see for example dd-wrt compatible devices).What we need is:
- The firmware (in our case the Yun firmware is openwrt-ar71xx-generic-yun-16M-squashfs-sysupgrade.bin)
- A Linux box. For this blog entry I will use Debian, but I guess the same will work under ubuntu and other debian based distros
It is worth noting at this point that I fully support Arduino’s choice of using an open solution such as OpenWRT, and squashfs is not the problem. Hacking firmwares is still possible even using proprietary formats, as long as the source of the firmware (or person handling the device before you) is not trusted.
Let’s first install the right tools. As root, run:
aptitude install squashfs-tools
The tools we need: unsquashfs and mksquashfs.Now, let’s get some information on the file:
unsquashfs -s openwrt-ar71xx-generic-yun-16M-squashfs-sysupgrade.bin
This should give an output such as below:
Found a valid SQUASHFS 4:0 superblock on openwrt-ar71xx-generic-yun-16M-squashfs-sysupgrade.bin.
Creation or last append time Sun Nov 9 01:25:00 2014
Filesystem size 7799.69 Kbytes (7.62 Mbytes)
Block size 131072
Filesystem is exportable via NFS
Inodes are compressed
Data is compressed
Fragments are compressed
Always_use_fragments option is not specified
Xattrs are compressed
Duplicates are removed
Number of fragments 130
Number of inodes 2083
Number of ids 1
In particular “Compression xz” will be useful to us when rebuilding the package.
Let’s now decompress the filesystem in a working directory:
A new directory should now be present: squashfs-root. It will contain all the files of the router. The purpose of this article is of course only to demonstrate how we could compromise a firmware so will only create a simple example. Let’s create something that, at boot, will write under /tmp a file
First we go in /etc/init.d and create the script, which we will call “hackTest”.
The file will contain:
echo “This might be a virus :)” > /tmp/virusTest
Let’s make it executable now
chmod +x hackTest
…And link it to the correct start sequence in /etc/rc.d. In my case, I decided to set it to S94:
ln -s ../init.d/hackTest S94hackTest
Now all is good to go – let’s pack our squashfs. Go back to the folder containing squashfs-root and create the new firmware:
mksquashfs squashfs-root openwrt-ar71xx-generic-yun-16M-squashfs-sysupgrade.bin -comp xz
Note “-comp xz”, this is the compression that was specified on the file info above.
All is now ready. Update the Arduino, wait for the reboot.
Now, I understand that someone might think: isn’t it easier to just modify the system once booted up?
Well, this is true but on a factory reset things will go back to normal. Also, most of those devices provide a limited set of read/write directories, so searching for issues if someone gets suspicious is a lot easier.
So what is the solution?
Well, make sure once the firmware is downloaded that the MD5 is correct using a different source to get the md5 strings (for example, your desktop). If your firmware was however modified, chances are it will not upload the firmware or might automatically modify the firmware during the install. This is quite a difficult matter to resolve, and if we are ever going to go back to a mainframe architecture in the future (i.e. Chromebook) this will become an ever bigger issue, and making the firmware proprietary is not the solution (see the various iOS hacks).