ATMega8A Lock Bit bypass

So I should preface this by saying I have never glitched anything. I do have extensive electrical knowledge though so complicated circuits are no problem. From the research I have done it seems like this is something that should be possible, yet I have no idea where to even start. Risk is low as this is mostly for fun since the circuit I am reverse engineering doesn’t particularly need the MCU, but I would like to be able to read the program on the ATMega8A as it would help in my reverse engineering effort.

I can’t answer specifically to that, but the ChipWhisperer platform and our Jupyter tutorials that go along with it are designed to teach the basics of glitching (among other things). If you’ve never glitched, I’d start with that.
Jean-Pierre

I’m assuming you want to voltage glitch since getting access to the clock in a real scenario is not that feasable. I don’t know how ATMega Lock Bits work, I’m currently trying to attack a nRF target. I’m assuming that your case works similar to mine, where the system checks on boot whether the debugger should be accessible or not. You want to skip this check.

First of all please try the Jupyter Labs in fault101 or at least read the solutions so that you can understand what the meaning of each parameter is, how you can set them, and how a general glitching loop looks like.

What you need is a glitcher, a programmer and some way to reset or power cycle your target, since you want to skip the instruction that locks you out of the debugging interface. An oscilloscope is also highly recommended.

Glitcher: The Crowbar Glitch channel on the ChipWhisperer serves as your glitcher here. You want to short the voltage input of the chip/CPU you’re attacking for a precise amount of time (too short: no fault in the program, too long: brownout detection triggers). The CW does most of the work for you in this regard, you will need to iterate through glitch settings though (width and location of the glitch). This also works with a simple transistor by the way, you just need some way to precisely short the voltage input. Try to circumvent any capacitors or voltage regulators so that you can drive the current to ground easily. If you’re attacking an SoC that has many different components, try to figure out where the CPU gets its power from. For example in the nRF there is internal voltage regulation for the BLE and CPU components because they draw different amount of power. Between the CPU and voltage regulation is a pin used for an external decoupling capacitor - by soldering a wire between the capacitor and this pin you can short both the voltage regulation and the DEC capacitor!

Programmer: As far as I know the ChipWhisperer can act as a programmer for custom targets but I don’t know how to configure that. I’m just using a development board for ST-Link in my case (for STM programming). You will need some indicator of success so that you can stop your glitch loop. I’m using “os.system” to start an openocd session that tries to establish a debug connection to the target, and then tries to dump its firmware. The return value of “os.system” should be 256 if successful and something else if not, so you can use that as an indicator whether your glitch worked or not. Alternatively, you can check whether the dump.bin exists in your file system and use that as an indicator.

Power cycling: If you can’t get access to a controllable reset, you can try to power cycle the MCU with a power supply and controllable transistor, or with the CW308. You can turn off or on the power on the CW308 UFO board using “scope.io.target_pwr” so that’s an easy way to do it. Don’t try to do this with the power pins of the ChipWhisperer itself though as it draws too much current and makes it crash. The CW308 works just fine.

Edit: I totally forgot the oscilloscope part. You need a trigger signal so that you can set the glitch at a consistent point in time! An oscilloscope with a trigger output can do this for you if your controller doesn’t give you an easy trigger. If your power on-signal doesn’t give you a good trigger, you may need to do some more power analysis to figure out what a good trigger location is such as measuring VDD-Core that you are trying to glitch.

Thomas Roth has great presentations on this topic in which he attacked the readout protection on an Apple AirTag. If you need motivation I recommend giving his presentation a watch.