ROOTBACK

Why this exists

In the post-AI era, exploit research is abundant and cheap. Proof of ownership is not.

A model can summarize a CVE. It cannot prove that the computer in front of you is yours, that its kernel is the one you think it is, or that you can still recover it without a vendor account, a cloud console, or a rescue USB.

ROOTBACK reads the kernel actually running, matches it against a curated snapshot of public root-escalation and KVM/container-escape research, and — only after explicit consent — runs a narrow set of public PoCs. When one succeeds, it uses the root context to reset a local password and verifies the reset with a root-owned marker.

Kernel exploits can crash or corrupt the machine. Use this only on hardware you own or are written-authorized to test. Keep a console or rescue path before changing a password.

What it is not

• No remote target option. There is no --host; it acts on this machine only.
• No persistence: no cron, no systemd unit, no shell-profile edits, no backdoor.
• No credential harvesting, no telemetry, no network scanning, no lateral movement.
• Not a replacement for patching. Detection is a version-and-feature hypothesis, not a vendor patch attestation.

Catalog — snapshot 2026-11-11

39 entries. auto means a public recipe exists and the tool can run it after consent. manual means detection plus a research link: these need host-side control of a VM/container, kernel-specific offsets, a second terminal, or the public PoC is a panic/DoS rather than a recovery path. Android entries are decided by ro.build.version.security_patch.

Kernel local privilege escalation

KVM guest-to-host

Android kernel

Matched against the device security patch level, not the GKI base version. Detection-only: no Android recipe, and no password reset.

Container runtime

These require control over container creation, a malicious image, or shared mounts. A version match alone is not an escape.

Userspace

Legacy kernel LPEs

Kept for long-lived LTS and embedded machines. Most are detection-only here because their public PoCs need kernel-specific offsets, a second terminal, or deliberately panic the host.

How it works

uname / config / modules / sysctls / ro.build.version.security_patch
              |
              v
   catalog match (stable fix matrix or Android SPL + feature gates)
              |
              v
   authorization gate (--authorized + typed phrase)
              |
              v
   fetch public PoC -> build -> feed reset payload
              |
              v
   root-owned marker (uid 0, nonce) -> reset verified

Detection checks the upstream stable fix matrix and then the feature gates that make the path reachable: algif_aead, esp4/esp6, act_pedit, rds, cifs.upcall, unprivileged user namespaces, ptrace_scope, /dev/kvm, and nested virtualization. A distribution kernel can backport a fix without changing its base version, so a VULNERABLE result on a vendor kernel is a hypothesis; non-interactive auto-runs of medium-confidence candidates require --include-medium. On Android, entries with a fixed patch level are decided by ro.build.version.security_patch; entries that only have an upstream matrix are capped at medium and annotated with the GKI caveat.

Use

git clone https://github.com/pysio2007/rootback
cd rootback
./rootback.sh deps
./rootback.sh scan
./rootback.sh exploit auto --authorized --dry-run
./rootback.sh exploit auto --authorized

Then type I OWN THIS MACHINE when prompted. SSH additionally requires --allow-ssh. A generated password is printed once and never written to the audit log; use --password-file instead of --password.

The gift

The post-AI era will produce more exploits than any one person can read. The scarce thing will be the ability to prove that a machine is yours, that you understand what it runs, and that you can still get back in.

This is a small attempt at that. It is text, shell, and public research — no account, no cloud, no permission from a vendor.