[HN Gopher] Zero Day in Microchip SAM Microcontrollers
       ___________________________________________________________________
        
       Zero Day in Microchip SAM Microcontrollers
        
       Author : BitBangingBytes
       Score  : 52 points
       Date   : 2025-04-02 17:48 UTC (5 hours ago)
        
 (HTM) web link (wiki.recessim.com)
 (TXT) w3m dump (wiki.recessim.com)
        
       | pvg wrote:
       | Unhugged url
       | 
       | https://web.archive.org/web/20250402165042/https://wiki.rece...
        
       | liamkinne wrote:
       | 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.
        
       | boznz wrote:
       | 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 wrote:
         | All decoupling caps were removed so the voltage fault injection
         | could have maximum effect.
        
           | boznz wrote:
           | 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 wrote:
       | 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.
        
       | flowerthoughts wrote:
       | > 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 wrote:
         | 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!
        
       | Omni5cience wrote:
       | Minor nitpick, but Sam in the title should be SAM. (It's an
       | acronym.)
        
         | BitBangingBytes wrote:
         | 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 wrote:
       | >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.
        
       | dealbreaker wrote:
       | 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 wrote:
         | 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.
        
       | userbinator wrote:
       | Good, another way to fight the loss of ownership and right-to-
       | repair.
        
       ___________________________________________________________________
       (page generated 2025-04-02 23:00 UTC)