Hi there,
I have a question that is probably ridiculously easy to answer, but I’m kind of stuck right now. I’m the proud owner of a CWlite. The first thing I did is detach the Xmega victim board from the CW lite board and equip everything with proper connectors. Works like a charm.
To verify that I have the correct understanding of how the victim board is connected (so that I can adapt my targets to pretty much behave exactly like the Xmega board) I soldered a little adapter board that let me connect a PC to the AVR board so I could try for myself. I generate a 7.3728 MHz, 50% DC, 3.3Vpp sqare wave clock and supply it to pin 6, GND on 2, 17, 19, +3.3V on 18, 3, TX on 10, RX on 12 (both 3.3V RS232-TTL) and have my oscilloscope hooked up to the trigger TIO4 on pin 16 of the 20 pin connector.
The AVR is alive (it responds to serial comm at 38400 8N1) and does calculate crypto (I see the trigger), but the ciphertexts are not what I expect. Since this puzzled me very much, I even copied the exact values from the screenshot here: newae.com/sidechannel/cwdocs … comms.html (i.e. K = 2b7e151628aed2a6abf7158809cf4f3c, P = ff23b7ec4de0245ba46e164e75821ea1). I expect to receive the AES128 encrypted ECB ciphertext ECA5FD6422AC929845750783DA530F73 (as is also shown in the screenshot, matches with my calculation), but instead I receive B1D6A3A0BC5F408F82A5DD01472C75CA. I consistently receive that over multiple trials and multiple resets.
Something weird is apparently going on and I’m really not sure what I’m doing wrong. Any help of you guys would be greatly appreciated.
Thanks so much,
Best regards,
Johannes
Hey there, so I really haven’t figured it out just yet. I’m pretty pretty sure that I’m doing something ridiculously stupid, but just can’t seem to be able to pinpoint what it is.
The curious thing is that the results are reproducible across complete power-downs and power-ups. So that rules out that the supply would rise too slow or the reset would be glitchy and internal SRAM could be corrupted, in my opinion. I really also don’t think that the firmware itself is corrupt, but I didn’t check with ICSP or JTAG – not that desperate yet 
What I’ve done is produce some logging output:
Expecting key: E8E9EAEBEDEEEFF0F2F3F4F5F7F8F9FA
-> b'xxxxxxxx'
<- b''
-> b'kE8E9EAEBEDEEEFF0F2F3F4F5F7F8F9FA\n'
<- b''
-> b'p00000000000000000000000000000000\n'
<- b'r288BCE3F016D39B84AF010410F00B02D\n'
Error: 288BCE3F016D39B84AF010410F00B02D rxed, 56C44AEF60AC84A971E34FB92EBE0E69 expected
-> b'p00000000000000000000000000000000\n'
<- b'r288BCE3F016D39B84AF010410F00B02D\n'
Error: 288BCE3F016D39B84AF010410F00B02D rxed, 56C44AEF60AC84A971E34FB92EBE0E69 expected
-> b'p00000000000000000000000000000000\n'
<- b'r288BCE3F016D39B84AF010410F00B02D\n'
Error: 288BCE3F016D39B84AF010410F00B02D rxed, 56C44AEF60AC84A971E34FB92EBE0E69 expected
-> b'pFF23B7EC4DE0245BA46E164E75821EA1\n'
<- b'r7AAF70DF1D77342458BA93024489A79F\n'
Error: 7AAF70DF1D77342458BA93024489A79F rxed, 6A134B115FE16558C3E48C4E21DBFA70 expected
-> b'pFF23B7EC4DE0245BA46E164E75821EA1\n'
<- b'r7AAF70DF1D77342458BA93024489A79F\n'
Error: 7AAF70DF1D77342458BA93024489A79F rxed, 6A134B115FE16558C3E48C4E21DBFA70 expected
-> b'p014BAF2278A69D331D5180103643E99A\n'
<- b'r37257746972977AE8771BD35B7801935\n'
Error: 37257746972977AE8771BD35B7801935 rxed, 6743C3D1519AB4F2CD9A78AB09A511BD expected
-> b'p014BAF2278A69D331D5180103643E99A\n'
<- b'r37257746972977AE8771BD35B7801935\n'
Error: 37257746972977AE8771BD35B7801935 rxed, 6743C3D1519AB4F2CD9A78AB09A511BD expected
-> b'pD5C5DD4ECFCCCAF38B0DCEB88BD438B9\n'
<- b'r35678114B5B90D44451A79B627C02BBD\n'
Error: 35678114B5B90D44451A79B627C02BBD rxed, 732FE0FC830EC0AA3488D82DEFE8F121 expected
That’s the example which is given in simpleserial-aes.c. I’ve checked the source and it seems very straightforward with no traps to fall into. The example key = E8E9EAEBEDEEEFF0F2F3F4F5F7F8F9FA and in the example in the comment the P = 014BAF2278A69D331D5180103643E99A and the response is R = 6743C3D1519AB4F2CD9A78AB09A511BD. That’s also what my Python script calculates the correct ciphertext to be, but instead the Xmega victim board consistently answers with 37257746972977AE8771BD35B7801935.
The source code is so simple that I cannot imagine that anything weird is going on, but I still really can’t explain this. The most plausible explanation would be that the algorithm that is used is not AES128 all along and there’s somehow a different firmware that I managed to put on the device. But all CW victim code for the XMega that I’ve seen so far use AES128 and I’ve not seen anything different.
Any ideas at all?
Best regards and have a nice evening,
Johannes
Crap - I had a response to your first message but forgot to hit save! I’m going to respond to your first message here:
Hi Johannes,
Does the ciphertext change if you change the input key or plaintext? i.e. is the B1D6A3A…CA always sent back, or does that change with different inputs/keys?
Offhand it’s puzzling to me as well. Things that I’d double-check:
- Is the clock bouncing, causing some double edges to be seen? This might require you to terminate the output of the signal generator, or try series terminating (just add a 20-100 ohm resistor in series with the clock).
-Colin
Can you easily program it (i.e., reconnect 20-pin cable, use programmer from ChiPWhisperer). One thing to check is change the firmware code such that it just echos the incoming plaintext (i.e., comment out the call to the aes encryption). This might show if there is some odd corner case.
Otherwise it’s very very hard to debug, since by design if some bit/byte is consistently off the output text looks totally random 
I’d change the firmware to just echo input plaintext, and see if that gives you any hints (i.e., for some reason not catching a certain byte). As you mention there isn’t a whole lot it does by default…
Hi Colin!
Thanks for your replies. Two very good hints indeed.
At first I took a look at the clock, because I really didn’t have any termination at the source. For reference, I’m having a 74F04 oscillate a 14.7546 MHz crystal and divide that down (to get 50% duty cycle) with a 74F74 D-FF (Q’ to D, oscillator output to CLK, Q to pin 6). It really had some nasty undershoot (approx. 1V). With 100 ohms in series right after the Q output, the clock looks beautiful now. Sadly, the problem still exists, and it also responds with the same data 
To answer your question, yes, the outputs change after the “k” command. It’s just like one would expect with a different algorithm or flipped bit in the key or something.
So now I’ll investigate the Xmega firmware as you suggested and report back on what I can see.
Thank you very much for your help,
Best regards,
Johannes
Sure thing - if you need a hint w.r.t. firmware mods please let me know!
Hi Colin!
So this appears to be a weird issue and it doesn’t have anything at all to do with the CW or victim board. Ultimately I think I’ve been sold counterfeit MAX3232.
I flashed a FW that echoed “char + 1” back (I’ve had issues with capacitive coupling on the RX/TX where a pure echo would go through even if the output was actually High-Z). Measured on the XMega pins, looks perfect. Measured on the MAX3232 input pins, looks perfect. But on the MAX3232 output (PC side) only the side PC->TTL looked good, the backside looked like utter garbage. I’m operating these on a RS232/USB converter and now am thinking that it doesn’t actually contain charge pumps, but probably abuses some control lines (which aren’t giving enough current for the USB converters). I’ll attach screenshots of the TTL side (RX and TX) and of the PC side.
How it could ever resond with anything that even looked remotely like a legit response is beyond me. But I can’t reproduce it now (now the PC is always receiving garbage). Since this sounds like an utterly unbelievable assessment, I’ve even made oscilloscope screenshots to prove it 
Anyways, I’ll replace the MAX3232 by a FT232 and hopefully get rid of all my problems.
I could change the SimpleSerial firmware to include some provisions for an echo test, is this something that would be useful for you? I’d keep the protocol backwards-compatible, of course. If it is, I’d code it and send you a pull request.
Thanks again for your help!
Best regards,
Johannes
RX on +12/-12V side (garbage)
Yup, it works!
Indeed it were counterfeit MAX3232 chips. I can’t really believe it, but I tried two brand new ones and both showed exactly the same error.
I replaced the whole thing with a FT232RL. First test (with the demo firmware that echos “rx + 1”):
-> b'p00000000000000000000000000000000\n'
<- b'q11111111111111111111111111111111\x0b'
-> b'p00000000000000000000000000000000\n'
<- b'q11111111111111111111111111111111\x0b'
Then, with the original XMega firmware
Expecting key: E8E9EAEBEDEEEFF0F2F3F4F5F7F8F9FA
-> b'xxxxxxxx'
<- b''
-> b'kE8E9EAEBEDEEEFF0F2F3F4F5F7F8F9FA\n'
<- b''
-> b'p00000000000000000000000000000000\n'
<- b'r56C44AEF60AC84A971E34FB92EBE0E69\n'
OK: 56C44AEF60AC84A971E34FB92EBE0E69
-> b'p00000000000000000000000000000000\n'
<- b'r56C44AEF60AC84A971E34FB92EBE0E69\n'
OK: 56C44AEF60AC84A971E34FB92EBE0E69
-> b'p00000000000000000000000000000000\n'
<- b'r56C44AEF60AC84A971E34FB92EBE0E69\n'
OK: 56C44AEF60AC84A971E34FB92EBE0E69
-> b'pFF23B7EC4DE0245BA46E164E75821EA1\n'
<- b'r6A134B115FE16558C3E48C4E21DBFA70\n'
OK: 6A134B115FE16558C3E48C4E21DBFA70
-> b'pFF23B7EC4DE0245BA46E164E75821EA1\n'
<- b'r6A134B115FE16558C3E48C4E21DBFA70\n'
OK: 6A134B115FE16558C3E48C4E21DBFA70
-> b'p014BAF2278A69D331D5180103643E99A\n'
<- b'r6743C3D1519AB4F2CD9A78AB09A511BD\n'
OK: 6743C3D1519AB4F2CD9A78AB09A511BD
-> b'p014BAF2278A69D331D5180103643E99A\n'
<- b'r6743C3D1519AB4F2CD9A78AB09A511BD\n'
OK: 6743C3D1519AB4F2CD9A78AB09A511BD
-> b'pCF0E3761A6F41C0C49BCF3435BC5DA9C\n'
<- b'rABBE53A6A1BD0D2FB9625C09CA67A2A8\n'
OK: ABBE53A6A1BD0D2FB9625C09CA67A2A8
Everything working perfectly! I think I’m going to add that command to the Xmega firmware for debugging. Although this is such a weird error constellation that I doubt anyone experiences the same, but who knows
Thanks again for making CW the cool product it is!
Cheers,
Johannes
