Notes – Reversing the e5573

Update: I managed to complete this attack. Read this.

A few months ago, I began the process of reverse engineering a Huawei E5573 LTE dongle device. This project went on hold due to lack of commitment on my part – recently, I picked this up again, and was able to make moderate progress. My lack of progress with this work translates to a lack of progress with other work, and thus, I write this post to seek temporary closure, that I might persevere elsewhere.

The overall goal is to:

  • Gain access past the authconsole binary, rooting the device, without resetting the authentication hash in nvram (i.e. forth32’s technique).
  • Learn hardware security processes and techniques.

At the time of writing, this goal remains unfulfilled.

NAND Dumping

I was able to use an RT908H NAND programmer (acquired from AliExpress), together with a BGA64 clip, to read the NAND chip. The first step to translate this into useful information is to use j-michel’s work to remove the OOB data from the raw NAND flash.

Then, using the loading information from the UART boot log, we are able to slice the file into it’s various constituent parts. I notice that the device filesystem is not recovered correctly, but the NVRam partitions appear to be valid, as verified by forth32’s balong-nvtool.

Using another firmware (the P711 edition), we know the general layout of authconsole, and the code which it uses to determine if a password is correct:

(not pictured – strlen() == 8 check).

From here, we can tell that it looks for either a raw hash, or (presumably) an 8-character string within NVRam. None of the 8-character strings from the nvimg.bin extraction worked in the UART console, but I can find several hash-length strings (surrounded by zero):

I intend to try cracking these hashes and trying them out.

Reviewing JTAG Access

I also began exploring the JTAG interface, using OpenOCD. The pin out is as follows: I understand that this 10-pin layout is similar across Huawei devices:

From here, I used a J-Link and OpenOCD to identify the presence of a Cortex-M3 and Cortex-A9 processor – while I had explored the M3 processor previously, I did not take into account the A9 processor.

I began by halting the A9 core and extracting memory – from this, I was able to identify the presence of what appeared to be an Android kernel, at the block starting from 0xC0000000, along with several pages of user memory. A simple “strings” showed that the memory contained strings present in the code, but this was not usefully exploitable – the code was nowhere to be found (and breakpoints didn’t seem to reveal their location, even though the strings were clearly used).

On further reading, I believe this is due to a mix of the ARM MMU, as well as the kernel’s own memory allocation trickery – I am not skilled enough in ARM reverse engineering to do this (yet), but would welcome advice and assistance with this.

As a side note, it is possible via JTAG to control a string passed to a printf function, but only for 10 tries (until you get locked out). Simple string leakage from the stack doesn’t work due to the presence of memset calls – but this is another potential attack point.

Baseband Extraction

During my exploration of JTAG, I was also able to identify the baseband blob, loaded in physical memory at the chunk starting from 0x50000000. While at the time of writing, I have not completed a full memory dump, I was able to recover enough of the baseband to identify matching code with baseband extracted earlier from the E3372 device, as shown by simple entropy analysis:

Furthermore, as the E3372 baseband is extractable with a complete symbol list, it should be trivial to match the functions here and begin identifying further points of attack (though exploiting this is another matter, given the more robust nature of LTE handover making this attack impractical against production devices – though I may just be a fucking scrublord in this area, the more likely option).

Nevertheless, huzzah.


I’ve had a lot of fun with this device so far, but there is still much to learn. Due to overwhelming other commitments, I will set this project aside temporarily to focus on delivery of the “hwctf” project, and several in-the-works community intiatives and reversing projects. Expect to see more of this, as my skill in reversing improves.

See you in this weekend’s CTFs.

About Norman

Sometimes, I write code. Occasionally, it even works.
This entry was posted in Bards, Computers, Jesting. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s