Root payload library / indexed by build, not brand
Every public, source-available late-load root payload we can verify, on any Android phone we can document — indexed by what actually decides whether it works: the build and kernel.
A payload here is a small program that gives the phone root once it's running. Late-load means that happens
after boot: no boot image is patched, nothing is written to a
partition, and root is gone again at the next reboot. Today the published payload set is
Samsung-heavy (the CVE-2026-43499 family), and each entry says exactly
what it covers rather than implying it is universal. We link to each project's own source instead of
bundling its binaries, so the code you run is the code its maintainer shipped.
at a glance
The largest public set. Exact firmware profiles, exploit source, verified KernelSU late-load artifacts.
Exact-match profiles with KernelSU 3.3.0 plus KDP/RKP/DEFEX handling. Best One UI 9 notes.
Upstream set with one added profile: SM-S906B on kernel 5.10.237.
Our GhostLock chain for F956BXXS4DZI1, shipped in the manager and as a standalone payload.
The manager half every payload above drives — ksud plus per-KMI kernelsu.ko.
The boot-time trigger that re-runs a payload after every reboot — and why it needs an app or a PC on a locked bootloader.
Build match, kernel match, published hashes, licence, and a stock firmware to go back to.
three rules before anything
These apply to every entry below. They are properties of the technique, not of any one project.
The exploit half depends on that kernel's structures and offsets; the KernelSU half is a module built for that exact release. A payload for another firmware is not "probably fine".
Nothing writes a partition, so there is no AVB trip and no brick risk from the payload itself — and also no root after a reboot until the payload runs again.
Rooting trips Knox (warranty_bit). Samsung Pay, Secure Folder and some banking apps
stop working and cannot be restored. Decide that before you start, not after.
the library
Ordered roughly by how much of the ecosystem they cover. "Verification" means what the maintainer reports — unless an entry says hardware-verified by us, we have not tested it on our own device.
The largest public set and the reference implementation for most of the others. Ships exact firmware profiles, the app-domain CVE-2026-43499 exploit source and its compiled payload, the bootstrap helper, verified KernelSU late-load artifacts, and a machine-readable support feed (schema v3) so an app can select an exact profile at runtime.
Coverage: Galaxy S25 / S25+ / S25 Edge / S25 Ultra (kernel 6.6.98) · S24 Ultra SM-S928U1 and SM-S9280 (6.1.145) · S24+ SM-S926B (6.1.157) · A56 5G SM-A566E (6.6.102) · A36 5G SM-A366W (6.6.46) · A53 5G SM-A536E (5.10.237) · Z Fold4 SM-F9360 (5.10.236) · S23 Ultra SM-S9180 (5.15.189, test in progress) · S23+ SM-S916B (5.15.189, shell-only experimental) · S23 Ultra SM-S918B (5.15.189, confirmed via app/Shizuku).
Apache-2.0 · maintainer BuSung-dev · not independently verified by us.
Exact-match profiles for the S25 generation, with KernelSU 3.3.0 builds that carry Samsung KDP, RKP and DEFEX handling. Its notes are the clearest public write-up of the DEFEX-compatible bind-execution path the root helper needs on One UI 9.
Coverage: SM-S938B S938BXXSBCZG3 (6.6.98) · SM-S937B S937BXXU8CZF1 (verified exact match, 6.6.98) · SM-S938B S938BXXUCZZI4 (One UI 9 beta, 6.6.127, hardware validated) · SM-S931B S931BXXUCZZI4 (exact-match profile) · SM-S936B (6.6.98, advanced support, unvalidated).
Apache-2.0 · maintainer igorcv88 · not independently verified by us.
A fork of the upstream set that adds one extra profile and otherwise inherits the upstream payload table.
Coverage: Galaxy S22+ SM-S906B S906BXXSNGZD7 (kernel
5.10.237), plus whatever the upstream repo currently carries.
Apache-2.0 · maintainer Memetic0 · not independently verified by us.
The root manager every payload on this page drives: ksud plus a per-KMI
kernelsu.ko, late-load mode included. If you are auditing a payload, this is where its
manager half comes from.
Coverage: KMI android12-5.10 through android17-6.18, per-KMI artifacts.
GPL-3.0 · maintainer KernelSU-Next.
The published IonStack exploit source that the Samsung payloads above are ports of. If you want to judge whether a port is honest, read the primitive first — it is short, and every port differs only in offsets and in how it survives KDP/RKP.
Licence as stated upstream · publisher NebuSec (CyberMeowfia / IonStack).
our own payload — the one we can vouch for
Our GhostLock chain for the Fold 6 on F956BXXS4DZI1 (kernel
6.1.145-android14-11-33418572-abF956BXXS4DZI1). It ships twice: as the manager's
automatic re-root after every boot, and as a standalone folder you can run from a PC when the app
cannot start.
The manager refuses to run unless the model is SM-F956B, the bootloader
starts with F956BXXS4DZI1, and the kernel starts with 6.1.145. The guard
reads that from os.version — no shell, no race. On unsupported firmware you get a
refusal, not a kernel panic.
GPL-3.0 (KernelSU artifacts) · Unbolt project (payload) · verified on the single build it targets,
checked end to end: guard passes, kernelsu.ko late-loads, root returns in roughly 200–240 s.
auto re-root scripts — any Android phone
The entries above are payloads: they are what creates root on a specific build. This section is the other half — the trigger that re-runs autonomously after every reboot. None of these are Samsung-specific; every one works on any Android device, and they are the same hooks used by Magisk, KernelSU, KernelSU-Next, SukiSU and APatch.
| trigger | where it lives | root at boot needed? | works with locked bootloader? |
|---|---|---|---|
| KernelSU / KernelSU-Next / SukiSU / APatch boot scripts | /data/adb/late-load.d/, /data/adb/service.d/, /data/adb/post-fs-data.d/ |
yes — the manager must already load | no |
| Magisk general boot scripts | /data/adb/post-fs-data.d, /data/adb/service.d |
yes — Magisk patches the boot image | no |
Module service.sh / post-fs-data.sh |
inside the module folder under /data/adb/modules/<id>/ |
yes | no |
| Termux:Boot | ~/.termux/boot/ (runs as the app, no root) |
no | yes |
| Tasker / MacroDroid "on boot" shell action | app automation profile | no | yes |
| Root manager app (ours, Root My Galaxy) | foreground service + retry loop | no | yes |
| PC-side adb watchdog | host script that waits for the device | no | yes |
init.d |
/system/etc/init.d/ |
yes — and the kernel must support it | no |
So there are two kinds of trigger. If the bootloader is unlocked, the cleanest auto re-root is a
boot script: drop one executable file in /data/adb/service.d and the root
manager runs it on every start. If the bootloader is locked (our Fold 6), a boot script is useless — the
trigger must be an app or a PC, because nothing with root privileges exists yet.
One file, executable, correct line endings. KernelSU, KernelSU-Next, SukiSU and APatch all read the
same directories; Magisk reads post-fs-data.d and service.d. Prefer the
service stage — it is non-blocking; post-fs-data is blocking and time-capped.
#!/system/bin/sh
# /data/adb/service.d/zz-reroot.sh
# runs as root on every boot (unlocked bootloader / LKM loaded at init)
LOG=/data/local/tmp/reroot.log
echo "$(date) boot trigger fired" >> $LOG
# already loaded? nothing to do
grep -q '^kernelsu ' /proc/modules && exit 0
# otherwise re-apply the payload for THIS build
/data/local/tmp/unbolt/payload >> $LOG 2>&1
# verify, do not trust the exit code
for i in $(seq 1 60); do
id=$(su -c id 2>/dev/null)
case "$id" in *uid=0*) echo "root back after ${i}s" >> $LOG; exit 0;; esac
sleep 1
done
echo "FAILED to regain root" >> $LOG
Requires chmod +x and LF line endings. su may not exist during the very
first seconds — that is why the check loops instead of testing once.
When the bootloader is locked, root does not exist at boot, so the only thing that can re-create it is
something already running without root. Three portable options, in order of reliability: a root
manager’s own foreground service with retries; Termux:Boot
(~/.termux/boot/, GPL-3.0 addon, fires after boot as the app user); or a
Tasker/MacroDroid boot profile that runs the payload binary.
All three have the same weakness: Android’s background restrictions. Termux and the trigger app must both be exempt from battery optimisation, or the boot event is dropped — this is the usual reason a working setup silently stops re-rooting.
They cannot unlock a bootloader, cannot make a payload work on a build it was not built for, and cannot survive a factory reset. A payload that panics the kernel will panic it again on every boot trigger, so a firmware guard in front of the trigger matters more than the trigger itself.
verify before you run
Nothing here is custom-tested by us unless it says hardware-verified. Five minutes of checking beats a patched kernel:
# 1. what are you actually running?
adb shell getprop ro.product.model
adb shell getprop ro.boot.bootloader # the build the payload must name
adb shell uname -r # the kernel the module was built for
# 2. does the payload name THIS build, or only the model?
# read its README / support feed and compare to the two lines above
# 3. if the project publishes hashes, check them before running
sha256sum payload
# 4. keep the stock firmware for your exact build — it is the only way back
1. The payload names your exact build, not your model.
2. Your kernel release matches what it was built for.
3. It publishes SHA-256 per artifact — compare before running.
4. The licence is readable (Apache-2.0 / GPL-3.0). Closed blobs are not auditable.
5. You have the stock firmware for your build. That is the recovery plan.
why this is an index, not a download mirror
Repackaging someone else's exploit and KernelSU build under our domain would make us the trust anchor for code we did not write and cannot test on your device. That is exactly how supply chains break. So this page tells you what exists, what it covers, who made it, and how to check it — and the download happens at the source that signs its own releases.
The single exception is our own Fold 6 payload, because it is ours and we can prove it works on the one build it targets.
machine-readable
The same catalogue is published as JSON so tools can consume it without scraping this page. Unbolt Manager bundles a copy at build time, so the list still works offline.
assets/payloads.json Submit a payload
Spotted a payload we missed, or one that has gone stale or unsafe? Send it and we will add it with credit — or mark it, if it has stopped being safe to run.