Wrong Boot

Wrong Boot (codename: wrong8007) is a programmable dead man's switch for Linux, living entirely in kernel space. Think of it as the software equivalent of a burner phone OR a modular kernel trigger framework for last-resort execution.

Inspired by the legendary USBKill project and reinvented from scratch, it's modular, trigger-agnostic, and execution-flexible: you choose how it activates, you choose what it does.

This project was revisited and expanded in memory of Mark Klein (May 2, 1945 – March 8, 2025) the AT&T technician who, in 2006, revealed the existence of warrantless mass surveillance (Secrets of Room 641A) by the NSA.

In a world where truths vanish into evidence lockers, systems can be seized, tampered with or forcibly accessed, and control can be taken in seconds, reaction time is everything.

Wrong Boot isn't just a tool. It's last words. A line you draw before someone else crosses it.

When the moment comes, wrong8007 won't ask questions. It will act exactly how you told it to.

<p align="center"> <img src="https://github.com/user-attachments/assets/d5a0bb9e-a23e-46f8-af5f-bb8e01277dca" alt="demo gif"> </p> <p align="center"> <a href="#usage">Installation</a> &nbsp;&nbsp;&nbsp;•&nbsp;&nbsp;&nbsp; <a href="docs/security-model.md">Security model</a> &nbsp;&nbsp;&nbsp;•&nbsp;&nbsp;&nbsp; <a href="docs/manifesto.md">Philosophy</a> </p>

Disclaimer: This project is for educational and lawful defensive purposes only. Using it to damage systems you don't own or have permission to modify is illegal.

Features

• Kernel-space monitoring: Zero user-space dependencies; works even if most of the system is compromised.
• Multiple triggers: Phrase detection, USB events, network packets all extendable by design.
• Custom execution hooks: Run any script or binary, from data wipes to custom alerting logic.
• Fail-closed design: Invalid configurations prevent module load rather than causing undefined behavior.
• Fast & silent: Triggers execution instantly, without relying on cron jobs or user-space daemons.
• Modular architecture: Clean separation between core logic and triggers.

Design

The design of this project was intentionally made modular to allow for customization and the use of individualized solutions (by default, it comes with a rudimentary script for nuking).

Wrong Boot's architecture keeps triggers separate from the core logic, making it easy to add or remove trigger types without touching the core.

<p align="center"> <img width="708" height="440" src="https://github.com/user-attachments/assets/d0bb5624-77b1-45d7-bff8-8adb7a45859a" alt="system architecture" /> </p>

For example, the keyboard trigger (trigger/keyboard.c) listens for a secret phrase and instantly runs your configured executable when matched. Other triggers (USB, network) work independently - load the module with any combination you need.

Execution model

Wrong Boot enforces strict ownership and layering between triggers and execution.

Triggers detect conditions only.

They do not execute payloads, coordinate with each other, or own execution state.

The core module owns execution policy, including:

• One-shot execution semantics (exactly once)
• First-trigger-wins behavior
• Deferred execution via a workqueue
• Clean re-arming on module reload

All triggers interact with the core through a single stable API:

wrong8007_activate();

Internally, this is implemented as a one-shot latch:

flowchart TB
    Trigger[Trigger detects condition]
    Core[Core execution policy]
    Latch[One-shot latch]
    Work[Deferred workqueue]

    Trigger -->|request| Core
    Core -->|authorize execution| Latch
    Latch -->|consumed on first trigger| Work

This design provides:

• Clear ownership boundaries
• Fail-closed behavior
• Predictable execution
• Easier auditing and future extension

Triggers can only request execution. The core decides if and when it happens.

You can read more about the project's design philosophy here. For trust boundaries and non-goals, see the security model.

Usage

The usage is pretty simple, actually, but you will need to have superuser access to the machine.

1. Clone the repository

    $ git clone https://github.com/0x48piraj/wrong8007.git
    $ cd wrong8007/

2. Build the kernel module

Compiling the LKM,

    $ make

Debugging:

• Optional -DDEBUG flag prints verbose logs for keypresses and command execution

  Enable with:

    $ make EXTRA_CFLAGS=-DDEBUG

At last, installing the kernel module,

3. Load the module

Example: run tests/test_exec.sh when the phrase secret phrase is typed.

    $ chmod +x tests/test_exec.sh
    $ test -f tests/test_exec.sh && make load PHRASE='secret phrase' EXEC="$(realpath tests/test_exec.sh)"

The executable/script must have execute permissions (chmod +x) and use an absolute path.

Removing the kernel module

    $ make remove   # Remove the module
    $ make clean    # Optional: clean build artifacts

Keyboard-based trigger

The wrong8007 module can trigger actions when a specific phrase is typed on the keyboard.

• Case-sensitive matching. "nuke" is different from "NUKE".
• Matches exactly as typed, without ignoring spaces or punctuation.
• Works only on printable characters (no special keys like Shift or Ctrl).

Usage

Load the module with the desired trigger phrase:

make load PHRASE="nuke" EXEC="/path/to/script"

The configured script will run immediately after the phrase is typed in sequence.

Limitations

• Works with the US keymap only.
• Requires the phrase to be typed without mistakes - any wrong key resets the match.
• Does not capture keys from virtual keyboards or remote sessions.

USB-based triggers

The wrong8007 kernel module supports advanced USB event–based triggers with flexible configuration:

• Multiple USB devices supported in a single load.
• Fine-grained control over event types: insertion, removal (eject), or any activity.
• Support for whitelisting or blacklisting USB devices.

Usage

You can specify a list of USB devices using their Vendor ID (VID) and Product ID (PID), along with an event type.

Load module with a single device trigger on insertion/ejection (default)

make load USB_DEVICES="1234:5678" EXEC="/path/to/script"

Trigger on removal (eject)

make load USB_DEVICES="1234:5678:eject" EXEC="/path/to/script"

Trigger on any USB event (insert or remove)

make load USB_DEVICES="1234:5678:any" EXEC="/path/to/script"

Trigger on multiple devices at once

make load USB_DEVICES="1234:5678:insert,abcd:ef00:any" EXEC="/path/to/script"

Device matching modes: Whitelist vs. Blacklist

Use the WHITELIST param:

• WHITELIST=1 → Only listed devices trigger the payload.
• WHITELIST=0 (default) → Listed devices are blocked, all others trigger.

Example:

make load USB_DEVICES="1234:5678:any" WHITELIST=1 EXEC="/path/to/script"

Find your device VID & PID

Use:

lsusb

⚠️ Note on parameter validation and trigger behavior

Dynamic configuration via the usb_devices module parameter was introduced and improved in commits 7a6ab4d and 4fd9648, enabling runtime specification of USB device rules for fine-grained trigger control.

This replaces the legacy approach introduced in commit 875ff0a.

• The module accepts USB device rules via the usb_devices module parameter as an array of strings in the format:

  VID:PID:EVENT
  

  where EVENT is one of insert, eject, or any.

• Upon module load, these rules are parsed and validated strictly:

  • Each rule is checked for correct hexadecimal VID and PID values.
  • The event string is verified to be one of the supported values.
  • Invalid or malformed rules cause the module initialization to fail with clear error messages.

• If no valid USB device rules are provided, the USB trigger disables itself silently and does not register for USB event notifications.

• This rigorous validation ensures that only well-formed configurations are accepted, avoiding undefined or unexpected behavior at runtime.

• usb_notifier_callback() schedules work once per USB event so we don't need to dedup for correctness.

• Users must provide valid rules; incorrect inputs will prevent module load.

Design rationale

• Validation is performed in the kernel module on load, ensuring invalid configurations are rejected immediately.

• This balances robustness and safety with kernel code simplicity.

• The module avoids runtime overhead of repeated checks by validating once during initialization.

• Users should still carefully prepare module parameters (e.g. via scripts or tooling) to avoid load failures.

Network-based triggers

The wrong8007 module supports various network-triggering modes - flexible enough for LAN environments, and stealthy when used with passive traffic.

Usage

Trigger on specific MAC address

Trigger when any packet from this MAC address is seen on the interface:

make load MATCH_MAC='aa:bb:cc:dd:ee:ff' EXEC="/path/to/script"

Trigger on specific IP address

Trigger only when a packet originates from the matching IPv4 address:

ma