Electronics > Microcontrollers

Reverse engineering an i.MX RT1170 based system

(1/3) > >>

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: ---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

--- End code ---

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:

--- Quote from: newbie666 on September 10, 2024, 08:54:38 pm ---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 :)

--- End quote ---
Using known attack vector is not hacking - it's what script kiddies do to show that they are the coolest hackers in their kindergarden :palm:
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 :)

Navigation

[0] Message Index

[#] Next page