Firmware Security Research: Dahua Facial Recognition Station

Share This

In the Nozomi Networks security research lab, we work daily with a broad variety of embedded devices. Our objectives differ on a case by case basis, but the most common situations are those in which we study a product to understand its protocols in depth or where we want to assess the security posture of a solution.

To achieve these goals, we often need to analyze firmware images and extract specific binaries which represent the final targets of our analysis. This process begins by obtaining an actual image and it might involve dumping the binary directly from the device hardware.

In this blog, we’re focusing on the next step, where given an input binary, an analyst has to figure out the firmware structure and eventually obtain unencrypted executable code, in addition to the configuration files. 

Though some vendors cite security reasons for actively encrypting firmware, being able to inspect device firmware means being able to understand its attack surface in depth, through the layers of the software stack.
Though some vendors cite security reasons for actively encrypting firmware, being able to inspect device firmware means being able to understand its attack surface in depth, through the layers of the software stack.

The Problem of Firmware Inspection

Many vendors distribute firmware images as they’re produced by the standard build process in place. They typically don’t document details such as the chosen filesystem, or compression algorithms used. However, a researcher with some experience and with the right set of tools can determine these technical details quickly and proceed with the assessment.

In the last few years, we’ve seen a trend of vendors actively obfuscating or encrypting firmware, with the goal of blocking any type of analysis other than a pure black box interaction. In some cases, vendors are even describing these efforts as security driven.

While we understand this line of thought, our experience tells us that for organizations deploying networked devices, the opposite is true. Being able to inspect device firmware allows us to understand its attack surface in depth, through the layers of the software stack.

Since some emerging high-risk vulnerabilities affect components at different layers of the stack, analyzing the software supply chain of an embedded device is critical. This doesn’t mean that the risk wasn’t there to begin with, but rather that the security community is only now fully understanding the magnitude of the problem.

Our intention with this blog is not to single out specific vendors, but rather promote a healthy debate about this problem. To illustrate how we tackle this issue, we selected a popular facial/thermal recognition camera and describe how we can analyze the firmware in detail.

Dahua Face Recognition Access Controller Firmware Decryption

DHI-ASI7213X-T1 is a face recognition access controller which, among other details, can detect the temperature of the person looking into the device. A web management interface is available to configure the access controller. SSH access can be enabled, but to our surprise, the credentials set for the web interface don’t apply to the remote shell. Our understanding is that SSH access is available only to Dahua support, should the need arise.

The Dahua DHI-ASI7213X-T1 Thermal/Face-recognition Access Station

Firmware can be downloaded from the vendor website, but as you unpack the binary with Binwalk, you’ll notice that the process does not proceed as expected. The tool successfully extracts a series of uImage files, but the content of most of these binaries was encrypted with a proprietary scheme. In particular, the kernel and the partition images containing the final executables were not accessible.

Click to enlarge.

From the artifacts previously unpacked, the bootloader stored in file dhboot.bin.img was found not to be encrypted. We then reverse engineered a considerable part of this binary and eventually reached the function responsible for decrypting the kernel.

Click to enlarge.

The Decryption Process

The decryption scheme is based on AES-ECB with a key derived from the SHA256 of a hardcoded key. Since the decryption functions contained some customizations on top of the block cipher and we didn’t want to waste more time reimplementing the whole scheme, we opted for an emulation-based approach and let the original code perform the decryption for us.

Since the addresses to which the bootloader expects to be mapped are compatible with userspace memory layout, we wrote a loader that would take the bootloader binary as the input and map it at the correct address.

Click to enlarge.

We then defined the function pointers for the decryption routine we intended to emulate and set the corresponding address within the mapped executable code. Once the loader was ready, we ran it and decrypted the kernel successfully, as shown in the screenshot below.

Click to enlarge.

We tried the very same procedure with the encrypted files containing the device partitions, but the process was unsuccessful. Since the kernel is executed right after the bootloader, we continued our analysis by reverse engineering the newly decrypted code.

As we determined at the end of the decryption process, the kernel of this device is a Linux-4.9.37 with some customizations. Its sheer size and complexity are such that we had to resort to some heuristics to find the functions in charge of decrypting the remaining images.

We looked for the constants used by AES as a starting point. Once we could clearly define the boundaries of the AES implementation, we looped through all the functions that reference the block cipher algorithm.

We eventually located the same decryption routines that we initially found in the bootloader. The caveat, though, was that the key derivation function was not in proximity of the decryption code. With further analysis, we also identified the key derivation function and realized that the encryption scheme for the partition is identical to the one used for the kernel. What differs is a simple positional parameter.

This finding meant that we could simply tweak our existing decryption tool and use it to decrypt the remaining firmware. We could finally run Binwalk on the decrypted squashfs image and access the firmware partitions statically. With full access to the executable binaries, we could then perform the usual analysis.

Figure 1a: Decompiled function from executable “sonia”
Click to enlarge.

Security by Obscurity is Not a Good Strategy

In this post we presented the problem of extracting and decrypting firmware code, and discussed why, in today’s threat landscape, asset owners need to understand the software stacks that power the devices deployed in their network. We then provided an example of a firmware decryption process that we had to perform, to assess the security posture of a facial recognition access controller.

While the overall encryption scheme used in this product was eventually understood, in general firmware encryption is counterproductive to the security posture of a network and the vendor. We need to assume that an advanced malicious actor will manage to access the firmware of a target device, while asset owners without similar resources and skills are effectively left in the dark.

Network transparency is required for these situations, as it provides the baseline tools to understand what’s happening at a fundamental level. The analysis of firmware images is a complementary approach to network observability, as it allows researchers to further refine their knowledge of a device software stack.


The S3CUREC4M Project: Vulnerability Research in Modern IP Video Surveillance Technologies

Learn how to assess the security posture of an IP video surveillance system, including hardware extraction and firmware analysis techniques.

Let's get started

Discover how easy it is to anticipate, diagnose and respond to cyber threats and process issues before they impact your operations.