I currently have the problem that I just can’t get a glitch. When I got the CW Husky I noticed that the demo “03 - Husky Glitching” at the point “Validation” did not work, here I always got the value “zerolens : 1000”. Could it be that the MOSFET has burnt out?I ran the test scripts and did not get an error, except at the point
=================================== FAILURES ===================================
______________________________ test_fpga_version _______________________________
../../tests/test_husky.py:531: in test_fpga_version
assert scope.fpga_buildtime == '1/12/2024, 09:25'
E AssertionError: assert '4/11/2024, 09:41' == '1/12/2024, 09:25'
E
E - 1/12/2024, 09:25
E ? ^ ^ ^^
E + 4/11/2024, 09:41
E ? ^ ^ ^^
=========================== short test summary info ============================
SKIPPED [9] ../../tests/test_husky.py:1841: requires cw305 test platform
====== 1 failed, 156 passed, 9 skipped, 6 deselected in 999.58s (0:16:39) ======
Does anyone have an idea?
When you say that you’ve never gotten a glitch, what have you tried? Have you tried our fault101 course notebooks?.
The “validation” part of the 03 - Husky Glitching is leftover from development so I wouldn’t worry about that. You could re-run it with a higher value for scope.glitch.width and it should pass.
That notebook and test_husky.py don’t actually test the glitching of a target. Your best bet there is the notebooks in fault101. If you still have issues with those, follow up and let us know.
1 Like
I just tested it and the fault101 cours notebooks work? I think you specifically have the “Fault 2_3 - Voltage Glitching to Memory Dump.ipynb” in mind. Yes, that works. I have to adjust the parameters as follows:
gc.set_range(“width”, 1850, 1901)
gc.set_range(“offset”, 2500, 2600)
gc.set_global_step([50])
but it works. So it can’t be the MOSFET…
But then why don’t the two notebooks work?
- 03 - Husky Glitching.ipynb
--------------------------------------------------------------------------
AssertionError Traceback (most recent call last)
Cell In[26], line 3
1 print(“zerolens : {}”.format(zerolens))
2 print(“overlens : {}”.format(overlens))
----> 3 assert zerolens == 0 and len(overlens) == 0
AssertionError:
zerolens = 1000
overlens = 0
- husky_glitch_stress_test.ipynb
Customization: PLATFORM = ‘CW308_SAM4S’ (I do not have a CW308_STM32F3)
Am I wrong in expecting the demos to simply work? It’s clear that I have to do something with the courses, but the demos are only supposed to show how great the CW Husky is.
P.S.: I also just have a bad osciloscope. The Glich is simply a “step response” and is not displayed correctly. So the assumption about the MOSFET was wrong - but now I have a new MOSFET in the CW.
It sounds like we’re getting our wires crossed.
If you successfully ran the Fault 2_3 notebook: great! You were able to glitch. There are several other notebooks in fault101 to learn more about glitching. Most of the notebooks in courses require you to figure some things out and make modifications and/or write some of the attack code.
With glitching in particular, there isn’t a set of glitch settings that will always work for everyone, because there are lots of variables outside our control that affect the success rate- temperature, different manufacturing batches of targets, cables, etc… That’s just the nature of glitching.
The “Validation” portion of the 03 - Husky Glitching.ipynb notebook is an unintentional leftover from development. I will remove it.
Same for husky_glitch_stress_test.ipynb, and test_husky.py. These are intended for developers who are making changes to Husky.
Other than these exceptions (which I’m fixing now), everything in demos/husky should indeed “just work” out of the box.
1 Like