Introducing BusKill: A Kill Cord for your Laptop

This post will introduce a simple udev rule and ~$20 in USB hardware that effectively implements a kill cord Dead Man Switch to trigger your machine to self-destruct in the event that you’re kicked out of the helm position.

BusKill: A USB Kill Cord for you Laptop

ⓘ Note: This is an old article that is out-of-date.

To learn how to install BusKill, see our BusKill GUI App Documentation.

Photo of a Rubber Ducky USB drive
Rubber Ducky I <3 you; you make hack time lots of fun!

Let’s consider a scenario: You’re at a public location (let’s say a cafe) while necessarily authenticated into some super important service (let’s say online banking). But what if–after you’ve carefully authenticated–someone snatch-and-runs with your laptop?

Maybe you can call your bank to freeze your accounts before they’ve done significant financial harm. Maybe you can’t.

Or maybe your laptop was connected to your work VPN. In less than 60 seconds and with the help of a rubber ducky, the thief could literally cause millions of dollars in damages to your organization.

Surely there must be some solution to trigger your computer to lock, shutdown, or self-destruct when it’s physically separated from you! There is: I call it BusKill.

ⓘ Note: This post is adapted from its original article on Michael Altfield’s tech blog, which first introduced BusKill.

Surprisingly, I couldn’t find a low-tech solution that implements a laptop kill cord, so I decided to build one myself for ~$20 and a simple udev rule.

Demo

Here’s a quick video demo showing BusKill triggering a kill signal when the magnetic breakaway is tripped.

Hardware

The key to BusKill is using a cable that will trigger a udev remove action when your laptop is stolen. You could just have a usb thumb drive on a retractable lanyard (think RFID badges or DoD Common Access Cards), but what if that thin retractable cord just snaps–leaving the USB drive snugly in-place in the laptop?

Photo of the BusKill hardware, including a carabiner, keyring, usb drive, usb extension able, and magnetic usb breakaway adapter
My $20 in BusKill hardware (USB-A)

A better solution is to attach the USB device as close & snugly connected to your body as possible and run a data cable all the way to the computer. This can further be improved using a break-away magnet connector as close to the machine as possible. For example, the following items are sufficient to build this USB kill cord:

  1. A cheap $4 USB drive with durable keyring hole
  2. A small & strong carabiner keyring for attaching the above drive to your belt loop (I like this $6 one because it’s small, well-made, and has a clever locking mechanism)
  3. A $7 USB magnetic breakaway adapter to plug into the computer’s USB-A port
  4. And finally, a $3 1-meter USB extension cable to connect them

It’s 2020, and a lot of laptops no longer have USB-A ports on them. If you only have a USB-C, you can either go hybrid by adding this:

  1. $9 USB-C to USB-A converter

Or go full USB-C with:

  1. A cheap $9 USB-C drive
  2. A $24 USB-C magnetic breakaway adapter
  3. And a $13 1-meter USB-C extension cable

ⓘ Note: If you’d prefer to buy a BusKill cable than make your own, you can buy one fully assembled here.

Software

To set this up, we need to add a new udev rule file to /etc/udev/rules.d/. Here’s a simple rule that will trigger xscreensaver to lock the screen every time any USB drive is removed:

cat << EOF | sudo tee /etc/udev/rules.d/busKill.rules
ACTION=="remove", SUBSYSTEM=="usb", RUN+="DISPLAY=:0 xscreensaver-command -lock"
EOF
sudo udevadm control --reload

But that rule may be a bit too broad. If you want to have a specific brand of USB drive trigger the lockscreen, first we need to do some debugging to find some properties that are triggered by your BusKill-specific usb drive when it’s ejected. To get those, follow this procedure

Step 1: Insert your USB drive
Step 2: Run udevadm monitor --environment --udev
Step 3: Remove your USB drive

Check the output of the udevadm command. You should see a bunch of potentially uniquely identifiable properties about your drive, such as the manufacturer, model, filesystem uuid, etc. For example, let’s say we see the following line indicating that the ID_MODEL property of your USB drive is Micromax_A74.

$ udevadm monitor --environment --udev
...
ACTION=remove
...
ID_MODEL="Micromax_A74"
...
SUBSYSTEM=usb
...

Then we can update the udev rule to be:

cat << EOF | sudo tee /etc/udev/rules.d/busKill.rules
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_MODEL}=="Micromax_A74", RUN+="DISPLAY=:0 xscreensaver-command -lock"
EOF
sudo udevadm control --reload

And, of course–depending on the risk model–you may want the kill signal to actually shut down your machine:

cat << EOF | sudo tee /etc/udev/rules.d/busKill.rules
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_MODEL}=="Micromax_A74", RUN+="shutdown -h now"
EOF
sudo udevadm control --reload

Conclusion

We do what we can to increase our OpSec when using our laptop in public–such as using a good VPN provider, 2FA, and password database auto-fill to prevent network or shoulder-based eavesdropping. But even then, there’s always a risk that someone could just steal your laptop after you’ve authenticated! As of yesterday, that’s a hard attack to defend against.

As of today, we have BusKill. The BusKill solution described in this article can trigger your laptop to self-destruct if it’s physically separated from you. Because the data cable runs all-the-way from your body to the laptop, cutting the cable will still result in BusKill triggering.

BusKill is simple. There is no need for anything to actually be stored on the USB drive. And if the USB drive suddenly failed, BusKill would still be triggered. If an attacker quickly inserted a clone of your USB drive before or after stealing your laptop, BusKill would still be triggered.

And because it’s just a cable, there’s no risks of the attacker using some complex vector of attack over bluetooth, RFID, etc.

If you’d like to purchase a BusKill cable, click here.

Michael Altfield

View posts by Michael Altfield
Hi, I'm Michael Altfield. I write articles about opsec, privacy, and devops About Michael
Scroll to top