Skip to content
KitploitKITPLOIT
OutilsBlog
Soumettre
OutilsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
Root-My-Galaxy-S938B — KSU installer pour les firmwares Samsung Galaxy pris en charge avec CVE-2026-43499 | Kitploit
Outils/GitHubGitHub/asarr22/root-my-galaxy-s938b
Sécurité AndroidEscalade de PrivilègesExploitationPost-ExploitationSécurité MobileDéveloppement de Charges UtilesAnalyse de Micrologiciel
GitHubasarr22/root-my-galaxy-s938b

Root-My-Galaxy-S938B

KSU installer pour les firmwares Samsung Galaxy pris en charge avec CVE-2026-43499

Voir le dépôt
1il y a 1 moisPas encore vérifié

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager

Root My Galaxy — S938B

Root My Galaxy est un installateur basé sur le profil du firmware pour un root temporaire via KernelSU sur les builds Samsung pris en charge. Ce fork est maintenu pour le Galaxy S25 Ultra SM-S938B exécutant :

root@kitploit:~
Build:  BP4A.251205.006.S938BXXSBCZG3
Kernel: 6.6.98-android15-8-pd6ff1cd-abogkiS938BXXSBCZG3-4k

Télécharger le dernier APK signé

Le code source de l'application, le flux de firmware et le fournisseur Zygisk sont intentionnellement séparés :

  • application : ce dépôt ;
  • flux de payloads : Root-My-Galaxy-Payloads-S938B ;
  • fournisseur Zygisk post-démarrage testé : NeoZygisk-PostBoot.

Modèle de sécurité

Le root est temporaire. Un redémarrage complet ou un arrêt supprime la session KernelSU active, bien que les modules installés restent dans /data/adb/modules pour la prochaine exécution réussie de l'exploit.

L'application fait automatiquement correspondre la version complète du noyau, l'ID d'affichage du build, le SDK, l'ABI et la taille de page. Le mode avancé permet une sélection manuelle du profil, mais un modèle ou une famille de noyau similaire n'équivaut pas à un profil de firmware exact.

Utilisez uniquement sur des appareils que vous possédez ou pour lesquels vous êtes explicitement autorisé à effectuer des tests.

Procédure de root

  1. Installez le dernier APK signé depuis Releases.
  2. Exécutez le flux d'exploit simple et attendez que KernelSU soit signalé comme actif.
  3. Ouvrez KernelSU Manager et confirmez l'accès root.
  4. Pour une utilisation exclusivement KernelSU, arrêtez-vous ici.
  5. Pour Zygisk, installez exactement un fournisseur et les modules qui en dépendent.
  6. Lors d'une première installation dans une session noyau propre, utilisez Soft Reboot depuis KernelSU Manager une fois.
  7. Attendez le retour d'Android et vérifiez le fournisseur et les modules dépendants.

N'utilisez pas le pont automatique ReZygisk retiré et n'émettez pas de commande ciblée ctl.restart zygote sur le firmware Samsung validé. Les tests matériels ont montré que ce chemin peut faire entrer l'appareil dans l'état d'échec Device Services Uninstalled de Samsung et nécessiter un redémarrage complet.

Les mises à jour du fournisseur nécessitent un redémarrage complet

N'installez pas une nouvelle version du fournisseur Zygisk sur un moniteur actif puis n'appuyez pas sur KernelSU Soft Reboot dans le même démarrage du noyau. Un test matériel a reproduit un état stopped(zygote crashed) lorsqu'un ancien moniteur/runtime a survécu tandis que des fichiers de fournisseur plus récents étaient activés.

Après la mise à jour de Zygisk Next ou NeoZygisk PostBoot :

  1. installez la mise à jour mais ne faites pas de Soft Reboot ;
  2. effectuez un redémarrage complet de l'appareil ;
  3. exécutez à nouveau l'exploit simple Root My Galaxy ;
  4. utilisez KernelSU Manager Soft Reboot une fois ;
  5. vérifiez le fournisseur.

Après tout rapport zygote crashed, moniteur supprimé, non-concordance de génération ou FULL_REBOOT_REQUIRED, ne tentez pas un autre Soft Reboot dans cette session du noyau.

Choix Zygisk

Utilisez un seul fournisseur Zygisk à la fois.

Zygisk Next

Zygisk Next peut être utilisé comme fournisseur conventionnel. Installez son module KernelSU, configurez-le normalement, installez les modules dépendants tels que LSPosed ou Zygisk Assistant, puis effectuez un Soft Reboot depuis KernelSU Manager à partir d'une session post-exploit propre. Les mises à jour du fournisseur suivent le cycle de vie de redémarrage complet ci-dessus.

Zygisk Next est un projet distinct. La compatibilité et les changements de versions closed-source sont contrôlés par ses mainteneurs.

NeoZygisk PostBoot

Le fork NeoZygisk PostBoot maintenu a été validé matériellement sur S938BXXSBCZG3. Il prépare son runtime sous /dev/.neozygisk pour éviter que Samsung DEFEX bloque un zygote avec des identifiants root d'ouvrir la bibliothèque persistante sous /data/adb.

Séquence de première installation validée :

  1. terminez l'exploit simple Root My Galaxy ;
  2. installez ou activez NeoZygisk PostBoot ;
  3. installez ou activez les modules Zygisk Assistant et/ou LSPosed ;
  4. utilisez KernelSU Manager Soft Reboot une fois ;
  5. utilisez le bouton Action du module NeoZygisk pour la vérification en direct.

Une vérification réussie signale un zygote64 injecté, un zygiskd64 en cours d'exécution, un seul moniteur de même génération attaché à init, et le mappage en direct de /dev/.neozygisk/lib64/libzygisk.so.

N'installez pas NeoZygisk PostBoot à côté de Zygisk Next, ReZygisk ou d'un autre fournisseur utilisant le même cycle de vie Zygisk.

Intégrité des payloads

L'APK résout le commit actuel de igorcv88/Root-My-Galaxy-Payloads-S938B, télécharge support/targets-v2.json depuis ce commit immuable et réécrit chaque URL d'artefact vers le même commit. Le workflow de publication vérifie :

  • les métadonnées exactes de la cible pa3q-S938BXXSBCZG3 ;
  • que chaque URL appartient au dépôt de payloads maintenu ;
  • que chaque payload référencé existe et correspond à sa taille en octets déclarée ;
  • que l'application ne contient aucun point de terminaison de payload mutable en amont.

Mises à jour de l'APK signé

Les APK stables sont signés par GitHub Actions et publiés directement comme ressources sous Releases, sans wrapper d'artefact Actions. versionCode augmente à chaque exécution de publication, donc les APK ultérieurs peuvent mettre à jour les builds stables précédents sans les désinstaller, à condition que le certificat de signature soit inchangé.

La première migration depuis un APK signé en debug ou signé différemment peut encore nécessiter une désinstallation. Android n'accepte une mise à jour sur place que lorsque l'APK installé et l'APK entrant partagent le même certificat de signature.

Secrets de dépôt requis :

root@kitploit:~
KEYSTORE_BASE64
KEYSTORE_PASSWORD
KEY_ALIAS
KEY_PASSWORD

La même clé de signature peut techniquement signer plusieurs noms de package. Réutiliser la clé BatteryRemapper est valide, mais cela couple la sécurité des deux applications : une compromission de la clé affecte les mises à jour des deux packages.

Build de développement local

Prérequis :

  • Android Studio JBR 21 ;
  • Android SDK 37 ;
  • Android NDK 28 ou plus récent ;
  • CMake 3.22.1.
root@kitploit:~
$env:JAVA_HOME='C:\Program Files\Android\Android Studio\jbr'
.\gradlew.bat :app:assembleDebug

APK de debug local :

root@kitploit:~
app/build/outputs/apk/debug/app-debug.apk
Télécharger l’outil