CW newbie here going through the tutorials (new CW5 Virtualbox VM on OSX, CW1200 pro hardware kit, XMEGA target, tutorial order as suggested in “!!Suggested_Completion_Order!!.ipynb”). Currently doing PA_SPA_1-Timing_Analysis_with_Power_for_Password_Bypass.ipynb using bleeding edge chipwhisper github commit 331a55a40d83d668777ba2c0e14a623e12649d0e.
First issue when executing:
import chipwhisperer as cw
scope = cw.scope()
target = cw.target(scope)
ERROR:root:Value -91.91176470588235 out of limits ((0, 1000000.0)) in parameter "Baud"
WARNING:root:SAM3U Serial buffers OVERRUN - data loss has occurred.
So I found SAM3U Serial buffers OVERRUN and was able to change “Helper_Scripts/Setup_Target_Generic.ipynb” to use “scope.clock.adc_src = “clkgen_x1”\n”, which definitely made the serial read more reliable. However, the data loss still occurs. The data loss is pretty bad, because later on when brute-forcing the password with traces it does not allow to conduct the attack and it will fail (although sometimes it works for one character).
My question: Switch to native client instead of CW5? Or can you recommend a github commit that should be a little more stable? Or is there a simple configuration option I can pass to the scope object?
That error pops up when you have lost data from the last time you read from the buffer and next time. If you are getting that error, I’d suggest doing the following instead:
Add a call to read the buffer (which will flush it) just before you send the password. You can ignore the error on that read.
Do everything else (arm scope, send password, etc).
The problem is you get the error if the device was reset a few times, or possibly if timing is a bit off. The actual data you need to read is small enough it should fit within the buffer.
With the new CW5 setup, we are working on getting the SAM3U to offer a “real” serial port. We hadn’t done that originally as it’s other variable in your host setup (i.e., what COM port are you connected to?). But without doing that we can’t take advantage of driver-level buffers, which would give us an ability to avoid all the overrun errors.
I’ve done a bunch of the work on moving to CW5, so I might be able to offer some additional help.
There’s a few things you can try:
Set the baud again by running target.baud = 38400
Verify that you have USB3.0 (xHCI emulation) selected in your VM USB Settings, since the transfer speed is a lot faster even with USB2.0 devices. If USB3.0 is selected, try switching back to 2.0.
We don’t have a super well tested commit (especially on Mac hosts), but commit c00dd351130f10753de3d887f0417a886e4b2989 may work better, since the next commit had a bunch of USB communication changes to speed up capture.
EDIT : Did a bit of digging, and based on your error the wrong serial class may be getting loaded. Those bounds seem to be applied for the SimpleSerial_ChipWhisperer class, but from looking at the SimpleSerial target stuff I believe SimpleSerial_ChipWhispererLite should be used instead.
If you can reproduce the issue, do you mind running print(target.ser) and posting the results?
Looks like that was a red herring. The correct serial module gets loaded by cw.target().
The error message that pops up doesn’t actually mean anything since all the serial stuff is setup later anyway
I think the reason you’re missing serial data is that the firmware takes a long time to boot up (over a second). Since capture recently got a lot faster, this causes the password guess to be sent before the device is finished booting. Try going into the firmware (hardware/victims/firmware/basic-passwdcheck/basic-passwdcheck.c) and removing all the delay_200ms() calls.
I’ll reduce the delay on startup and update the tutorial, which should fix things.
Thank you all for the responses, really appreciate the quick feedback.
So I tried first what Alex suggested last: removing the delay_200ms() calls. And it worked!
For me as a beginner this was a good challenge to see if I understood the tutorial . What the exercise tried to show worked for the first character, and if your lucky for the second character, but never for the third character. To show what I mean, here are the power traces with the delay when sending “\n” compared to “h\n”, “h\n” compared to “h0\n” and “h0\n” compared to “h0p\n”:
Here’s the most important trace, “h0\n” compared to “h0p\n”:
Note how in the last image that entering two correct characters from the password is indistinguishable from entering three correct characters from the password. Here is the same with the fixed version without the delays:
Sorry about the late response. I believe your error has to do with one of the CW1200 only baud settings caused by a bounds check being applied to an uninitialized variable. The ChipWhisperer should be connected and fully functional in spite of the error, so you shouldn’t need to rerun the script.
The Baud error above shouldn’t affect actual communication, as it is only for the functionality described here: https://wiki.newae.com/Tutorial_A1_Synchronization_to_Communication_Lines. Typically not getting a response is due to the target not running correctly or a misconfiguration with the serial communication between the devices. Make sure the target is flashed with the correct firmware, that the serial TX/RX pins are correct, etc.