Importing manual captured Traces

Hi everyone,

I am using Sakura-X with our own control platform and a Picoscope 5000 series, in order to capture Power Traces from an AES algorithm. I am saving the Power Traces at .mat format. Using some scripts I made in python, I am formatting them in .npy format. The same is also done for the Ciphertexts and Plaintexts.
I am interested in importing them in ChipWhisperer Analyzer. However, the Trace Management only gives me the option of importing .cfg files.
I have searched through the forum, but I wasn’t able to find a solution. Is it possible to import them and how can that be done?

Kind regards,
Nassos

Hi Nassos,

The issue is that the ChipWhisperer software stores a bit of extra information in these config files. An example of one of these files is:

[Trace Config] numTraces = 5000 format = native numPoints = 400 prefix = 2017.03.08-22.29.05_ date = 2017-03-08 22:29:05 scopeSampleRate = 64000007 notes = "AckPattern: Basic (Key=Fixed:E9 8C EA B5 AC 48 99 96 15 E5 DD 78 6C B9 6C 87, Plaintext=Random); Aux: " scopeName = ChipWhisperer/OpenADC scopeXUnits = 0 targetSW = unknown targetHW = Simple Serial scopeYUnits = 0
Some of this info is used inside the trace manager to ensure that all of the traces will play nicely together.

Right now, there’s no way to auto-generate one of these files, but it might be possible to make a dummy one - I’ll add this as a feature request on Github.

@gdeon
Hi and thanks for your reply!
Really useful the format of the .cfg file you posted. If I find some spare time from my Thesis, I will make a python script for the transformation from .npy to .cfg of the traces and share it with you.

Colin posted a wiki page: wiki.newae.com/File_Formats , backed in mid-2016, where people can get the basic idea how the .cfg looks like.

@coflynn @gdeon ,
First, It’s better to document on wiki more details of so called ChipWhisperer’s native file format. e.g.:

  • It is by reading source code I got to know expected dtype for keylist/textin/textout is np.uint8;
  • It is unclear whether expected dtype for traces is np.float or np.double;
  • I assume the numpy array is the default C-style, and knownkey is of shape(1, n) where n should be 16, 24 or 32;
  • I assume for each row in keylist/textin/textout, lower byte is stored in lower index, e.g. B0 (according to AES spec) is stored in index 0 while B15 is stored in index 15;

Second, it is better to document the software organization how ChipWhisperer expects to extend support for more formats, e.g. to deal with traces produced by CRI’s DPAWS or Rescure’s Inspector. Today, the organization is not very clear, e.g.:

  • Both below classes have codes dealing with traces in native format:
    [list]
    [*] software/chipwhisperer/common/utils/tracereader_native.py;

  • software/chipwhisperer/common/traces/TraceContainerNative.py;
    [/:m]
    [
    ] software/chipwhisperer/common/traces/TraceContainerDPAv3.py for dealing with DPAv3, besides inheriting from TraceContainer class, also depending on classes from below:

  • software/chipwhisperer/common/utils/tracereader_dpacontestv3.py;

  • software/chipwhisperer/common/utils/tracereader_native.py;
    [/:m]
    [
    ] software/chipwhisperer/common/traces/TraceContainerDPAv3.py has code for both logic operations, and GUI;[/*:m][/list:u]
    Is it expected to transit all codes to take use classes in common/traces to deal with traces of different formats, no matter to writing in capturing stage or reading in analyze stage?

-f1xc0

Hello,

Just catching up - unfortunately our industrial gdeon has left to return for more schooling, so a little behind on stuff here. But to provide a quick answer…

The nptype itself is documented “externally” I guess - I hadn’t looked into the actual binary format too much, I know there was a way of reading that stuff in C files (see github.com/rogersce/cnpy). Behind that we use it in a fairly “opaque” way to be honest.

Some of the trace format stuff is a little crazy, as it has a lot of “historical baggage” behind it. We’re working on making a new API (v4) which won’t fix the baggage, but WILL provide a much cleaner API. This will let us then slowly fix the underneath code, but giving a nicer API right away.

Regards,

-Colin