Hi Alex,
Unfortunately, the V5 doesn’t really work well on my side.
Is there anything on the V4 which I could use?
I’m still not getting any VCC glitches to work on the CW1200 + CW308(STM32F3) =(
Regards,
Melvin.
Hi Melvin,
Unfortunately I never had any success glitching the F3 while I was using v4. With that tutorial setup, I actually found more success on the Lite Arm with the HP glitch, so if you haven’t tried that yet, it might provide better results.
Alex
Hi Alex,
Thanks for the tip.
Just to check, did the HP glitch and external offset of 2186 work for glitch1 on the F3?
Regards,
Melvin.
Yeah, that’s correct. All the code there is run through sequentially when we generate the tutorials.
Alex
Do you mean this tutorial “https://chipwhisperer.readthedocs.io/en/latest/tutorials/fault_2-openadc-cwlitearm.html#tutorial-fault-2-openadc-cwlitearm”?
I thought it was glitching glitch_infinite() instead of glitch1(). Hahaha.
Hi Melvin,
That width and offset was for 3 cm coax connector with glitch_infinte() function. For glitch1() I found that the glitch has another offset. I has finding it in this range of parameters:
offset_range = Range(-35, -33.2, 0.4)
width_range = Range(17.5, 19.5, 0.4)
sample_size = 25
scope.glitch.repeat = 25
scope.glitch.ext_offset = range(140, 200, 5)
where the sample_size mean number of trying to glitch.
Regards,
Nik.
Hi Nik,
Thanks for the reply.
For the glitch1() parameters, are they for the 3cm coax connector or the 60cm coax cable?
Also, are these parameters for high power glitch, i.e. scope.io.glitch_hp = True?
Do these glitch parameters work 100% of the time?
Regards,
Melvin.
Whoops, I misread your post. This is for glitch_infinite(), not glitch1().
Hi Alex,
Do you have any glitch parameters that work for glitch1()?
Thanks.
Regards,
Melvin.
Hi Melvin,
Your ext offset should be between 37 and 47. Width/offset should be the same as with glitch_infinite().
Alex
Hi Alex,
Could you share the modified script for executing the attack script on glitch1?
Also, I noticed that the only difference (assuming the underlying python codes are the same) is that the V5 glitcher uses ext continuous glitching whereas the V4 glitcher uses ext single shot glitching. Do you know why is this the case?
Is ext continuous glitching just a triggered version of continuous glitching?
I’ve also tried running glitch_infinite() using the V5 from the VM. I did not manage to get any glitch parameter to work. It shows:
[38.671875, -28.515625, 0.0, 0.0] =(
[39.0625, -28.515625, 0.0, 0.0] =(
Any suggestions?
Thanks.
Regards,
Melvin.
Hi Melvin,
Unfortunately, I’ll be away for the next week, so I won’t be able to get the glitch1 script to you until I get back. Regarding the glitch_infinite() tutorial from the VM, try finding an area around where the target begins to crash, then scan offsets in that width area.
Alex
Hi Alex,
Another thing I noticed about the V5 is that on the CWpro, glitch.offset_fine and glitch.width_fine are set to 0 when I was running through 1.3.4 despite setting those parameters with some values.
Any advise on this?
Regards,
Melvin.
Hi Melvin,
From my understanding, reading the value back from the FPGA is unreliable due to the possibility of the underlying hardware block that the register represents being modified without that register being updated. As such, we’ve made the value write-only, since the read could potentially be incorrect.
That being said, I could be incorrect, since I’m not very knowledgeable about FPGA stuff and I’m only relaying information from Colin.
Alex
Hi Melvin,
You may want to try some other ext_offsets as well. We’ve had people had a lot of success with other ext_offsets (1000 worked well for a lot of people). We’ve also had a lot of success with smaller glitches with large repeats.
Alex
Hi Melvin,
This parameters correct for 3cm coax.
I setup scope.io.glitch_lp = True, scope.io.glitch_hp I don’t setup (think this must be False).
Yes, parameters is stable by the time.
Regards,
Nik.
Hi Alex,
Did you have some experience in VCC glitch attack the glitch3()? Does it possible?
I have success atack by clock glitch, but can’t get VCC atack.
Sometime by the atack in results I see the password in the buffer of UART messages. But this dissapered when I do the char passwd[] = “touch”; global.
Regards,
Nik.
Hi Nik,
Yeah, I also haven’t been able to glitch past the password check. It’s possible that on the STM, VCC glitching will only really corrupt read/write values, while the glitching past the password check depends on skipping instructions.
Alex
Hi Alex,
Thank’s for your answer!
I have another question. At this time I keep try to bypass Read Protection in Bootloader of STM32F1. Did you have any experience in this question? Can you give me any recommendations how to do it?
I have reade this tutorial http://wiki.newae.com/Tutorial_A9_Bypassing_LPC1114_Read_Protect and this paper https://pdfs.semanticscholar.org/4c01/a7514deacc2c02d010bb14c4fb58d1712adc.pdf
Regards,
Nik
Hi Nik,
We’ve actually tried to recreate the F3 version of the attack, but were unsuccessful. As for the F1 version of the attack, your best bet is probably to try triggering off the communication line. How difficult that is will depend on how you’re communicating with the bootloader (UART would be fairly simple, but something like USB would probably require some additional hardware to generate the trigger).
Otherwise, proceed as normal (i.e. scan ext_offsets, offsets, widths) until you get a glitch.
Alex