Zero Day in Microchip SAM Microcontrollers

https://wiki.recessim.com/view/ATSAM4C32

by BitBangingBytes • 1 year ago

74 20 1 year ago

wiki.recessim.com

pvg• 1 year ago

Unhugged url

https://web.archive.org/web/20250402165042/https://wiki.rece...

liamkinne• 1 year 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.

boznz2• 1 year 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.

BitBangingBytes4• 1 year ago

All decoupling caps were removed so the voltage fault injection could have maximum effect.

boznz2• 1 year 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.

RicoElectrico• 1 year 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.

bobmcnamara2• 1 year ago

Which ESP backdoor?

aspenmayer• 1 year ago

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

flowerthoughts2• 1 year 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!

BitBangingBytes4• 1 year 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!

flowerthoughts2• 1 year ago

Amazing!

Omni5cience• 1 year ago

Minor nitpick, but Sam in the title should be SAM. (It’s an acronym.)

BitBangingBytes4• 1 year 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 year 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.

dealbreaker2• 1 year ago

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.

BitBangingBytes4• 1 year 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.

dealbreaker2• 1 year 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.

userbinator• 1 year ago

Good, another way to fight the loss of ownership and right-to-repair.

josephcsible• 1 year ago

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.

Zero Day in Microchip SAM Microcontrollers

Related Stories