Strumento di root per Android per Samsung Galaxy S25 Ultra (SM-S938B) che concatena DirtyFrag CVE-2026-43284 e CVE-2026-43499 per ottenere i privilegi di root automaticamente all'avvio tramite KernelSU.
Fork di diabl0w/DFRoot, adattato specificamente per Samsung Galaxy S25 Ultra (SM-S938B / pa3q), con interfaccia e output di esecuzione interamente in cinese.
Due percorsi, un'unica interfaccia:
Soluzione Vulnerabilità Caratteristiche Canale rapido DirtyFrag (CVE-2026-43284) Quello di DFRoot upstream, da pochi secondi a qualche decina di secondi Manuale CVE-2026-43499 Probabilistico, scaletta a tre round, fino a una decina di minuti Predefinito "Automatico": esegue prima il canale rapido, se non riesce passa automaticamente alla soluzione manuale.
In una frase: ottenere root automaticamente all'avvio. Ad ogni avvio prova prima il canale rapido per pochi secondi; se non riesce, passa automaticamente al percorso manuale, riprovando per tre round secondo "rapido → stabile → paziente".
Dopo aver ottenuto root, esegue automaticamente anche due comandi cmd connectivity (per rimuovere la pubblicità del "Programma di installazione pacchetti" di Samsung),
comandi, output e codici di uscita vengono tutti registrati nel log dell'interfaccia —— vedi la sezione 5 "Impostazioni pubblicità programma di installazione".
Dalla v1.8 questi due comandi vengono scritti come script di avvio di KernelSU, e da quel momento ad ogni avvio sarà KernelSU stesso a eseguirli come root,
senza dover aprire l'app né mostrare finestre di autorizzazione.
Cannot run program "su": error=2, No such file or directory:
la v1.8, per evitare un ulteriore riavvio, aveva rimosso --soft-reboot da ksud; ma il su di KernelSU
è montato dal modulo kernel su /system/bin/su solo nella fase post-fs-data, mentre il late-load di ksud esegue
solo le fasi late-load / post-mount / service / boot-completed (sorgente KernelSU
userspace/ksud/src/late_load.rs) —— senza riavviare il framework, in questo ciclo di avvio il punto di mount
non apparirà mai, e su -c … nell'app darà inevitabilmente error=2. Questi due problemi hanno la stessa causa radice;KsudChannel) —— nell'APK è inclusa una copia di ksud
(libksud.so, posizionata in jniLibs/arm64-v8a/, installata in nativeLibraryDir, l'App può eseguirla direttamente con execve),
si apre una root shell con libksud.so debug su, e i comandi vengono scritti nel suo stdin. L'elevazione passa attraverso
l'ioctl(KSU_IOCTL_GRANT_ROOT) del kernel, senza dipendere da /system/bin/su, senza finestre di autorizzazione e senza riavviare il framework di sistema;* root 通道：helper=…，ksud=可用，su=…, così si vede a colpo d'occhio dove si blocca;su, vengono aggiunti al PATH /data/adb/ksu/bin, /debug_ramdisk, /data/adb/magisk, /data/adb/ap/bin,
e SU_PATHS è stato esteso a 8 voci (alcune varianti di KernelSU mettono su solo in queste directory).--soft-reboot a ksud. In precedenza questo parametro faceva sì che ksud,
dopo l'installazione, riavviasse il framework di sistema —— l'utente vedeva "dopo l'avvio si riavvia da solo"; peggio ancora, questo riavvio
interrompeva il processo dell'app insieme alle "Impostazioni pubblicità programma di installazione" in esecuzione;su (in quel momento KernelSU non è ancora pronto, e su dispositivo reale falliva ad ogni avvio, richiedendo di aprire manualmente KernelSU e poi l'app).
Ora gli stessi due comandi vengono scritti in /data/adb/service.d/dfroot-ads.sh, e KernelSU li eseguirà come root ad ogni avvio
—— senza passare dall'app, senza passare da su, senza alcuna finestra di autorizzazione;cmd connectivity,
con comandi, output e codici di uscita tutti registrati nel log dell'interfaccia (in caso di successo c'è sempre output);Quello incluso in DFRoot upstream, tutto il codice in app/src/main/jni/ (exp.c + due shellcode +
il modulo kernel in dirtyfrag-lkm/), compilato in libexp.so e chiamato direttamente dall'App:
splice() per modificare la page cache di un file di sola lettura;/vendor/lib64/libstagefrighthw.so e caricamento con finit_module,
impostando SELinux in permissive;libc.so / libc++.so, avvio del ksud integrato tramite il dominio di modprobe,
late-load di KernelSU.Veloce (pochi secondi), il prezzo è che lascia una traccia "già armato in questo ciclo" in /dev/df,
e il percorso di installazione del suo ksud è diverso da quello manuale (vedi sezione 7).
I tre binari sono tutti precompilati (byte per byte invariati):
| File | Posizione | Funzione |
|---|---|---|
libcve43499root.so | jniLibs/arm64-v8a/ | helper, ELF eseguibile, l'App lo esegue direttamente con execve, non richiede Shizuku |
cve-2026-43499-app.so | assets/payloads/ | payload, eseguito dall'helper dopo dlopen per sfruttare la vulnerabilità |
ksud-s25u-kdp | assets/payloads/ | KernelSU stesso (ksud + kernelsu.ko incorporato) |
1. helper --run-payload <payload> <helper> <log> ottenere root (probabilistico)
2. helper -c "cp ksud …" copiare ksud in /data/local/tmp
3. helper --late-load bind mount /system/bin/logcat,
poi exec "logcat late-load …" per installare KernelSU
Criterio di successo: nel log compaiono contemporaneamente exploit completed e done=1 root=1.
La soluzione "Manuale" nell'interfaccia esegue proprio questo (anche la soluzione "Automatica", se il canale rapido non riesce, la esegue di seguito).
Pressione manuale del pulsante (nell'interfaccia)
└─ Esegue nel processo corrente: soluzione "Automatico" = canale rapido → manuale; soluzione "Manuale" = direttamente manuale