Changes

Digital hardware devices almost always expect some form of reliable clock. We can manipulate the clock being presented to the device to cause unintended behaviour. We'll be concentrating on microcontrollers here, however other digital devices (e.g. hardware encryption accelerators) can also have faults injected using this technique.

This is the login code for the Linux OS. Note that if we could skip the check of <code>if (uid != 0)</code> and simply branch to the end, we could avoid having to enter a password. This is the power of glitch attacks - not that we are breaking encryption, but simply bypassing the entire authentication module!

The ChipWhisperer Glitch system uses the same synchronous methodology as it's Side Channel Analysis (SCA) capture. A system clock (which can come from either the ChipWhisperer or the Device Under Test (DUT)) is used to generate the glitches. These glitches are then inserted back into the clock, although it's possible to use the glitches alone for other purposes (i.e. for voltage glitching, EM glitching).

[[File:glitchgen-mux.png|frame|none]]

The phase shift blocks use the Digital Clock Manager (DCM) blocks within the FPGA. These blocks have limited support for run-time configuration of parameters such as phase delay and frequency generation, and for maximum performance the configuration must be fixed at design time. The Xilinx-provided run-time adjustment can shift the phase only by about +/- 5nS in 30pS increments (exact values vary with operating conditions).

If in the course of following this tutorial you find the FPGA appears to stop responding (i.e. certain features no longer work correctly), it could be the partial reconfiguration data is incorrect.

The portion of the GUI of interest to us is primarily located in this section:

If the Partial Reconfiguration system has been disabled (due to missing PR files or files differing from the FPGA bitstream) the two fields marked that say (as % of period) will be disabled. Only the fields labeled (fine adjust) will be available.

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>

The hardware is almost as in previous incarnations. The difference is the 'FPGAOUT' is bridged to the AVR clock. This example will use the CLKGEN feature.

[[File:glitchhw.jpg|image]]

We'll now look at glitching this routine. You should inspect the source code to determine that a simple series of calculations are performed:

If the routine works as expected, we would expect it to print <code>250000 500 500</code>. If a glitch interrupts the program flow, we would expect some of those values to be incorrect. This could be because a loop was skipped, an addition done incorrectly, or the program flow was exited unexpectedly.

To begin with, you'll simply use the manual glitch triggering. This works well in the examples where we have a simple loop we are breaking out of. Doing so requires modifying the glitch width and glitch offset experimentally. The exact values will vary for every device and setup.

! AVR on Multi-Target (CW301)

! CW-Lite XMEGA Board

|-

| Glitch Width (as % of period)

| 7.5

|-

| Glitch Offset (as % of period)

| -10

|-

| Repeat

| 5

| 105

|}

</li>

'''Be aware that you may crash the target!''' In the previous examples the target could have reset after each glitch. It may simply go into another infinite loop however, or even enter invalid states. Again force a hardware reset of the target in these cases. It may appear like the target was never glitched, whereas in reality it was glitched into some invalid state.

If we are going to start with the target at a pre-determined state, we need to reset the target. There are two ways of automatically performing this. The method used here will use the existing programmer interface to reset the device by performing that &quot;read signature&quot; operation we have already been using. The other method is to toggle a GPIO pin, which is more generic for future use.

To setup the automatic reset, perform the following:

We can now confirm the reset works with the &quot;Capture 1&quot; button. This requires us to disable the normal routing of the output data to a file for analysis, as we want to just dump data to the terminal emulator. To do this:

}

}</pre></li>

<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>

The manual trigger used previously is suitable when the embedded system is waiting for further input. For example if the embedded system is waiting for a password, you could insert glitches without requiring accurate timing. We'll explore the use of the capture trigger for glitching here, which also improves the repeatability of your glitch attempts.

<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>

Finally, we can enable the trigger of the glitch to occur based on this external trigger pin. This can be accomplished by:

<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>

Now that we can automatically perform the glitching, we can use the ''glitch explorer'' to automatically vary glitch parameters while recording what the target device is doing. Before continuing with the tutorial, we'll go through an overview of the the glitch explorer.

Where you can see the following parts

</blockquote>

We'll be looking at each of these sections in more detail next.

[[File:ge_top.png|image]]

Glitches can also be flagged as 'normal', in which case there is no highlight as in |2|. Finally the glitch could be flagged as an error, in which case it will be highlighted in red.

Details of the main settings:

The expected and desired responses are expected to be Python expressions, where <code>s</code> is a str-type variable which contains the response of the system. The expression must evaulate to <code>True</code> or <code>False</code>. For example, the following shows examples of what you could use as possible expressions:

! Parameter Expression

|-

|-

|-

| Check for hex 0xAF in last byte position.

Note that there is sometimes garbage in the first position. This occurs because if the target device is being reset before the glitch, you may see the serial lines floating. These floating lines may cause invalid characters to be recorded.

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>On the main GUI in the ''Scope Settings'' tab, change the following values for the ''Glitch Module'':</p>

<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>

<li><p>On the ''General Settings'' tab:</p>

<li>Set the ''Number of Traces'' to 121.</li></ol>

<li><p>With any luck, at least one of the glitches will be successful:</p>

<p>If you get a reset (prints 'hello' again), you might need to reduce the &quot;repeat&quot; 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 &quot;glitch width&quot;.</p></li></ol>

<ol style="list-style-type: decimal;">

</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>

This assumes you now have a set of parameters which caused a reliable glitch. We'll now glitch past a password check, initially using our trigger as a crutch. The function of interest compares a received password to some known password. The <code>glitch3()</code> function looks as follows:

<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>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>

</blockquote></li>

<li>Open the ''Glitch Explorer'', and press ''Capture 1''. You should see the ''Denied'' message come across.</li>

<li>Set the number of traces on the ''General Settings'' tab to 200.</li>

<li>On the main GUI, in the ''Scope Settings'' tab, ensure that you have the number of repeats on the ''Glitch Module'' set to 1. We will start with a single clock cycle glitched.</li>

<p>You can also increase the repeat count in the glitch explorer, which simply tries the same settings multiple times. You will likely find that the successful glitch does not have 100% success rate, so using a repeat count of 2 or 3 is helpful to increase your chances of success.</p></li></ol>

This basic tutorial has introduced you to glitch attacks. They are a powerful tool for bypassing authentication in embedded hardware devices. There are many ways to expand your knowledge with additional practice, such as:

* Use manual glitches to try simply glitching past the prompt in <code>glitch3()</code>.

* 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]].

[[Category:Tutorials]]