Dumping STM32 protected firmware - Page 1
Forum section: electronics / general

author: darkspr1te
author_rank: Frequent Contributor
timestamp: April 03, 2020, 12:15:34 pm
content: 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 uphttps://gitlab.zapb.de/zapb/stm32f1-firmware-extractorand a working version based of thathttps://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 usinghttps://github.com/dmitrystu/sboot_stm32tools 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 herehttp://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 2Bootloader 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 resetgoing from RDP2 to any other RDP setting will erase flash even if it is done via bootloaderon 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'sdarkspr1te

author: mikerj
author_rank: Super Contributor
timestamp: April 03, 2020, 12:33:43 pm
content: Nice work!

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: April 03, 2020, 06:15:54 pm
content: Thumbs up,Some tutorials would be nice!

author: darkspr1te
author_rank: Frequent Contributor
timestamp: April 04, 2020, 09:58:23 am
content: Quote from: ali_asadzadeh on April 03, 2020, 06:15:54 pmSo 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 dodarkspr1te"Where we go, there is no warranty"

author: DC1MC
author_rank: Super Contributor
timestamp: April 04, 2020, 10:09:46 am
content: 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 effortThread(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

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: April 04, 2020, 02:50:29 pm
content: QuoteA 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

author: up8051
author_rank: Frequent Contributor
timestamp: April 05, 2020, 08:48:16 am
content: Here are information (short video & full description) how to dump STM32F1:https://blog.zapb.de/stm32f1-exceptional-failure/

author: MarkMLl
author_rank: Frequent Contributor
timestamp: April 05, 2020, 12:39:28 pm
content: 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

author: darkspr1te
author_rank: Frequent Contributor
timestamp: April 05, 2020, 05:28:22 pm
content: Quote from: up8051 on April 05, 2020, 08:48:16 amI 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

author: Miti
author_rank: Super Contributor
timestamp: April 07, 2020, 01:17:23 am
content: Quote from: MarkMLl on April 05, 2020, 12:39:28 pmDid you read that he did just that and the manufacturer basically told him “tough luck “ ?

author: MarkMLl
author_rank: Frequent Contributor
timestamp: April 07, 2020, 08:36:17 am
content: Quote from: Miti on April 07, 2020, 01:17:23 amDid 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

author: Kilrah
author_rank: Unknown
timestamp: April 07, 2020, 10:46:14 am
content: 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.

author: Mechatrommer
author_rank: Super Contributor
timestamp: April 07, 2020, 02:24:52 pm
content: i bought this device 2 years ago,FOXWELL NT650: Full Function OBD2 Scan Tool with Lifetime Upgrade Reviewit 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...

author: Kjelt
author_rank: Super Contributor
timestamp: April 07, 2020, 09:49:35 pm
content: 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.

author: DC1MC
author_rank: Super Contributor
timestamp: April 08, 2020, 02:56:35 pm
content: Quote from: Kjelt on April 07, 2020, 09:49:35 pmHa, 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...

author: MarkMLl
author_rank: Frequent Contributor
timestamp: April 09, 2020, 11:31:50 am
content: Quote from: Kjelt on April 07, 2020, 09:49:35 pmSure, 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

author: darkspr1te
author_rank: Frequent Contributor
timestamp: April 09, 2020, 09:19:00 pm
content: Quote from: Mechatrommer on April 07, 2020, 02:24:52 pmSadly 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

author: bson
author_rank: Unknown
timestamp: April 14, 2020, 10:21:56 pm
content: Is this fixed in the newer ARM CM trace-debug cells?

author: morcibacsi
author_rank: Regular Contributor
timestamp: June 11, 2020, 01:19:07 pm
content: I am experimenting with the extracting utility fromhttps://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:main.py 0x00000000 16384 --binary > firmware.binShould 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.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: June 12, 2020, 06:17:35 am
content: Try putting —binarybeforethe addr/len args.

author: ETITsynthesizer
author_rank: Contributor
timestamp: June 12, 2020, 01:52:46 pm
content: 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.

author: MarkMLl
author_rank: Frequent Contributor
timestamp: June 12, 2020, 05:23:02 pm
content: Quote from: ETITsynthesizer on June 12, 2020, 01:52:46 pmHell hath no fury like a Chinese engineer who finds a compatriot ripping off his intellectual property.MarkMLl

author: andyB2022
author_rank: Regular Contributor
timestamp: May 31, 2023, 03:38:24 pm
content: Quote from: darkspr1te on April 03, 2020, 12:15:34 pmHi! Could you please make a tutorial on how to do it? Thanks!

author: prosper
author_rank: Regular Contributor
timestamp: April 19, 2025, 04:10:38 pm
content: whoops, wrong thread

author: bson
author_rank: Unknown
timestamp: April 21, 2025, 07:53:41 pm
content: Quote from: DC1MC on April 04, 2020, 10:09:46 amThe python program only requires OpenOCD and access to the SWD pins. The latter just requires holding the device in reset while connecting to it, then let it out of reset into a halted state if they were disabled since that's handled by the boot ROM.The program automates the exception twiddling needed to read out flash byte by byte.The 'firmware' C program part of the repo is just a test, probably what the author used to develop it.

author: onesystem
author_rank: Regular Contributor
timestamp: August 29, 2025, 08:37:03 pm
content: I consider it is better to continue this thread instead of starting a new topic - previous data here may be of value. Despite STM32F1 being an old chip, there is some equipment that is still using it, and if you want to repair it and need to get data out of the chip, it is quite useful. I ran into this amazing github page:https://github.com/CTXz/stm32f1-picopwnerI tested the method - it works flawlessly.I will add only, that in my case the UART pin was remapped by the manufacturer to PB6 (STM32F103C6T6A), so I had to allow the RPi pico to load attacking firmware into SRAM using pin PB6, then when the step of manually disconnecting ST-Link from the target board came, right before disconnecting ST-Link I swapped UART connection from pin PB6 to a default UART1 location of PA9, getting the full dump of the chip.So maybe this method will be very useful to car restoration gurus as well.

author: peter-h
author_rank: Super Contributor
timestamp: August 31, 2025, 05:52:58 am
content: Dump read-out protected STM32F1's with a Pi Pico - A Pi Pico implementation of @JohannesObermaier's, Marc Schink's and Kosma Moczek's Glitch and FPB attack to bypass RDP (read-out protection) level 1 on STM32F1 chipsWho would use RDP1 and not RDP2? RDP1 seems completely pointless unless you want to preserve the option of reflashing the chip if you made a big screwup in production. With RDP2, if you screw up, you have to unsolder itThere is an RDP1 hack for the 32F4xx also.https://community.st.com/t5/stm32-mcus/how-to-change-the-read-out-protection-on-stm32f1/ta-p/49408

author: abyrvalg
author_rank: Frequent Contributor
timestamp: August 31, 2025, 06:48:30 am
content: There is no RDP2 on F103, that’s why.

author: peter-h
author_rank: Super Contributor
timestamp: August 31, 2025, 06:56:37 am
content: OK; above post says F1 and maybe it was supposed to be F103. F1 does have RDP2.Edit: I wrote nonsense aboveThe 32F103 is the 32F1xx. But the above st.com link says the chip hasRDP2.STM32F1 microcontrollers offer three levels of read-out protection: level 0 (no protection), level 1 (Flash memory, backup SRAM, and backup registers protected), and level 2 (same as level 1, but with permanent protection by locking the option bytes). It's important to note that level 2 should only be considered for the final product, not during development stages.At level 0, no read-out protection is enabled, and all read and write operations on the flash memory and backup SRAM are possible in all boot configurations. Option bytes on the microcontroller can also be changed.Level 1 sets read protection for the Flash memory. Access to protected memories is only allowed when booting from User Flash memory, otherwise a system hard fault is generated, blocking all code execution until the next power-on reset. Option bytes are still configurable at this level, making it possible to revert the read-out protection to level 0 either via system bootloader mode or regular SWD/JTAG interface.Level 2 provides the same protection as level 1, but with permanent protection by locking the option bytes. Once level 2 protection is set, it cannot be undone, and the microcontroller will remain permanently protected, the system bootloader is also unreachable in this mode.Also:https://www.eevblog.com/forum/microcontrollers/stm-32f4xx-what-hacks-are-known-around-level-2-security/msg5596655/#msg5596655Why would anybody use RDP1? One reason I can think of is for a car ECU where the mfg wants to be able to do firmware updates, for emissions reg changes, VW-style software cheats (if caught), etc. But you can still write the FLASH of an RDP2 protected chip, by running internal software. I do exactly that; can have OTA updates on an RDP2 product.