Exploit unifié du BootROM pour Exynos 990 / Exynos9830

Outillage unifié CVE-2024-56426 pour les familles Exynos 990 Galaxy S20, S20 FE et Note20. L'exploit accepte les dix noms de modèles et les associe à six familles de bootloaders stock vérifiées.

[!CAUTION] Le bundle de clés suivi et les images générées sont compatibles avec le fusing. Le fusing est irréversible. Un téléphone fusé sur une clé ne peut démarrer que des images compatibles avec cette clé. Un mauvais modèle, une mauvaise révision de rollback, un mauvais ensemble de correctifs ou un mauvais bundle de clés peut laisser l'appareil dans une boucle de démarrage fusée. Utilisez des clés de développement et le payload UFS pendant l'itération. Ajoutez --no-fuse à chaque commande de préparation/signature sauf si le fusing avec clé personnalisée est explicitement souhaité.

Modèles pris en charge

Le modèle sélectionné contrôle à la fois l'ID de modèle BL1 et le TSV de patch LK spécifique au modèle. Runtime artifact contrôle quel firmware stock et quelles images fractionnées chiffrées sont utilisés par le preflight. Les quatre indicateurs non-5G qui utilisent des artefacts d'exécution 5G appariés corrigent également la vérification de l'ID de modèle de LK et le chemin de programmation de l'ID de modèle.

[!IMPORTANT] Sur les versions de firmware stock listées ci-dessous, G780F, N980F, N981B, N985F et N986B ne peuvent pas utiliser la méthode UH-to-BOOTLOADER pour entrer en EUB. Leurs bootloaders LK appellent Check_signinfo(), qui compare le BinaryName intégré à l'image (uh.bin) avec le nom de fichier attendu de la partition BOOTLOADER (sboot.bin). La discordance produit Binaryname has changed (uh.bin) -> (sboot.bin) et rejette le flash.

Utilisez les points de test spécifiques au modèle approprié pour entrer en EUB sur ces appareils au lieu de la méthode UH.

Indicateur de modèle	Artefact d'exécution	Firmware d'exécution	ID de modèle	EVT	Rollback	Testé	Méthode UH / entrée EUB
G780F	G780F	G780FXXSOFYJ1	0x154	11	24	❌	Bloqué — utilisez les points de test
G980F	G981B	G981BXXSNHYB1	0x143	11	23	✅	Pas de blocage de nom de fichier
G981B	G981B	G981BXXSNHYB1	0x13D	11	23	❌	Pas de blocage de nom de fichier
G985F	G986B	G986BXXSNHYB1	0x142	11	23	✅	Pas de blocage de nom de fichier
G986B	G986B	G986BXXSNHYB1	0x13C	11	23	✅	Pas de blocage de nom de fichier
G988B	G988B	G988BXXSNHYB1	0x13E	11	23	❌	Pas de blocage de nom de fichier
N980F	N981B	N981BXXSIHYH3	0x153	11	18	❌	Bloqué — utilisez les points de test
N981B	N981B	N981BXXSIHYH3	0x14E	11	18	❌	Bloqué — utilisez les points de test
N985F	N986B	N986BXXSIHYH3	0x152	11	18	❌	Bloqué — utilisez les points de test
N986B	N986B	N986BXXSIHYH3	0x14D	11	18	❌	Bloqué — utilisez les points de test

Mode KVM et EL2 de l'Exynos 990

Les dix indicateurs de modèles Galaxy S20, S20 FE et Note20 pris en charge disposent d'un profil de démarrage KVM en CLI uniquement, sur opt-in. Construisez une branche du noyau Exynos 990 dont le nom contient kvm, et ajoutez --kvm à la commande spécifique au modèle, par exemple :

python3 exploit/exploit.py --build-sboot --model G985F --no-fuse --kvm

Ce profil supprime le chemin LK H-Arx/UH, demande à EL3 d'entrer dans le noyau au niveau EL2, et applique la table de correctifs du moniteur EL3 déchiffrée/re-chiffrée correspondante. Il reste indisponible pour les modes de flashage du bootloader d'origine/altéré. Le centre de contrôle web n'a intentionnellement aucun contrôle KVM. Avec le noyau correspondant et WindowsInQemu, Windows peut fonctionner dans QEMU sur le téléphone à pleine vitesse via KVM.

Démarrage rapide

Ne traitez pas chaque mode comme une séquence d'installation numérotée unique. Choisissez un objectif :

Objectif	Chemin
Installer une ROM personnalisée signée	Modèle/configuration exact → EUB → chaîne temporaire --signed --no-fuse → flasher la sortie signée complète de la ROM → premier démarrage UFS
Tester l'exploit	Optionnel --prepare --no-fuse → EUB → --signed --no-fuse → arrêt
Développer la chaîne de démarrage (CLI uniquement)	Test temporaire sans fusible → compilation → flasher les SBoot/TZSW/LDFW générés → UFS
Dump / récupération	Utilisez son flux de travail séparé et les vérifications de l'état des fusibles

--prepare effectue une préparation côté hôte uniquement : il remplace les images de travail générées et compile et signe les fichiers locaux, sans ouvrir l'USB. Ce n'est pas un essai à blanc en lecture seule ni un prédécesseur obligatoire : --signed répète la vérification préalable. La commande Heimdall en trois parties générée est un outil de développement de chaîne de démarrage ; ce n'est pas un flashage de ROM personnalisée.

Lisez USER_GUIDE.md et choisissez son flux de travail correspondant avant de toucher un appareil. Il inclut la passation de la ROM complète ainsi que les règles de récupération pour les états sans fusible, avec fusible et incertain.

Interface locale optionnelle

Le serveur HTTP de l'interface navigateur utilise la bibliothèque standard de Python et appelle l'interface CLI existante exploit/exploit.py. La validation du bundle de clés et l'exécution des outils nécessitent également les paquets dans requirements.txt. Le développement de la chaîne de démarrage et sa commande Heimdall en trois parties générée restent des outils en terminal uniquement.

Démarrez-le depuis la racine du dépôt :

python3 exynos990_control_center.py

Le lanceur se lie à 127.0.0.1, génère un nouveau jeton d'accès, affiche l'URL locale complète et l'ouvre dans le navigateur par défaut. Utilisez --no-browser lorsqu'un navigateur ne doit pas être ouvert automatiquement :

python3 exynos990_control_center.py --no-browser

L'interface fournit :