So to start the story off in 2018 I purchased a OBD2 reader for JDM vehicles, the majority of vehicles here are used JDM so it made sense to have one to cover our fleet.
Day 1:
Tried every vehicle and not one connected to the OBD2 reader, Contacted the maker and was told to upgrade firmware.
Day 1.5:
Downloaded firmware for the unit, flashed it and it was dead, no screen, no USB just light up lcd and nothing.
Day1.5.5:
After noticing we had flash the v1 firmware on a v2 board (nothing online pointed this out) we contacted the manufacturer to be told you're out of luck as you made the mistake.
We then purchased another unit from a different amazon supplier only to find it was DOA, now as we like in central africa our Amazon has to go via UK so the cost of shipping back was more than the product so we just decided to buy a different product all together.
With the old two units I just dumped in to a draw for a month then decided to use them as STM32 dev boards but alas the SWD was locked out, thats where my research into STM protection began.
Quickly I found the articles on dumping ST-Link firmware and the shedding too much light onto MCU's articles but found them beyond my trained and knowledge at the time.
fast forward to a few weeks ago when this popped up
https://gitlab.zapb.de/zapb/stm32f1-firmware-extractorand a working version based of that
https://github.com/doegox/stm32f1-firmware-extractorBased off the works off Marc Schink they fixed the extraction procedure. However the extraction has its issues, every few bytes cannot be read, the ones which match up certain IRQ vectors(7-13),
However it was enough for me to start me research into encrypted bootloaders, which my OBD2 reader has(had).
Fast forward to today and I now have a fully working OBD2 reader times 2 running original factory software.
They key was finding AES s-box values within the dumped bootloader, while there was many bytes missing there was enough to diassemble using ghidra and narrow down the aes key.
Then using
https://github.com/dmitrystu/sboot_stm32 tools i was able to modify the encrypt/decrypt firmware app to decrypt the factory firmware, from that I worked out the entry vector and wrote a simple dump to uart program that i overlay-ed on the original firmware using the "steel series mouse hack" and after a short boot up I was not able holding the entire decrypted firmware dump but I also had a working device.
Now the device i am talking about is a autophix OM127 JOBD reader, its sold under other names like Ancel JP700 and a few other names. They all use the same 0x10 bytes for the key and all the firmware say Autophix in the firmware, even the ones from other makers who have changed the logo's and about text still have autophix text in the binaries.
you can see the device here
http://www.autophix.com/ &
https://www.anceltech.com/product/detail?id=1085379019941081088Some interesting things I found while working the bootloader and main firmware:-
On bootup SWD is disabled and RDP is checked and if found below RDP 2 is reset to RDP 2
Bootloader uses 1 key for firmware and second key for EEPROM contents (0x10 bits for FW and 0x8 for eeprom) and a third key for text.
SWD can be enabled by connecting while device is in reset
going from RDP2 to any other RDP setting will erase flash even if it is done via bootloader
on this device SWD has to be disabled to function normally as they used the SWD pins within the design making debug as issue however i was able to patch the pin used for CAN_MUTE to another by solder the LED wire to CAN_MUTE and then shifting a 1 in the code.
the key is not found within the update software but provision for it is there.
90% of data is kept in encrypted form until used, all eeprom reads are encypted to memory,decrypted and then are zeroed out.
the IRQ table is huge and had to be patched to allow the dump firmware to function.
I will be putting all the decrypted files on my github over the next few weeks, there is still a lot of junk code within my final working files i need to remove as it's useless/test code/does not work.
So to confirm, yes it's possible to dump stm32 encrypted firmware however it's not easy and there are few tricks to stop it from happening.
I will cover these in future post's
darkspr1te