Read locked AVR

[Skorpionm]

https://github.com/CreateRemoteThread/sparkgap/tree/master/experiments/avr If I understand correctly, these are attacks on the ISP protocol with the firmware read protection bits set. Did they get away? and if I counted correctly, you make glith in the window 16000..45000 nc after lowering the Reset pin, the duration of glith is 95..150nc. do I understand correctly?

[CreateRemoteThread]

Oh, this is a blast from the past! 😄

The attacks are against the ISP protocol, intended for both for bypassing the security fuse and finding unlisted commands, I don't think the fuse bypass worked here, IIRC you need to power cycle the target to get the fuses read again (see here)

It looks like I was using a secondary trigger / support system but can't recall exactly what I used (i.e. not triggering on the reset pin... maybe on an SPI command), so I can't give an answer on what the timing was.

[Skorpionm]

then remember everything you remember) from attacks on locked AVRs. Every little thing can help...

[CreateRemoteThread]

I took a new look at this as part of benchmarking some new tools. Targetting atmega328p, notes below:

• The correct ISP commands are in this document, not AVR910 (the ISP manual).
  • The 0x4C write memory page is used as thus: 40 00 00 FE 48 00 00 EF 4C 00 00 00 writes EFFE to address 0x0000 in Flash (see this page).
  • Chaining these commands together too quickly will cause write failures
  • How does the legit ISP programmer do it so fast?
• Very reliable printf faults (that partially dump firmware) can be generated by placing short mosfet activations (using same mosfet as chipwhisperer's high power glitch) together with little delay between them, single extended faults seem prone to rebooting the device.
• Intuitively, the lock bit status seems to be checked on every read command instead of at reset / startup like a jtag disable security lock:

  >>> a.enterProgramming()
  0x0:0x0:0x53:0x0
  >>> a.readMemory(0x00,0x00)
  bytearray(b'\x00 \x00\x0c')
  bytearray(b'\x00(\x00\x94')
  >>> a.setLockbits(0xF0)
  0x0:0xac:0xe0:0x0
  >>> a.readMemory(0x00,0x00) # without releasing rst
  bytearray(b'\xf0 \x00\xff')
  bytearray(b'\x00(\x00\xff')
  >>>

Think there's a few paths to explore, but not glitching the memory read as I was trying years ago. Not sure if we can read out the ISP code itself somewhere?

Keen to share notes, shout out if you - or anyone reading - wants to work together.

[Skorpionm]

if you could tell me about your developments, I would be very happy, what did you mean by high power attacks while reading? can you provide a diagram and oscillogram of the attack

[CreateRemoteThread]

Sure. High power just means I'm using the same mosfet as ChipWhisperer Lite as the glitch output to the target (IRF7807. Digikey's suggested replacement should work too, maybe with timing adjustments.

A few quick updates:

• I've looked at the start of reset, to identify whether lock bits are loaded here. Initial answer is no (but traces attached).
  • The target is not power cycled when this is read (based on the fact that we don't need to power cycle after setting lock bits to see the effect - infact, we don't even need to toggle reset).
  • Intuitively, the other paths are cold boot + enter programming. I'll discount attacking read memory (unless there's an undocumented page read command).
• Commands seem to execute during SPI communications, adding noise to the transmission. This is "chip erase", you can see something executing after the first 2 bytes are sent:

Traces below: these are 125MS, triggering on rst low. avr_locked has lockbits 0xF0, avr_unlocked should be 0xFF (just after chip erase).

avr_locked.zip avr_unlocked.zip

[Skorpionm]

yes, I tried the erase command, it reads its execution at the moment when the address of this command has already been received but the checksum has not been transmitted. i.e. in the middle of the transmission. I tried to turn off the power at the start of erasing, but apparently Lock bits remain at the end, when the flash has already been erased. I don’t understand whether you succeeded or not to knock down the check of the lock bits, are we serving with a glitch of 0 volts or 12? if it worked out, you can throw off the oscillogram of a successful attempt

[CreateRemoteThread]

The attack above is unsuccessful (so far), I'm not sure where to test. I'll try to look for where the lock bits are loaded.

I'm pulling VCC to gnd via serial programming.

Have you had any success attacking 12V / parallel programming?

[Skorpionm]

no. i tried glitch to gnd. in a wide range after the reset signal and goes into the programming mode. so far also without success.

[CreateRemoteThread]

I've got this working reliably:

Gently under-volting the target is enough (no glitch needed). Annoyingly, once you bypass the lock bits, the first read to a given address will give the wrong result, but you can just read it a few times until the value "stabilizes".