Custom fabrication. Reversing D-Link router firmware

This router is equipped with 8 MB of flash memory and 64 MB RAM. Its core is the MediaTek MT7620A chip. This chip is based on the MIPS architecture and is supported by the Linux kernel. The stock firmware is flushed with U-Boot. The built-in TFTP client can be used for recovery if you accidentally load a faulty firmware. The main thing is not to kill the bootloader; otherwise, your last resort would be a soldering iron.

In my opinion, this piece of hardware is perfectly suited for experiments. One of its downsides is that DIR-806A doesn’t have USB out-of-the-box. However, USB wiring is present on the board, and if you possess the proper knowledge and skill, you can solder this port on your own.

Let’s connect to UART first; make sure that you have a level converter for UART. During the connection, don’t forget to ‘criss-cross’ RX and TX: the RX line must be connected to TX; while TX, to RX. Connection parameters: 57600 8N1.

Congrats, you’ve connected to UART. Now let’s try to flush the patient keeping an eye on the console. Perhaps, some lines there could help you find the code sections responsible for the flushing process?

Success! The router displays a message in the console that the update has started and indicates the section the firmware is loaded to (Linux). This is a classical reversal engineering procedure: you search for certain lines, and based on these lines, identify specific locations in the code. Let’s search for the line start... in the firmware:

Here is the fw_updater utility. Let’s run it:

Apparently it’s fw_updater that loads the new firmware to the Linux section.

Now let’s try to find in the firmware the code section from where fw_updater is called:

As you can see, fw_updater is used in the libdhal.so library. Interesting… Let’s see what’s inside it. I suggest to use Ghidra for reverse engineering since it can convert a binary executable file into C code. This is very convenient, and you don’t have to dig into the assembler listing.

You also need a utility that can transfer the required file to you computer. Any network file transfer mechanism would fit. If there is nothing suitable on the router, you can unpack the firmware on your computer using binwalk. Note that there are no universal solutions suitable for all situations…

In this particular case, netcat is available. Let’s transfer libdhal.so to the computer:

Next, let’s create a project in Ghidra and disassemble the library. A quick examination shows that it contains a function with a self-explanatory name: check_firmware_in_buffer. Below is its listing in C:

This function makes the decision whether a particular firmware is suitable for the router or not. Three parameters are checked: image size, magic number, and MD5 hash.

A brief analysis of the above code makes it possible to conclude that:

• param_1 is a pointer to the buffer containing the firmware file; and 
• param_2 is the buffer size.

Look at the string below:

It’s obvious that the magic number is contained in the last four bytes of the firmware and is equal to 0xc0ffee.

Time to examine the hash:

As you can see, the hash is computed based on the local_95 array 16 bytes in size and the firmware file (except for the 20 bytes at the end). These 20 bytes are the size of MD5 + the 4 bytes of the magic number. The local_95 array is built on the basis of the pcVar4 parameter that contains the device UUID.

Let’s see what’s going on in this piece of code:

This is a conversion operation: a byte is converted from textual representation to machine code.

Time to check your coding skills. Let’s write a Python script to compute MD5:

The above script takes firmware as input. Its execution result is shown below:

Compare the computed hash with the original firmware at offset 0x6c4750, and you’ll see that the hash was computed correctly.

Now you can easily create firmware that can be flushed using the stock web interface.

MD5 hashes (especially those composed of UUID and image, as in this particular case) are pretty rare. The specific implementation depends only on the manufacturer’s creative imagination. For example, such vendors as SNR or Keenetic prefer simpler solutions. SNR engineers, instead of computing the CRC32 checksum of the kernel, compute CRC32 of the entire firmware; while Keenetic guys specify the magic number, CRC32, and device ID in the firmware.

In terms of complexity, the situation with firmware embedded into Xiaomi routers is similar. They also operate with minimum firmware size and magic number, but instead of MD5, RSA is used… Overall conclusion: there is no signature that could not be reversed.

Good luck!