ATSAM4C32: Difference between revisions

← Older edit

VisualWikitext

@@ Line 1: / Line 1: @@
 ==Bypassing Lock - Microchip/Atmel SAM4C32==
+Hash Salehi
 ===Introduction===
@@ Line 66: / Line 67: @@
 ===Voltage Fault Injection===
-The animation below shows faults being injected into the VDDCORE supply approaching the voltage fluctuation. When it lands in the correct place on top of the fluctuation the process stops. The animation then starts over. It stops because JTAG was enabled on the processor and OpenOCD was able to connect halting the glitching script.
+The video below shows faults being injected into the VDDCORE supply approaching the voltage fluctuation. When it lands in the correct place on top of the fluctuation the process stops. It stops because JTAG was enabled on the processor and OpenOCD was able to connect halting the glitching script.
-[[File:ATSAM4C32 - Oscilloscope Glitch Animation.mov]]<br />
+The triggered traces jump around so much because I am triggering on the rising edge of VCC 3.3V and this rising edge varies for reasons such as the capacitance of the chipwhisperer breakout board being used and the power supply itself.
+[[File:ATSAM4C32 - Oscilloscope Glitch Animation.mov|800px]]<br />
+The image below shows the aggressive glitch parameters used. This value was initially guessed and worked, narrower or wider glitches were not tested.
+[[File:ATSAM4C32 Glitch Z2 with cursors.png|none|thumb|612x612px|Glitch width approximately 2uS]]
+<br />
 ----
 ===JTAG Access===
-TBD
+OpenOCD in Ubuntu and an ATMEL-ICE programmer were used to connect to the SAM4C32. Microchip Studio IDE in a Windows VM was used to set the security bit, although this functionality appears to be available in OpenOCD I never tested it.
+When the security bit is bypassed the following commands can be run, shown with their associated output
+====at91sam4 info====
+ > at91sam4 info
+     CKGR_MOR: [0x400e0420] -> 0x00000008
+ 	    MOSCXTEN:     0 [0x0000] (main xtal enabled: NO)
+ 	    MOSCXTBY:     0 [0x0000] (main osc bypass: NO)
+ 	    MOSCRCEN:     1 [0x0001] (onchip RC-OSC enabled: YES)
+ 	     MOSCRCF:     0 [0x0000] (onchip RC-OSC freq: 4 MHz)
+ 	    MOSCXTST:     0 [0x0000] (startup clks, time= 0.000000 uSecs)
+ 	     MOSCSEL:     0 [0x0000] (mainosc source: internal RC)
+ 	       CFDEN:     0 [0x0000] (clock failure enabled: NO)
+    CKGR_MCFR: [0x400e0424] -> 0x000107a0
+ 	    MAINFRDY:     1 [0x0001] (main ready: YES)
+ 	       MAINF:  1952 [0x07a0] (3.998 Mhz (32.768khz slowclk)
+   CKGR_PLLAR: [0x400e0428] -> 0x00003f00
+ 	        DIVA:     0 [0x0000]
+ 	        MULA:     0 [0x0000]
+ 	PLLA Freq: (Disabled,mula = 0)
+    CKGR_UCKR: [0x400e041c] -> 0x00000000
+     PMC_FSMR: [0x400e0470] -> 0x00000000
+     PMC_FSPR: [0x400e0474] -> 0x00000000
+      PMC_IMR: [0x400e046c] -> 0x00000000
+     PMC_MCKR: [0x400e0430] -> 0x00000001
+ 	         CSS:     1 [0x0001] mainosc (3.998 Mhz)
+ 	        PRES:     0 [0x0000] (selected clock)
+ 		Result CPU Freq: 3.998
+     PMC_PCK0: [0x400e0440] -> 0x00000000
+     PMC_PCK1: [0x400e0444] -> 0x00000000
+     PMC_PCK2: [0x400e0448] -> 0x00000000
+     PMC_PCSR: [0x400e0418] -> 0x00000000
+     PMC_SCSR: [0x400e0408] -> 0x00000003
+       PMC_SR: [0x400e0468] -> 0x00030018
+  CHIPID_CIDR: [0x400e0740] -> 0xa64d0ee0
+ 	     Version:     0 [0x0000]
+ 	       EPROC:     7 [0x0007] Cortex-M4
+ 	     NVPSIZE:    14 [0x000e] 2048K bytes
+ 	    NVPSIZE2:     0 [0x0000] none
+ 	    SRAMSIZE:    13 [0x000d] 256K Bytes
+ 	        ARCH:   100 [0x0064] SAM4CxxC (100-pin version)
+ 	      NVPTYP:     2 [0x0002] embedded flash memory
+ 	       EXTID:     1 [0x0001] (exists: YES)
+  CHIPID_EXID: [0x400e0744] -> 0x00000000
+    rc-osc: 4.000 MHz
+   mainosc: 3.998 MHz
+      plla: 0.000 MHz
+  cpu-freq: 3.998 MHz
+ mclk-freq: 3.998 MHz
+  UniqueId: 0x20000c00 0x01006df3 0x010046af 0x010046b3
+====reg====
+ > reg
+ ===== arm v7m registers
+ (0) r0 (/32): 0x00000000
+ (1) r1 (/32): 0x00000000
+ (2) r2 (/32): 0x00000000
+ (3) r3 (/32): 0x00000000
+ (4) r4 (/32): 0x00000000
+ (5) r5 (/32): 0x00000000
+ (6) r6 (/32): 0x00000000
+ (7) r7 (/32): 0x00000000
+ (8) r8 (/32): 0x00000000
+ (9) r9 (/32): 0x00000000
+ (10) r10 (/32): 0x00000000
+ (11) r11 (/32): 0x00000000
+ (12) r12 (/32): 0x00000000
+ (13) sp (/32): 0xffffffd8
+ (14) lr (/32): 0xfffffff9
+ (15) pc (/32): 0xfffffffe
+ (16) xPSR (/32): 0x01000003
+ (17) msp (/32): 0xffffffd8
+ (18) psp (/32): 0x00000000
+ (20) primask (/1): 0x00
+ (21) basepri (/8): 0x00
+ (22) faultmask (/1): 0x00
+ (23) control (/3): 0x00
+ ===== Cortex-M DWT registers
+====at91sam4 gpnvm====
+Note below GPNVM bit 0 says its current value is 0 due to the glitch, if the processor is reset we lose access and it goes back to 1.
+ > at91sam4 gpnvm
+ sam4-gpnvm0: 0
+ sam4-gpnvm1: 1
+ sam4-gpnvm2: 1
 ----
 ===Other Vulnerable Devices===
-TBD
+Microchip (ATMEL) families
+[[File:ATMEL SAM Family Overview.jpg|650x650px]]
+This list is not exhaustive, there may be more that are vulnerable and do not show up in this main overview of devices provided by Microchip. Only the '''bold''' ones are confirmed, the others are assumed vulnerable because the datasheet specifies the use of GPNVM bits for security.
+*'''SAM E70/S70/V70/V71'''
+*'''SAM 4C'''
+*SAM 4E
+*SAM 4N
+*'''SAM 4S'''
+*SAM G51/G54/G55
+*SAM 3X/3A
+The following datasheets were reviewed and '''''did not''''' show the use of GPNVM bits for security protection. This does not mean they are secure, but this specific vulnerability may not be present.
+*SAM 4L
+*SAM L10/L11
+*SAM L21/L22
+*SAM C20/C21
+*SAM D10/D11/D21/DA1/D5x/E5x/D20
 ----
 ===Conclusion===
-TBD
+Many devices in the Microchip (ATMEL) SAM Family make use of GPNVM bits to secure access to the JTAG debug interface. This protection can be bypassed using voltage glitching allowing full access to the device. It appears this is a low-level hardware bug, likely not patchable in the field.
+===Disclosure===
+Full disclosure at time of discovery via YouTube. Enjoy!<br>
+<youtube width="640" height="360">IOD5voFTAz8</youtube>
+<br />