AVR-GCC compiler seems to have unexpected results compared to precompiled hex files on XMEGA

vabashiah · January 14, 2019, 12:05am

I’ve recently bought Chipwhisperer Lite (2 part) and was going through the tutorials (version 4.0.4).

For instance, I tried the simpleserial, simpleserial_aes and basic-passwdcheck.

The issue:

When I use precompiled simpleserial_aes, it does return a response to command “p1234567890abcdef” when I put it in terminal. When i build it myself with “make PLATFORM=CWLITEXMEGA” I get no response.

However, using “x” to reset works and also it works when I use “putch()”. Just I that I can’t see the response for some reason. The basic-passwdcheck works since it uses putch() instead of simpleserial_put().

Example are two these screenshot, one is my compiled version and the other is precompiled version (a .hex file from 4.0.4 release):

wrong compiled with my compiler: https://i.imgur.com/iOWSYOZ.png
right with precompiled hex file: https://i.imgur.com/siKoL4P.png

I tried to change SimpleSerial version in Scope settings, but it does not seem it has any effect.

Strange thing is that the Tutorial B5 with breaking AES works even with the “wrong” version (the responses seem to appear in the multiple capture). Not sure what to make of it.

Any ideas?

EDIT: tried it on two machines, Ubuntu 16.04 and Ubuntu 18.04, same result

ExMachina · January 18, 2019, 12:49pm

Hi,

I am just guessing here but can you try using PLATFORM=CW303 and see if things start working?
I am suspecting #defines can not handle the CWLITEXMEGA
For example this code

github.com

newaetech/chipwhisperer/blob/develop/hardware/victims/firmware/hal/xmega/xmega_hal.c#L37


   //wait for clock
   while((OSC.STATUS & OSC_XOSCRDY_bm) == 0);
   
   //Switch clock source
   CCP = CCP_IOREG_gc;
   CLK.CTRL = CLK_SCLKSEL_XOSC_gc;    
   
   //Turn off other sources besides external    
   OSC.CTRL = OSC_XOSCEN_bm;
   
#if PLATFORM == CW303
   PORTA.DIRSET = PIN5_bm | PIN6_bm;
   PORTA.OUTSET = PIN5_bm | PIN6_bm;
#endif
}


#if HWCRYPTO
#include "XMEGA_AES_driver.h"
static uint8_t enckey[16];


void HW_AES128_Init(void)

vabashiah · January 20, 2019, 12:55pm

Thanks, tried that, ran make clean beforehand, but the result is the same. When sending pXXXX manually, it doesn’t work, however when running traces with the “1” or “M” for single/multiple traces it seems to work. Still no idea what could be the issue.

EDIT: I found what makes the difference. When I input a short string for the p command like “p1234”, the precompiled version gives output, while the one I compiled doesn’t. When I put p with 32 nybbles, both output: p6d73ab51b78213541ffd901acdba11c6

So it seems the precompiled program is different.

vabashiah · January 21, 2019, 1:13am

After some experimenting, I seem to be even more confused.

After flashing the hex file compiled by myself, the XMEGA responds even to things it didn’t before (like too short string - p1234), even after reset. And again it doesn’t respond anymore to short strings.

I have problems reproducing the bug, thus fixing the issue. I tried to compare the two hex files, but since they are made by different versions of compilers, simple byte-by-byte comparison is not useful. I’d need IDA or gdb.

Alex_Dewar · January 29, 2019, 4:13am

Strange that the binary provided with ChipWhisperer responds in that case, since it shouldn’t respond if the string you send it isn’t long enough. Checking GitHub, it’s much older than simpleserial.c (where the simpleserial functions actually are). Perhaps the function didn’t check the length of what it received back then.

If we continue to provide binaries with ChipWhisperer 5, we’ll it might be a good idea to update them more often. I’ll also make sure to update the earlier tutorials so that it’s clear that commands with an incorrect length are ignored.

Alex