Glitch Explorer


#1

Hi,

I was wondering how the Glitch Explorer tool can be used in Chip Whisperer.
In the post at http://hackaday.io/post/2511 it appears that one can set up parameters that are
iterated and thus allowing one to automatically find working glitch parameters.

The “Script Command” appears to be the command with the parameter that should be iterated. How do I specify which of the parameters should be changed within this command ? Is there some kind of variable I need to enter that is then substituted with the actual iteration value ?

So far I didn’t manage to get this thing working. Specifically, I would like to know how I can do the following in the Glitch Explorer tool:

(1) Send and receive serial communication with the target
(2) Toggle I/O pins to reset the target
(3) Arm the glitch trigger
(4) Specify which parameter should be iterated

Also, is there an example I could look at to understand the basic concepts used in the Glitch Explorer Tool ?

Basically, I would like to set up a loop where each iteration does the following:

  1. reset target (GPIO pin)
  2. enable bootloader (other GPIO pin)
  3. communicate with the target (RXD and TXD GPIO pins)
  4. set up glitch and digital pattern matching trigger
  5. send command to target (TXD) that also triggers the glitch through the digital pattern match trigger
  6. receive and analyze response from target (RXD)

Regarding the digital pattern trigger, is it possible to trigger on non-printable characters (i.e. “\n”) as well ?
I tried to edit the binary pattern by hand so that it triggers on a 0x10, but it didn’t work.

So far I wrote my own Python Script that varies the glitch offset while constantly resetting and communicating with the target. However, after a few iterations it tends to crash in the QT GUI code for some reason. Besides it is terribly slow (4 sec for one glitch attempt). Maybe this works better with Glitch Explorer ?

It it possible to write a non-GUI script for glitching with ChipWhisperer ?
While the OpenADC implementation seems to be well separated from the GUI, the rest of the implementation seems to require the GUI components ?

Thank you!


#2

Hello,

Ah… the glitch explorer is at the top of my todo list for documentation. What you are describing is exactly what it was designed for, let try to free some time to describe it better and answer your questions.

To some degree - the problem is I used some elements of PySide in the main program logic (particularly signals & slots). I didn’t think of it at the time, but this requires you to have the GUI running.

When running from a script you often need to run the processEvents (or ‘pe()’) command which causes the main event loop to be executed. It’s a bit of a hack but it works.

Normally what I actually do is have a script that inserts some special module into the GUI. For example you aren’t limited to the pull-down menu for the scope, you can just have your own scope class that gets set via the script. The GUI will now work as if you had selected some other scope module. This is especially useful in glitching or when setting IO pins. Let me try to document a few examples, as I’ve been doing almost the same thing.

Regards,

-Colin


#3

Hi Colin,

This is exactly what I did with my Python Script. It is a GUI ‘tool’ stored in ‘software/chipwhisperer/capture/utils’ that can be called from the ChipWhisperer ‘Tools’ menu.
It looks very similar to the ‘Terminal’ Tool, but includes a few more buttons allowing me to reset the target device
or to communicate with the target up to some interesting point.
I also have buttons to start and stop glitching.

The start button starts a QThread. In the thread there is a loop that does what I described in the previous post.
However, it is not only rather slow, but it also segfaults indeterministically (somewhere in QT GUI code) after a bunch of loop iterations. I suspect it is due to some GUI code, but I’m not sure.
Due to this behavior, I started to write a non-GUI script, but I’m still working on it.

Thanks !


#4

Ah… yes this is almost certainly a race condition between the two event loops I think. If possible to keep without the QThread it might work - you can manually call processEvents() to cause events to be executed if you are doing a while loop or similar, which is basically the cheater way of doing threading. There is more legitimate ways such as using a QTimer() for example, or for doing something after each capture there is various signals you can latch onto and have the system call your special function.