Android-Root-Tool für das Samsung Galaxy S25 Ultra (SM-S938B), das DirtyFrag CVE-2026-43284 und CVE-2026-43499 verkettet, um beim Booten automatisch über KernelSU Root zu erlangen.
Ein Fork von diabl0w/DFRoot, speziell angepasst für Samsung Galaxy S25 Ultra (SM-S938B / pa3q), Oberfläche und Laufzeitausgaben vollständig auf Chinesisch.
Zwei Pfade, eine Oberfläche:
Verfahren Schwachstelle Merkmale Schnellkanal DirtyFrag (CVE-2026-43284) Der Pfad des Upstream-DFRoot, Sekunden bis einige zehn Sekunden Manuell CVE-2026-43499 Probabilistisch, dreistufige Leiter, bis zu über zehn Minuten Standardmäßig „Automatisch": zuerst Schnellkanal, falls dieser scheitert, automatisch manuelles Verfahren.
In einem Satz: Beim Booten automatisch Root erlangen. Bei jedem Start wird zuerst für einige Sekunden der Schnellkanal versucht; falls dieser scheitert, wird automatisch der manuelle Pfad angehängt und nach „Schnell → Stabil → Geduldig" in drei Runden wiederholt.
Nach Erlangung von Root werden außerdem automatisch zwei cmd connectivity-Befehle ausgeführt (um die Werbung des Samsung „Paketinstallationsprogramms" zu entfernen),
Befehl, Ausgabe und Exit-Code werden gleichermaßen im Oberflächenprotokoll ausgegeben —— siehe Abschnitt 5 „Installer-Werbungseinstellungen".
Ab v1.8 werden diese beiden Befehle als KernelSU-Boot-Skript geschrieben, danach bei jedem Start von KernelSU selbst mit Root
ausgeführt, ohne die App öffnen oder Autorisierungsdialoge bestätigen zu müssen.
Cannot run program "su": error=2, No such file or directory:
v1.8 hat, um einen zusätzlichen Neustart zu vermeiden, das --soft-reboot an ksud entfernt; KernelSUs su wird jedoch
vom Kernelmodul erst in der post-fs-data-Phase nach /system/bin/su eingehängt, und der late-load von ksud führt nur
die Phasen late-load / post-mount / service / boot-completed aus (KernelSU-Quellcode
userspace/ksud/src/late_load.rs) —— ohne Neustart des Frameworks erscheint dieser Einhängepunkt im aktuellen Boot-Zyklus nie,
und su -c … in der App führt zwangsläufig zu error=2. Diese beiden Probleme haben dieselbe Ursache;KsudChannel) —— die APK enthält eine zusätzliche ksud-Kopie
(libksud.so, abgelegt in jniLibs/arm64-v8a/, installiert in nativeLibraryDir, die App kann direkt execve ausführen),
mit libksud.so debug su wird eine Root-Shell geöffnet, Befehle werden in deren stdin geschrieben. Die Rechteausweitung läuft über den Kernel-
ioctl(KSU_IOCTL_GRANT_ROOT), unabhängig von /system/bin/su, ohne Autorisierungsdialog und ohne Neustart des System-Frameworks;* root 通道：helper=…，ksud=可用，su=… ausgegeben, sodass sofort sichtbar ist, wo es hängt;su werden /data/adb/ksu/bin, /debug_ramdisk, /data/adb/magisk, /data/adb/ap/bin
in den PATH aufgenommen, SU_PATHS wurde ebenfalls auf 8 Einträge erweitert (manche KernelSU-Varianten legen su nur in diesen Verzeichnissen ab).--soft-reboot mehr übergeben. Früher führte dieser Parameter dazu, dass ksud nach der Installation
das System-Framework einmal neu startete —— für den Benutzer sichtbar als „nach dem Booten startet es sich selbst noch einmal neu"; schlimmer noch, dieser Neustart
unterbrach den App-Prozess samt der gerade laufenden „Installer-Werbungseinstellungen";su ausgeführt wird
(zu diesem Zeitpunkt ist KernelSU noch nicht bereit, auf realen Geräten schlug dies bei jedem Start fehl, man musste manuell KernelSU und dann die App öffnen).
Jetzt werden dieselben zwei Befehle in /data/adb/service.d/dfroot-ads.sh geschrieben, KernelSU führt sie bei jedem Start
mit Root aus —— ohne die App, ohne su, ohne jeglichen Autorisierungsdialog;cmd connectivity-Befehle ausgeführt,
Befehl, Ausgabe und Exit-Code werden vollständig im Oberflächenprotokoll ausgegeben (bei erfolgreicher Ausführung gibt es immer eine Ausgabe);Der vom Upstream-DFRoot mitgelieferte Pfad, der gesamte Code liegt in app/src/main/jni/ (exp.c + zwei Shellcode-Abschnitte +
das Kernelmodul in dirtyfrag-lkm/), kompiliert zu libexp.so und wird von der App direkt aufgerufen:
splice() zum Ändern des Page-Cache einer schreibgeschützten Datei;/vendor/lib64/libstagefrighthw.so geschrieben und dann mit finit_module geladen,
SELinux wird auf permissive gesetzt;libc.so / libc++.so, über die Domäne von modprobe wird das mitgelieferte ksud gestartet,
late-load KernelSU.Schnell (Sekunden), der Preis ist, dass es in /dev/df Spuren von „in diesem Zyklus bereits aufgestellt" hinterlässt,
und sein ksud-Installationspfad unterscheidet sich von dem des manuellen Pfads (siehe Abschnitt 7).
Alle drei Binärdateien sind vorkompiliert (byteweise unverändert):
| Datei | Ort | Funktion |
|---|---|---|
libcve43499root.so | jniLibs/arm64-v8a/ | helper, ausführbare ELF, App führt direkt execve aus, kein Shizuku erforderlich |
cve-2026-43499-app.so | assets/payloads/ | payload, wird vom helper dlopen und führt die Schwachstelle aus |
ksud-s25u-kdp | assets/payloads/ | KernelSU selbst (ksud + eingebettetes kernelsu.ko) |
1. helper --run-payload <payload> <helper> <log> Root erlangen (probabilistisch)
2. helper -c "cp ksud …" ksud nach /data/local/tmp ablegen
3. helper --late-load bind mount /system/bin/logcat,
dann exec "logcat late-load …" zur Installation von KernelSU
Erfolgsfeststellung: im Protokoll erscheinen gleichzeitig exploit completed und done=1 root=1.
Das Verfahren „Manuell" in der Oberfläche führt genau diesen Pfad aus (das Verfahren „Automatisch" führt ihn ebenfalls aus, wenn der Schnellkanal scheitert).