Glitching with Husky

Hello everibody,

trying to glitch the JN5169 using CW Husky on the line after the voltage regulator, but it seems that something is really unclear to me. The target has this code, a double for is executed and the output is sent via serial line:


Which is translated to (similar to the openrisc ASM):


The main part of the glitching code is:

scope.glitch.repeat = 5
offsets = np.arange(0, 2000, 20)
repeats = 5

crashes = 0
faults = 0

for offset in tqdm(range(len(offsets))):
    scope.glitch.ext_offset = offsets[offset]
    for i in range(repeats):
        = False                # only using the 'low power' glitch mosfet = False
        # Reset the target and flush the serial
        target.flush() = 'low'
        time.sleep(0.05) = True                # only using the 'low power' glitch mosfet = False
               = 'high'
        ret1 = scope.capture()
        ret =,timeout=200)
        x = ret.split(' ')
        if ret1:
            print('Timeout - no trigger')

        if x[0] != "loop":
            crashes += 1
            print("crash_" + ret)

            f1 = int(x[1])
            f2 = int(x[2])
            f3 = int(x[3])
            if f3 != 100000:
                faults += 1
                print('Fault?!' + str(f1) + ' ' + str(f2) + ' ' + str(f3) + '-' + str(scope.glitch.ext_offset))
total = len(offsets)*repeats
print("\nTotal # attempts:", total) 
print("Total # faults: %d (%f%%)" % (faults, (faults/total)*100))
print("Total # crashes: %d (%f%%)" % (crashes, (crashes/total)*100))

The strange is that the result is thisone:

Offset Final count
80 100001
120 100002
260 100005
300 100006
340 100007
380 100008
420 100009
460 100010
600 100013
640 100014
680 100015

How it’s possible that I’m getting these results? It doesn’t make sense to me. Also if I can glitch the counter k or j, it doesn’t make sense that the final value increment in this way.

On “Fault 1_1 - Introduction to Clock Glitching” I saw that: “On CW-Husky, glitch offset and width are specified in number of phase shift steps, whereas on CW-Lite/Pro, they are specified in percentage of clock period. The code provided below sets appropriate starting ranges for each case. Run help(scope.glitch) to understand this better.

I will figure out better how the Husky is manage the glitching values in the nexts days, but anyway I cannot undestand how I’m getting these values.

Any idea?

The glitch in some way is done correctly (red line is the trigger, blue line is the VCC after the regulator):


Hi Inode,

Perhaps you’re zeroing out the loop variable somehow, and every 40 offset is one step further in the loop?

cnt variable is set to 0 at the start of the code. On the assembly code:


R0 is always 0 in this architecture.

I’m incrementing the offset by 20 every time. It seems that when the CPU crash the next test will be incremented by one, but still doesn’t make any sense to me.

After a full reset (of the target and also of CW Husky) when running the code on a single glitching with offest 420 I still get 100009.

I modified the code adding 2 more variables:


At the end I print it via serial:

sprintf(pcMessage,"loop %u %u %u %u %u\n", k, j, cnt, k1 ,j1);

Here some example of output for the faults:

Fault?!loop 1000 100 100003 1002 100003
Fault?!loop 1000 100 100007 1002 100007

Seems that in some way it partially override the first for… But I still can’t undestand why the output is thisone.