Tutorial A7 Glitch Buffer Attacks - Revision history

Adewar at 13:38, 29 July 2019

2019-07-29T13:38:58Z

Show changes

Adewar at 21:00, 4 October 2018

2018-10-04T21:00:43Z

Show changes

Fheubach at 18:50, 1 May 2018

2018-05-01T18:50:51Z

Fheubach at 14:18, 1 May 2018

2018-05-01T14:18:24Z

Coflynn at 03:05, 6 November 2017

2017-11-06T03:05:28Z

Coflynn: /* Appendix: Setup Script */

2017-11-06T03:00:44Z

‎Appendix: Setup Script

Coflynn: /* Appendix: Setup Script */

2017-11-06T02:57:35Z

‎Appendix: Setup Script

Gdeon: /* Ideas */

2016-06-28T20:04:26Z

‎Ideas

Gdeon: /* Attack Script & Results */

2016-06-28T19:35:05Z

‎Attack Script & Results

Gdeon: /* Ideas */ Added script

2016-06-28T19:24:28Z

‎Ideas: Added script

@@ Line 216: / Line 216: @@
 </pre>
 {{Template:Tutorials}}
 [[Category:Tutorials]]

@@ Line 16: / Line 16: @@
 This tutorial discusses a specific type of glitch attack. It shows how a simple printing loop can be abused, causing a target to print some otherwise private information. This attack will be used to recover a plaintext without any knowledge of the encryption scheme being used.
-= Background =
+== Background ==
 This section introduces the attack concept by showing some real world examples of vulnerable firmware. Then, it describes the victim firmware that will be used in this tutorial.
-== Real Firmware ==
+=== Real Firmware ===
 Typically, one of the slowest parts of an embedded system is its communication lines. It's pretty common to see a processor running in the MHz range with a serial connection of 96k baud. To make these two different speeds work together, embedded firmware usually fills up a buffer with data and lets a serial driver print on its own time. This setup means we can expect to see code like
 <pre>
@@ Line 72: / Line 72: @@
 </pre>
-= The Attack Plan =
+== The Attack Plan ==
 Since we have access to the source code, let's take our time and understand how our attack is going to work before we dive in.
-== The Sensitive Code ==
+=== The Sensitive Code ===
 Inside <code>bootloader.c</code>, there are two buffers that are used to store most of the important data. The source code shows:
 <pre>
@@ Line 104: / Line 104: @@
 This looks very similar to the example code given in the previous section, so it should be vulnerable to a glitching attack. The goal is to cause the loop to continue past its regular limit: <code>data_buffer[0]</code> is the same as <code>ascii_buffer[80]</code>, so a successful glitch should dump the data buffer for us.
-== Disassembly ==
+=== Disassembly ===
 As a final step, let's check the assembly code to see exactly what we're trying to glitch through. Run the command
 <pre>
@@ Line 124: / Line 124: @@
 There's one quirk to notice in this code. In the C source, the for loop checks whether <code>i < ascii_idx</code>. However, in the assembly code, the check is effectively whether <code>i == ascii_idx</code>! This is even easier to glitch - as long as we can break past the <code>brne</code> instruction ''once'', we'll get to the data buffer.
-= Attack Script & Results =
+== Attack Script & Results ==
 To speed up the tutorial, the script in [[#Appendix: Setup Script]] will open the ChipWhisperer Capture software and fill in all of the appropriate settings. Copy this code into a Python script and run it. Then, open the serial terminal and connect to the target, using the ASCII with Hex display mode. If everything is set up correctly, the Capture 1 button should cause the text <code>r0</code> to appear in the terminal. This is the bootloader's response to a block of ciphertext.
@@ Line 142: / Line 142: @@
 If you can't get this to work, remember that glitching is a very sensitive operation - one glitch timing will probably not work for every board on every day. Try using the glitch explorer to attack different ''Glitch Width''s, ''Glitch Offset''s, and ''Ext Trigger Offset''s. The built-in Glitch Explorer will be very useful here - take a read through [[Tutorial A2 Introduction to Glitch Attacks (including Glitch Explorer)]] if you need a refresher.
-= Ideas =
+== Ideas ==
 There's a lot more that can be done with this type of attack...
-== Safer Assembly Code ==
+=== Safer Assembly Code ===
 You may have been surprised to see that the assembly code uses a <code>brne</code> instruction to check if the loop is finished - after all, we used a less-than comparison in our C source code! Try changing this line to use a more prohibitive loop. Here's how you might do this:
 # Find a copy of the [http://www.atmel.com/webdoc/avrassembler/index.html AVR assembler documentation] and find a better instruction to use. You should be able to drop in the <code>brlt</code> instruction without much hassle. Figure out the new op-code for this instruction.
@@ Line 151: / Line 151: @@
 # Upload your new bootloader onto the target and retry the attack. Does it still work? You might be able to see one extra byte from the ASCII buffer, but it will be very difficult to get to the data buffer. Can you change the glitch settings to complete the attack?
-== Volatile Variables ==
+=== Volatile Variables ===
 The reason why the original assembly code used the <code>brne</code> instruction is because GCC is an ''optimizing compiler''. The compiler doesn't directly translate the C source code into assembly instructions. Instead, it tries to determine if any of the code can be modified to make it faster or more compact. For instance, consider the loop
 <pre>
@@ Line 183: / Line 183: @@
 Try changing the bootloader's source code to use a volatile variable inside the loop. What happens to the disassembly? Is the loop body longer? Connect to the target board and capture a power trace. Does it look different? You'll have to find a new ''Ext Trigger Offset'' for the glitch module. Can you still perform the attack? Is it feasible to use this fix to avoid glitching attacks?
-= Appendix: Setup Script =
+== Appendix: Setup Script ==
 The following script is used to set up the ChipWhisperer-Lite with all of the necessary settings:
 <pre>

← Older revision		Revision as of 03:05, 6 November 2017
Line 1:		Line 1:
		+	{{Warningbox\|This tutorial has been updated for ChipWhisperer 4.0.0 release. If you are using 3.x.x see the "V3" link in the sidebar.}}
		+
		+	{{Infobox tutorial
		+	\|name = A7: Glitch Buffer Attacks
		+	\|image =
		+	\|caption =
		+	\|software versions =
		+	\|capture hardware = CW-Lite
		+	\|Target Device =
		+	\|Target Architecture = XMEGA
		+	\|Hardware Crypto = No
		+	\|Purchase Hardware =
		+	}}
		+
		+
	This tutorial discusses a specific type of glitch attack. It shows how a simple printing loop can be abused, causing a target to print some otherwise private information. This attack will be used to recover a plaintext without any knowledge of the encryption scheme being used.		This tutorial discusses a specific type of glitch attack. It shows how a simple printing loop can be abused, causing a target to print some otherwise private information. This attack will be used to recover a plaintext without any knowledge of the encryption scheme being used.

@@ Line 196: / Line 196: @@
 scope.io.hs2 = "glitch"
-target.go_cmd = ""
+target.go_cmd = "p516261276720736265747267206762206f686c207a76797821\\n"
 target.key_cmd = ""
-target.output_cmd = "p516261276720736265747267206762206f686c207a76797821\\n"
+target.output_cmd = ""
 </pre>

@@ Line 171: / Line 171: @@
 The following script is used to set up the ChipWhisperer-Lite with all of the necessary settings:
 <pre>
-import sys
+# GUI compatibility
-import chipwhisperer.capture.ui.CWCaptureGUI as cwc
-from chipwhisperer.common.api.CWCoreAPI import CWCoreAPI
-from chipwhisperer.common.scripts.base import UserScriptBase
-from chipwhisperer.common.utils.parameter import Parameter
-−
-# Check for PySide
 try:
-     from PySide.QtCore import *
+     scope = self.scope
-    from PySide.QtGui import *
+     target = self.target
-except ImportError:
+except NameError:
-    print "ERROR: PySide is required for this program"
+    pass
-    sys.exit()
-−
-class UserScript(UserScriptBase):
-    def __init__(self, api):
-        super(UserScript, self).__init__(api)
-−
-     def run(self):
-        #User commands here
-        print "***** Starting User Script *****"
-−
-        # Set up board and target
-        self.api.setParameter(['Generic Settings', 'Scope Module', 'ChipWhisperer/OpenADC'])
-        self.api.setParameter(['Generic Settings', 'Trace Format', 'ChipWhisperer/Native'])
-        self.api.setParameter(['Generic Settings', 'Target Module', 'Simple Serial'])
-        self.api.connect()
-−
-        # Fill in our other settings
-        lstexample = [['OpenADC', 'Gain Setting', 'Mode', 'high'],
-                      ['OpenADC', 'Gain Setting', 'Setting', 30],
-                      ['OpenADC', 'Trigger Setup', 'Mode', 'rising edge'],
-                      ['OpenADC', 'Trigger Setup', 'Total Samples', 500],
-                      ['OpenADC', 'Trigger Setup', 'Offset', 0],
-                      ['OpenADC', 'Clock Setup', 'CLKGEN Settings', 'Divide', 26],
-                      ['OpenADC', 'Clock Setup', 'CLKGEN Settings', 'Multiply', 2],
-                      ['OpenADC', 'Clock Setup', 'ADC Clock', 'Source', 'CLKGEN x4 via DCM'],
-                      ['OpenADC', 'Clock Setup', 'ADC Clock', 'Reset ADC DCM', None],
-                      ['CW Extra Settings', 'Target HS IO-Out', 'CLKGEN'],
-                      ['CW Extra Settings', 'Target IOn Pins', 'Target IO2', 'Serial TXD'],
-                      ['CW Extra Settings', 'Target IOn Pins', 'Target IO1', 'Serial RXD'],
-                      ['Glitch Module', 'Clock Source', 'CLKGEN'],
-                      ['Glitch Module', 'Glitch Width (as % of period)', 3.0],
-                      ['Glitch Module', 'Glitch Offset (as % of period)', -5.0],
-                      ['Glitch Module', 'Glitch Trigger', 'Ext Trigger:Single-Shot'],
-                      ['Glitch Module', 'Ext Trigger Offset', 68],
-−
-                      ['Simple Serial', 'Go Command', u'p516261276720736265747267206762206f686c207a76797821\\n'],
-                      ['Simple Serial', 'Output Format', u''],
-                      ['Simple Serial', 'Load Key Command', u''],
-−
-−
-        # NOTE: For IV: offset = 70000
-        #Download all hardware setup parameters
-        for cmd in lstexample:
-            self.api.setParameter(cmd)
-        # Try a couple of captures
+scope.glitch.clk_src = 'clkgen'
-        self.api.capture1()
+scope.glitch.ext_offset = 68
-        print "***** Ending User Script *****"
+scope.gain.gain = 45
 </pre>
 {{Template:Tutorials}}
 [[Category:Tutorials]]

← Older revision		Revision as of 19:35, 28 June 2016
Line 110:		Line 110:

	= Attack Script & Results =		= Attack Script & Results =
		+	To speed up the tutorial, the script in [[#Appendix: Setup Script]] will open the ChipWhisperer Capture software and fill in all of the appropriate settings. Copy this code into a Python script and run it. Then, open the serial terminal and connect to the target, using the ASCII with Hex display mode. If everything is set up correctly, the Capture 1 button should cause the text <code>r0</code> to appear in the terminal. This is the bootloader's response to a block of ciphertext.
		+
		+	Once this is set up, connect the glitch module's output to the target's clock. Do this by changing the <code>Target HS IO-Out</code> to <code>Glitch Module</code>. Try to Capture 1 again and watch the serial terminal. If you're lucky, a large amount of text will appear in this window:
		+	<pre>
		+	r0
		+	261276720736265747267206762206f686c207a767978210000000000000000000000000000000000000000000000
		+	00000000000000Don't forget to buy milk!000000000000000000000000000000000000000000000000000000
		+	000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
		+	000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
		+	000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
		+	...
		+	<many more lines omitted>
		+	</pre>
		+	In the middle of this output, the plaintext is clearly visible! The data buffer has successfully been printed to the serial port, allowing us to see the decrypted text with no knowledge of the algorithm.
		+
		+	If you can't get this to work, remember that glitching is a very sensitive operation - one glitch timing will probably not work for every board on every day. Try using the glitch explorer to attack different ''Glitch Width''s, ''Glitch Offset''s, and ''Ext Trigger Offset''s. The built-in Glitch Explorer will be very useful here - take a read through [[Tutorial A2 Introduction to Glitch Attacks (including Glitch Explorer)]] if you need a refresher.

	= Ideas =		= Ideas =

@@ Line 114: / Line 114: @@
 * Change hex file to use BRLT
 * Use volatile loop variables
 {{Template:Tutorials}}
 [[Category:Tutorials]]