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
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 ==
! Parameter
! 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>
=== 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.
<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 ==
