Reverse engineering an i.MX RT1170 based system - Page 1
Forum section: electronics / general

author: newbie666
author_rank: Regular Contributor
timestamp: September 10, 2024, 07:15:01 am
content: 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 isi.MX RT1170which has 1GHz Cortex M7 + 400MHz Cortex M4 and 2Mb of ram- flash isIS25WP032in an easy to access 8 pin SOIC packageWhat 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'sSPSDKpython 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 goalI was most impressed with this forum's efforts to hack scopes so I hope some experienced hackers chime in.Thanks!Bootloader logCode:Bootloader Version 1.2.0flash_area_open rc = 0Bootloader chainload address offset: 0x100000Reset_Handler address offset: 0x100400Jumping to the image...calculated msp 0x0x30100400 reset 0x0x30100404

author: asmi
author_rank: Super Contributor
timestamp: September 10, 2024, 03:47:46 pm
content: 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).

author: newbie666
author_rank: Regular Contributor
timestamp: September 10, 2024, 08:54:38 pm
content: 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

author: asmi
author_rank: Super Contributor
timestamp: September 11, 2024, 03:36:03 am
content: Quote from: newbie666 on September 10, 2024, 08:54:38 pmUsing known attack vector is not hacking - it's what script kiddies do to show that they are the coolest hackers in their kindergardenOn 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.

author: newbie666
author_rank: Regular Contributor
timestamp: September 11, 2024, 12:48:41 pm
content: 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

author: nimish
author_rank: Regular Contributor
timestamp: September 14, 2024, 11:02:11 pm
content: Quote from: newbie666 on September 11, 2024, 12:48:41 pmA 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

author: newbie666
author_rank: Regular Contributor
timestamp: September 17, 2024, 07:25:00 am
content: 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.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: September 18, 2024, 05:38:57 am
content: 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).

author: nimish
author_rank: Regular Contributor
timestamp: September 19, 2024, 03:17:35 am
content: Quote from: newbie666 on September 17, 2024, 07:25:00 amYou 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

author: 5U4GB
author_rank: Super Contributor
timestamp: September 22, 2024, 12:24:23 pm
content: You could also look at existing i.MX vulnerabilities, for examplethese oneswhich are unpatchable because they're in ROM. You can also try glitching it to try and bypass the fuse read using something like aChipWhisperer. 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.

author: tellurium
author_rank: Frequent Contributor
timestamp: September 23, 2024, 01:50:33 pm
content: Quote from: asmi on September 10, 2024, 03:47:46 pmOfftopic, but but I was under impression RT1170 actually can run Linux

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 23, 2024, 07:56:20 pm
content: Quote from: tellurium on September 23, 2024, 01:50:33 pmIt seems so:https://emcraft.com/imxrt1170-evk-board/building-and-installing-linux-uimage

author: newbie666
author_rank: Regular Contributor
timestamp: September 27, 2024, 08:24:32 am
content: Quote from: abyrvalg on September 18, 2024, 05:38:57 amHmm interesting, I'm currently working on dumping the flash (in circuit - not going great as expected) so I may give this a try. Thanks!

author: 5U4GB
author_rank: Super Contributor
timestamp: September 30, 2024, 08:25:00 am
content: If you don't mind looking at STM32s instead of i.MX devices, the guys over inthis threadcould probably do with your help. And for a direct link to some of the stuff that's being done, apost about using a ChipWhisperer to glitch an STM32.

author: newbie666
author_rank: Regular Contributor
timestamp: October 17, 2024, 11:11:23 am
content: 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 partHaving 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 verified2) 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 proceeding4) 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.

author: 5U4GB
author_rank: Super Contributor
timestamp: October 19, 2024, 08:30:18 am
content: Quote from: newbie666 on October 17, 2024, 11:11:23 amIf 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.

author: 5U4GB
author_rank: Super Contributor
timestamp: October 19, 2024, 08:35:17 am
content: Quote from: newbie666 on October 17, 2024, 11:11:23 amDo 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.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: October 19, 2024, 12:26:44 pm
content: 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.

author: newbie666
author_rank: Regular Contributor
timestamp: October 30, 2024, 12:09:21 pm
content: QuoteUnfortunately I do not know that. All of the security related docs from NXP are not accessible to anyone who hasn't signed NDA so there's not much info I can get from datasheets.I'll read up on the "trendy stuff" you've mentioned. Maybe this will answer my question on the format of the image (parts look encrypted while big portions containing strings, other data structures and what looks like debug symbols(!)) are in plain text.

author: 5U4GB
author_rank: Super Contributor
timestamp: October 31, 2024, 05:12:25 am
content: What all of those have in common is that they're stream ciphers that XOR the key stream with the data rather than actually encrypting it, meaning passing it through an encryption function. This means that if you can find the keystream you can "decrypt" anything with an XOR. It also means you can change the decrypted data without knowing the key, for example if you flip bit 5 of the ciphertext it flips the same bit in the decrypted plaintext.