Tutorial A5 Breaking AES-256 Bootloader (Adding New Target)

Hi All,

I’m very new to the side channel area and I recently purchased a CW-lite board. I am trying to do the A5 tutorial following the steps provided in (wiki.newae.com/Tutorial_A5_Brea … Bootloader). However the steps using the target and capture code is not very clear. I did save the both the files in the target folder, but running the capture code gives me the following error “no module named CWCaptureGUI”. Could you please provide the steps needed to progress through the tutorial, let me know what stupid mistake I have done.

Also I used the hex file (“bootloader-xmega.hex”) found online to flash the memory. Please let me know if this is correct as well.


Hi Hans,

Hope you’ve enjoyed your CW-Lite so far. Have you tried the other tutorials too?

I can’t reproduce your error on my end. Maybe you have an older version of the software - what version of the ChipWhisperer software are you using? The latest is v3.4.2. If you have Git set up (for example, if you’re using the VM) you can run git pull to update everything.

By the way, I read through the tutorial again; everything makes sense to me, but I’m biased because I wrote it :slight_smile: If you have specific questions, please let me know and I can try to clear things up. One thing that I noticed is that the tutorial firmware ends up in a file like bootloader-aes256-CW303.hex. Are you sure you’re using the right firmware?

Yeah I am very much enjoying it and getting to grips with it.

I have the older version of CW Ver2. I will sort it out now. The files that I have from the bootloader file is from the this location (github.com/newaetech/chipwhispe … der-aes256). I was able to successfully create the hex file for other tutorials such as simple serial exercise, but using the make command in with respect to bootloader gave me an error. So I thought the hex file already present in the file is the one. Please let me know if this is correct?

As per instrctions I have saved the target code in the location chipwhisperer\software\chipwhisperer\capture\targets also the capture script is saved in the same location.

Thank you very much for your help


Using the the right version, solved most of the issues and was able to flash the lite properly. In the new version I have saved the capture and the target scripts here projects folder and both of them are saved as .py scripts. But running the error gives me the following error.

Please let me know if I have missed a step? Thanks

Hi Hans,

Glad to hear you solved the firmware issues.

This error message means that the CWCapture software can’t find your target module. There are two possible reasons:

  1. The software isn’t looking in the folder where you’ve saved the .py file, or
  2. There’s a bug in the module that’s causing it to fail when it loads.

Can you open the plugin status window (Help > List Enabled/Disabled Plugins) and try to find it in the list of modules? If it’s saved in the right place, you should see a line that says <class 'chipwhisperer.capture.targets.BootloaderTarget.BootloaderTarget'> or similar. If #1 is the problem, then you won’t see it in the list; if #2 is the problem, it’ll be there, but the Details column will tell us what the bug is.


Thank you very much for your help and now everything is fine and I am able to obtain traces. But before I continue with the exercise, I want better understand the AES-256 trace obtained. The trace attached shows my understanding/assumption of the trace. So I have noted 14 rounds for the AES, as shown, but there are other blocks (denoted by A,B,C…) that roughly show 14 rounds. Is this because of the CBC mode operation? If so shouldn’t the blocks have a similar structure (block D is completely different), because its the same 14 rounds. Or is the difference due the actual bytes it operates on?

Any information on this that would help me to better understand the trace is very much appreciated.

Full AES256_Bootloader_Myassumption.jpg

The software AES implementation is a lot slower than you’re thinking!

I count 16 spikes in the first piece (labelled “14 Rounds of AES”) - I think this might be the AddRoundKey() step. Then, I count 16 spikes again in “A”, so this is probably SubBytes(). You probably can’t see Round 2 in this trace.

Hi Thank you very much for your feedback.

But I was wondering if the blocks are addround key, subbytes, shifitrows, mixcol what is represented by blocks D and E? The A block is kind of similar to the E block. Since this is the first round can it be (thinking out loud) that A is addround key, B is Subytes, C is Shiftrows, D is Mixcol and E is addround key (since they are similar and is repeating in the first round only). And the block marked as “14 Rounds of AES” is some sort of key expansion??

Thanks in advance

My mistake - I just realized that this is AES decryption! I looked at the source code for a while - here’s what I can tell…

  • A is the part where the attack succeeds (ie: the CPA attack peaks occur in A). This means that A has to be InvSubBytes.
  • The section labelled “14 rounds” must be AddRoundKey because this is the only place for it to go.
  • The short ramp-up between AddRoundKey and InvSubBytes must be the InvShiftRows step - it’s a very simple operation so it shouldn’t take long.
  • B is probably the key expansion
  • C is probably AddRoundKey again
  • The traces lose synchronization around D (see the tutorial for pictures of this), so this must be InvMixColumns
  • The gap between D and E is probably InvShiftRows again
  • The 13th round attack succeeds at E, so this is the second InvSubBytes
    You could look into this a little more if you want - the full AES256 source code is at chipwhisperer\hardware\victims\firmware\bootloader-aes256. Maybe you could add in some delays or extra trigger signals to confirm where these things are.