Help needed with Tutorial A3 VCC Glitching XMEGA Target

Hello.

I’ve been trying very hard to VCC glitch the XMEGA target as described in Tutorial A3.
I’ve ran through various glitch widths, glitch offsets, glitch external offsets, glitch repeats.
None of the above combinations worked =(

Would appreciate if someone could share some insights to this.
Thanks.

Regards,
Melvin.

Hi Melvin,

You’re probably better off just skipping VCC glitching for now, since they don’t seem to work very well on the XMega at the moment. VCC glitching in particular can be very sensitive to small changes in setup, so I’m guessing the conditions of the setup when the tutorial was written don’t quite match new ChipWhisperers.

Alex

Hi Alex,

Thanks for the reply.
Noted on the advice. Do you have other easier targets where I can practice VCC glitching on?

Hope to hear something from Colin O’Flynn as well.
Thanks.

Regards,
Melvin.

Hi Melvin,

Personally, I found the most success performing the LPC1114 Attack. I’ve also had some success running the glitch described here, though it’s been a few months since I’ve run either.

The CWNano is also apparently a pretty reliable VCC glitch target as well, though Colin has a lot more experience than me with that one.

Alex

Hi Alex,

Thanks for the reply.
My CW1200 kit just arrived. I noticed that the target board in the kit is a STM32F3.
Will this work like the STM32F0 as described in your 2nd link?

Regards,
Melvin.

Hi Melvin,

I did try getting some voltage glitching done on F3 around the time moved that tutorial to CW5, but I didn’t have any luck with it. It should be possible, but unfortunately I don’t have any advice for the setup like with the F0.

Alex

Had some time to try glitching on the F3 and I may have found some settings that work on 7.37MHz:

Width 20.7 to 22.7
Offset (-19.1) to (-19.9)

I’m not sure what glitch setup you’re on, but give those a try. Also, my F3 board doesn’t have C5, C6, C7, and C8.

Alex

Hi Alex,

Thanks for the prompt reply.
May I know what external trigger offsets and how many repeats did you have?
Did these values work for glitch_infinite or glitch1?

Separately, I noticed that you suggested running 35 times faster than the target’s clock speed. This will give us much better control over the width, shape, and placement of our glitches. When should we resort to such means?

Thanks.

Regards,
Melvin.

For Tutorial A9 with the LPC-P1114 Development Board, I observed that glitch width and glitch offset aren’t particularly important as opposed to the external trigger offset and the repeats. This approach seems to differ from the one described in A2 and A3, where we start by scanning the across the glitch width and glitch offset first. Could you share when will the A2/3 vs A9 approaches be appropriate?

Thanks.

Regards,
Melvin.

Hi Melvin,

I ran with an external offset of 2186 and a repeat of 1, attacking glitch_infinite().

In that case, I tried the higher clock speed since I was trying to mimic the glitch response of the Nano, which also has an F0 target and is very susceptible to voltage glitching, but a different glitch module. I figured that using the higher clock speed would give me greater control over the response. In other cases, such as when attacking the LPC, I used a 100MHz clock speed since I was replicating an attack and that was the clock speed used in that attack.

For Tutorial A9, the glitch module is set to “enable_only”, which pulls Vcc low for the entire clock cycle. This means that the width/offset parameters have no effect in this case. For A2, as well as in the F3 case, I’m using “glitch_only”, which is affected by these settings.

When the target/CW are running at the same clock speed, ext_offset is basically controlling which instruction is being attacked, while width/offset determine whether that attack is successful. Repeat just makes it so the glitch is repeated every clock cycle (less useful in this case as it often causes the target to crash). When running at different clock speeds, ext_offset controls both the attack settings and which instruction is being attacked, while repeat becomes the width of the glitch.

Your best case scenario for finding glitch settings is to vary the offset/width in a situation where you know the ext_offset is right, though that situation isn’t always easy to setup. The offset/width can then be applied to other situations.

Hope that clears things up,

Alex

Hi Alex,

Thanks again for the detailed explanation.
I’m just curious about the external offset of 2186.
The code for glitch_simple is as follows:

void glitch_infinite(void)
{
char str[64];
unsigned int k = 0;
//Declared volatile to avoid optimizing away loop.
//This also adds lots of SRAM access
volatile uint16_t i, j;
volatile uint32_t cnt;
while(1){
cnt = 0;
trigger_high();
trigger_low();
for(i=0; i<200; i++){
for(j=0; j<200; j++){
cnt++;
}
}
sprintf(str, “%lu %d %d %d\n”, cnt, i, j, k++);
uart_puts(str);
}
}

My basic understanding of external offset trigger is the number of clock cycles it waits after trigger_high() was called in glitch_infinite. For example, if external offset trigger was 0, the glitch module would immediately perform VCC glitching, and if external offset trigger was 10, the glitch module would wait 10 clock cycles before performing VCC glitching. So when external offset trigger was set at 2186, are we waiting to hit the instruction that is executed 2186 clock cycles after trigger_high() was called? Which instruction are we actually trying to hit? Does this also work for glitch1?

One other question, does it make sense to set negative glitch widths for VCC glitching? My chipwhisperer pro has a mini display that plots the shape of the VCC glitch. So when I was sweeping through the glitch widths from the negative extreme to the positive extreme, I noticed that it shows a flat line when glitch widths are negative but shows pulses of varying widths when on positive glitch widths.

Regards,
Melvin.

Hi Melvin,

Your assumptions are correct for ext_offset. We’re not really trying to hit any particular instruction here (since glitch infinite has a bunch of different cycle offsets that should cause a glitch), I just picked a value that worked well for another device I was glitching on. For something like glitch1(), you will have to be a lot more precise with ext_offset.

Alex

Hi Alex,

I’m been trying to VCC glitch my F0 board to get the “1234” in glitch1, but I’ve seem to hit a wall.
Could you share the glitch parameters that you had success with? Also, do the STM32Fx boards typically require multiple repeats to be glitched or only 1 repeat is suffice?

Another question, I noticed that the glitch parameters obtained from running Python script differ when I tried manual glitch. For example, I varied the glitch widths and offsets using a Python script and ext trig offset and it tells me that glitch widths > 25 will cause the target to reset regardless the glitch offset. However, when I keyed in glitch width of 24 using manual trigger, the target behaves differently, i.e. reset =(
Any insight on this?

Thanks.

Regards,
Melvin.

Hi Melvin,

Have you gotten glitch_infinite working? You should be able to use your settings from there for this attack as well, with only the ext_offset changing.

Assuming you’re running at 7.37MHz, a repeat > 1 will usually cause the target to crash. There shouldn’t be any difference between using the manual trigger vs. triggering automatically. The only thing I can think of is that you may be hitting an instruction that will crash the target if corrupted/skipped when you’re doing it manually.

If you’d like, I should be able to try the attack sometime next week.

Alex

Hi Alex,

Thanks for the reply. Definitely appreciate your time and effort to try the attack.

Yup. I’m at 7.37MHz. I haven’t tried glitch_infinite yet. I went straight to glitch1 XD
I was wondering if you could share your approach to VCC glitching?
Let’s say you have a STM32F0 board programmed with glitch1. What would you do first?

If I’m following Tutorial A2/3 correctly, my first step would be to fix repeat = 1, ext trigger offset = 0, and sweep glitch widths and offsets. Once I get a glitch plot, I would be able to tell which glitch widths and offsets cause the target to reset, and those glitch widths and offsets that the target do not respond to.

My second step would be to replica the above, just that repeat = 2. Then repeat = 3, and so on. Is my approach correct?

Thanks again =)

Regards,
Melvin.

Hi Melvin,

I’d recommend starting with glitch_infinite() first, as glitching that effectively removes ext_offset as a variable (since there’s so many instructions to glitch). You should also keep repeat as 1 unless you’re unable to get any glitches/crashes even with max glitch width. Repeats higher than 1 will usually just crash the target since the voltage for the target usually hasn’t fully recovered by the end of the glitch cycle. Other than that, that seems like a good approach to finding glitch settings.

Alex

Hi Alex,

Thanks again for the advice.
I’ll work on glitch_infinite() for both the F0 and F3. Supposedly if I had success with those boards, what is next?
Will the glitch widths and offsets for glitch_infinite() work on glitch1() as well?

Thanks =)

Regards,
Melvin.

Hi Melvin,

Yeah, those widths and offsets should work for glitch1() as well (at least that’s been my experience glitching other stuff), it’s just a matter of finding the right ext_offset for that function. Some other stuff you may want to try after you’ve had your fill with glitchsimple.c:

  • Mapping out how often different settings produce glitches to find which settings work best. This is pretty difficult to do with the GUI, but it’s a lot simpler to do via the Python API and it’s something we cover in the CW5 versions of the tutorial.
  • Trying out Tutorial A7 with voltage glitching.
  • There’s some new tutorials on CW5 that involve glitching - Fault_4, which uses glitching to break AES, and Fault_5, which uses glitching to break RSA. These are both clock glitching tutorials (and the AES one was designed for the XMEGA), but if you’re looking for a challenge, these should both be possible via voltage glitching as well.

Alex

Hi Alex,

I have tried glitch_infinite() on the F0 for the whole day but no luck at all =(

P.S.: I meant to say “what is next” as in what should I do after I obtained a set of glitch width and offset that worked for glitch_infinite(). Guess that can wait till I solve glitch_infinite() first XD

Regards,
Melvin.

Hi Melvin,

After you find some good width/offset settings, you should be able to directly apply them to glitch1() and only worry about ext_offset.

I’ve been doing some testing, and I’ve only been getting glitches with an SMA cable of roughly 15cm with the settings I’ve mentioned earlier. I’ve tried a cable of 30cm and not gotten any glitches.

Alex