Hi,
I’ve been trying since last week to unlock the LCP1114 with the CWNano. Last year, I was lock/unlock without any complication…
I’ve been trying to figure out why now I can’t unlock it, so I did many different runs, I even let it running several times the notebook covering all the range of ext_offset and repeat values for the glitch… during one of the tests, I noticed a discrepancy in the ADC clock configuration.
The Hardware Hacking Handbook specifies that for this attack, the nano should be set to 20 Msps. However, after configuring the nano to that speed, it get configured to15 Msps.
After noticing this, I gradually increased the speed without any changes in the effective speed effect until I reached 23e6 (23 Msps). At that point, the nano suddenly jumped from 15 Msps to 30 Msps
I can’t speak to what the book specifies, but the Nano derives all its clocks by dividing a 90MHz clock, so that’s why you’re seeing the jumps you are. 20MS/s isn’t a possible even division there, so that might just be a typo.
Hello Alex,
Is not the book, the webpage also says also the ADC only can go up to 20Msps, clock says 60Mhz in divisions of 1/2/4/8/16
The book shows this snippet of code, that was the on I used last time I did this notebook with success:
import matplotlib.pylab as plt
#Enter ISP Mode
nxpdev.isp_mode()
#Sample at 20 MS/s (maximum for CW-Nano)
scope.adc.clk_freq = 20E6
scope.adc.samples = 2000
#Reset again and perform a power capture
scope.io.nrst = 'low'
scope.arm()
time.sleep(0.05)
scope.io.nrst = 'high'
scope.capture()
#Plot Waveform
trace = scope.get_last_trace()
plt.plot(trace)
plt.show()
So how I can do a capture at 20Msps (or whatever is the actual max of the nano)? Or it mean I should put clock at 60Mhz to get 20Msps? Or nano is able to get up to 60Msps at 60Mhz?
I’m a little bit lost with this right now 
Sorry, 60MHz is correct, not 90MHz. 20MS/s is the max speed the ADC can sample at - it’s unrelated to what clocks the Nano can generate.
Basically the fastest input clock that the ADC can handle is 20MHz, but the closest the Nano can get to that is 15MHz. I don’t think the frequency is likely to matter much here, you should just be able to run at 15MS/s and be fine.
Hi Alex,
I think I’ve found the problem causing the nano not being able to unlock the LCP1114, I was doing some captures and saw in the plot the glich dissapear when glitch.repeat has value beween 8 and 9 (that was the repeat range I had success last times).
As you can see the glitch is varely visible (at the very begining of the plot) and sometimes it dissapear, here is with repeat=8, if the value were 9 the glitch is not visible at all. When lees values like 5 o 7 the glitch is very visible and consistent
So I decided to attach the oscilloscope to ‘see’ what was heppening and I was able to confirm that the glitch is being skipped or simply missing… Any Idea?
Ah looking at the Nano’s code, I think I know what’s going on there. The Nano switches from using individual instructions to a loop to determine how long to make the glitch at repeat 8. Glitching on the Nano is very finicky, so I didn’t want the ability to glitch the minimum of this loop to be removed, so repeat=8 will be a very small glitch. Try further increasing the repeat until you start seeing glitches again.
Alex
Increasing it does make the glitch ‘visible’ in the plot, but this also happens when repeat have a smaller value, which makes no sense to me… I had succes unlocking the LCP1114 at repeat=13 (maybe I was wrong when I said the last year I glitched it with 9, I lost the old notebooks in the update to v6 and said from my memory) .
In the video with a repeat value of 8 or 9 the glitch in the plot has a thickness of one line (one pixel or unit on the X axis), and many times it is not visible not to say even ‘clipping’ under -0.4…
In the other side when repeat has a very low value like 1 or 2 (even 3) it behaves similar in the way that it is barely ‘visible’ in the plot, what I think in this case is that the glitch itself is so narrow that doesn’t take a full unit in the X axis, so sometimes is visible and sometimes not… that explains the glitch being visible sometimes, but does not explain why with the scope configured at x=10ns/div the glitch is not there…
When repeat has a value of 5, 6 or even 7 the glitch in the plot is very visible, it takes in X axis from 4 to 5 units, so is clearly visible in both the plot and the scope…
I have another nano (virgin) I didn’t ripped of the intergrated target yet, I will solder the sma conenctor and see if this other one behaves the same against SAM4S at that same repeat value range… The curiosity is killing me 
Yes, that’s expected. I’m saying that glitch generation is different <8 and >=8, with a repeat of 8 being close to a repeat of 1. This was a change made in firmware a while ago, so you might’ve ran the original lab on an earlier version of the firmware where the behaviour was different.
Oh, I didn’t catch that, thanks for your patience 
Yes, I had done that notebook more than a year ago 
