Hacking embedded MCU system firmware ideas needed

[mitaux8030]

A device I'm playing around with has a Freescale / NXP MCU model MK22FN512VLL12. The MCU interfaces with an EEPROM, external Flash memory, LCD driver and a custom DSP IC, and it has 512kb of internal flash memory where operating firmware is stored. That firmware is updatable via USB interface, and the firmware files supplied by the manufacturer are encrypted, and presumably are decrypted by a software bootloader in the MCU as they get loaded and stored into MCU flash memory.

The manufacturer of the device are a bit slow to fix a couple of long outstanding issues with the firmware, and we'd like to attempt addressing those issues ourselves, but MCU readout protection is enabled so we can't pull out the firmware by SWD interface. Done a little bit of Googling to see if the MK22 has any specific vulnerabilities, but it seems to be pretty solidly locked down by features that Freescale implement in the MCUs design. The USB interface uses a custom protocol, a bit like the STM32 DFU, and as far as I can tell only permits reading out configuration settings, not firmware or raw memory address contents. Given the low cost of the device, and the limited memory available (firmware image is 481k, leaving at most 31k for it's firmware update bootloader) the encryption of any firmware file is likely not to be too complex - probably just XORs the incoming data with a key perhaps 512 or 1024 bytes long. The bootloader never changes as the user can freely change firmware versions from the earliest to the newest and back again without any problem, so presumably the same encryption method & key are used for all firmware update files.

One interesting thing found in the external flash memory IC are segments of data that don't look like they're encrypted, and are not related to the configuration data that the flash memory holds - they can be safely deleted without any impact on the operation of the device. I'm wondering if it could be partial copies of the firmware.... but it doesn't ARM decompile to anything particularly sensible. Was hoping it could be used as part of a plaintext to encrypted XOR matching, but no luck so far.

So what's some general lines of attack that could be used to get to the firmware? TIA

[crazy]

Has the same company other devices that have already been reverse engineered to some aspect that you can use the same techniques?

[Gitch]

Is there a link to firmware, or can you upload it so as others can have a look? Give us an idea of what the device is might actually help too...

[mitaux8030]

Is there a link to firmware, or can you upload it so as others can have a look? Give us an idea of what the device is might actually help too...

OK, the device in question is a digital DMR two way radio, made by Chinese company TYT, resold under the Radioddity brand name. They've had a previous product's firmware jailbroken, but the techniques that applied to that model (MD-380)don't apply here: different MCU, and a different contracted software company wrote the firmware for that, so not using the same encryption key / perhaps different key length too.

All previous versions of firmware and it's PC updating software are downloadable from here:


What we know:
Each firmware .sgl image has a (hex) 473 byte header, using a very simple XOR 2 byte encryption which was easy enough to undo. It contains model & version information to ensure a compatible firmware image is being sent, and a bunch of other bytes we don't know the function of (filler to obfuscate?)
The updater program begins sending the firmware image sequentially in 1kb blocks, with 32 bytes per packet sent via USB from address 0x0474 in the firmware image. Despite the presence of the STDFU.dll file, the USB protocol is different from the ST DFU protocol.
Since we expect the encryption key to remain the same, it was hoped that the first few bytes sent would be a MCU vector initialisation table that also wouldn't change, therefore the first few hundred bytes should also be the same. But they're not. The previous model I spoke of above hid this by loading the firmware backwards eg: high bytes first. Again, I looked for that same trick being used in this case, and didn't see it.

I don't have a lot of software programming experience, and even less cryptographic knowledge, so any pointers or general ideas would be appreciated. Old dog learning new tricks.