ESP32_nRF52_SWD
ESP32_nRF52_SWD copied to clipboard
atc1441
Problems Glitching nrf52832
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?
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
Thank you for the quick response! Do you remember the glitch width which yield to success? And how long did it take for you?
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
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
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'.
@bettse thank you for the information! Do you happen to have a picture of your oscilloscope output, for visuals?
Cheers.
@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
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.
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…
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" 😆 .
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.
@charliebruce wow thank you for the information mate. We all appreciate it and thank you for the help 🤗.
- cheers
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
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.
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
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.)
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
@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.
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)
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
Can agree that the nrf52832 is harder to catch. Sometimes i needed to glitch for 24hours
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.
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
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?
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!
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