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

Difference between revisions of "Simulating the XMEGA Target Code"

From ChipWhisperer Wiki
Jump to: navigation, search
(Simulating)
Line 72: Line 72:
 
* Set a breakpoint at the higher-level code, as this is where the trigger starts. Check how many cycles it takes to reach the first vulnerable portion of your code.
 
* Set a breakpoint at the higher-level code, as this is where the trigger starts. Check how many cycles it takes to reach the first vulnerable portion of your code.
  
=Building=
+
==Building==
  
 
At this time, it is recommended to use WinAVR to build. The version of certain tools provided with Atmel Studio does not directly work with the provided Makefile.
 
At this time, it is recommended to use WinAVR to build. The version of certain tools provided with Atmel Studio does not directly work with the provided Makefile.
  
 
See [[http://wiki.newae.com/CHES2016_CTF#Compiling_Firmware_as_Server_Does]] for brief details. You can use the built ELF-file as above.
 
See [[http://wiki.newae.com/CHES2016_CTF#Compiling_Firmware_as_Server_Does]] for brief details. You can use the built ELF-file as above.

Revision as of 06:40, 1 May 2018

This page describes how to simulate the XMEGA target code in order to determine the length of time AES takes. This was designed for the CHES CTF 2016, but may be valuable in other circumstances.

Required Tools

You will require the following tools:

  • Atmel Studio 7
  • avr-gcc (suggested to use WinAVR, but you can actually build with Atmel Studio)

Simulating

The following assumes you have an EXTERNAL build environment (such as WinAVR, or avr-gcc). Building with Atmel Studio is possible, but not documented/supported right now.

Opening Object File

To begin, we'll be opening the existing .elf file. This file contains all the debug information created during the build process.

  1. From the File --> Open menu, select Open Object File For Debugging:
    Sim1 openobject.png
  2. Select your ELF-file built previously:
    Sim2 selectelf.png
  3. This will prompt you to save a project. Give it a location somewhere:
    Sim3 saveproject.png
  4. Select the XMEGAD as the family, and the ATxmega128D4 as the specific device:
    Sim4 selectxmega.png
  5. Your project will now open. You should be able to click on a source file to see the contents:
    Sim5 openfile.png

Great - now let's look into how we can simulate this project.

Simulating

  1. On the tool-bar, there is an open to select the debug interface. It may say "No Tool" as below, if so click to select the tool:
    Sim7 selecttoolA.png

  2. And select the "Simulator" option:
    Sim8 selecttoolB.png

  3. You're ready to simulate! As a first example, you can set Breakpoints by clicking in the margin. If they can be set a red circle will appear. Be very careful in location - sometimes once you go to simulate the breakpoints will be disabled or moved (more on this later), so you'll have to go back and check the location of them once the simulator is running:
    Sim6 setbreakpoint.png

  4. To start the simulator, select the "Start Debugging" option:
    Sim9 startdebug.png

  5. But what happens? You'll likely see NO break-point hit! This is because the code is waiting on the serial port. Go back to the source-file and add a call to the AES encryption operation, just as it would be called later. The following shows the location to add this to in the simpleserial-aes.c file:
    Sim10 insertcall.png

  6. Recompile. Atmel Studio should flag the object file as changed (NB: only if using external project, if building through Atmel Studio these messages don't appear), if so hit "Reload":
    Sim11 reload1.png
    Sim11 reload2.png

  7. You can now try debugging again, and should see the break-point hit. But what good is that? To see the cycle count, open the "Processor Status" window:
    Sim12 pstatus.png

  8. This window has a field called Cycle Counter, which is the current clock cycle count. When a breakpoint is hit you can read this field:
    Sim13 cyclecount.png

  9. You can also clear it, writing it to 0 for example at the start of the encryption operation:
    Sim14 resettozero.png

  10. Back to simulating. If you try setting a break-point, you might get an open circle as below. Note this appeared to be set OK, until we hit Debug at which point it turned into the open circle! This breakpoint will NEVER be hit.
    Sim15 bpnothit.png

  11. Instead, you should set a break-point at the higher level code. You can use Step Over and Step into to work your way through the code. The following example shows that for the first S-Box substitution, this code is taking almost 1800 cycles. Each run through this loop was taking far too long - the result being that the S-Boxes would not be covered by the 10 000 samples taken by the CTF system.
    Sim16 stepin.png

That's it! Using the Atmel Studio, you can easily simulate your code to determine the number of cycles taken for certain operations. To summarize key points:

  • Use the framework described by the CTF page, which provides the required makefile + supporting files.
  • You'll have to modify the simpleserial-aes.c file to directly call your encryption function.
  • Set a breakpoint at the higher-level code, as this is where the trigger starts. Check how many cycles it takes to reach the first vulnerable portion of your code.

Building

At this time, it is recommended to use WinAVR to build. The version of certain tools provided with Atmel Studio does not directly work with the provided Makefile.

See [[1]] for brief details. You can use the built ELF-file as above.