Dumping STM32 protected firmware

[darkspr1te]

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-extractor
and a working version based of that
https://github.com/doegox/stm32f1-firmware-extractor

Based 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=1085379019941081088

Some 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

[mikerj]

Nice work!

[ali_asadzadeh]

Thumbs up ,Some tutorials would be nice!

[darkspr1te]

Thumbs up ,Some tutorials would be nice!

So long as readers do not mind my bad C,C++ coding skills, My crazy make files and random assumptions and illogical logic, 

"I Don't know what I'am doing here" will be my first answer, I've never received any training in reverse engineering or coding beyond my pascal days at college.

Also to be fair the guides I used to get this far will be quoted a lot, the only thing I'll be adding is proof it works by example and providing actual dumps from a commercial product proven to be locked.

It might even be more of a platformio guide as that was key to being able to build "similar code" using a variety of different backends (i would need to swap between CM3,STM32CUBE,STMDUINO,BAREMETAL)

then pulling that into ghidra to compare disassembly.
Well I have some time, let me see what i can do



darkspr1te

"Where  we go, there is no warranty"
 

[DC1MC]

The FeelElec 6600 people that still have firmware 3.0/3.1 on their front panel would like to have a word with you and will raise you a small statue if you can dump a firmware version 3.3 or 3.4 and/or decrypt the firmware upgrade. I will also personally PayPal you something for the effort 

Thread(s) here:

https://www.eevblog.com/forum/repair/feeltech-fy-6600-corrupted-flash-repair/

https://www.eevblog.com/forum/testgear/feeltech-fy6600-60mhz-2-ch-vco-function-arbitrary-waveform-signal-generator/

 Cheers,
 DC1MC

[ali_asadzadeh]

So long as readers do not mind my bad C,C++ coding skills, My crazy make files and random assumptions and illogical logic,

"I Don't know what I'am doing here" will be my first answer, I've never received any training in reverse engineering or coding beyond my pascal days at college.

Also to be fair the guides I used to get this far will be quoted a lot, the only thing I'll be adding is proof it works by example and providing actual dumps from a commercial product proven to be locked.

It might even be more of a platformio guide as that was key to being able to build "similar code" using a variety of different backends (i would need to swap between CM3,STM32CUBE,STMDUINO,BAREMETAL)

then pulling that into ghidra to compare disassembly.
Well I have some time, let me see what i can do



darkspr1te

"Where  we go, there is no warranty"

A step by step of how you did what you did, is enough!

Also sometimes I use IDA Pro from Hex rays as a reverse engine help

[up8051]

Here are information (short video & full description) how to dump STM32F1:
https://blog.zapb.de/stm32f1-exceptional-failure/

[MarkMLl]

Well done. Some people would no doubt complain that you shouldn't have attempted to reverse-engineer a proprietary device, but I think that the manufacturer brought it on themselves for not having a robust check that the right firmware was being flashed.

I think I'd suggest, though, that if you ever have to do something like that again you approach the manufacturer asking if he'd like a local (and proven competent) agent before putting the results on Github.

MarkMLl

[darkspr1te]

Here are information (short video & full description) how to dump STM32F1:
https://blog.zapb.de/stm32f1-exceptional-failure/

I started with that but alas their posted code is buggy so i've posted a working one in the first post (not my code) , also it just the first step as this method skips bytes that overlay irq 7-13 so if your key or important code is matching up with these unreadable bytes then your stuck.


darkspr1te

[Miti]

I think I'd suggest, though, that if you ever have to do something like that again you approach the manufacturer asking if he'd like a local (and proven competent) agent before putting the results on Github.

MarkMLl

Did you read that he did just that and the manufacturer basically told him “tough luck “ ?

[MarkMLl]

I think I'd suggest, though, that if you ever have to do something like that again you approach the manufacturer asking if he'd like a local (and proven competent) agent before putting the results on Github.

Did you read that he did just that and the manufacturer basically told him “tough luck “ ?

Did you read that I used the word "again"?

The vendor- who might or might not have been the ultimate manufacturer- was dismissive when it was a simple commercial/support matter. Somebody might have been more receptive once it was obvious that there was somebody motivated and able to support their kit properly- and who might turn into an effective competitor if not handled properly.

MarkMLl

[Kilrah]

Everybody will react nicely under threat - separating the worthy from the non-worthy is done when things are in their favor.
You don't have 2 occasions to make a good first impression - if CS throws me out I will give zero Fs about them either.

[Mechatrommer]

i bought this device 2 years ago, FOXWELL NT650: Full Function OBD2 Scan Tool with Lifetime Upgrade Review it turned out it cant read any data from all of my cars. so its a piece of useless equipment laying around.. checking the FW (available in the plugged in MicroSD card iirc) there alot of cryptic files inside there, i attach some of them here. i never figure them out what, if anyone have an idea i will appreciate it...

[Kjelt]

I think any manufacturer should replace a defective device for cost of goods and handling plus shipping.
Just return the defective device and replace it with a new one.
Why? Because the manufacturer benefits from good feedback, reputation and can learn from analysis of the defective returns to make their product better.

[DC1MC]

I think any manufacturer should replace a defective device for cost of goods and handling plus shipping.
Just return the defective device and replace it with a new one.
Why? Because the manufacturer benefits from good feedback, reputation and can learn from analysis of the defective returns to make their product better.

Ha, ha, a Chinese distributor of a Chines manufacturer, very funny joke ...

Oh wait, you're serious, then... MUHAHAHAHAAAA !!!

I also have some affordable COVID tests and face masks to sell as well...

[MarkMLl]

I think any manufacturer should replace a defective device for cost of goods and handling plus shipping.

Sure, they /should/. And most of their customers would be aghast if it turned out that they ran a sweatshop.

Neither of which matters a damn if the consumer and producer are in different legal jurisdictions.

Which illustrates the utter stupidity of certain countries that think it's a good idea to weaken the connection they have with their trading partners... I'm looking at you, England.

MarkMLl

[darkspr1te]

i bought this device 2 years ago, FOXWELL NT650: Full Function OBD2 Scan Tool with Lifetime Upgrade Review it turned out it cant read any data from all of my cars. so its a piece of useless equipment laying around.. checking the FW (available in the plugged in MicroSD card iirc) there alot of cryptic files inside there, i attach some of them here. i never figure them out what, if anyone have an idea i will appreciate it...

Sadly OBD2 readers are a mine field of the makers creation, just because they say OBD2 compatible does not mean it is , there is Euro OBD2, USOBD2+CA, JOBD2 & AUOBD2 and it's not a electrical difference only the "question  & answer" data of obd2 or the speed(baud), then you get to manufacturer problems like OBD gateways (think super cars & toyota).
In reality the software could support all and be updated often but that does not sell product, better sell half baked goods than perfect goods or client he no come back.

Am guessing your files are challenge & response codes for the various cars, no doubt encrypted to protect IP.
Have you tried updating it recently ?   what territory are you testing it in?   

darkspr1te

[bson]

Is this fixed in the newer ARM CM trace-debug cells?

[morcibacsi]

I am experimenting with the extracting utility from https://github.com/doegox/stm32f1-firmware-extractor. I am running the following command to dump the firmware on Windows from a STM32 blue pill (readout protection is not enabled on the device):

Code: [Select]

main.py 0x00000000 16384 --binary > firmware.bin

Should this be enough or I am missing something? I was planning to compare the output from the binary read by the ST-Link utility from the device, but it refuses to save the content as a binary file, it saves the content as a HEX file.

[abyrvalg]

Try putting —binary before the addr/len args.

[ETITsynthesizer]

don't feel bad on the ethics. I'm sure someone in china already reverse engineered, hacked and cloned this device. you could be told there is no remedy because the vendor you purchased it from is selling clones or dumpster dives. the one real product designer is possibly out of business for all the cloning and the expensive R&D. it might even be from an american company. that would explain why they would want to encrypt what they copied to avoid a lawsuit. I don't know for a fact. but I know that there are so many possible scenarios that you might not get anywhere speculating on the ethics of stealing from a company that stole your money.

[MarkMLl]

don't feel bad on the ethics. I'm sure someone in china already reverse engineered, hacked and cloned this device. you could be told there is no remedy because the vendor you purchased it from is selling clones or dumpster dives. the one real product designer is possibly out of business for all the cloning and the expensive R&D. it might even be from an american company. that would explain why they would want to encrypt what they copied to avoid a lawsuit. I don't know for a fact. but I know that there are so many possible scenarios that you might not get anywhere speculating on the ethics of stealing from a company that stole your money.

Hell hath no fury like a Chinese engineer who finds a compatriot ripping off his intellectual property.

MarkMLl

[andyB2022]

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

Hi! Could you please make a tutorial on how to do it? Thanks!