Outil de root Android pour Samsung Galaxy S25 Ultra (SM-S938B) qui enchaîne DirtyFrag CVE-2026-43284 et CVE-2026-43499 pour obtenir le root automatiquement au démarrage via KernelSU.
Fork de diabl0w/DFRoot, spécialement adapté pour Samsung Galaxy S25 Ultra (SM-S938B / pa3q), interface et sortie d'exécution entièrement en chinois.
Deux chaînes, une seule interface :
Méthode Vulnérabilité Caractéristiques Canal rapide DirtyFrag (CVE-2026-43284) Celle du DFRoot amont, quelques secondes à quelques dizaines de secondes Manuel CVE-2026-43499 Probabiliste, échelle à trois tours, jusqu'à une quinzaine de minutes Par défaut « Auto » : exécute d'abord le canal rapide, et s'il échoue, enchaîne automatiquement sur la méthode manuelle.
En une phrase : obtention automatique du root au démarrage. À chaque démarrage, on tente d'abord le canal rapide pendant quelques secondes ; en cas d'échec, on enchaîne automatiquement sur la chaîne manuelle, avec trois tours de tentatives selon le principe « rapide → stable → patient ».
Une fois le root obtenu, deux commandes cmd connectivity sont également exécutées automatiquement (pour supprimer les publicités de l'« Installateur de packages » Samsung), et les commandes, sorties et codes de retour sont tous consignés dans le journal de l'interface — voir la section 5 « Configuration des publicités de l'installateur ». À partir de la v1.8, ces deux commandes sont écrites comme script de démarrage de KernelSU, et seront exécutées par KernelSU lui-même en root à chaque démarrage, sans avoir à ouvrir l'application ni à passer par une fenêtre d'autorisation.
Cannot run program "su": error=2, No such file or directory :
la v1.8, pour éviter un redémarrage supplémentaire, avait retiré le --soft-reboot passé à ksud ; or le su de KernelSU est précisément monté sur /system/bin/su par le module noyau à la phase post-fs-data, et le late-load de ksud n'exécute que les phases
late-load / post-mount / service / boot-completed (source KernelSU
userspace/ksud/src/late_load.rs) —— sans redémarrer le framework, ce point de montage n'apparaîtra jamais lors de ce démarrage, et su -c … dans l'application donnera forcément error=2. Ces deux problèmes ont la même cause racine ;KsudChannel) —— l'APK embarque une copie supplémentaire de ksud
(libksud.so, placé dans jniLibs/arm64-v8a/, installé dans nativeLibraryDir, l'App peut directement l'execve),
utilise libksud.so debug su pour ouvrir un shell root, les commandes étant écrites dans son stdin. L'élévation de privilèges passe par l'ioctl(KSU_IOCTL_GRANT_ROOT) du noyau, sans dépendre de /system/bin/su, sans fenêtre d'autorisation, et sans redémarrer le framework système ;* root 通道：helper=…，ksud=可用，su=…, ce qui permet de voir d'un coup d'œil où ça bloque ;su, on ajoute /data/adb/ksu/bin, /debug_ramdisk, /data/adb/magisk, /data/adb/ap/bin
au PATH, et SU_PATHS est étendu à 8 entrées (certaines variantes de KernelSU ne placent su que dans ces répertoires).--soft-reboot à ksud. Auparavant, ce paramètre faisait redémarrer le framework système une fois après l'installation de ksud —— ce que l'utilisateur voyait était « un redémarrage automatique après le boot » ; pire encore, ce redémarrage interrompait le processus de l'application ainsi que la « configuration des publicités de l'installateur » en cours d'exécution ;su au moment du boot
(à ce moment-là KernelSU n'est pas encore prêt, et sur appareil réel cela échouait à chaque démarrage, nécessitant d'ouvrir manuellement KernelSU puis l'application
pour que ça fonctionne). Désormais les deux mêmes commandes sont écrites dans /data/adb/service.d/dfroot-ads.sh, et KernelSU l'exécutera en root à chaque démarrage
—— sans passer par l'application, sans passer par su, sans aucune fenêtre d'autorisation ;cmd connectivity,
avec commandes, sorties et codes de retour tous consignés dans le journal de l'interface (une exécution réussie produit toujours une sortie) ;Celle fournie par le DFRoot amont, tout le code se trouve dans app/src/main/jni/ (exp.c + deux segments de shellcode +
le module noyau dans dirtyfrag-lkm/), compilé en libexp.so et appelé directement par l'App :
splice() pour modifier le page cache d'un fichier en lecture seule ;/vendor/lib64/libstagefrighthw.so puis finit_module pour le charger,
et passage de SELinux en permissive ;libc.so / libc++.so, lancement du ksud embarqué via le domaine de modprobe,
late-load de KernelSU.Rapide (quelques secondes), au prix de laisser une trace « déjà armé pour ce cycle » dans /dev/df,
et son chemin d'installation de ksud diffère de celui de la méthode manuelle (voir section 7).
Les trois binaires sont précompilés (inchangés octet par octet) :
| Fichier | Emplacement | Rôle |
|---|---|---|
libcve43499root.so | jniLibs/arm64-v8a/ | helper, ELF exécutable, execve direct par l'App, pas besoin de Shizuku |
cve-2026-43499-app.so | assets/payloads/ | payload, dlopen par le helper puis exécution de la vulnérabilité |
ksud-s25u-kdp | assets/payloads/ | KernelSU lui-même (ksud + kernelsu.ko embarqué) |
1. helper --run-payload <payload> <helper> <log> obtention du root (probabiliste)
2. helper -c "cp ksud …" dépôt de ksud dans /data/local/tmp
3. helper --late-load bind mount /system/bin/logcat,
puis exec "logcat late-load …" pour installer KernelSU
Critère de succès : présence simultanée de exploit completed et done=1 root=1 dans le journal.
La méthode « Manuelle » de l'interface exécute cette chaîne (la méthode « Auto » l'enchaîne également lorsque le canal rapide échoue).