One half-done feature I've had for the last release or two is this idea that analysis can be configured through the GUI, but in reality is just a Python script. So for example if you decide to use a low-pass filter in the GUI, you can see in the script all you are really doing is specifying some parameters to a standard scipy filter object:

Getting that working involved quite a bit behind the scenes. In particular for example note how imports are automatically pulled in depending what modules you are using, and it updates the parameters passed to the API based on your GUI inputs.

When it comes time to run the analysis, that text file is actually saved (it's just a .py file), and dynamically loaded. Those functions are then called. This means you could write Python code directly into that file, especially useful if you wanted to add your own preprocessing module or attack, without forcing you to jam everything into the GUI. In practice the GUI interface code can be a lot more work than the actual logic/algorithm.

The latter point is important for more complex attacks: it's unrealistic to try and make everything accessible through the GUI. At some point you'll be generating your own models, and it's much much easier to do this directly inside of a Python environment. The one missing feature from the previous releases was the ability to run the script from any file, one that wasn't automatically generated. Now each project can have a bunch of script files you can switch between. There is the special one that is automatically generated from the GUI, but you can copy that base and then modify it without it being overwritten by changes in the GUI:

So you can set the 'active' script file, along with a name for what it does. I'll probably pull that out of a docstring eventually so it's embedded in the file itself, but small steps for now. One other thing that works is detecting when conflicting edits occurred, because for example you decided to modify the file in a real text editor:

As you can see I'm hoping to avoid the Abort, Retry, Fail error message that perplexed me on some of my original computers by keeping the choices as verbose as possible. These changes are in the 'scripteditor' branch still, but I'll probably merge that back to master shortly. With these changes in place I can complete my AES-256 tutorial now too, as I needed to hack some Python files directly for that attack to work (from my previous project log). That last log entry required me to modify the ChipWhisperer software files a little for the attack to work. Ideally as a user you shouldn't have to touch the core ChipWhisperer files, and it just gets out of your way! Which is now possible with the external scripts.

I've still got to save the script filenames in the chipwhisperer project file - right now you have to re-add them every time you restart the program. It's not that big a deal, but I'd prefer to have them load automatically. Once that's done I'll probably make a new release.