As of August 2020 the site you are on (wiki.newae.com) is deprecated, and content is now at rtfm.newae.com.

Changes

Jump to: navigation, search
no edit summary
[[File:glitchhw.jpg|image]]
 
=== Programming the Target ===
{{CollapsibleSection|intro = === Programming the XMEGA Target ===|content = Programming XMEGA}}
=== 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 &amp; 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 &quot;reset&quot; 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:
! Parameter
! AVR on Multi-Target (CW301)
! CW-Lite XMEGA Board/CW-Lite Arm Board
|-
| Glitch Width (as % of period)
<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>
<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 ==
<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>
<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>
Approved_users, administrator
366
edits

Navigation menu