I am trying to glitch the LPC1765 using a CW Lite. I made a custom PCB with only the CPU and 3 pin headers for the programming mode, UART and power. The CPU runs a simple loop that increases 2 counters and compares them (they are marked as volatile so optimization didn’t remove them, I checked in a disassembler). Once they differ it will enter an infinite loop and write “sucess” on the UART, that’s when I know the glitch worked.
Unfortunately I just can’t get a glitch done. Either I trigger BOD or nothing happens at all. So I assume either my glitches are too short or too long. As this CPU seems to have an internal voltage regulator that supplies 1.8V to the core I tried to lower VCC aswell to the lowest possible voltage at which the chip runs stable. That also didn’t help so I am not sure what else to try.
Anybody has any idea what I could try? I am pretty sure this CPU can be glitched and I am doing something wrong, but what am I doing wrong?
Try bumping up the clock frequency of the Lite to 200-300MHz and using enable_only mode (only repeat and ext_offset will matter). This will help give you more precise glitches.
Try inserting a shunt resistor between the device power supply and the LPC. This will change the glitch waveform which may help.
thanks for your help and sorry about my late response, I wasn’t able to work on this until now! Unfortunately my CW is bricked somehow (I’ve created a new thread for that), so I will have to find a solution for that first before I can try this.
I tried increasing the clock frequency. I am using the manual trigger since currently I am trying to glitch some loop, so any sucessful glitch there is already sufficient. I am wondering: Does the “offset” even matter in this mode? As far as I understand it moves the glitch within the clock cycle, so for manual triggering which isn’t really synced to anything it doesn’t really matter for my case? So I can just ramp up the clock to 300MHz and then try all possible width’s and repeats (and setting offset to 0), hoping I get some success in this case? And in case it doesn’t work different shunt resistors and going through all those values again.
Width and offset don’t do anything in enable_only mode. Instead, repeat determines your glitch width, while ext_offset accounts for the offset. Other than that, your plan sounds correct, though you may want to try recreating the “DPA on Fuse Bytes” section of chipwhisperer-jupyter/LPC1114_Fuse_Bypass.ipynb at master · newaetech/chipwhisperer-jupyter · GitHub to help you narrow down the ext_offset.
I’m in manual mode right now, trying to glitch an endless loop. This should be a lot simpler than doing the Fuse Bypass as I can’t really get the offset/ext_offset wrong, correct? So basically I wrote code that constantly calls manual_trigger, tries to read from the serial the “Ooops” message that should occur if my glitch worked and if it reads “Restart” it counts up the “restart” counter, and if there’s nothing it counts up the “normal” counter.
In manual mode the offset doesn’t do anything either? Or is it worth testing various values for that aswell?
Manual mode is unrelated to having your output set to enable_only. ext_offset is unused in manual mode, as the clock cycle based timing is effectively random. Offset is still useful in manual mode so long as you’re not in enable_only mode as, depending on your hardware setup, the CW and the target may be phase locked. This means you can still precisely change the phase offset of the glitch, which can affect glitch success in a similar way to width.
Ah okay, got it. Unfortunately the LPC has an internal clock, so getting them locked won’t work. I will try to ramp up the frequency now, switch to enable_only, set the offset to 0 and try again to sweep through possible width and repeat values, hoping to get some kind of success like this.
Alright. I tried various shunts now (4.7, 9.4 and 27 Ohm) and ramped the clkgen_freq up to 600 MHz, absolutely no way of getting a sucessful glitch. Either it resets, or it operates normally.
I also tried different cable lenghts and even attaching the SMA connector to different parts of my PCB so that maybe if I am closer to a specific power pin I could have better chances. I also tried using the LP and HP glitch MOSFET at the same time, and also only using the LP one and only the HP one. I even tried different input voltages (from 2.0V to 3.3V) for the LPC.
I am a little clueless about why this isn’t working, the LPC1765 has, just like the LPC1114, an internal voltage regulator that generates 1.8V for the CPU, but for the LPC1114 that isn’t an issue either.
Any ideas what might be going on? I assume if this isn’t working I don’t even have to try to do the bootloader glitching as additional parameters like the ext_offset would make it even less likely to get it right? I replicated the bootloader code (access the 0x2FC offset and compare it) in my loop now, so breaking out of that loop requires basically the same settings as getting that bootloader glitched. Looking at the assembly my test program generated I can see, that it for sure tries to access the flash every time in the loop:
So I am going through the LPC1114 Fuse Bypass lab now and I noticed several issues in there:
In capture_crp the variable ref_list is a global variable and so it sums/averages up ALL power traces, so if I analyze the 0x0 and 0xFFFFFFF like it’s done in the Notebook the sum/average of both is collected, which is probably not what is intended at all
Where it says “#Wrong order - unlocked” that’s not actually unlocked. That’s just another level of CRP (see the table at the top of the Notebook).
I can probably also provide some explanation on why the timings from DPA aren’t matching with the actual glitch timings: Those LPCs first load the CRP value to determine if they should enable JTAG (at this point they do a branch based on it, which will cause the power traces to shift), then they do all sorts of configuration stuff, later on they only load the CRP value into the RAM. That’s only a few instructions before the loop for autobaud starts (which should be clearly visible at the end, you might need to increase the capture duration a little). I think it’s also visible on the power trace, just not as clear as the branch.
Unfortunately I still haven’t had success with the LPC1765 though, I ramped up the multiplier all the way to 6 and I also tried attacking the JTAG activation, hoping that I might be able to glitch that one more easily, but no luck with that either. I switched through various resistor options again aswell, 27 Ohms, 13 Ohms, 4.7 Ohms, without any luck. Could the chip-integrated voltage regulator really be such an issue for glitching? The other LPCs that can be glitched have one aswell though, so I still think I am doing something wrong.
Just as an fyi, we were running voltage glitching on lpc1768 for months without a success. We also had BOD turned on. There’s also Andrea who was successful glitching lpc1768 without BOD, but not with BOD: GitHub - vekexasia/lpc_voltage_glitch_test: LPC1768 voltage glitch test. . There is more info on the ChipWhisperer Discord if you search for “lpc1768”.
By now we assume the lpc17xx BOD is just very good and does not allow glitching. Please be aware that lpc11xx has BOD by default off, lpc17xx has BOD by default on.