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.
BitBangingBytes 1 days ago [-]
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.
dealbreaker 18 hours ago [-]
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.
liamkinne 1 days ago [-]
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.
flowerthoughts 1 days ago [-]
> 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!
BitBangingBytes 1 days ago [-]
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!
flowerthoughts 14 hours ago [-]
Amazing!
Omni5cience 1 days ago [-]
Minor nitpick, but Sam in the title should be SAM. (It’s an acronym.)
BitBangingBytes 1 days ago [-]
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!
delfinom 1 days ago [-]
>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.
1 days ago [-]
boznz 1 days ago [-]
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.
BitBangingBytes 1 days ago [-]
All decoupling caps were removed so the voltage fault injection could have maximum effect.
boznz 1 days ago [-]
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.
bobmcnamara 24 hours ago [-]
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.
1 days ago [-]
userbinator 1 days ago [-]
Good, another way to fight the loss of ownership and right-to-repair.
RicoElectrico 1 days ago [-]
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.
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.
Overall it just seemed like the processor definition for Ghidra needed more work.
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.
https://web.archive.org/web/20250402165042/https://wiki.rece...
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!
Edit: seems I could fix it, thanks!
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.
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.
Undocumented backdoor found in Bluetooth chip used by a billion devices
371 points | 25 days ago | 112 comments