Difference between revisions of "Simulating the XMEGA Target Code"

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:

   

2. Select your ELF-file built previously:

   

3. This will prompt you to save a project. Give it a location somewhere:

   

4. Select the XMEGAD as the family, and the ATxmega128D4 as the specific device:

   

5. Your project will now open. You should be able to click on a source file to see the contents:

   

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:

   

   
   

2. And select the "Simulator" option:

   

   
   

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:

   

   
   

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

   

   
   

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:

   

   
   

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

   

   

   
   

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:

   

   
   

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:

   

   
   

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

   

   
   

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.

    

    
    

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.

    

    
    

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.