Approved_users, administrator
366
edits
| As of August 2020 the site you are on (wiki.newae.com) is deprecated, and content is now at rtfm.newae.com. |
Changes
→Using the Glitch Explorer
|capture hardware = CW-Lite
|Target Device =
|Target Architecture = XMEGA/Arm
|Hardware Crypto = No
|Purchase Hardware =
}}
This advanced tutorial will demonstrate clock glitch attacks using the ChipWhisperer system. This will introduce you to many required features of the ChipWhisperer system when it comes to glitching. This will be built on in later tutorials to generate voltage glitching attacks, or when you wish to attack other targets.
'''If you're working on an STM32F3/CW303 Arm target, it's recommended that you have the latest updates from the develop branch. Recent firmware changes have made glitching far more reliable.'''
== Background on Clock Glitching ==
=== Firmware Setup ===
For this example, we'll be using the <code>glitch-simple</code> firmware.
{{CollapsibleSection
|intro = ==== Building for CWLite with XMEGA Target ====
|content= Building for XMEGA}}
You should also open the file <code>glitchsimple.c</code> which is the source code. The subroutine being glitched in this example looks like this:
return 1;
}</pre>
=== Hardware Setup ===
{{CollapsibleSection
|intro = ==== CW1173 (Lite) Hardware Setup ====
|content= CWLite HW Setup}}
{{CollapsibleSection|intro ==== XMEGA Target = CW1200 (CW1173 + CW303Pro) Hardware Setup ====|content=CW1200 HW Setup}}
==== Multi-Target Board, AVR (CW301) ====
[[File:glitchhw.jpg|image]]
=== Programming the Target ===
{{CollapsibleSection|intro = === Programming the XMEGA Target ===|content = Programming XMEGA}}
{{CollapsibleSection|intro = === Programming the Arm Target ===|content = Programming Arm}}
{{CollapsibleSection|intro = === Programming Other Targets ===|content = Programming Other}}
=== Software Setup ===
Assuming you still have ChipWhisperer setup as described in the programming step (aka have run connect_simpleserial.py and the setup script for your target), there's only a few modifications we need to make to be able to glitch:<ol style="list-style-type: decimal;"><li><p>Connect to the ChipWhisperer device:</p><blockquote><ol style="list-style-type: decimal;"><li>As the Under ''Scope ModuleSettings'', select the change ''ChipWhisperer/OpenADC'' option</liCW Extra Settings><li>As the ''Target ModuleHS IO-Out'', select the ''Simple Serial'' option</li><li>Switch to the ''Scope SettingsGlitch Module'' tab, and as the ''connectionGlitch Module>Clock Source'', select the ''NewAE USB (CWLite/CW1200)'' or ''Serial Port (LX9)'' option</li><li>Switch to the ''Target SettingsCLKGEN'' tab, and as . This routes the ''connection'', select clock source for the ''NewAE USB (CWLite/CW1200)'' or ''Serial Port (LX9)'' option</li><li>Run connect on both microcontroller through the Scope & Target. They should both switch to green circles indicating the system is connectedglitch module.</li></ol></blockquotep></li><li><p>Setup the CLKGEN Module to Generate a 7.37 MHz clock and route it through the Glitch Generator</p><blockquote><ol style="list-style-type: decimal;"><li>Switch From the ''Freq Counter SrcTools'' to the menu, select ''CLKGEN OutputOpen Terminal''</li><li>Set the ''Desired Frequency'' to 7.37 MHz. Note you should only adjust the 'frequency' portion of this, if you highlight the entire field you may not be able to type the frequency into the system.</li><li>Confirm the and press ''DCM LockedConnect'' checkbox is checked, if not hit on the ''Reset CLKGEN DCM'' boxterminal. Check the ''Freq Counter'This will allow us to see what' s being sent to ensure and from the system is correctly generating a 7.37 MHz clock.</li><li><p>Under the ''Glitch Module'' set the ''Clock Source'' as ''CLKGEN''microcontroller:</p><p>[[File:glitchgen-clkgenTermconn.png|imageframeless|371x371px]]</p></li><li><p>Under Reset the ''Target HS IO-Out'' option select the ''Glitch Module'':</p><p>[[File:targiooutdevice.png|image]]</p></li></ol></blockquote></li><li><p>Connect the Serial Port</p><blockquote><ol style="list-style-type: decimal;"><li>For the XMEGA Target (including the CW-Lite integrated target), perform the following:<ol style="list-style-type: lower-alpha;"><li>Switch You can do this by going to the ''Scope Settings'' tab, and scroll down to switching ''CW Extra Settings>Target IOn Pins''</liGPIO Mode><li>Switch the nRST: GPIO''Target IO1(or '' to be PDIC: GPIO''Serial RXD''</li><li>Switch , for the XMEGA target) to ''Target IO2Low'' , then back to be ''Serial TXDDefault''</li></ol></li><li><p>From the ''Tools'' menu select ''Open Terminal'. If you're using a target that can be programmed from ChipWhisperer, and press running ''ConnectCheck Signature'' on from the terminal:</p><blockquote><p>[[File:termconn.png|image]]</p></blockquote></li><li>The baud rate for this system is 38400, which should be the default for the ChipWhisperer serial port.</li><li><p>Using the target programmer programming window, we will use the Read Signature or Check Signature button to also reset the target every time we want to restart the programdevice. Confirm this works by pressing the Read Signature button, for example if using the ChipWhisperer-Lite integrated programmer, you would see this window:</p><p/li>[[File:xmegaprog_main.png|image]]</pli><p>But if using the external AVR Studio programmer for the ChipWhisperer Capture Rev2, you would You should see this window:</p><p>[[File:readsig.png|image]]</p><p>When you press this button text populate the AVR will display the Hello message, which should look something like thisterminal:</p><p>[[File:termhelloTermhello.png|imageframeless|506x506px]]</p><blockquote><p>'''tip'''</p><p>If you uncheck the ''RX: Show non-ASCII as hex'' you will not see the red text with ASCII values of newline (<code>0a</code>).</p></blockquote><blockquote><p>'''hint'''</p><p>Sometimes the "reset" message won't appear. This happens often on the virtual machine version, or if your host computer is slow or loaded. Generally you can ignore this error, for example in the video version the welcome message is never printed. You will just have to trust the system is resetting correctly.</p></blockquote></li></ol></blockquote></li></ol>
We'll now look at glitching this routine. You should inspect the source code to determine that a simple series of calculations are performed:
! AVR on Multi-Target (CW301)
! CW-Lite XMEGA Board
!CW-Lite Arm Board
|-
| Glitch Width (as % of period)
| 7.5
| 9.5
| -10
|-
| Glitch Offset (as % of period)
| -10
| -2
| -40
|-
| Repeat
| 5
| 105
|105
|}
</li>
<ol>
<li> Scroll down the list of scripts, and you'll find one labeled "aux_reset_cw1173.py". Depending on your target, you may have to modify this script to change the reset pin. Most targets (except for the XMEGA) use ''nrst'', so if you're unsure, this is usually the correct choice . This script sets up the aux module that attempts to reset the XMEGA target device using the programmer. <b>Note: The aux module is only executed after capture is executed.</b>
<br>
[[File:auxreset_test1.png|600px]]
}
}</pre></li>
<li><p>When you perform a ''Capture 1'', the terminal should print <code>hello\nA</code>, based on the above source code. Note the objective will be to glitch past the infinite loop, such that <code>1234</code> is printed. If using the XMEGA target CW303 board , this will also turn light the red LED on the RED ledboard up.</p>
<blockquote><p>'''hint'''</p>
<p>If the startup message isn't visible, it may be related to issues with the Capture software not being fast enough after reset to display the serial port contents on the terminal emulator. This happens often on the virtual machine environment, as can be seen in the demo video. You can ignore this error for now.</p></blockquote></li></ol>
<ol style="list-style-type: decimal;">
<li><p>Press ''Capture 1'', confirm some waveform is displayed. For example with the XMEGA Target on the ChipWhisperer-Lite, the waveform looks like this:</p>
<p>[[File:basic_waveform.png|image]]</p></li>
<li><p>Performing a ''Capture 1'', you'll notice that the waveform is now perturbed. This is due to the clock glitches causing odd power consumption behavior:</p>
<p>[[File:basic_waveform_glitchy.png|image]]</p></li>
<li>Play around a bit with the glitch width, offset, and repeat. You should see different effects in the power consumption traces.</li></ol>'''From this point on, you may want to disable displaying of traces, as this will speed up giltching significantly. To do this, go to ''Results>Trace Output Plot>Input'' and change it to ''None''.'''
== Using the Glitch Explorer ==
=== Example Running the Glitch Explorer ===
==== XMEGA ====
This example will attempt to break out the loop in <code>glitch1()</code>. Moving ahead from where you were in [[#Automatically Triggering Glitch]], we will see how we can view the output of the target device in the glitch explorer.
<li><p>On the main GUI in the ''Scope Settings'' tab, change the following values for the ''Glitch Module'':</p>
<ol style="list-style-type: lower-alpha;">
<li>''Repeat'' set to 10105.</li>
<li>''Glitch Width (as % of period)'' set to 8.0.</li></ol>
<p>These values will be used during the glitch explorer run. We have not specified anything for the tuning, so they will not be changed from whatever is already in the GUI.</p></li>
<p>If you get a reset (prints 'hello' again), you might need to reduce the "repeat" value. If you have no successful glitches, double-check all settings. You can continue to the next step anyway, as in that step we will also tune the "glitch width".</p></li></ol>
We may also need to tune the "Glitch Width". We can use knowledge of the successful glitch from the previous step to reduce our search space. In this case, assume we had a successful glitch with a width of 8.0 and offset of -2. We'll search around those values to see if we can achieve a more successful glitch performance.
==== Arm ====
This example will attempt to break out the loop in <code>glitch1()</code>. Moving ahead from where you were in [[#Automatically Triggering Glitch]], we will see how we can view the output of the target device in the glitch explorer.<ol style="list-style-type: decimal;">
<li><p>Switch to the ''Target Settings'' tab, and set the ''Output Format'' to be <code>$GLITCH$</code>:</p>
<p>[[File:output_glitch.png|image]]</p></li>
<li>From the ''Tools'' menu select ''Glitch Monitor'' to open the glitch explorer.</li>
<li><p>Press the ''Capture 1'' button a few times, and you should see the table populated with outputs:</p>
<p>[[File:ge_setup1.png|image]]</p>
<p>We want to mark them as "normal" or "glitch successful" to get the color-coding working appropriately.</p></li>
<li>Double-click on a normal response, and copy the text. In the ''Normal Response'' field, we need to compare the magic variable <code>s</code> with that copied text. Do this by setting the ''Normal Response'' to be: <code>s == '\x00hello\nA'</code>.</li>
<li>We want to mark a string ending with <code>1234</code> as a pass. Thus in the ''Successful Response'' field, set the test to be <code>s.endswith('1234')</code> (remember in Python both <code>'</code> and <code>"</code> are valid for string start/end characters).</li>
<li><p>Press ''Capture 1'' a few more times, and check the color-coding has changed:</p>
<p>[[File:ge_setup2.png|image]]</p></li></ol>
The next step is to tune the glitch offset to attempt to get a successful clock glitch. These steps are listed as follows:
<ol style="list-style-type: decimal;">
<li>Make a new file called '<nowiki/>''ge_adjustment.py'' with these contents:
<syntaxhighlight lang="python">
class IterateGlitchParameters(object):
def __init__(self, ge_window):
self._starting_offset = -45
self.ge_window = ge_window
def reset_glitch_to_default(self, scope, target, project):
""" Set glitch settings to defaults. """
self.offset = self._starting_offset
def change_glitch_parameters(self, scope, target, project):
""" Example of simple glitch parameter modification function. """
# This value is minimum clock offset/width increment
self.offset += 0.390625
if self.offset > 40:
self.offset = self._starting_offset
# Write data to scope
scope.glitch.offset = self.offset
#You MUST tell the glitch explorer about the updated settings
if self.ge_window:
self.ge_window.add_data("Glitch Offset",scope.glitch.offset)
glitch_iterator = IterateGlitchParameters(self.glitch_explorer)
self.aux_list.register(glitch_iterator.change_glitch_parameters, "before_trace")
self.aux_list.register(glitch_iterator.reset_glitch_to_default, "before_capture")
</syntaxhighlight>
</li>
<li><p>Assuming you still have the "Capture" working, you can simply find where you stored that script and hit ''Run''. You should see it execute successfully on the command line.:</p>
<p>[[File:ge_step1_register.png|1000px]]</p></li>
<li><p>Confirm you see the modules loaded in the ''Aux Settings'' tab:</p>
<p>[[File:ge_step2_checkregister.png]]</p></li>
<li><p>On the main GUI in the ''Scope Settings'' tab, change the following values for the ''Glitch Module'':</p>
<ol style="list-style-type: lower-alpha;">
<li>''Repeat'' set to 1.</li>
<li>''Glitch Width (as % of period)'' set to -10.</li></ol>
<p>These values will be used during the glitch explorer run. We have not specified anything for the tuning, so they will not be changed from whatever is already in the GUI.</p></li>
<li><p>On the ''General Settings'' tab:</p>
<ol style="list-style-type: lower-alpha;">
<li>Set the ''Number of Traces'' to 121.</li></ol>
</li>
<li><p>With any luck, at least one of the glitches will be successful:</p>
<p>If you start getting ADC timeouts and the device stops responding, you may have to reduce ''Glitch Width (as % of period)'' to be closer to 0.</p></li></ol>
==== Finishing the Tutorial ====
We may also need to tune the "Glitch Width". We can use knowledge of the successful glitch from the previous step to reduce our search space. In this case, assume we had a successful glitch with a width of 8.0 and offset of -2. We'll search around those values to see if we can achieve a more successful glitch performance.
<ol style="list-style-type: decimal;">
<li>Modify the glitch parameter script to also loop through the Glitch Width. If you get stuck you can look at the example script earlier (in section [[#Parameter_Settings]]).</li>
<li>Change To make glitching more likely, you'll also want to change the ''Range'' range of the first parameter ''Glitch Offset'' to span from 1 to 25use values around successful ones. For example, since it appeared that negative positive glitch offsets were never successful in our previous attempts. Be sure to reset typically work well for the ''Value'' of this parameter to your desired starting point (probably ''1''). This will reduce XMEGA target, while negative ones work better for the search timeCW303 Arm target.</li><li>On the main GUI in the ''Scope Settings'' tab, adjust the ''Glitch Module'' repeat parameter to be 1. We are now attempting to acheive achieve success with a single clock cycle being glitched.</li>
<li>Still in the main GUI, adjust the number of traces per capture to be 1000. This reflects the number of iterations required to run through both loops (20 x 50).</li>
<li>Hit the ''Capture Multi'' button and cross your fingers! Hopefully you will see a successful glitch for some combination of glitch width and offset. We aren't quite done yet, as you will also need to do some fine-tuning to achieve high reliability on the glitch.</li></ol>
<p>You might want to try seeing if there is an upper limit to this setting, and putting it mid-way between the lower and upper limits for generating a glitch.</p></li></ol>
Congrats! You've now performed some tuning to achieve a reliable glitch on the target device. The next step is to glitch something more fun - like a password check.
== Glitching a Password Check ==
<li>Close the glitch explorer.</li>
<li>Modify the file <code>glitchexample.c</code> to call <code>glitch3()</code> instead of <code>glitch1()</code>, which is to say simply change the main function called from <code>main()</code> to <code>glitch3()</code>.</li>
<li>Run R<code>make</code> in ebuild the folder <code>chipwhisperer\hardware\victims\firmware\glitch-simple</code>.</li>
<li>Program the target device with your <code>.hex</code> file.</li>
<li>On the ''Target Settings'' tab, clear the ''Output Format'' field. That is remove the <code>$GLITCH$</code> text, as we are no longer using the glitch explorer. If you don't do this, you will not see any output of the device on the terminal emulator.</li>
* Use manual glitches to try simply glitching past the prompt in <code>glitch3()</code>.
* Completing [[Tutorial A3 VCC Glitch Attacks]], which introduces glitching via voltage instead of the clock.
* Using the ChipWhisperer Python API to make GUI-less scripts. For examples of using scripting, see [[Making Scripts]].
* Download some example source code (bootloaders, login prompts, etc) and port them to the AVR. See how you can glitch past security checks.
* Use one of the IO triggers discussed in [[Tutorial_A1_Synchronization_to_Communication_Lines]].
