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?
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)
wiki.newae.com/Tutorial_A9_Bypa … ad_Protect
recon.cx/2017/brussels/resource … slides.pdf
aisec.fraunhofer.de/en/Firm … ction.html
That’s really helpful thanks 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.
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,
I have just started my path on security and my knowledge base is wide but not very in depth!
On the LPC series when crp3 is invoked it can be accessed with a ISP command
we are looking at being able to remote update a tool I have comissioned (i say commissioned as whilst the design idea overall is mine the actual hardware and software was done by 2 companies)
So would the attack be best done by glitching the bootloader or by wireshark/listening on the internet or usb signal that provides the update as this unloocks the chip, updates and relocks?
I guess the question is where do I need to spend the money protecting my data?
I’d say that wiresharking the connection would be a more ideal attack since you wouldn’t need physical access to the device, but the glitch attack would be more difficult to guard against. I’m not qualified to give security advice though, so definitely get a second opinion.
my issue with the wireshark is I know how we do it, so breaking it is easy!
its hard to be objective, the only advantage we have is that disassembling the code requires a “leap” to understand the call process and every call code is different as it uses 2 pieces of information in the device and a simple algo.
the board is not protected from physical attack, I’m not sure it could ever be.
and I have seen the CW glitch the lpx chip, so I will have to try it out as soon as we get in the first sample of pre-production boards in Feb(19)