Serial buffer issues

Hi there,

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"

Later when getting a trace via serial:

    trace = scope.getLastTrace()
    num_char = target.ser.inWaiting()
    print(target.ser.read(num_char, 10))

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?

Thanks,
floyd

Hi Floyd,

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:

  1. 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.
  2. 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.

-Colin

Hi Floyd,

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.
  • If you want to stick to CW5, you should be able to install natively on Mac by installing python3, then following the CW5 git install instructions. We haven’t had a chance to test this on Mac though, so you might run into issues.

Otherwise, installing CW4 might be your best bet.

Alex

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().

Alright, I believe I’ve figured out this issue:

  • 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.

Alex

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 :slight_smile:. 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”:

(apparently new users on the forum can only upload one picture per post, so here’s an imagebin link)
https://imagebin.ca/v/4QdnN552PqX0
https://imagebin.ca/v/4QdnWRo1Twyk
https://imagebin.ca/v/4Qdnh3xflCTO

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:

https://imagebin.ca/v/4QdoadbFYUJr
https://imagebin.ca/v/4Qdop02tSY7z
https://imagebin.ca/v/4QdoyzUD8OSE

Now I correctly got: “Success, pass now h0px3”

PS: While I still get the same errors as I posted originally, it does not have an effect on the trace results now. Thanks!

Happy to hear that that worked.

I believe I’ve fixed the error that happens upon connected (I also updated the tutorial with firmware fixes), so if you update to the latest commit it should fix things.

Alex

Hello, my first time running chipwhisperer cw1200 (version 4.0.2 software on Linux).

When I run the script connect_cwlite_simpleserial.py on CWCapture.pyw, I get the error
ERROR - Value -92 out of limits ((0, 1000000.0)) in parameter “Baud”.

When I click the same script a second time, I get the message:

raise Warning(‘Could not connect to “%s”. It may have been disconnected, is in an error state, or is being used by another tool.’ % self.getName())

Warning: Could not connect to "NewAE USB (CWLite/CW1200)". It may have been disconnected, is in an error state, or is being used by another tool.

Could someone please help?

Hi Andrew,

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.

Alex

Hi Alex,
When I try to run tutorial B1, I get the following problem: There is a “?” in the text out section on the Encryption Status Monitor.

The output is this:
INFO - SimpleSerial: protocol V1.0 detected
WARNING - Response length from target shorter than expected (0<34): "".
INFO - Capture completed.

So I think this is due to the above error with the parameter Baud. Do you have any other ideas to solve this?

Thanks,
Andrew Yuan

Hi Andrew,

Sorry about the late response.

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.

Alex