Open main menu

Changes

Glitch Explorer

249 bytes added, 20:17, 14 March 2018
Rewrote the page for cw4.0
The Glitch Explorer allows an automatic exploration of a range of one or more parameter values. It means that the user can test multiple glitch setups at the same time and see the result in a nice scatterplot, highlighting the successful attempts.
[[File:glitch explorer overviewglitch_explorer_overview_v4.pngPNG|1100px]]
== The Glitch Explorer Window ==
The main window of the glitch explorer looks like this:
[[File:Screen Shot 2016-07-15 at 10.24.13 AMglitch_explorer_window_v4.png|400px]]
In top, the output of the system combined with the parameters of the glitch is displayed (the 'output window').
In bottom, you can adjust general parameters of the glitching system, such as what counts as a successful glitch or not and how many parameters the ability to fiddle withload existing data into the glitch explorer table.
== Using the Glitch Explorer - The Basic Basics ==To start Here are a few steps that should be done before using the Glitch Explorer, glitch explorer (example uses the ChipWhisperer Lite):<ol><li> Connect the ChipWhisperer Scope and Target (example: run the <code>connect_cwlite_simpleserial.py</code> script)[[File: run_connect_script.png|800px]]</li><br><li>Set up the parameters for glitching (example: run the <code>connect_cwlite_glitch.py</code> script)[[File: run_glitch_script.png|800px]]</li><br><li>Setup the automatic reset aux module (example: run the <code>aux_reset_cw1173.py</code> script)[[ File: run_reset_aux_script.png|800px]]<br><b>Note: This file may have to be edited if you should first switch later have issues with trigger timeouts. The trigger timeouts can usually be fixed by switching the appropriate lines in a copy of the script</b><syntaxhighlight lang=python># Reset before arming - more stableaux_list.register(Resetter.resetThenDelay, "before_trace")# Reset after arming - scope can catch entire reset#aux_list.register(Resetter.delayThenReset, "after_arm")</syntaxhighlight>to <syntaxhighlight lang=python># Reset before arming - more stable#aux_list.register(Resetter.resetThenDelay, "before_trace")# Reset after arming - scope can catch entire resetaux_list.register(Resetter.delayThenReset, "after_arm")</syntaxhighlight><b> Another note: Remember to run this script and disable the other aux module inside the "Target Aux Settings" tab and set .</b></li><br><li>Change the glitch trigger source from manual to external single. Run this command in the python console:<code>self.scope.glitch.trigger_src = "Output Formatext_single" </code></li><br><li>Register the change_glitch_parameters function as the glitch explorer iterator (example: run the <code>ge_widthoffset_vary.py</code> script). Changes to the step size and range that the glitch explorer covers can be $GLITCH$customized by changing variables within this script and running the changed script. This will mean data is no longer sent to [[File: register_ge_iterator.png | 800px]]</li><br><li>Set the terminal emulator when normal and successful outputs (example: using the capture 1 or capture M buttons, but instead, is logged firmware in glitch-simple, after editing the c to use the glitch1() function rather than the glitch_infinite() function)[[File: set_responses.png | 400px]]</li><br><li>Open the glitch explorer windowgraph widget by pressing the <b>Plot Widget</b> button inside the Glitch Explorer Window.</li></ol>
Then, you should define what is a Normal and a Successful Response. This information is used to highlight the individual attacks. You should use Python expressions here, where 's' is a str-type variable which contains the response of the system (ex.: s.endswith("123456")).
The next step is Now you are ready to set click the number of tuning parameters. You may want "Capture M" to start with 1 (0 is used to just record manual the exploration attempts in the table) and then increment it to 2 or more later. This will generate another group in the list where you can tune the settings for each parameter: [[File:Screen Shot 2016-07-15 at 10.30.53 AM.png|400px]]* Name - is just a reminder of what we are tuning. * Parameter Path - defines what will be modified. This string can simply be copied from the Script Commands, provided that you remove the last element first (which is the value).* Data Format - defines what type of data will be inserted into the parameter.* Range - defines the range from the minimum to maximum that will be swept for the parameter.* Value - defines the current</start value of the sweep. This is NOT automatically set to the minimum value of your sweep since you may want to stop and continue later or attack a smaller number of traces. b>If you want run into forced trigger issues go back to perform the full sweep, you must manually set this to the minimum of the range or click reset.* Step - defines the incremented on each glitch attempt. When the value reaches the maximum defined by the range, previous steps where it will loop around to the minimum and continue incrementing.* Repeat - defines was mentioned how many times to perform fix the same valueissue. This can be used to determine the reliability of each glitch value.The last step is to set the "Generic Settings"-</b>"Acquisition Settings"->"Number of Traces" to a value high enough to loop trough all the value combinations. It can be performed automatically clicking in the "Glitch Explorer"->"Traces Required"->"Use this value" button. Now you are ready to click the "Capture M" to start the exploration.
== Using the Glitch Explorer - Advanced ==
To get more detailed information of how to use the Glitch Explorer, follow the [[Tutorial A2 Introduction to Glitch Attacks (including Glitch Explorer)|A2]] and [[Tutorial A3 VCC Glitch Attacks|A3]] tutorials.
If you want to create a script to fully automate this attack, check out the example in <code> chipwhisperer/software/scripting-examples/glitch_explorer_simple.py </code>.