Difficulty with clock glitching labs Fault101 on Husky

[chris]

Hi,

I’m having a hard time with the clock glitching labs (Fault101 1_1 - 1_3) on the CW Husky + CW312 SAM4S:

In 1_1 I was getting only very few hits scanning the whole width and offset range (0 - scope.glitch.phase_shift_steps) with a global step of 100. Not enough to identify ranges to use in the later notebooks. Instead I tried scanning the entire range over night using a global step of 10 and also stepping repeat from 0 - 10 just in case that made a difference:

gc.set_range("width", 0, scope.glitch.phase_shift_steps)
gc.set_range("offset", 0, scope.glitch.phase_shift_steps)
gc.set_global_step([10])
scope.adc.lo_gain_errors_disabled = True
scope.adc.clip_errors_disabled = True
gc.set_range("repeat", 1, 10)
gc.set_step("repeat", 1)

While this does lead to quite a few hits the ranges seem to be extremely narrow so no wonder I didn’t get many hits with a larger global step:

Using the width and offset ranges ranges found this way in lab 1_2 and 1_3 doesn’t seem to work very well. I was able to get the occasional glitch in 1_2 scanning ext_offset from 0 to 100 but they were very few (<10) and not easily repeatable. I’ve had not success in 1_3 so far.
Running the SOLN notebooks for 1_2 and 1_3 didn’t lead to any hits.

Is the very narrow band of successful glitch parameters expected or am I missing something? Any tips to improving my results in 1_2 or getting any in 1_3?

Any help would be greatly appreciated.

[chris]

After banging my head against a wall for two days, as a last ditch effort I decided to try on my windows machine… and it just works.

The SOLN files for 1_1, 1_2 and 1_3 just work out of the box.

For comparison here is 1_1 on Windows vs Linux:

I tried copying over the whole chipwhisperer folder from the Windows machine in case there is some version mismatch but no dice.

While I’m glad it works on one machine at least, I’d still prefer using my main development system. Any ideas what’s going on and how to fix this?

[jpthibault]

Glitching is not OS-dependent in any way; the only variable I can think of here is that the ChipWhisperer repositories are not at the same place (on the same commit) on the two machines.

[chris]

I thought of that, that’s why I tried copying the chipwhisperer folder from the windows machine. I even installed the same python version (3.10.8) just in case.

Any ideas on how to debug this further?

[jpthibault]

When you say that you’ve copied the folder-- are you sure that what you’ve copied is what’s being used? You can run this to know where Python is importing from:

import chipwhisperer as cw
print(cw.__file__)

You can also just compare the notebooks themselves. For example Fault 1.1 has add several Husky-specific updates over the past couple of years to work better for Husky:

History for courses/fault101/SOLN_Fault 1_1 - Introduction to Clock...

[chris]

Yes, it’s running from the correct folder.

I think it might be a timing thing. With debug logging on the naeusb_logger it suddenly starts working:

cw.naeusb_logger.setLevel(logging.DEBUG)

Of course now it runs much slower.

[chris]

Ignore the previous post that was a red herring.

It’s a difference in the .hex files, if I copy the .hex file from the Windows machine and program that everything works. I just thought it had to do with the debug logging because I skipped the programming step when I enabled that and the target still had the version from the windows machine on there …

Looks like the .hex file generated on Linux behaves very differently from the one built on Windows.

Not sure if its the reason but the Windows installer includes gcc 10.2.1 and on Linux I have 13.2.1.

edit: Looks like that’s it, I downloaded 10.2 from Downloads | GNU Arm Embedded Toolchain Downloads – Arm Developer and modified the make call like this:

%%bash -s "$PLATFORM" "$SS_VER"
export PATH=/mnt/data/Projects/ChipWhisperer/gcc-arm-none-eabi-10-2020-q4-major/bin:$PATH
cd ../../../hardware/victims/firmware/simpleserial-glitch
make PLATFORM=$1 CRYPTO_TARGET=NONE SS_VER=$2 -j

Now it works the same as on Windows.

[jpthibault]

Good job figuring out the root cause!
Yeah different compiler versions will produce different output. In Fault 1.1 we’re glitching a for loop and that should be pretty robust against what the compiler decides to do; however in 1.2 and 1.3, we need to glitch a specific instruction, and so our suggested glitch settings can end up being way off.