RHME3 - MATLAB File Format Converter

For anyone playing with RHME3, I thought I’d post some file conversion hints.

The default .mat file don’t load in scipy.io it seems, so the example conversion utilities on the wiki are no good. A quick-n-dirty method of fixing this is to:

  1. Split the .mat file (it’s text, open it in a text editor) into two text-files. The first contains the list of data (AFTER the header of ‘300 32’) which can be loaded by numpy. The second file contains the other block of data which is in a slightly different format.
  2. Run the below script. It will create a directory ‘rhme3’.
  3. Open ChipWhisperer analyzer, open the “Trace Manager”, and then hit “Add Trace” (the + button). Point it at the generated .cfg file.
import numpy as np
import ctypes
import os
from chipwhisperer.common.traces.TraceContainerNative import TraceContainerNative

ntraces = 300

inout = np.loadtxt('inout.txt')
traces = np.loadtxt('traces.txt')
inout = np.reshape(inout, (32, ntraces))
inout = inout.T

inp = np.uint8(inout[:, 0:16])
out = np.uint8(inout[:, 16:32])

#If you'd like to plot a trace to see it
from matplotlib.pylab import *
#plot(traces[0,:], 'r')
#plot(traces[1,:], 'b')

#Save as ChipWhisperer project
tc = TraceContainerNative()
for i in range(0, ntraces):

    #Temp - add fake key info. Required on Linux possibly, will be fixed to avoid this. Be sure to turn
    #highlight key off to avoid being confused.


EDIT: There is a short hack needed for now - open the .cfg file generated, and change the line:

prefix = None


prefix = .
The first line worked OK on Windows, but the Linux version failed. The real fix is a code patch but that work-around is good for now (or you can set a prefix as well solves the problem).

To actually recover the key, one may need to use features like SAD alignment, as you may notice the traces are slightly out of alignment if you plot several of them (i.e., 0-20).

Hi Colin,

I’m using the latest chipwisperer analyser from github develop branch (tried the pip one too).
It is working really good until I turn on SAD resync.
When I start the attack, getting the following error after a few seconds

Could not execute method run in script class UserScript: 'IndexError: too many indices for array:too many indices for array'

line number 56 [inside function oneSubkey] variable traces_all expected to be a multidimensional array [it is, if you disable SAD] but which is coming as a single dimensional array.

When I do print traces_all.shape in the the code, it is printing b[/b] with SAD enabled, (10, 6095) with SAD disabled

In chipwhisperer/analyzer/attacks/cpa_algorithms/progressive.py

def oneSubkey(self, bnum, pointRange, traces_all, numtraces, plaintexts, ciphertexts, knownkeys, progressBar, state, pbcnt):
        diffs = [0] * self.model.getPermPerSubkey()
        self.totalTraces += numtraces

        if pointRange == None:
            traces = traces_all
            # padbefore = 0
            # padafter = 0
                print traces_all.shape
            traces = traces_all[:, pointRange[0] : pointRange[1]] # Exception here

Is that a bug, or am I missing something?



This sounds like it might be an invalid input range? Can you post your capture script (or just the proprocessing setup part).

When it fails to find matches it may do funky things.

Do the traces look OK without the preprocessing enabled?


I found that scipy can read older version of the mat format so was able to do the following in octave.

load "traces.mat" 
save -6 newtraces.mat

newtraces are now scipy compatible.


You get that error if you try to run the attack with the default SAD parameters (everything set to 0?). Once you vary the reference points and the window in the preprocessing setup it works ( although some combinations of values may still result in that error).

I added my solution here(to me it looks like the for the SAD filter the input window must be about 3 times the size of the reference points else you indeed get exceptions.

github.com/x8-999-github/cw-pro … s_cw.ipynb