docs · faq(7)
FAQ
Common questions about behavior, limitations, compatibility, safety and planned work.
- Why kernel space instead of a udev rule or systemd service?
- So detection keeps working if user space is frozen, killed, or was never properly started. A script invoked from udev depends on udev, on the interpreter running it and on nothing having paused that process first. wrong8007 removes that dependency chain for the detection path. See Philosophy.
- Is this stable enough for production use?
- I do not think so. Treat it as experimental. There is no fuzzing harness for the configuration parsing path yet, no formal verification of the state machine and the subsystems may still change between minor versions.
- What does it actually do when a trigger fires?
- Runs exactly one command, the one you gave it as
EXEC, via/bin/sh -c. Nothing else. The module ships no default payload: you write the wipe script, the lock script, or whatever action you want. - Can I make it retry, escalate, or run more than one command?
- Not inside the module. Execution is gated by a single atomic latch and runs
exactly once per load, by design. See Philosophy and Architecture design.
If you need a sequence of actions, put that sequence inside your
EXECscript. - How is this different from USBKill?
- USBKill is a userspace script bound to one trigger, USB hotplug, invoked from udev. wrong8007 hooks three trigger sources directly in kernel space (keyboard, USB, network) and separates detection from execution behind a single latch, removing the userspace dependency at the cost of running with kernel privileges.
- Is this safe to load on a machine I care about?
- Test it first on hardware and data you can afford to lose. The keyboard trigger's exact-match requirement means an unlucky typo elsewhere won't fire it, but the MAC/IP network triggers can fire immediately on load under some network conditions: read the warning on Activation triggers before using them.
- Does it protect against forensic access to storage or a cold-boot attack already underway?
- Not on its own. What happens to your data is entirely up to your
EXECpayload; the module's contribution is triggering it quickly. Whether that's fast enough to matter against a given attack depends on your payload and your hardware, not on wrong8007 itself. - Does it work on ARM or embedded boards?
- Only tested on x86_64. The core has no architecture-specific code and the
usbandnettriggers use generic kernel subsystems that should build on arm64 but this is untested. Thephrasetrigger has no platform dependency. Reports and patches welcome. - Can a kernel panic anywhere on the system arm a trigger?
- No, not in the current version. A panic is not wired into the trigger graph. This is a known gap, documented on the Security model page, not a hidden one.
- Does it work on non-US keyboard layouts?
- Not for the keyboard trigger. The scancode-to-character mapping is a fixed US
keymap table compiled into
keyboard.c. USB and network triggers are layout-independent. - Does it work with virtual keyboards or remote sessions (SSH, VNC, RDP)?
- No. The keyboard trigger hooks the kernel's input notifier chain for physical keyboard events; input injected above that layer doesn't reach it.
- What license is this under?
- GPLv2, matching the kernel's own license for code that links against
EXPORT_SYMBOL_GPLinterfaces. - Is there DKMS or distro packaging?
- Not yet. Rebuild against each kernel you load the module on. It's on the roadmap below.
Roadmap
| area | status |
|---|---|
| Core functionality across all three triggers | done |
| Documentation of usage, parameters and caveats | done |
| Modular trigger/core separation | done |
| Clean load/unload, no kernel warnings or panics observed | done |
| Tagged releases and changelog | done |
| Debug logging mode | done |
| Multi-environment / stress testing | in progress |
| Dry-run or mock-environment mode | planned |
Load-time hardening (restrict who can insmod) | planned |
| DKMS support | planned |
| Install/uninstall scripts beyond the Makefile | planned |