I’ve been trying to work through the bootloader example on the CW-Lite. Everything looks good until I try to connect to the target with a serial port at 9600 baud. As soon as I click connect, the baud rate is reset to 38400. I traced the problem to this code in SimpleSerial.py:
class SimpleSerial_ChipWhispererLite(TargetTemplate):
...
def baud(self):
return 38400
I think a better approach might be:
class SimpleSerial_ChipWhispererLite(TargetTemplate):
...
def baud(self):
if self.cwlite_usart:
return self.cwlite_usart.getBaud()
return self.findParam('baud').value()
…with a corresponding getBaud method in ChipWhispererLite, of course.
Hello,
Ah… yes the current firmware in the SAM3U had that set as a fixed value. It should be easy to change… the firmware in the SAM3U can set this to almost any reasonable value, I just might not have exposed the API over the USB port yet.
-Colin
Ah. That explains the hardwired rate. Looks like the SAM3U firmware already supports changing the rate - when I switch it to 9600 baud, I can communicate with the bootloader.
Ha… apparently I can’t even remember what I have/haven’t done yet 
Let me know how it goes - I plan on checking all the tutorials work with the CW-Lite still, but am slowly working through them…
Finally managed to get a chance to take another crack at this tutorial. I can capture the power traces from TSB, set the password, and tell the difference between a correct vs incorrect password from the traces.
Then the tutorial talks about a USB input to the CW, which as I understand it allows the host PC to connect to the AVR chip directly, or to an AVR programmer circuit. The CWL has an AVR programmer, so presumably we could bypass the need for an external programmer, but I can’t see how to access it from the project setup script. In the Python console, it doesn’t seem to be accessible via self.scope, self.target, or even self.target.oadc. If I try to use an external programmer connected to the notduino, then it has trouble connecting, presumably because both the FPGA and the external programmer are connected to the AVR chip through that interface.
I’m sure I can find a way around this, but if you could expose the AVRProgrammer object (and the XMEGA one too) at the top level, that would make it much easier.
Okay, so I’m a little further into this, but at another roadblock.
I’m thinking that I should add another module under chipwhisperer.capture.auxiliary, or modify the existing ResetAVR. I was thinking that I’d use the AVRISP or XMEGAPDI object from chipwhisperer.capture.scopes.ChipWhispererLite, but although there is a reset line on the AVR ISP connector, there isn’t a reset method in that class, and furthermore I’m not sure how to get the USB device associated with the CWL from within the context of the auxiliary module.
What I see in AVRISP and XMEGAPDI is that you have a protocol for talking over PyUSB to the CWL with ctrl_transfer calls.
What I don’t see is any mention of a ctrl_transfer to cause the SAM3U to reset either the AVR or XMEGA chip, or any documentation of this interface, or the source code for the SAM3U firmware.
Absent any of that, I’m thinking that the best way forward for the password guessing tutorial is to write a custom target that (unlike TSB) can compile to both ATMEGA and XMEGA, and that implements the same silly password matching flaw. In the event of an incorrect character, it would sleep for a second, set the trigger line low, and then do a soft reset. That way we get the experience of writing a custom attack script, without requiring the original CW hardware, or even requiring people to break their CWL boards. Admittedly, it wouldn’t have the real-world authenticity of attacking TSB, but TSB already patched the vulnerability upstream anyway.
Hmm… the programmer interface doesn’t have a “toggle this line” available, what you can do is read the signature. From the command line it would be one of these types:
self.scope.scopetype.cwliteAVR which is of class chipwhisperer.capture.utils.AVRProgrammer.AVRProgrammerDialog
self.scope.scopetype.cwliteXMEGA which is of class chipwhisperer.capture.utils.XMEGAProgrammer.XMEGAProgrammerDialog
So to reset the AVR a call to “self.scope.scopetype.cwliteAVR.readSignature()” should do the trick. BTW to figure all this out I tend to use the command line interface to see for example the class of “self.scope”, then search the class to see the definition. From there can basically go down the rabbit hole…
While it will break “object oriented” nature, I’ve started to make a “global” class that will get written with direct references to useful stuff. So for example having the ability to go “globals.avrprogrammer” or something instead.
Crap - the SAM3U dev was done in another repo. I completely forgot to copy that over… it’s supposed to be open-source too, but I don’t think it was part of the main CW repo. Will try to rip that out and get it copied over.
You’re ahead of me 
Actually rather than doing a “silly password checking”, I’ve been planning on making a simple security system or basic password checking system that still has the timing attack, BUT requires you to break the for() loop during which the final password is checked. The idea being that it can compile on XMEGA or AVR as you mention. Attacking the final password check (i.e. after all characters are received) is more realistic, as many real products perform this type of loop. It’s still possible to see the timing differences with the ChipWhisperer and should be scriptable, but needs some more time. Am trying to get the rest of the docs updated first, as still want to do that before end of August.
PPS: For resetting a device, also see the “Aux” module that lets you toggle an IO line. if you toggle an unused IO line (say IO line 3), you can connect that to the reset pin too.
Oh, so you mean I can take the IO3 pin from the 1x10 header row just behind the 2x10 shrouded header on the CWL, and connect that to the RST header on the notduino? Ahhh…I hadn’t thought of that. Thanks!
Once there’s a way to access the AVRISP/XMEGAPDI interface from within the auxiliary module, checking the signature will do the trick - thanks for that tip.
The globals idea is interesting. A more OO way of achieving the same effect would be for the higher level code to create a globals dict, and pass it on initialization to other classes as an optional argument to init. But I don’t think that it gives any practical benefits over the globals class you describe, and it would involve more code changes.
I agree that updating the docs should take a higher priority than recoding the TSB tutorial. Meanwhile, I’ll take a look at putting together a password checking system and let you know how I get on.
Yup! A similar technique was used in one of the demos/tutorials… to be honest Im not 100% sure it’s published there even, but it’s an easy way to do it.
There is a boatload of code that is in the “should be refactored for more OO design”, or even just “should be cleaned up”. At some point I’m hoping we can hire someone to dedicate more time to software, and someone with a software background would do a hell of a better job than me!
As a sidenote the SAM3U code was committed as well. It’s built with Atmel Studio 6, see assembla.com/spaces/chipwhi … e/sam3u_fw .
Let me know how it goes - I plan on checking all the tutorials work with the CW-Lite still, but am slowly working through them…