The Piezoelectric Glitching Attack

Many readers will be familiar with the idea of a glitching attack, introducing electrical noise into a computer circuit in the hope of disrupting program flow and causing unexpected behaviour which might lead to hitherto unavailable access to memory or other system resources. [David Buchanan] has written a piece investigating glitching attacks on PC memory, and the tool he’s used is the ubiquitous piezoelectric lighter.

Attaching a short piece of wire to one of the lines on a SODIMM memory module, he can glitch a laptop at will with the lighter through the electromagnetic noise its discharge creates. It’s a cool trick, but the real meat of the write-up lies in his comprehensive description of how virtual memory works, and how a glitch can be used to break out of the “sandbox” of memory allocated to a particular process. He demonstrates it in a video which we’ve placed below the break, in which he gains root access and runs an arbitrary piece of code on a Linux laptop. It’s probable that not many of us have the inclination to do this for ourselves, but even so it’s fascinating to know how such an attack works.

18 thoughts on “The Piezoelectric Glitching Attack

  1. Fascinating article. I wonder though…

    Given the ESD sensitivity of parts like these, what is the difference in threshold is between injection of a useful EMI “glitch” and a game-over fry?

    1. It may fry the new tech as it is made with smaller detail chips. For a long time, in space was used older technology because it is more resilient to cosmic radiation because of bigger internal details on the silicon waffer.
      Perhaps one day hacking will ment to take the target device into space and leave it there for a while.

    2. ESD injects ~kilovolts directly into a part (e.g. after you’ve charged your body up like a capacitor).

      While I suppose there’s no upper bound on the current/voltage you can induce with EMI, you only need a few millivolts to garble a bus read. Newer parts are probably easier to fry, but they should also take less of a prod to induce a bit flip – so my theory is that it still works fine, but maybe you’d want a smaller “antenna” and/or to hold the lighter further away.

      1. “ESD injects ~kilovolts directly into a part …”

        Not necessarily. Yeah, direct injection is bad, but you can trash a part merely through -proximity- to a charged object, no need to apply ESD “directly.”

        That’s why you’re not supposed to have paperwork, synthetic clothing, long hair, or even a tape dispenser within 12 inches of an unprotected PCB assembly… and when you need to dispense some tape (to seal a static bag, for example) you should only do so in the stream of an ionizer.

        The problem with a piezo lighter as a signal source is that there is no way to bracket or control its amplitude… hence my concern.

        ” you only need a few millivolts to garble a bus read….”

        OK. Maybe a safer approach, then, would be the application of narrow low-voltage pulses coupled through a capacitor or current-limiting impedance? Another application for the venerable 555?

  2. This seems insane to me… pure luck! “If we know that 99% of memory accesses are to our pointer array…” Whoa, what about the OS running thread-switching, and drivers, and screen-updates, and other processes altogether, which are now cache-missing every time, so cache-refilling, as well? Seems 50% at-best, nevermind the for loop tests and iterations… And when one of those other tasks gets a damaged byte..? Down goes Bash, the entire OS, X, the terminal emulator, the CPython interpreter… How many times did he film shooting this basketball ’till he finally got it in the bucket?

    1. Read the linked blog next time. From there: “I was unusually lucky on this run, normally it takes several clicks of the lighter to get a good glitch. Not shown are the several previous attempts that crashed the whole system! I’m not sure what the overall exploit reliability is, I haven’t tried to measure it rigorously. When the laptop’s screen is off and I’m SSHed in it feels like it’s around 50%. But when I’m at a graphical shell like in the demo, it’s maybe closer to 20% reliability. This system has integrated graphics, so perhaps the GPU’s memory accesses interfere with the exploit. There are also various background services running (pipewire, sshd, systemd stuff etc.), and swap is enabled too. I wanted it to be a fairly realistic desktop Linux environment, and disabling all these things would probably increase reliability.”

    2. I was unusually lucky on this run, normally it takes several clicks of the lighter to get a good glitch. Not shown are the several previous attempts that crashed the whole system! I’m not sure what the overall exploit reliability is, I haven’t tried to measure it rigorously. When the laptop’s screen is off and I’m SSHed in it feels like it’s around 50%. But when I’m at a graphical shell like in the demo, it’s maybe closer to 20% reliability.

      He addresses this in the article.

  3. Completely unrelated to the subject, I loved the mention of remapping the address lines to make routing easier. I’ve used this several times to get round some very knotty PCB routing problems.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.