800+ IT
News
als RSS Feed abonnieren📚 MindShaRE: Dealing with encrypted router firmware
💡 Newskategorie: Hacking
🔗 Quelle: thezdi.com
Perhaps you read our multiple previous blog posts on router vulnerability research and decided to give it a try. Great! You downloaded the firmware of your home router from the vender website, threw it in binwalk so that you could just emulate it in QEMU. Then the following screen appeared…
Fig 1. binwalk tosses its hands into the air, shrugs, and reports back nothing.
What now?
In general, each non-binwalk friendly firmware will be an adventure of its own, making it impossible to provide a step-by-step guide for defeating all types of encrypted firmware. This blog aims to go through a few common scenarios and provide a general guide to dealing with this type of firmware. We’ll also provide an example for decrypting the D-Link DIR-882 firmware.
Look back and look around: Three common scenarios of encrypted firmware releases
The simplest method to decrypt the firmware is to look for the decryption routine within the firmware. “How?” you ask. If the router can decrypt the new firmware for updates, the decryption routine must be located in the old firmware image somewhere. If you encounter an encrypted firmware, go to the vendor website and look for archived versions of the firmware, download all old versions and start poking around.
Below are three common firmware release scenarios:
Scenario 1
The device firmware was not encrypted nor did it contain any decryption routine when it was factory released. A decryption routine is shipped along with an unencrypted version of the firmware in a newer version (v1.1) for future encrypted firmware update. Subsequent firmware releases are encrypted.
Figure 2: Firmware release scenario 1
In this scenario, we can obtain the decryption routine from firmware v1.1 and use it to decrypt the latest firmware version 1.2.
Scenario 2
The device firmware is encrypted in the original release. The vendor decided to change the encryption scheme and release an unencrypted transition version v1.2 which contains the new decryption routine.
Figure 3: Firmware release scenario 2
Similar to scenario 1, we can obtain the decryption routine from v1.2 image and apply it to the latest encrypted firmware. Reading the release notes of the firmware releases could be helpful in identifying the unencrypted transition version. The release notes will usually direct the user to upgrade to an intermediate version before upgrading to the latest version. The intermediate version is very likely to be the unencrypted transition firmware.
Scenario 3
The device firmware is encrypted in the original release. However, the vendor decided to change the encryption scheme, and release an unencrypted transition version which contains the new decryption routine.
Figure 4: Firmware release scenario 3
In this case, there is no easy method to obtain the decryption routine. One route is to purchase a device and extract the unencrypted firmware from the hardware directly. Another possible route is to perform more analysis on the firmware in hopes to “break the encryption.”
Scenario 3: Bust out the Hex Editor
Quickly scrolling through the firmware in a hex editor can give us an intuitive sense of what we are dealing within. View it in binary mode; view it in hex mode. Are there fields of 0xFF bytes or 0x00 bytes? Are there patterns within the file? Is it a homogenous blob of random hex bytes? In that case, there is a good chance the firmware has been instead of a simple XOR with a static key. Inspect the histogram, is there a hex byte that appears more often than the others?
Scenario 3: Compressed, Encrypted, or Obfuscated?
Entropy provides important insights into the firmware. A section of the firmware with high entropy suggests encryption. A section of low entropy bytes suggests low-randomness, structures, and predictability. When combined with other analytics, it allows us to determine if compressed, encrypted or obfuscated. The vast number of options of binwalk could become useful in this stage of analysis.
Work in theory, also works in practice
Let’s apply our newfound knowledge to an encrypted D-Link DIR-882 firmware image:
Figure 5: binwalk unable to identify anything in the firmware image
From the vendor’s FTP server, we can find all the old firmware for this router. If we examine the earliest firmware version v1.00B07 with binwalk, it will correctly detect the uImage header, and the LZMA compress data:
Figure 6: binwalk scan results for the early DIR-882 router firmware
This shows that we are in Scenario 1 of firmware release schedule. After going through all available versions of the firmware image, we discover that v1.04B02 of the firmware is the transition version and it is included within the v1.10B02 firmware package. You may also calculate the entropy of the images to quickly determine which one has been encrypted.
Figure 7: binwalk results for the unencrypted transition version and the first encrypted firmware
We then extract the file system from the v1.04B02 firmware with binwalk.
Figure 8: binwalk extracting the root file system for firmware version 1.04B02
After a successful extraction, we can start investigating the firmware update process and determine how the firmware is being decrypted. Luckily, a quick browse of the file system found a promising looking binary named imgdecrypt in the /bin directory.
Figure 9: Directory contents of /bin for the extracted file system.
Just one small problem
We have the small problem of difference in processor architecture between the host and the binary. Luckily, we can perform a cross-architectural chroot with QEMU. To do this, first we copy the qemu-mipsel-static binary to the /usr/bin/ directory of the firmware root file system. We also copy the encrypted firmware to the unencrypted firmware file system. Finally, we chroot into the firmware root and obtain a working shell. Special thanks to the researcher known as chung96vn for showing us this cross-architectural chroot technique.
Figure 10: Using QEMU to perform a cross-architectural chroot and decrypt the firmware
With a working shell, we may run imgdecrypt and decrypt the encrypted firmware.
Figure 11: binwalk successfully detecting different sections of the decrypted firmware
Conclusion
And there you have it! This is how you deal with encrypted firmware. If you encounter scenario 3, don’t panic. Consumer routers are often limited in computing power. This limitation rules out slower, harder-to-crack asymmetrical encryption such as RSA. Also, vendors sometimes use the same encryption scheme for multiple routers. In fact, the imgdecrypt binary can also be used for decrypting the firmware for DIR-878, and DIR-867. Look for routers that are in the same product line, with same processor architecture. Look around there and you might just hit jack pot. In any case, I wish you luck in your hardware hacking endeavors and look forward to seeing your submission!
You can find me on Twitter @TrendyTofu, and follow the team for the latest in exploit techniques and security patches.
References and further reading
https://wzt.ac.cn/2019/09/18/D-Link_BUG/
https://www.itcodemonkey.com/article/13631.html
...