About Offset Limit

Embedded Security ChipWhisperer Software
1

Hi

How can I change the offset limit to a value bigger than 1e6 ?

What is the maximum value that it can take ?

Thanks :slight_smile:

2

The hardware limit is 2^32-1 (4294967295), 1E6 was a stupid software limit… will be fixed in GIT. But to quickly fix it:

Go to chipwhisperer\openadc\controlsw\python\openadc\openadc.py. Around line 260 find this:

            {'name': 'Offset', 'type':'int', 'value':0, 'limits':(0, 1000000), 'set':self.setOffset, 'get':self.offset},

and change to:

            {'name': 'Offset', 'type':'int', 'value':0, 'limits':(0, 4294967294), 'set':self.setOffset, 'get':self.offset},

Let me know if it works!

3

It works…partially…
The soft limit was removed, however…some weird things happened…

The GUI allows me to put manually an offset bigger than 1e6 and capturing a trace…
If a single trace is captured…
Sometimes it reads a trace of all zeroes and others don’t :frowning:
Additionally, when I perform some capturing at some point something it fails with a stack trace that ends with a message like:

File "c:\users\administrador\desktop\cw\chipwhisperer-0.12rc1\software\chipwhisperer\common\traces\TraceContainer.py", line 146, in addWave self.traces[self._numTraces][:] = trace ValueError: cannot copy sequence with size 768 to array axis with dimension 3000

After some test, the values of the destination and source arrays vary and are not always the same for different tests…

This was obtained loading in the cw-lite the simpleserial-aes script example script and putting the offset at 2000000 and doing a multi capture (50 traces).

The full stack trace is shown below for reference…

****Finished Script: ChipWhisperer-Lite: AES SimpleSerial on XMEGA Capture delta time: 0:00:02.602000Traceback (most recent call last): File "ChipWhispererCapture.py", line 1038, in captureM ac.doReadings(addToList=self.manageTraces) File "c:\users\administrador\desktop\cw\chipwhisperer-0.12rc1\software\chipwhisperer\capture\AcquisitionController.py", line 190, in doReadings self.writer.addTrace(self.scope.datapoints, self.textin, self.textout, self.key) File "c:\users\administrador\desktop\cw\chipwhisperer-0.12rc1\software\chipwhisperer\common\traces\TraceContainer.py", line 116, in addTrace self.addWave(trace, dtype) File "c:\users\administrador\desktop\cw\chipwhisperer-0.12rc1\software\chipwhisperer\common\traces\TraceContainer.py", line 146, in addWave self.traces[self._numTraces][:] = trace ValueError: cannot copy sequence with size 768 to array axis with dimension 3000

4

Hmm… that’s odd! Actually I did some more testing and see issues with capture offsets > 800000, there is occasionally reliability issues! I’ll look into that, offhand I don’t know why it would fail with higher limits.

5

After a few experiments it seems that the offset should not be bigger than the number of samples required to reach the execution of trigger_low().

With a code at the xmega that when a plaintexts is received it activates the trigger but it never deactivate it until another specific character is received…if a multicapture is executed…(with offset at zero, neverminds)…the traces are all zeroes (as expected)…and if a terminal is opened and during the multicapture the character that deactivates the trigger is send…voila !! the error happened !!

It seems that a workaround to this problem is not trying to capture a trace after the trigger_low(), that after all should be the expected thing to do.

6

Ah awesome, thanks for the tips. That helps a lot in debugging actually, as it gives me a better way to reproduce it. I also think the error is within a specific area of the trigger logic, and your work-around somewhat confirms that. Will let you know when I figure out those exact details…

PS: If you see anything else let me know too!

7

Here is a quick work-around until I push the better fix:

In chipwhisperer/openadc/controlsw/python/openadc/openadc.py, around line 1070, inside the “capture” function you’ll find this:

            if waitingCallback:
                waitingCallback()

        self.setSettings(self.settings() & ~0x08);
        return timeout

The root issue is this function returns too fast, which causes the data download to start. Just add a small delay before the return, the following should be sufficient:

            if waitingCallback:
                waitingCallback()

        self.setSettings(self.settings() & ~0x08);
        time.sleep(0.05)
        return timeout

You might need to increase the timeout depending on your offset or computer speed.

8

FYI a slightly better fix is committed to the OpenADC git repo now. Rather than a fixed sleep, call it just does this:

 # If using large offsets, system doesn't know we are delaying capture        
        nosampletimeout = 100
        while (self.getBytesInFifo() == 0) and nosampletimeout:
            time.sleep(0.05)
            nosampletimeout -= 1

        if nosampletimeout == 0:
            print "WARNING: No samples received from ADC. Either very long offset, or no ADC clock."
            print "         If you need such a long offset, manually update 'nosampletimeout' limit in source code."
9

Perfect !

Good fix and a very fast reponse !!