What if width is 0 from CW-lite?

Embedded Security
1

I am using CW-lite to clock attack. I found, if width is 0, the code can be attacked. So what happened, if width is 0? Other configurations are as follows:
offset=-46.875, ext_offset=4, repeat=4.
And I found when the code is attacked, width is always 0.

2

In our Introduction to Clock Glitching notebook we show that the glitch is synthesized by creating two shifted copies of the input clock and combining these two copies. scope.glitch.width controls the shift for one of the shifted clocks and scope.glitch.offset controls the shift for the other.

If you set the width to 0, you will get a glitch pulse that has a very very small width, or perhaps doesn’t exist at all. We also note in the API documentation that the system may not be reliable when the width is set to 0.

3

Thank jpthibault. Understood.
Maybe I can give the protect code as below.

trigger_high();
for (i = 0; i < count; i++) {
    index[i] = data[i];
}
trigger_low();

if (((i) != (count)) || (~(i) != ~(count))) {
    PANIC;
}

if (i != count) {
    if ((~i) != (~count)) {
        uart_puts("1234");
        while(1);
    }
}

I think the “for” condition is protected, cannot print “1234”. But I found “1234” is printed sometimes.
So how to understand it?

4

I’m not sure what you mean by “protected” here. But in any case, in situations like these it’s important to see what the compiler has decided to do with your code.

5

Thanks. I can give the assembly code compiled as below. If attack is occurred. It should jump to “PANIC” which is a dead loop, cannot print “1234” . But “1234” is printed sometimes.

trigger_high();

80002f8: f000 f926 bl 8000548 <trigger_high>
for (i = 0; i < count; i++) {
80002fc: 2300 movs r3, #0
80002fe: f8c7 3080 str.w r3, [r7, #128] ; 0x80
8000302: e011 b.n 8000328 <for_check_main+0x70>
index[i] = data[i];
8000304: f8d7 3080 ldr.w r3, [r7, #128] ; 0x80
8000308: f8d7 2088 ldr.w r2, [r7, #136] ; 0x88
800030c: 441a add r2, r3
800030e: f8d7 3080 ldr.w r3, [r7, #128] ; 0x80
8000312: 7812 ldrb r2, [r2, #0]
8000314: f107 0190 add.w r1, r7, #144 ; 0x90
8000318: 440b add r3, r1
800031a: f803 2c50 strb.w r2, [r3, #-80]
for (i = 0; i < count; i++) {
800031e: f8d7 3080 ldr.w r3, [r7, #128] ; 0x80
8000322: 3301 adds r3, #1
8000324: f8c7 3080 str.w r3, [r7, #128] ; 0x80
8000328: f8d7 3080 ldr.w r3, [r7, #128] ; 0x80
800032c: f8d7 2084 ldr.w r2, [r7, #132] ; 0x84
8000330: 429a cmp r2, r3
8000332: d8e7 bhi.n 8000304 <for_check_main+0x4c>
}
trigger_low();
8000334: f000 f913 bl 800055e <trigger_low>

if (((i) != (count)) || (~(i) != ~(count))) {

8000338: f8d7 3080 ldr.w r3, [r7, #128] ; 0x80
800033c: f8d7 2084 ldr.w r2, [r7, #132] ; 0x84
8000340: 429a cmp r2, r3
8000342: d107 bne.n 8000354 <for_check_main+0x9c>
8000344: f8d7 3080 ldr.w r3, [r7, #128] ; 0x80
8000348: 43da mvns r2, r3
800034a: f8d7 3084 ldr.w r3, [r7, #132] ; 0x84
800034e: 43db mvns r3, r3
8000350: 429a cmp r2, r3
8000352: d001 beq.n 8000358 <for_check_main+0xa0>
SCAP_PANIC;
8000354: f000 f81c bl 8000390 <scap_panic_loop>
}

if (i != count) {

8000358: f8d7 3080 ldr.w r3, [r7, #128] ; 0x80
800035c: f8d7 2084 ldr.w r2, [r7, #132] ; 0x84
8000360: 429a cmp r2, r3
8000362: d00b beq.n 800037c <for_check_main+0xc4>
if ((~i) != (~count)) {
8000364: f8d7 3080 ldr.w r3, [r7, #128] ; 0x80
8000368: 43da mvns r2, r3
800036a: f8d7 3084 ldr.w r3, [r7, #132] ; 0x84
800036e: 43db mvns r3, r3
8000370: 429a cmp r2, r3
8000372: d003 beq.n 800037c <for_check_main+0xc4>
uart_puts(“1234”);
8000374: 4804 ldr r0, [pc, #16] ; (8000388 <for_check_main+0xd0>)
8000376: f7ff ff2f bl 80001d8 <uart_puts>
while(1);
800037a: e7fe b.n 800037a <for_check_main+0xc2>
}
}

6

I won’t analyze your assembly, but there are certainly many ways that a glitch could lead to 1234 being printed.
As you noted here glitching is complex and can have many effects.

7

Hmmm. Yeah, it is really mysterious and hard to explain rationally…