Problems Glitching nrf52832

[pascal-gujer]

Thank you for this nice little SWD programmer GUI and the glitcher for the ESP32 :D

I am currently trying to glitch an nrf52832. I narrowed down the glitching width in the source code to 6-10us, as this should do the trick according to other researchers. I try to find the right timing for glitching the nrf52832 for quite some time now. Somehow I am either glitching at the wrong timing or just doing something wrong. Has anyone a hint for me? I recorded some scope recordings:

Where should the glitch be applied? I thought somewhere around +7ms in Zoom1/Zoom2 - is this correct?

[atc1441]

Hey.

The nRF52832 is way harder then the nRF52840, i was able to glitch it and your timing at +7 ms is correct.

I am not sure why nRF52832 is harder it could be that caps are needed to be removed

[pascal-gujer]

Thank you for the quick response! Do you remember the glitch width which yield to success? And how long did it take for you?

[bettse]

I had to buy an oscilloscope (analog discovery 2) to get the right timing, but I was successful with an nRF52832. I tweaked the code to allow a delay up to 60 and used these settings:

• Delay: 8250
• Delay end: 8500
• Power off delay: 100
• SWD wait: 100

It took something on the order of 6 hours but I eventually got a final

Answer: Glitcher running Delay: 8382 Width: 40

[ANTI443]

I had to buy an oscilloscope (analog discovery 2) to get the right timing, but I was successful with an nRF52832. I tweaked the code to allow a delay up to 60 and used these settings:

• Delay: 8250
• Delay end: 8500
• Power off delay: 100
• SWD wait: 100

It took something on the order of 6 hours but I eventually got a final

Answer: Glitcher running Delay: 8382 Width: 40

---

Wow Great job @bettse could you make a repo and upload your version?

Also could you explain what and where you changed they code up. To help the community.

Cheers. @bettse

[bettse]

Had my change been any more significant, I absolutely would have forked and opened a PR.
The 'tweak' I made was on this line: https://github.com/atc1441/ESP32_nRF52_SWD/blob/main/ESP32_SWD_WIFI/glitcher.cpp#L15

changing the width_max from '30' to '60'.

[ANTI443]

@bettse thank you for the information! Do you happen to have a picture of your oscilloscope output, for visuals?

Cheers.

[bettse]

It is very much like Pascal's

[ANTI443]

@bettse hey looks about the same, what do you think?

[ANTI443]

@bettse question did you change anything else? I have been letting the glitcher run for 24hrs, with no success.

nRF52832

Delay start 8250 Delay end. 8600

Power off delay 100 SWD wait. 100

Width I changed it to 0 -60

I'm using a DC 5V-36V 15A Max 30A 400W Dual High-Power MOSFET Trigger Switch Drive Module 0-20KHz

Are you using the same mosfet? I would appreciate your advice thank you.

• cheers

[bettse]

Looks like the same mosfet. The glitch in your screenshot does look quite a ways before dip, but it's hard to be sure without a timescale. From what I read about glitching the nrf52832 there is a certain amount of luck involved.

[pascal-gujer]

A general question to the ones succeeding in glitching the nrf: What was your room temperature?

I have the Idea, that maintaining a constant temperature is crucial and that warmer temperatures help with glitching…

[bettse]

My thermostat would have been near 72°F (Stop looking at me like that, I live in the US, this is how we measure temperature). I'm in a well insulated building, so I suspect it would be near that value if not slightly above.

I look forward to a blog post on "glitching in the oven" 😆 .

[charliebruce]

I found the following that might be useful:

• You might need to remove excess capacitance from the target supply (3.3v) rail. I tried this technique on a board with ~20uF of total capacitance on the supply rail. This causes slower ramp-up of the supply, which leads to variability in the power-on time and makes the technique unreliable.
• You might need to use a P-channel FET or load switch to power the board on in a repeatable manner. Sourcing the current directly from the ESP32 pin might not supply enough current, especially if your target has high-power peripherals.
• Rather than modifying the target, you could instead transplant the nRF52 onto a known-vulnerable board using hot air desoldering.
• You might still need multiple repetitions over the same timing region. Getting that as close as possible on the scope, and changing the delay start/end periods to cover a small range should make this faster.
• You may need to remove the DEC1 capacitor entirely, rather than just soldering to its terminal.

I didn't need any increase in my glitch width, and I was using the same MOSFET module. Not sure how temperature would affect things, but it would have been around 22C/72F for me as well.

[ANTI443]

@charliebruce wow thank you for the information mate. We all appreciate it and thank you for the help 🤗.

• cheers

[ikarus23]

Had my change been any more significant, I absolutely would have forked and opened a PR. The 'tweak' I made was on this line: https://github.com/atc1441/ESP32_nRF52_SWD/blob/main/ESP32_SWD_WIFI/glitcher.cpp#L15

changing the width_max from '30' to '60'.

Thank you @atc1441 for this great tool and thank you @bettse for the parameters! With that I was able to glitch my nRF52832! Don't even have an oscilloscope (yet), but enough time ;)

• Delay: 2000
• Delay end: 8000
• Power off delay: 100
• SWD Wait: 100
• Pulse width: 60 (https://github.com/atc1441/ESP32_nRF52_SWD/blob/main/ESP32_SWD_WIFI/glitcher.cpp#L15)

Off topic: It would be great if the pulse width would be a configurable parameter

[atc1441]

Please check out the branch called PCB_Version.

If i remember right i did add the option to setting more time. I did added it for sure just dont know if i ever published it

That version has a different pinout.

[atc1441]

Was just glitching an nRF52832 I removed 2 caps, after doing that it only took 30 seconds as on the nRF52840, so as a tip i suggest on removing these 2 caps for nRF52832 glitching

[ikarus23]

Yes, it seems like these caps (or other caps in the power circuit, if there are any) will keep the nRF52 powered way longer. I now have an oscilloscope and was able to confirm, that a power off delay of 100 is the bare minimum for my setup. Also, with cap C4 gone, I'm pretty sure the typical pulse width should be ok and modifying glitcher.cpp is not needed. (Can not confirm this. So far I don't want to remove C4 in my setup.)

[atc1441]

Tested once more with resoldered C9 so it seems C4 is enough to remove.

Then i have a super reliable glitch after just a 1-30 seconds

[ANTI443]

@atc1441 hey 👋 what perimeters are you using? I think it would be helpful to include the information for others. nRF52832

Mine are 8550 - 8700 32 width Power off 150 swd 150 Time 0 mins to 3 hrs it's random for me.

[c0d3z3r0]

@atc1441 can you share your timing settings? :)

[c0d3z3r0]

So, I removed C4, C9, C10 on a device based on the reference schematics. Chip Rev. is E (not fixed like G). I've tried various timing ranges, increased max_width=60 but have no luck yet :/ (No scope here, unfortunately)

[c0d3z3r0]

Got a scope now. I successfully glitched a nrf52840 (makediary nRF52840 Micro Dev Kit, cap present) multiple times. However, nrf52832 seems to be a tough nut to crack. I have two different devices, which I didn't glitch successfully, yet:

• JINOU BLE0405C1P, cap on DEC1 removed
• custom device, cap on DEC1 removed (not allowed to publish details, but it's based on the reference schematics)

This is what the JINOU looks like on the scope:

CH1 VCC_nrf (trigger), CH2 DEC1, CH3 glitch signal

Parameters:

• width 1-32
• power on delay 50ms (I also tried 150-200)
• swd delay 50 (also tried longer delays)
• voltage drop on DEC1 is at roughly 1640us, so glitch delay 1640 - 3000

[atc1441]

Can agree that the nrf52832 is harder to catch. Sometimes i needed to glitch for 24hours

[c0d3z3r0]

Can agree that the nrf52832 is harder to catch. Sometimes i needed to glitch for 24hours

Hmm, you mean for 24h in a loop? IOW testing multiple delays multiple times?

I wonder if it would get better with even shorter glitches.

[atc1441]

Yes, the ESP32 was looping trough the set times, also since the temperature does also has an influence this does extend it in the end as well. On one device the glitching did took not even 1 minute on the other hours so its a bit of luck involved, i had better luck with desoldered Capacitors around DEC

[c0d3z3r0]

Yes, the ESP32 was looping trough the set times, also since the temperature does also has an influence this does extend it in the end as well. On one device the glitching did took not even 1 minute on the other hours so its a bit of luck involved,

i had better luck with desoldered Capacitors around DEC

I tried with only DEC1 cap (C4 in the ref schematics) removed and with the VCC cap (C9) and even C10 removed additionally. Did you remove the DEC4 cap as well?

[atc1441]

Dont remember exactly, but its worth a try.

[c0d3z3r0]

Finally..... JINOU has fallen \o/ Removing DEC1-4 was too much (voltage became extremely unstable), so I resoldered DEC2-3. One thing I noticed is that by increasing the glitch delay the voltage drop gets pushed ahead (iow delay between power on and drop increases as the glitch delay increases) until the glitch point suddenly is several hundred us past the voltage drop... Maybe that is what makes glitching the nrf52832 so hard.

Oh, important detail: I glitched DEC4

Update: success on the other device through DEC4!

[c0d3z3r0]

Outch. Glad too early... the flash always only reads 42 00 00 23 .... o.O

Another update: just glitch multiple times and retry. Flash dump will work at some point

[TimelessNL]

Thanks for this great find! I was able to glitch a nrf52832 successfully with C4 removed within 3 hours.

Unfortunately I trying to glitch another nrf52832 on a different style board without C4 removed (yet, as the board is very cramped and removing the cap is difficult) but I'm having trouble understanding the build-in software oscilloscope.

I've tried multiple timings, but the voltage drop seems to move between the glitch timings 3690 - 5680:

When I choose glitch timings before 3690 and after 5680 I can clearly see that the glitch is to soon or late:

Did anyone observe such a moving voltage drop, and to my understanding the glitch should have more success in the 5680 range than it would around 3690. As after 5680 the natural voltage drop seems to happen?

[c0d3z3r0]

Thanks for this great find! I was able to glitch a nrf52832 successfully with C4 removed within 3 hours.

Unfortunately I trying to glitch another nrf52832 on a different style board without C4 removed (yet, as the board is very cramped and removing the cap is difficult) but I'm having trouble understanding the build-in software oscilloscope.

I've tried multiple timings, but the voltage drop seems to move between the glitch timings 3690 - 5680:

When I choose glitch timings before 3690 and after 5680 I can clearly see that the glitch is to soon or late:

Did anyone observe such a moving voltage drop, and to my understanding the glitch should have more success in the 5680 range than it would around 3690. As after 5680 the natural voltage drop seems to happen?

Check out my comment https://github.com/atc1441/ESP32_nRF52_SWD/issues/10#issuecomment-1416321034 I have seen this "moving target", too. I tried, too, with the built-in osci but it was a PITA, so I got myself a real osci.

The correct glitch point is right after that voltage drop. Timing is very much depending on multiple factors like 1) temperature 2) exact capacitance values (tolerances, trace lengths etc.) 3) attached peripherals 4) probably more. So, the only way to find the right timing is by trying on the specific device.

[TimelessNL]

Ah you're right, I read your comment but I misinterpreted it the first time 🤦. Now I see it.

Temperature is quite cold (18°c) and previous successful glitch was indeed warmer (25°c). Maybe I should use a hair dryer to get the temps up 😆.

Mmh so if it should be right after the voltage drop in my case the glitch delay should be between 5680 and 5900 I suppose.

[c0d3z3r0]

Ah you're right, I read your comment but I misinterpreted it the first time 🤦. Now I see it.

Temperature is quite cold (18°c) and previous successful glitch was indeed warmer (25°c). Maybe I should use a hair dryer to get the temps up 😆.

That might help

Mmh so if it should be right after the voltage drop in my case the glitch delay should be between 5680 and 5900 I suppose.

You can also try to glitch through DEC4 instead, where I had waaaaaay better results

[TimelessNL]

And by using DEC4 you removed C4 and C10 correct?

[c0d3z3r0]

And by using DEC4 you removed C4 and C10 correct?

Yep

[TimelessNL]

Also my chip dates from 2021 week 11 and according to the description below (source), and from what I've read the method is patched around November 2021. So I suspect my chip is still vulnerable 🤔🙏

[c0d3z3r0]

Also my chip dates from 2021 week 11 and according to the description below (source), and from what I've read the method is patched around November 2021. So I suspect my chip is still vulnerable thinkingpray

You just can check the hardware revision, which is the first of the two letters in the build code (HP). For nRF52832 anything before G is vulnerable (G is the first fixed revision). For nRF52840 it's anything before E.

[TimelessNL]

Ah that's even better, mine is at E0 so it is definitely vulnerable 😈

[TimelessNL]

And by using DEC4 you removed C4 and C10 correct?

Yep

I've been running the glitching on previously said timings yet no successful glitch after 24h 😢 So I removed C4 and C10 together with C9 as they were all cramped together. And as C9 is on the VDD line and that one also got removed on my first successful glitched nRF52832 I hope it doesn't affect things very much this time.

I do still glitch using DEC1 though as I had some success with it previously, if this again fails I will try DEC4 and maybe re-solder C9.

As you also noticed the power (DEC1?) is very noisy after removing the caps, yet I'm able to read the coreid and detect that the unit is locked. So at least the CPU is somewhat functioning I suppose.

[c0d3z3r0]

And by using DEC4 you removed C4 and C10 correct?

Yep

I've been running the glitching on previously said timings yet no successful glitch after 24h cry So I removed C4 and C10 together with C9 as they were all cramped together. And as C9 is on the VDD line and that one also got removed on my first successful glitched nRF52832 I hope it doesn't affect things very much this time.

I do still glitch using DEC1 though as I had some success with it previously, if this again fails I will try DEC4 and maybe re-solder C9.

As you also noticed the power (DEC1?) is very noisy after removing the caps, yet I'm able to read the coreid and detect that the unit is locked. So at least the CPU is somewhat functioning I suppose.

Well, yeah, I was trying for hours and hours without success. Then switched to DEC4 and had damn reliable success within a hour of testing various timings :D Don't waste your time :P

I wonder how bad flash reading are going to be if you got a successful one with that unstable power :/ Could be that dumping doesn't work at all, but that's just pure speculation.

[TimelessNL]

My first successful glitch had C4 and C9 removed, unfortunately I did not test if it had unstable power at the time. It did however got 3 matching dumps so I suspect they were correct, and device was still able to run its program without the caps.

Maybe if glitching keeps failing I test the other PCB and see how that one behaves.

[TimelessNL]

Well, yeah, I was trying for hours and hours without success. Then switched to DEC4 and had damn reliable success within a hour of testing various timings :D Don't waste your time :P

I've now attached the glitch signal to DEC4 but the build-in osci is all over the place 🥲 When I measure the wire itself it is at 1.427v which seems alright to me.

Seeing this graph I cannot determine the right glitch timing.

[c0d3z3r0]

Well, yeah, I was trying for hours and hours without success. Then switched to DEC4 and had damn reliable success within a hour of testing various timings :D Don't waste your time :P

I've now attached the glitch signal to DEC4 but the build-in osci is all over the place smiling_face_with_tear When I measure the wire itself it is at 1.427v which seems alright to me. Seeing this graph I cannot determine the right glitch timing.

Oops. You could try to resolder the DEC4 cap. I think I had seen that as well but... it was laaaate... so I don't remember well \o/

[TimelessNL]

So you mean you either had C10 and C4 or only C4 removed? But are not sure what combination created a successful glitch?

[c0d3z3r0]

So you mean you either had C10 and C4 or only C4 removed? But are not sure what combination created a successful glitch?

Yeah, right. Maybe I just remembered wrongly when reporting success here :/ I had tried various combinations

[TimelessNL]

Ok re-soldered C10, and the graph seems more promising now. At what point did you apply the glitch?

[c0d3z3r0]

Ok re-soldered C10, and the graph seems more promising now. At what point did you apply the glitch?

Yeah, that looks way better! It's difficult to estimate bc of the missing scale, but it should be a bit earlier, like so:

You should start here, right before the drop:

[TimelessNL]

Thanks! Seems to be between 5600 and 5700, I'll let it run for some time. 👍 I must say that the glitch has another impact on DEC4 than it does on DEC1. On DEC4 the voltage drop gradually decreases after the glitch, while on DEC1 it remains a immediate drop

[c0d3z3r0]

Thanks! Seems to be between 5600 and 5700, I'll let it run for some time. +1 I must say that the glitch has another impact on DEC4 than it does on DEC1. On DEC4 the voltage drop gradually decreases after the glitch, while on DEC1 it remains a immediate drop

Yeah, the "moving target" problem gets worse indeed.