alt Hacker NewsZero Day in Microchip SAM Microcontrollers
Comments
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.
Excellent work!
Minor nitpick, but Sam in the title should be SAM. (It’s an acronym.)
>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.
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.
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.