How did reverse engineering m16c prove challenging? I recently extracted a 4 stage encrypted payload from an M16C arch that also used time-based encryption. Each time it was run, the output was different. The time based key was also rotating.
It used a very simple custom encryption for the time stuff and AES in ECB mode.
Protip Ghidra does not emulate inherent CPU behavior of INDEX instructions, behaviour not specified in ISA. I had to backport M32C instructions and patch M16C slaspec to emulate this behavior, caused by compiler bugs.
Particularly for this adventure, I have kept it strictly private. It was a hobby project and also was a challenge to myself.
In the process I learned not only of M32C(backwards compatible with M16C processor module in Ghidra), but as I mentioned, certain compiler bugs(not following the ISA spec strictly) that it is more flexible despite what the M16/M32C software manual says. However this meant that emulation produced wrong results, and thus my patches to fix it and ultimate success
I have opened a Ghidra support ticket, but I needed to provide proof that there is ISA behavior not described in the software manuals.
Trying to secure hardware that the attacker has direct access to is just so brutal. Your hardware vendor can promise compliance with X spec, implement Y protections and still fall foul to something like this.
Given that the vulnerable feature "ensures the confidentiality of the code", I'm happy that it doesn't work. It should always be possible for the owner of a device to have full access to the code running on it. I hope there are many more vulnerabilities like this one.
> The most interesting part of this attack was the discovery that the reset pin goes low for the window of time you should insert a glitch to bypass security!
Wait, does this mean you can use the reset signal directly as a glitch signal, or that the glitch has to happen for a short while within the window? If the former, that's the first time I hear of a device that provides its own bypass signal.
The glitch has to happen within the window shown to you by the microcontroller. It seems to be in a different location for each microcontroller evaluated. The fact that it shows you where depending on which processor you’re attacking is pretty convenient!
>Many devices in the Microchip (ATMEL) SAM Family make use of GPNVM bits
Only in the SAM(single letter)(rest of part number) and SAME/V/S70 family.
They went out of their way to maintain legacy parity with the M7 cores against the older M4 cores (which have GPNVM) for some reason I forget when I was discussing those chips with them in pre-production sampling long ago.
I wouldn't call this a zero-day per say. If I have your chip, programmed, physically in my hands. I will nitric acid the sucker and throw it under an electron scanning microscope to laser the security bits off if I want your firmware. I've done it before.
Thanks, makes a lot more sense now, I guess if Vcc was lower the effect would be more pronounced if anything, never really considered this as an attack vector, but looking online now it seems to well established, I'm surprised Microchip engineers didn't pick it up.
With the possibility of bypassing JTAG lock and reading firmware at least this one has practical uses compared to the ESP32 ""backdoor"". Thankfully still not quite exploitable in typical IoT use cases. Doing the same to a secure microprocessor (think smart cards, eSIM) on the other hand would be notable.
How did reverse engineering m16c prove challenging? I recently extracted a 4 stage encrypted payload from an M16C arch that also used time-based encryption. Each time it was run, the output was different. The time based key was also rotating.
It used a very simple custom encryption for the time stuff and AES in ECB mode.
Protip Ghidra does not emulate inherent CPU behavior of INDEX instructions, behaviour not specified in ISA. I had to backport M32C instructions and patch M16C slaspec to emulate this behavior, caused by compiler bugs.
Have you published anything about this anywhere? I also had to work on the SLEIGH file for the M16C.
Overall it just seemed like the processor definition for Ghidra needed more work.
Particularly for this adventure, I have kept it strictly private. It was a hobby project and also was a challenge to myself.
In the process I learned not only of M32C(backwards compatible with M16C processor module in Ghidra), but as I mentioned, certain compiler bugs(not following the ISA spec strictly) that it is more flexible despite what the M16/M32C software manual says. However this meant that emulation produced wrong results, and thus my patches to fix it and ultimate success
I have opened a Ghidra support ticket, but I needed to provide proof that there is ISA behavior not described in the software manuals.
Trying to secure hardware that the attacker has direct access to is just so brutal. Your hardware vendor can promise compliance with X spec, implement Y protections and still fall foul to something like this.
Unhugged url
https://web.archive.org/web/20250402165042/https://wiki.rece...
Given that the vulnerable feature "ensures the confidentiality of the code", I'm happy that it doesn't work. It should always be possible for the owner of a device to have full access to the code running on it. I hope there are many more vulnerabilities like this one.
> The most interesting part of this attack was the discovery that the reset pin goes low for the window of time you should insert a glitch to bypass security!
Wait, does this mean you can use the reset signal directly as a glitch signal, or that the glitch has to happen for a short while within the window? If the former, that's the first time I hear of a device that provides its own bypass signal.
Excellent work!
The glitch has to happen within the window shown to you by the microcontroller. It seems to be in a different location for each microcontroller evaluated. The fact that it shows you where depending on which processor you’re attacking is pretty convenient!
Amazing!
Minor nitpick, but Sam in the title should be SAM. (It’s an acronym.)
I don’t know if it was autocorrected or what, but it was SAM when I hit submit.
Edit: seems I could fix it, thanks!
>Many devices in the Microchip (ATMEL) SAM Family make use of GPNVM bits
Only in the SAM(single letter)(rest of part number) and SAME/V/S70 family.
They went out of their way to maintain legacy parity with the M7 cores against the older M4 cores (which have GPNVM) for some reason I forget when I was discussing those chips with them in pre-production sampling long ago.
I wouldn't call this a zero-day per say. If I have your chip, programmed, physically in my hands. I will nitric acid the sucker and throw it under an electron scanning microscope to laser the security bits off if I want your firmware. I've done it before.
It is a very noisy 3.3V supply they are using, I wonder if they removed the decoupling caps on the supply and vcore pins before doing this.
All decoupling caps were removed so the voltage fault injection could have maximum effect.
Thanks, makes a lot more sense now, I guess if Vcc was lower the effect would be more pronounced if anything, never really considered this as an attack vector, but looking online now it seems to well established, I'm surprised Microchip engineers didn't pick it up.
Another good trick is to replace the crystal with a bit stream.
If you can identify the cycle where the security bits are being read you can insert a runt pulse that is much faster than the norflash read time.
Good, another way to fight the loss of ownership and right-to-repair.
With the possibility of bypassing JTAG lock and reading firmware at least this one has practical uses compared to the ESP32 ""backdoor"". Thankfully still not quite exploitable in typical IoT use cases. Doing the same to a secure microprocessor (think smart cards, eSIM) on the other hand would be notable.
Which ESP backdoor?
https://news.ycombinator.com/item?id=43301369
Undocumented backdoor found in Bluetooth chip used by a billion devices
371 points | 25 days ago | 112 comments