hmascs/ksurootEin Rooting-Tool für den Android-Kernel mit einem Klick, das CVE-2026-43499 ausnutzt, um KernelSU zu installieren – mit offiziellen, gebündelten und benutzerdefinierten .so-Payload-Quellen.
⚠️ Hinweis: Die Scheduling-Strategie der Blue-Factory-Modelle ist recht strikt, beim Rechte-Eskalieren werden Kindprozesse leicht vom System recycelt. Bitte aktiviere zuerst in den „Entwickleroptionen" die Option „Kindprozesse nicht einschränken", bevor du die Rechte-Eskalation ausführst – die Erfolgsrate ist dann höher.
Ein Ein-Klick-KernelSU-Rechte-Eskalationswerkzeug auf Basis der Kernel-Schwachstelle CVE-2026-43499 (GhostLock).
Dieser Branch basiert auf KSuRoot und synchronisiert vollständig das Hauptlinien-Update von Root-My-Galaxy v0.2.6 und ergänzt darauf aufbauend Payload-Build, integrierte Hersteller-Payloads sowie eine komplette Liquid-Glass-UI.
Mod von hmascs · Version 4.1.2 · Apache-2.0 Repository: https://github.com/hmascs/KSuRoot
vr.ko markiert Tasks, die von der App stammen. Dieser Offset hat zwei Varianten, 0x04 / 0x06, und ist zur Kompilierzeit in die Payload eingebacken, lässt sich also nicht patchen. Erschwerend kommt hinzu, dass zwei vr.ko-Dateien desselben Geräts jeweils eine andere Variante haben (im vendor_boot des Y300 Pro+ liegen zwei, mit identischer srcversion) –
wählt man falsch, äußert sich das als „falsche Bytes gelöscht, Markierung nicht entfernt, Kindprozess wird weiterhin gekillt", während im Log alles normal aussieht.
Jetzt verlangt die Blue-Factory-Lösung von dir ein vendor_boot.img: Die App liest aus der darin tatsächlich geladenen lib/modules/vr.ko den echten Offset dieses Geräts aus und schreibt die Payload um. Alle vier mitgelieferten/selbstgebauten Bibliotheken
(libbaseline_6_1 / libbaseline_6_12 / libbs / libionstack) erzwingen ihre eigene Stufe; wählt man falsch, wird man vom Null-Treffer-Gate sofort gestoppt, statt ein unverändert kopiertes Artefakt zu erhalten.
Zusätzlich neu: „Vollständiges Flash-Paket importieren" – wähle direkt das heruntergeladene OTA-Zip oder fastboot-tgz, es extrahiert selbst boot und vendor_boot, du musst weder vorher entpacken noch manuell extrahieren.
⚠️ Das vollständige Paket muss komplett in den App-Cache kopiert werden, um wahlfrei lesen zu können (das ZIP-Zentralverzeichnis liegt am Paketende, und die SAF-URI lässt sich nicht in eine File umwandeln). Bei zu wenig Speicher wird sofort abgelehnt, nach dem Extrahieren wird der Cache umgehend gelöscht.
4.1.2 = 4.1.0 + 19 Commits. Diese Commits lagen ursprünglich auf dem Branch fix/baseline-routing und sind nun in main eingeflossen. Das bereits veröffentlichte 4.1.0-Installationspaket enthält sie nicht – jeder der folgenden Punkte wurde erst danach behoben.
| # | Defekt | Folge |
|---|---|---|
| 1 | VR_TAG_A_OFF von 6.1 mit 0x06 belegt (tatsächlich sollte es 0x04 sein) | Auf Blue-Factory-6.1-Modellen wird die Markierung kein einziges Byte entfernt, während der Selbsttest Erfolg meldet. Das äußert sich als „nach erfolgreicher Rechte-Eskalation wird der Kindprozess sofort gekillt", ohne dass man den Grund erkennt |
| 2 | Die kallsyms-Offset-Tabelle verwendete negative Modulo-Berechnung (direkte Übersetzung der Python-Semantik) | Bei 6.4+-Kerneln schlägt die gesamte Stufe fehl, die Basisadresse wird aus einem ASCII-Textstück bezogen |
| 3 | Das Kriterium der Offset-Tabelle prüfte nur „die ersten drei Einträge sind monoton" | Nahezu keine Unterscheidungskraft (jede Position in der Tabelle ist monoton); wurde geändert auf Prüfung der Form der Tabelle |
| 4 | BASELINE_6_12.imageBase mit der Zielbasisadresse belegt | Konstruktionsstellen in Form absoluter Adressen wurden alle übersehen (39 Stellen → 9 Stellen) |
| 5 | Bei nicht ausgerichteten Symbolen wurde nur das Artefakt geleert, gate blieb aber Proceed | blocked=false und Artefakt 0 B, die UI zeigt keinen Blockier-Dialog |
| 6 | Der Fallback von FopsSlot wurde nie genutzt | Wird die Tabelle nicht gefunden, wird direkt aufgegeben, ein Rückgriff auf Ersatzsymbole ist nicht möglich |
TARGET_ASHMEM_FOPS_UNSYMBOLED)07-文档/6.1-6.12-双方案清单.md0x04, 6.6 / 6.12 = 0x06 (die vr.ko aus den Hersteller-Firmwares von drei echten Geräten)载荷构建/): zuvor gab es im Repository 15 Stellen, die auf ein nicht existierendes Verzeichnis verwiesenDas Ergebnis eines Build-Laufs auf dem X100 Pro (6.1.145) ist:
偏移解析: 28 / 28 项
需要改写: 26 项 · 校验通过: 0 项
该动态库未引用 26 项偏移
Das ist nicht „nichts zu ändern", sondern „diese beiden Dinge gehören nicht zusammen". Die Grundursache ist, dass zwei unabhängige Pfade falsch abgebogen sind:
| Was gewählt wird | Wonach gewählt wird | Auf 6.1.145 gewählt |
|---|---|---|
| Basisbibliothek | Strukturfamilie (F6_1) | libbaseline_6_1.so (alter Wert aus baseline-6.1-tokay/target.h) |
| Stufe | Drei-Stufen-Routing (Kernel-String) | up-6-1-145-… (alter Wert aus GhostLocks offsets.h) |
Die Patch-Methode ist „den alten Wert aus der Stufe nehmen und im .so nach dem Literal suchen". Die beiden alten Werte haben keine Schnittmenge, deshalb passt keiner der 26 Einträge, und das Ergebnis ist effektiv eine unveränderte Kopie der Basisbibliothek.
Warum das ursprüngliche harte Gate nicht gegriffen hat: Das Kriterium von hasFailures ist changed && !ok && !absent ——
absent ist explizit ausgeschlossen. Diese Begründung („die alte .so-Version hat möglicherweise keinen entsprechenden Codepfad") gilt für einzelne Schlüssel,
aber nicht für „alle Schlüssel sind absent".
Zwei Lösungsansätze:
libbaseline_6_1.so / libbaseline_6_12.so)
müssen mit ihrer eigenen Stufe kombiniert werden (baseline-6-1-tokay / baseline-6-12-honor),
die Upstream-up-*-Stufen gelten nur für die Upstream-.so. Neu hinzugefügt: BaselineLibraries.profileIdForLibrary().SpecOutcome ein kind-Feld hinzugefügt.Die Regressionstests befinden sich in BaselineLibraryPairingTest (4 Stück), wobei einer direkt behauptet, dass die beiden alten Werte keine Schnittmenge haben ——
damit wird „warum die Paarung zwingend ist" zu einer ausführbaren Tatsache.