Clock, power, and EM glitching discussions. Does not need to use ChipWhisperer.
#2099 by jrussell88
Wed Sep 05, 2018 4:05 am
Hi, this is a newbie question and I'd appreciate your advice on it.

I have a TI/Chipcon 8051-based board - TI CC2430 - from which I'd like to extract an RF key. There's debug access over 2 pins, plus clock and reset, so 4 lines; firmware is protected by the DBGLOCK bit. The debug clock line can run up to 7.1MHz; the 8051 is running at 32MHz.

There are no headers, so just solder the lines onto the board.

I think the easiest way to read the firmware will be to glitch the lock; will the checking code be running at debug clock speed, or at the 8051's 32MHz?

I'm looking for a simple setup for a one-off use. I thought a combination of Goodfet42 and ChipWhisperer, with Goodfet.cc to talk to the debugger should work. Are there any other alternatives I should consider?

The goodfet.cc offers instructions for reading the entire memory; I'm not sure if those are based on repeating 8051 debug commands - I can't find a reference for these - in which case would they trigger the DBGLOCK repeatedly?

Thanks.
#2112 by Alex_Dewar
Fri Sep 07, 2018 10:56 am
Hi jrussell,

I'd guess that whatever's checking the access would be running at the 32MHz, since the debug clock is typically just used for synchronization. Your setup should work fine, we did something similar for testing on an STM32 using an STLink and OpenOCD. Reading memory would be done though repeated commands.

You might also want try glitching the read of the Flash Lock Protection, which is often done during boot (at least that's the case for the STM32 and LPC1114 chips). That should have the advantage of keeping the debug lines open until the chip is restarted, but might be harder to do than to glitch past the check itself. That's what the LPC1114 stuff I linked below did, though keep in mind that in that case any bit changed in the read would disable protection, instead of a specific bit like in your case.

It may be worth playing around with what the behaviour of DBGLOCK actually is. Based on one of the papers I linked below, the STM32F0 is "open" until a locked command is tried, after which all debug stuff is locked until a power cycle.

They're different architectures, but you may want to check out some other attacks on read protection:
(These 3 are all the same attack)
https://wiki.newae.com/Tutorial_A9_Bypa ... ad_Protect
https://recon.cx/2017/brussels/resource ... slides.pdf
https://toothless.co/blog/bootloader-bypass-part1/

https://www.aisec.fraunhofer.de/en/Firm ... ction.html

Cheers,
Alex
#2114 by jrussell88
Fri Sep 07, 2018 6:52 pm
Alex

If I use a Goodfet to connect the target via USB to my laptop, will I be able to use the Goodfet's interface for the target board from the ChipWhisperer to run code sync'd with glitches?

Alternatively I could connect it directly to the CW; simple but I'd have to write some code for the debug commands.
#2117 by Alex_Dewar
Mon Sep 10, 2018 10:36 am
Hi John,

You've always got access to Python, both in the GUI and in a Python script using the ChipWhisperer API, so you can either run GoodFET's python commands or run goodfet.cc from the python script. A Python script will run faster than the GUI, so you'll likely find more success using that, especially since glitching is very trial and error based.

Syncing will be a little tricky, since anything involving your PC/USB won't be sync'd with what the ChipWhisperer is doing. Instead, I'd recommend using the trigger pin to sync the two, probably using the debug clock pin and using the "Ext Trigger Offset" to delay the glitch for an amount of time after the trigger event. Going back to your first post, I'd also recommend using the micro debug commands (mostly the DEBUG_INSTR command, since that does all the reading and writing stuff) to give yourself precise control over when each command is happening.

Let me know if that helps,
Alex

Who is online

Users browsing this forum: No registered users and 1 guest