Security analysis of the device firmware is a very crucial part of IoT Security Auditing. Obtaining firmware is amongst the many challenges of the analysis and there are tons of techniques by which you can do that. Once you have the firmware you dissect it for more extensive analysis. But the easiest method of acquiring the firmware of the device is to download it from vendor update server(usually FTP server) where they store the different version of the firmware and the technique to get the next version is coded in the firmware. To defend against this, vendors have started storing the firmware in encrypted form on the server so even if you acquire the firmware you still need to decrypt it before doing any further analysis.
In this post I will walk you through a detailed analysis of firmware decryption of DLINK router DIR-822 US variant, we will use the techniques presented in that ZDI blog and look into the details of how the decryption is handled by the device and reverse engineer the decryption algorithm. So, let get started.
In this section, I will summarize the ZDI post for those of you who are lazy enough to not read, and but if you have read it you can skip this section.
Lets, consider a situation where you have the version of the firmware which is encrypted and the algorithm to decrypt the update firmware is in the device firmware. When you upload the firmware it decrypts and it starts the normal update process. But let’s say that this decryption routine was not part of firmware initial factory release and at some later point in time vendor thought of introducing this security mechanism so they coded the new encrypt/decrypt API into the new firmware version. This version can be called as a transition version. Since the transition version is unencrypted we can reverse engineer the decryption algorithm and decrypt the firmware manually. This is precisely what we are going to do in this post.
Binary diffing is the technique where you take two binaries of different version of the same software and use diffing tool to understand the new functionality introduced in the new version of the program. We will use kdiff3 for file-system diffing between transition version and the version before it because in the transition version will have the encryption/decryption routine and the previous version won’t.
If in some case firmware protection was not mentioned in the release notes you could use the method of entropy calculation to find if the firmware is encrypted or not. In simple terms, entropy is a measure of randomness, it has a value between 0 and 1, higher the value indicates more randomness. A value near one is considered to be high entropy and vice-versa. The data which is compressed or encrypted has high entropy value.
Entropy distribution of the binary image will give us the entropy value of incremental offset of the binary file. This information will help up to guess which part of binary is encrypted/compressed and which is code. Lets look at entropy distribution of two different the binary version, a transition encrypted FW303WWb04_i4sa_middle and encrypted version 3.15B02. Let’s see how are they different from each other.
If you have noticed the difference in the graph, Figure B has a nearly constant entropy of above 0.9 which means it is highly likely that it’s encrypted throughout different parts of the firmware. In figure C initial section has low entropy then it is constantly high and then it drops again and rises again this fluctuation suggest that it a mix of code and encrypted/compressed data.
You will often see this pattern for unencrypted firmware which has fluctuating entropy initially and high entropy data in the later section. This could mean that there is code in the initial section of the binary which dynamically decompresses the code(from the later section) during device boots up.
NOTE: Encryption and Compression are both blamed equally here for high entropy as there is no exact way of telling which one of them is responsible for randomness based on entropy value.
Next, we should try to figure out what changes have been made in the new release and try to reverse the algorithm.
Now that we know the transition version, lets to figure out what changes were introduced in the new version by doing file system diffing between the versions 3.02B05 and FW303WWb04_i4sa_middle. We will use kdiff3 for this purpose. We should be looking for an update in file names which has keywords like “firmware”, “update”, “upgrade”, “download” or combination of these keywords.
Durning the file-diff search you will can across many interesting files related to firmware update functionality but the meat of the matter was residing in file /etc/templates/hnap/StartFirmwareDownload.php on line 111 you will come across the following snippet of code.
// fw encimg
setattr(“/runtime/tmpdevdata/image_sign” ,”get”,”cat /etc/config/image_sign”);
$image_sign = query(“/runtime/tmpdevdata/image_sign”);
fwrite(“a”, $ShellPath, “encimg -d -i “.$fw_path.” -s “.$image_sign.” > /dev/console \n”);
del(“/runtime/tmpdevdata”);
From the above code we can deduce that binary called encimg is executed with command encimg -d -i <fw_path> -s <image_sign>. Next, I search for the location of encimg binary in the file system, it was located on path /usr/sbin/encimg other unknown variables are fw_path which I am assuming to be firmware path and another variable is image_sign we can trace back the value of this variable been read from /etc/config/image_sign and there is one more parameter -d which is not clear.
Let’s do some dynamic analysis to further decipher this command. Running a simple file command revealed that it is an ELF 32-bit MIPS MSB executable. We can now use qemu user-space emulator for MIPS architecture to run this binary. Go to the squashfs-root directory of the firmware and run the following command.
$ qemu-mips -L <rooth path of file system> ./usr/sbin/encimg
Note: in the above command we provide -L parameter to qemu-mips which specify the path of the root directory to use to load the dependencies. Another method often used is Linux chroot.
From the above help usage message, it is clear that this is the binary used to decrypt the firmware, -s parameter is called signature but I think it is used to take decryption key as a parameter which is read from file /etc/config/image_sign. The file contained string value _wrgac43s_dlink.2015dir822c1, I assume it is the decryption key. Another parameter is -i which is the input file which will be the new received encrypted firmware file. Now let’s try to decrypt the firmware using qemu emulator.
qemu-mips -L . ./usr/sbin/encimg -d -i <path to encrypted firmware> -s wrgac43s_dlink.2015_dir822c1
Qemu user-space emulator also has another interesting and very important functionality from reversing stand-point called strace which does system-call logging made by the binary. You can enable it by providing -starce parameter to qemu it will print all the system call made by the binary, I tried it on the above binary and picked up some interesting logs as shown below.
# Aahh…. a crypto library been loaded by the binary, it
# hints that it is using some sort of encryption algorithm possiblity AES
# or some symentic encryption algorithm as we have seen there already
# a password we provide to the binary.
open(“/lib/libcrypto.so.0.9.8”, O_RDONLY) = 3
...
...
...
# opening the file (return fd 3)
open(“/home/payatu/test_1.bin”, O_RDWR) = 3
stat(“/home/payatu/test_1.bin”, 0x7fffea90) = 0
write(1,0x7f689298,99)The file length of /project/dlink/AC1200/test_1.bin is 6865072
= 99
read(3,0x7fffeb50,4) = 4
# mmap fd 3
mmap(NULL,6865072,PROT_WRITE,MAP_SHARED,3,0) = 0x7ef51000
munmap(0x7ef51000,6865072) = 0
# again truncate operation on fd 3
ftruncate(3,6865044,0,0,0,0) = 0
# good bye fd 3
close(3) = 0
You can load encimg binary in your favourite disassembler/decompiler tool to do more in-depth analysis. Wandering around the function section I stumbled upon an interesting function main(0x401244), this method parses the parameter and then calls build(0x400d24) which has all the core functionality of encryption/decryption. Also, there were come crypto relate import done by the binary, some of these functions are _AES_set_encryptkey, _AES_set_decryptkey and _AES_cbcencrypt this confirms that binary is using the AES encryption algorithm which means the same key for encrypting and decrypting the files. Doing some basic research you can manage to understand the function prototype. Here is a short description of those function.
// Same prototype for AES_set_encrypt_key
AES_set_decrypt_key (
// user input key
const unsigned char *userKey,
// size of key
const int bits,
// encryption key struct which will be used
by
// encryption function
AES_KEY *key
)
AES_cbc_encrypt (
// input buffer
const unsigned char *in,
// output buffer
unsigned char *out,
// buffer length
size_t length,
// key struct return by previous function
const AES_KEY *key,
// initializatin vector
unsigned char *ivec,
// is encryption or decryption
const int enc
)
Let’s look at the decompilation code of the build function.
From the above code, we can say that binary file is mapped into memory with mmap function. It then setups AES_KEY data struct by either calling AES_set_encrypt_key/AES_set_decrypt_key based on parameter and uses that struct to encrypt/decrypt the payload using AES_cbc_encrypt then it writes the data back to the file using munmap function call. Nothing fancy!
Once we have decrypted the firmware. Lets again have look at the entropy of the decrypted firmware.
It looks very similar to the unencrypted firmware which we saw earlier.
Note: I have not tested the above-mentioned attacks, dude to the limitation of time and scope of the project. but this some I would be looking for if I were an attacker.
Doing analysis using ten different tools can be time-consuming and error-prone, reflecting on our daily workflow we have created a tool to automate lots of chores for firmware analysis and the product is called Firmware Auditor and the community edition is free for anyone to use. As you have already seen I use Firmware Auditor for most of the analysis which we did above. you can find more details features about this product on this link and send us your feedback on the same. Firmware Auditor can be used for:
We saw different methods to find if the firmware is encrypted or not and saw how we can use the method of firmware diffing to find the decryption method be used and how it is used and replicated that method another firmware. We also discussed some of the attack surfaces which decryption methods open up. One needs to be aware of this when using such protection schemes.