KSuRoot

⚠️ Note: Blue factory models have fairly strict scheduling policies, and child processes are easily reclaimed by the system during privilege escalation. Please first enable "Stop restricting child processes" in "Developer options" before performing privilege escalation for a higher success rate.

A one-click KernelSU privilege escalation tool based on the CVE-2026-43499 (GhostLock) kernel vulnerability.

This branch is based on KSuRoot as a blueprint, fully syncing the Root-My-Galaxy v0.2.6 mainline update, and on top of that adds payload building, built-in vendor payloads, and a complete liquid glass UI.

Mod by hmascs · Version 4.1.2 · Apache-2.0 Repository: https://github.com/hmascs/KSuRoot

---

What's changed in 4.1.2

New in this round (4.1.2): reading the vr.ko tag offset from the image

vr.ko tags tasks coming from apps, and that offset has two variants, 0x04 / 0x06, and it is baked into the payload at compile time, so it cannot be patched. What's worse is that two vr.ko files on the same device each have a different one (the Y300 Pro+'s vendor_boot contains two copies, with identical srcversion) — picking the wrong one manifests as "clearing the wrong bytes, the tag isn't erased, and child processes still get killed", while the logs show everything as normal.

Now the Blue factory solution requires you to provide a vendor_boot.img: the app reads the actual offset for this device from the actually loaded lib/modules/vr.ko inside it, then rewrites the payload. All four bundled/self-built libraries (libbaseline_6_1 / libbaseline_6_12 / libbs / libionstack) are forced to match their own profile, and picking the wrong one will be stopped on the spot by the zero-hit gate, rather than giving you a byte-for-byte copy of the artifact.

Also newly added: "Import full flash package": directly select the OTA zip or fastboot tgz you downloaded, and it extracts boot and vendor_boot itself, so you don't need to unzip first or extract manually.

⚠️ The full package must be copied entirely into the app cache to allow random reads (the ZIP central directory is at the end of the package, and SAF's uri cannot be turned into a File). If there isn't enough space it will refuse on the spot, and the cache is deleted immediately after extraction.

4.1.2 = 4.1.0 + 19 commits. These commits were originally parked on the fix/baseline-routing branch, and have now been merged into main. The released 4.1.0 installer does not include them — every item below was fixed only after that.

Silent failures that were fixed

#	Defect	Consequence
1	6.1's VR_TAG_A_OFF was set to 0x06 (measured value should be 0x04)	On Blue factory 6.1 models the tag was not erased by a single byte, while the self-check reported success. It manifests as "child processes are killed immediately after successful privilege escalation", with no way to tell this was the cause
2	The kallsyms offset table location used negative modulo (a direct translation of Python semantics)	The entire profile failed on 6.4+ kernels, with the base address landing on a stretch of ASCII text
3	The offset table criterion only checked that "the first three entries are monotonic"	Almost zero discriminating power (any position in the table is monotonic); changed to checking the table's shape
4	BASELINE_6_12.imageBase was set to the target base address	All construction sites in absolute-address form were missed (39 → 9)
5	When symbols didn't line up it only nulled the artifact, while gate remained Proceed	blocked=false with a 0 B artifact, and the UI didn't pop up the blocking dialog
6	FopsSlot's fallback was never actually used	If the table wasn't found it just gave up, with no fallback to the alternate symbol

Feature completion

• 6.12 actually works now: ashmem became a Rust implementation in 6.12, with all symbol names mangled → changed to reading it at runtime from the miscdevice's fops slot (TARGET_ASHMEM_FOPS_UNSYMBOLED)
• 6.1 / 6.12 are usable under both the generic / Blue factory solutions (the four combinations have 16 / 16 / 13 / 13 profiles respectively), see the archive 07-文档/6.1-6.12-双方案清单.md for the list
• vr.ko tag offset measured per device: 6.1 = 0x04, 6.6 / 6.12 = 0x06 (the vr.ko in the vendor firmware of three real devices)
• Payload build recipes included in the repo (载荷构建/): previously the repo had 15 references pointing to a directory that didn't exist

★ Caught on a real device: on 6.1, none of the 26 offsets were changed, and it still produced an artifact

The result of running the build on an X100 Pro (6.1.145) was:

偏移解析: 28 / 28 项
需要改写: 26 项 · 校验通过: 0 项
该动态库未引用 26 项偏移

This isn't "nothing to change," it's "these two things aren't a matched set." The root cause is that two independent paths diverged:

What to choose	Chosen by	What gets picked on 6.1.145
Base library	Struct family (F6_1)	libbaseline_6_1.so (old value from baseline-6.1-tokay/target.h)
Profile	Three-tier routing (kernel string)	up-6-1-145-… (old value from GhostLock's offsets.h)

The patching approach is "take the old value from the profile and search for the literal in the .so." The two sets of old values have zero intersection, so none of the 26 items match anywhere, and the output is effectively a verbatim copy of the base library.

Why the original hard gate didn't catch it: hasFailures is judged by changed && !ok && !absent — absent is explicitly excluded. That rationale ("older .so versions may not have the corresponding code path") holds for individual keys, but not for "all keys are absent."

Two fixes:

1. Force library and profile to be same-origin: self-built family baselines (libbaseline_6_1.so / libbaseline_6_12.so) must be paired with their own profiles (baseline-6-1-tokay / baseline-6-12-honor); upstream up-* profiles only apply to the upstream .so. Added BaselineLibraries.profileIdForLibrary().
2. Zero-hit hard gate: if not a single offset spec lands on a site, stop packaging (the base-address one doesn't count — even when nothing matches it often changes, which would mask "not a single offset was changed"). For this, a kind field was added to SpecOutcome.

Regression cases are in BaselineLibraryPairingTest (4 cases), one of which directly asserts that the two sets of old values have no intersection — turning "why pairing is mandatory" into an executable fact.

Dynamic libraries: the "tapped but nothing happens" class of problems

#	Defect	Consequence
1	"Payload build → use as payload" uses the in-memory artifact; after the process is reclaimed outputLibrary is null, and the old code was ?: return	Tapping does nothing at all: no Toast, no error, button unchanged — what the user sees is "tapped but nothing happens"
2	PayloadStaging's cache key is "same name + same length"	Custom payloads are always named payload.so in the private directory, so swapping in a payload with exactly the same byte count silently reuses the previous one
3	shizukuStage's cache key is length only	The same pitfall is stepped into again on the Shizuku path
4	Only one custom payload can be stored	Importing a second one overwrites the first, with no prompt
5	All files live in the app's private directory	Users can't see them in a file manager, and can't back them up or organize them themselves

Dynamic library repository: Download/动态库/<机型>/<文件名>.so