Reverse engineering an i.MX RT1170 based system

[newbie666]

Hello,

I'm trying to get a bit more experience with reverse engineering and I've picked a little embedded board that does audio processing as my first victim.

Few info about the board:
- main uC is i.MX RT1170 which has 1GHz Cortex M7 + 400MHz Cortex M4 and 2Mb of ram
- flash is IS25WP032 in an easy to access 8 pin SOIC package

What I've got so far:
- I've located a 20 pin debug connector and found UART, only one pin (TX) is pulled up so I think RX pin resistor is not populated for release boards.
- I have a log of the device booting up, it appears to have a custom second stage bootloader (log attached to the bottom of the post) rather than using uBoot which is what I've seen from this manufacturer previously (bummer as I was hoping to get uboot prompt)
- I've dumped the firmware of the device. It's encrypted and is a bit over 1Mb in size. Size of the firmware + the bootloader situation makes me think this device is not running Linux like other devices from the same manufacturer I've previously inspected
- The device is fused (so JTAG should be disabled)
- I've figured out a way to put the device in SDP boot mode
- I've got NXP's SPSDK python tooling suite running and I've managed to read a few flags (blhost get-property) with it. However when trying to read memory with spsdk blhost -u -- read-memory the device responds with "command not supported" error. The SDP boot mode times out after 10 seconds or so so it's a bit painful to explore blhost commands it supports.

So here I am at this point and I'm looking for ideas on how to progress. Having read some of NXP datasheets and application notes my understanding is that the aes key used to decrypt the firmware is stored on device and will be hard or impossible to extract. The firmware is also decrypted by the device "on the fly" (and then put in RAM?) so it's most likely never in the flash memory in decrypted form.

Ideally my end goal would be to have the firmware decoded so that I can put it into ghidra and explore it more.

What are my options? Looking for even the craziest ideas. I don't care if I break the device in the process and I am willing to spend unreasonable amount of time on this as I'm not in rush, not doing this for money and the journey is the goal I was most impressed with this forum's efforts to hack scopes so I hope some experienced hackers chime in.

Thanks!


Bootloader log

Code: [Select]

Bootloader Version 1.2.0
flash_area_open rc = 0
Bootloader chainload address offset: 0x100000
Reset_Handler address offset: 0x100400
Jumping to the image...


calculated msp 0x0x30100400 reset 0x0x30100404


[asmi]

This is an MCU - even though a fast one - so no wonder it doesn't run Linux - because it simply can't, just like their entire line of i.MX RT devices. If you want Linux, you need to look at their i.MX6/7/8/9x SoCs - they run Linux (though some of them can also run other embedded OSes like Android and Windows IoT).

[newbie666]

Hey asmi, thanks for your reply. I'm not sure if I got my question across correctly - I don't want to run linux on this board, what I'm looking for is a known attack vector on those uC that would let me extract the key used to decrypt firmware that the device runs. I know it's a long shot but this still seems like the best place to ask

[asmi]

Hey asmi, thanks for your reply. I'm not sure if I got my question across correctly - I don't want to run linux on this board, what I'm looking for is a known attack vector on those uC that would let me extract the key used to decrypt firmware that the device runs. I know it's a long shot but this still seems like the best place to ask

Using known attack vector is not hacking - it's what script kiddies do to show that they are the coolest hackers in their kindergarden
On a more serious note - this is a very recent MCU, so I doubt there exist much research on it's protection system yet. These things tend to take time, or money, or both.

[newbie666]

asmi, you're obviously not willing to help (or even read my posts) so I'm not sure why you're replying, you're just wasting everyone's time.

In the meantime I've done some more research. Extracting the aes key from the device doesn't seem like a feasible route. I've read about a few attacks that managed to get the key extracted from a firmware update in case the early versions of the firmware were not encrypted because a "transitional" firmware had to contain the key.
I was able to find the very first firmware for my device and it's encrypted as well which means this route is closed as well.

It seems like the most likely way of getting my hands on the firmware is re-enabling JTAG and reading it from the RAM. I haven't found any papers talking about re-enabling JTAG on RT1170 family but there are documented successful attempts on LPC family from NXP. I'll keep on reading about fault injection attacks to understand which ones I can try with the devices I already have and report back if I get to anything interesting

[nimish]

asmi, you're obviously not willing to help (or even read my posts) so I'm not sure why you're replying, you're just wasting everyone's time.

In the meantime I've done some more research. Extracting the aes key from the device doesn't seem like a feasible route. I've read about a few attacks that managed to get the key extracted from a firmware update in case the early versions of the firmware were not encrypted because a "transitional" firmware had to contain the key.
I was able to find the very first firmware for my device and it's encrypted as well which means this route is closed as well.

It seems like the most likely way of getting my hands on the firmware is re-enabling JTAG and reading it from the RAM. I haven't found any papers talking about re-enabling JTAG on RT1170 family but there are documented successful attempts on LPC family from NXP. I'll keep on reading about fault injection attacks to understand which ones I can try with the devices I already have and report back if I get to anything interesting

A fun way might be to use side channel attacks to infer the key. I don't think the rt1170 is hardened that much. Also you control the ciphertext so adaptive chosen-ciphertext attacks will likely work too.

If you can control inputs try getting shell code to run, RCE style with buffer overflows or something. USB and wireless stacks are notoriously garbage so a lot of potential there

[newbie666]

Hmm, haven't thought about buffer overflow attack, that's a great idea! Intuitively it should be more probable to find a hole in a custom bootloader or serial comms stack so I'll definitely give it a try.

I'm still not sure how to do remote code execution on an embedded device - I won't have access to a debugger to see where segfault happened so it's going to be tricky to pick the right address within the allocated buffer to put my instructions and then to jump to.
One thing that comes to my mind is trying to flash my "malware" to an empty part of the memory and hope that the bootloader stops reading data from memory at the end of the firmware image (it's a secure boot jobby so it will verify that the firmware is signed before giving control to it). That way I'd have a known address to jump to and could attempt to execute some code on the device.

Now writing the code so that it does something useful is not very obvious to me right now but I'll keep researching.

For your other suggestion (side attack for when I attempt to get into secured JTAG) - this looks super interesting and I'd like to try it at one point but I'm probably lacking hardware to pull that off right now. I'll have to come back to this idea at a later point.

[abyrvalg]

The bootloader reports the “main” area offset: 0x100000 (quite a big bootloader I’d say) and says nothing about main image verification. I suggest to corrupt the main image (write some 4k of trash starting at 0x100000) and observe bootloader’s behavior in this case. It can i.e. enter some recovery mode, or even just ignore the corruption (revealing that it doesn’t verify the main image at all).

[nimish]

Hmm, haven't thought about buffer overflow attack, that's a great idea! Intuitively it should be more probable to find a hole in a custom bootloader or serial comms stack so I'll definitely give it a try.

I'm still not sure how to do remote code execution on an embedded device - I won't have access to a debugger to see where segfault happened so it's going to be tricky to pick the right address within the allocated buffer to put my instructions and then to jump to.
One thing that comes to my mind is trying to flash my "malware" to an empty part of the memory and hope that the bootloader stops reading data from memory at the end of the firmware image (it's a secure boot jobby so it will verify that the firmware is signed before giving control to it). That way I'd have a known address to jump to and could attempt to execute some code on the device.

Now writing the code so that it does something useful is not very obvious to me right now but I'll keep researching.

For your other suggestion (side attack for when I attempt to get into secured JTAG) - this looks super interesting and I'd like to try it at one point but I'm probably lacking hardware to pull that off right now. I'll have to come back to this idea at a later point.

You could also try emulating the flash and maybe messing about with XIP, if it only checks once for authenticated code you could likely inject some.

Or investigate MCUboot CVEs: https://nvd.nist.gov/vuln/detail/CVE-2024-32883

[5U4GB]

You could also look at existing i.MX vulnerabilities, for example these ones which are unpatchable because they're in ROM.  You can also try glitching it to try and bypass the fuse read using something like a ChipWhisperer.  However you may want to work your way up via simpler attacks to get practical experience, e.g. buy a few cheapie STM32 boards and enable security features, then see if you can bypass them, using one of the others as a reference device in case you run into problems.

[tellurium]

This is an MCU - even though a fast one - so no wonder it doesn't run Linux - because it simply can't

Offtopic, but but I was under impression RT1170 actually can run Linux

[SiliconWizard]

This is an MCU - even though a fast one - so no wonder it doesn't run Linux - because it simply can't

Offtopic, but but I was under impression RT1170 actually can run Linux

It seems so: https://emcraft.com/imxrt1170-evk-board/building-and-installing-linux-uimage

[newbie666]

The bootloader reports the “main” area offset: 0x100000 (quite a big bootloader I’d say) and says nothing about main image verification. I suggest to corrupt the main image (write some 4k of trash starting at 0x100000) and observe bootloader’s behavior in this case. It can i.e. enter some recovery mode, or even just ignore the corruption (revealing that it doesn’t verify the main image at all).

Hmm interesting, I'm currently working on dumping the flash (in circuit - not going great as expected) so I may give this a try. Thanks!

[5U4GB]

If you don't mind looking at STM32s instead of i.MX devices, the guys over in this thread could probably do with your help.  And for a direct link to some of the stuff that's being done, a post about using a ChipWhisperer to glitch an STM32.

[newbie666]

I had a bit of time to go back to this project and I finally got the flash dumped. Quick entropy check shows two regions: bootloader and the firmware. Firmware seems to be split into two parts - they may be distinct binaries for M7 and M4 cores of the device but I'm not sure (see the attachment for the plot).

Binwalk detected two public keys and two signatures in the memory dump. I assume they will be the public keys that are used to verify signature of bootloader and the firmware.
Here's where I'm already confused - what's the point of storing public key next to the firmware? Wouldn't I be able to load modified firmware that I sign with my own private key and swap the public key in the memory for my own public key to make the device accept my modified firmware? I'm surely missing something because that wouldn't be much of a security feature, would it?

Now for the dump itself, the firmware appears to be encrypted BUT I can clearly see some strings in there as well as something that looks like dwarf debug symbols (both in bootloader and firmware parts). This is the second part that confuses me as I didn't think only part of the firmware would be encrypted - is this a common practice?

I've processed the dump in ghidra and as expected the decompiler didn't produce any meaningful output which confirms that the assembly part of the binary is encrypted.

Now the fun part

Having read / write access to the memory enabled a few experiments:

1) Add a few bytes someplace at the end of the memory -> device boots ok which means only parts of the flash are verified
2) Modify one bit in the main firmware -> bootloader rejects the firmware and stops the boot process, there's some output on the serial port that confirms it.
3) Modify one bit in the bootloader part -> the device doesn't boot, no serial output which means that the ROM bootloader does verify the flash bootloader signature before proceeding
4) Modify the main firmware by changing one of the strings that I found in the dump, load it using SDP bootloader mode -> Now this gives me a really interesting result because the modified firmware gets executed in that scenario. I confirmed it by prompting the device to return some data over serial and the data contained my modified string. Subsequent reset to the device resulted in the same behaviour as in 2 - bootloader did not proceed with boot as it rejected the image.

Now for the experiment 4 I still used the original firmware, just with a tiny modification to the unencrypted part. I'm not sure if I can exploit this bug to run my own custom firmware on the device because, if the bootloader tries to decrypt it, my non-encrypted binary will be mangled into something meaningless.

---

Outside of poking the target from every possible angle I also got a book called "Hardware Hacking Handbook". I'm only half way through but it already gave me a few interesting ideas. For anyone reading this thread that also would like to get a good introduction to most attacks that are feasible for a hobbyst - go check out this book, it's pretty good.

[5U4GB]

Here's where I'm already confused - what's the point of storing public key next to the firmware? Wouldn't I be able to load modified firmware that I sign with my own private key and swap the public key in the memory for my own public key to make the device accept my modified firmware?

If implemented correctly the device will verify the new firmware with the existing hardcoded public key so you're in a catch-22, to inject your own key you need to get it to load modified firmware containing the new key.

Having said that, there are a million ways to get this wrong, and it's been done over and over again.  If you want to look at this avenue of attack look at the metadata which is typically not secured in any way and see if you can do something like modifying the load address to get the untrusted firmware to overwrite the existing firmware, or the signature-check code, as part of the verification process.

[5U4GB]

I'm not sure if I can exploit this bug to run my own custom firmware on the device because, if the bootloader tries to decrypt it, my non-encrypted binary will be mangled into something meaningless.

Do you know what encryption algorithm and/or mode they're using?  If its trendy stuff like AES-CTR, AES-GCM, or ChaCha20 you're in luck, you can modify the decrypted plaintext any way you want without having to know the decryption key.

[abyrvalg]

The public key stored together with signed firmware is not the root of trust chain. ROM verifies it against hash stored in efuse, so you can’t replace this key with your own. The reason why not store the key itself in efuse is this would need a much bigger efuse.