Inception: a tool for compromising the slumber of computers with full-disk encryption

Inception is a tool for breaking into computers with full-disk encryption. It assumes that you have access to a suspended/screen-locked computer whose disk is encrypted. You access the machine over its FireWire interface (or, if it doesn't have FireWire, you plug a FireWire card into one of its slots, and the machine will automatically fetch, install and configure the drivers, even if it's asleep), and then use the FireWire drivers to directly access system memory, and from there, patch the password-checking routine and walk straight into the computer.

This (and its predecessors, like winlockpwn) is a substantial advance on previous attacks against sleeping full-disk encrypted systems, which involved things like plunging the RAM into a bath of liquid nitrogen. As the author, Carsten Maartmann-Moe, points out, this can't be easily remedied with a FireWire driver update, since FireWire requires direct memory access to effect high-speed transfers.

So, two things: First, shut down your computer when it's not in your possession; second, "Inception" is an inspired name for an attack that breaks into the dreams of a sleeping computer, directly accesses its memory, and causes it to spill its secrets.

Inception’s main mode works as follows: By presenting a Serial Bus Protocol 2 (SBP-2) unit directory to the victim machine over the IEEE1394 FireWire interface, the victim operating system thinks that a SBP-2 device has connected to the FireWire port. Since SBP-2 devices utilize Direct Memory Access (DMA) for fast, large bulk data transfers (e.g., FireWire hard drives and digital camcorders), the victim lowers its shields and enables DMA for the device. The tool now has full read/write access to the lower 4GB of RAM on the victim. Once DMA is granted, the tool proceeds to search through available memory pages for signatures at certain offsets in the operating system’s password authentication modules. Once found, the tool short circuits the code that is triggered if an incorrect password is entered.

An analogy for this operation is planting an idea into the memory of the machine; the idea that every password is correct. In other words, the nerdy equivalent of a memory inception.

After running the tool you should be able to log into the victim machine using any password.

Inception (via JWZ)


  1. Disable you FireWire port in the bios?

    From the OP:
    “Q: Isn’t FireWire a dying horse? Few laptops ship with FireWire ports these days, which makes Inception a useless tool.
    A: You can use any interface that expands the PCIe bus, for example PCMCIA, ExpressCards, the new Thunderbolt interface and perhaps SD/IO to hotplug a FireWire interface into the victim machine. The OS will install the necessary drivers on the fly, even when the machine is locked.”

    1. You might be able to outright delete the files containing Firewire driver code.

      This doesn’t solve the general problem though – there are other externally accessible DMA buses (see BunkLung’s post above). If Firewire finally fully dies off, or if disabling the drivers more robustly becomes general practice, then some other DMA-accessing interface will be used.

      1. Nah. The drivers for the OS are primarily to coordinate keeping the OS from reading/writing the same memory as DMA devices at the same time. Removing them doesn’t stop the FireWire device from having DMA access.

      1. That’s true.

        Even better, all devices not present at boot require acknowledgement by someone at console. You’d need some way to deal with new HID without opening up a vulnerability though.

      2. wat?  How is the kernel even going to be aware if the hardware is sleeping?  I think they mean the PCIe bus will load the device firmware when it’s hotplugged.

        Also: glad I got the cheaper laptop without expansion slots!

          1. Oh? then please explain how an interrupt is processed causing a disk to spin up, a driver loaded to RAM and linked into the kernel if the CPU is “turned off”?

            In sleep mode the CPU is in a low power state, but it is still executing code.

      3. It might be more helpful to look into the possibility of better handling the keys for an encrypted filesystem.

        If my reading is correct, the cool part of this attack is not the ability to stub out the password verification step(being able to do so with just a firewire cable is certainly nice, and more elegant than popping out the drive and then either reading what you want on a different system or overwriting the locally stored password hashes and logging in that way); but the fact that, if the computer is sleeping, the secret key that allows decryption of an encrypted filesystem is protected only by the (breakable) password verification step, rather than actually requiring knowledge of the password, as it would if you were cold booting.

        In an ideal world, the sleeping system would not actually be storing the decryption key at all, only enough to infer it with access to the real password(so, even if the attacker stubbed out verification, they’d still get a garbage decryption key unless they used the correct password).

        That would make things significantly more complex, since the system would have to have enough unencrypted components to wake from sleep and ask for credentials without panicking horribly; but not so many unencrypted components that useful fragments of user information could be gathered; but if it were possible it would also reduce the DMA attacks to a merely more convenient flavor of ‘just pop out the HDD’ attack…

        1. They’d just have a special case for those OSes that finds the function that attempts to decrypt the file system with the password provided, and insert a function that attempts with the keys already in the keyring — back-patching.
          Most modern OS’ encrypt with keys, stored in a keyring management system, which is itself unlocked by the provided password.
          Some OS’ kernel teams / encryption teams aren’t going to write special-case code to handle “what if someone has FireWire/DMA access”, especially if file system decryption is a time-intensive /RAM – intensive task to begin with, and the OS itself is in the encrypted disk.
          Even if the user filesystems are separately encrypted, the kernel’s compromised, so as soon as those are decrypted (when the user logs on), those keys are compromised.

          The scarier possibility here, is that DMA access allows for arbitrary code execution, which allows for patching arbitrary firmware of any chipset or device on the machine, permanently compromising the device even if the filesystems are entirely replaced.

  2. This requires physical access. Rule number one of hacking. If you can touch it, you can own it. This definitely looks to make it easier though.

        1. It used to be, but someone got physical access to Fight Club and overwrote the rules with nothing more than a FireWire cable.

  3. >  (or, if it doesn’t have FireWire, you plug a FireWire card into one of its slots, and the machine will automatically fetch, install and configure the drivers, even if it’s asleep)

    Nope. You’re not going to be hot swapping PCI Express cards while the computer’s running. Some server motherboards and BIOSes can allow hot swapping PCI-E but 99.99% of computers in the world do not have that capability.

    1. You forgot the 0.01% of computers in the world that feature a PCMCIA slot or ExpressCard slot. They’re new-fangled devices that have crazy batteries inside and are foldable to fit inside backpacks.

      1. Have you shopped for one of these “crazy foldable battery computers” in the past few years? Good luck finding any that have an Expresscard slot. USB3 and eSATA have effectively made it obsolete.

        1. from TFA: “You can use any interface that expands the PCIe bus, for example PCMCIA, ExpressCards, the new Thunderbolt interface and perhaps SD/IO [SDcard] to hotplug a FireWire interface into the victim machine.”

    2. I thought that sounded odd.  (Really, really odd.)

      I guess it makes sense if “asleep” means “powered off and hibernating”, provided you can wake the machine up from hibernation without requiring a password?

  4. Indeed. WTF were the OHCI folks even thinking of when they allowed “unimpeded DMA access to physical memory without the intervention of the operating system”?

    That’s a few shades worse than Microsoft’s allowing untrusted code resources to be downloaded from anywhere and executed with full user privileges in email messages and browsers.

    1. DMA is used because it is both faster and substantially less demanding of CPU time than the alternatives. PIO is a serious drag on performance, especially if your situation requires high, and predictable, throughput in a system that may be under other sorts of load(as in, for example, a computer ingesting a DV tape over firewire and dumping it to disk.)

      The demand for hot-pluggable external ports on computers that are kept outside physically secure environments makes this hitherto largely theoretical problem a more serious concern(ISA and PCI were also vulnerable, in the ages when dinosaurs wandered the earth; but you’d notice before somebody screwdrivered open your IBM PC and popped a malicious card in, even assuming that that wouldn’t kill the motherboard…); but it isn’t as though this is an abberation of some kind in a single standard; DMA shows up in a great many high speed(or high speed for their time) interfaces because it is good at what it does.

      1. that is all true. but none of that means or requires that a device gets access to arbitrary areas of system RAM without intervention by the OS. the fact that you CAN grant a device access to RAM for DMA doesn’t mean that you have to.

        1. Actually, DMA means just that – Direct Memory Access, without CPU or OS intervention. The particular mode here sets up DMA to the lower 4 GB, without signaling the portion of the operating system that could stop the process. The OS is given a signal that this hardware setup is happening, load your driver – but whether it loads a driver or not (a driver that essentially does little more than coordinate flags so that it doesn’t write/read the exact same memory the DMA device is at the same time), the FireWire device is getting DMA, because that’s in the firmware.

  5. I’d be interested to know if SATA has similar issues (how many full size PCs have an eSATA connection on the back). It is a lot more likely to have SATA than firewire and the drivers will already be loaded / be pretty much required to boot (so you can’t simply delete them)
    (If so, we’ve now gone from an attack that mainly hits laptops and older PCs with firewire to an attack that hits a large number of modern PCs and laptops without even needing to open the box.)

    What gets me is that the target machine can successfully load drivers etc while sleeping. Surely “sleep” means “don’t do any processing and keep memory state static” ?

    1. “Sleep” means “shut down power-hungry components such as video, hdu, fans, and anything needing a fan”. The CPU still operates, as does RAM and often the net interface continues to operate (all at decreased clock speed), so the machine can handle wake signals, wake-on-LAN, and system-level events (hardware events).

  6. It’s even easier. Just unplug the datacable, leave the power plugged in, plug your own datacable into the (not) encrypted HDD and copy/edit/delete stuff as you wish. Works for most computers (Problem is not the HDD but the implementation in the system – system should encrypt the HDD on sleep not leave it decrypted which is totally facepalm.
    There is a talk on that topic on the 29C3 of the CCC in Hamburg – look it up must be somewhere on Youtube. Firewire is nice but not the best way to do it because you could be faced with flipping bits.

    1. Depends on where your disk decryption is handled. If the chipset on the disk is doing encryption and decryption, then possibly you could just unplug and replug data cables, unless the disk ditches the decrypt tables on unplug events. If the OS is doing encrypt and decrypt of the filesystem, hitting the cable won’t do anything.

  7. So, the upshot here is: for real security, shut your machine down when not using it, and require a boot password, and have strong disk encryption, and have a way to disconnect – physically – FireWire ports and PCMCIA slots and anything else that uses DMA, and also be able to reliably detect case openings.

  8. This one, AGAIN? Sheesh. 

    In the real world, if you care about securing your computer, you can already store the key off-board AND require a HW backed PIN that is quite robust. You can do this for hibernate if you like standby but are worried about security. And BitLocker wipes memory *even on an unplanned power-down* so you’re covered there too.

    I wrote about the basics of this WAAAAAAY back in 2008:

    Also note that we developed an additional cipher for BitLocker that makes grinding out the PW check auth code extremely difficult by adding cross-block-level randomness to the disk so you can’t reboot over and over again and look for diffs and try to find the registry setting requiring PWs a midst a sea of random. 

    Also on my machine, installation of admin-privileged code (that includes DMA driver updates and replacement of PW code, last I checked) requires a user confirmation, which a device isn’t going to be able to do… not unless it is also somehow replacing the mouse driver. Which would require user auth. 
    What am I missing here? How do you get past UAC? 
    Which it’s recursive, innit? 

  9. I’m not entirely sure what is meant by the computer is asleep, but I can pretty much guarantee that when I put my machine into sleep mode, the only thing it does is trickle-feed power to the RAM. Everything else, including processing, stops. That’s actually the whole point. (Yes, the OS has to be aware of the sleep function, but that is only to prepare itself for the stasis it is about to go into.) Any hardware changes you make while it is sleeping will not be noticed until you wake it up. (I suppose it is conceivable that the sleep function could be designed to wake on hardware change, but that would require something stay awake to look for them… and then, it wouldn’t be a sleeping computer anymore, would it?)

    But maybe they aren’t talking about computers. Maybe they are talking about Macs. (ooh, burn) I’ve no idea what sort of stupid things Macs do when they are asleep or what stupid redefinition of “sleep” Apple uses, but if either are this fucked up, IMO it is just another one of the 92438765879436587 reasons to never use a Mac. Too much hand-holding and automagical system actions (like, say, polling for hardware changes and downloading and installing drivers, all while asleep, in the name of “Easy!”) leads to what we like to call gaping security holes.

    1. If this were true your computer would never come out of sleep as there would be no way to detect mouse, power switch, or keyboard actions. The only thing it would be doing is refreshing the RAM, not checking for hardware events that are supposed to wake it up.

      The DMA part of firewire doesn’t need OS level drivers installed. It’s a function of the motherboard. Both Windows and Mac’s are vulnerable to the add-in card scenario, although only one current model of Mac even allows add-in cards, the laptops, iMacs and mac mini don’t.

      For Mac’s with built-in firewire (and thunderbolt, that is vulnerable as well) the problem was fixed in 10.7.2 and DMA access is disabled on sleep. Not sure on Windows, but since Microsoft doesn’t make the PC hardware at the moment they may be more vulernable.

      PGP is less vulnerable as long as your hibernation and page files are on encrypted volumes.  On sleep the key is erased from memory and the user must re-enter their password on wake before the drives can be used. If you use whole disk on your boot volume you’re probably ok.

      More accurate info than Corey’s is available at Ars Technica: the comments in particular have some good info on this.

      1. of course you are correct, but in defense of the ignorant, it would be theoretically possible to use another processor (superIO, etc) to boot the entire shebang just like we do from POST.  but of course this would be an entirely different world…

Comments are closed.