Exploit du Bootrom SM-G985F / Exynos9830

[!CAUTION] Le lot de clés actuel et les fichiers générés peuvent être fusionnés. Une fois qu'un appareil a été fusionné, la modification de l'eFuse est irréversible et l'appareil doit continuer à utiliser des images de démarrage et un matériel de clés correspondant à la clé fusionnée. L'utilisation de ces fichiers ou procédures se fait à vos propres risques en raison du comportement de fusion ; toutes les conséquences restent de la responsabilité de l'utilisateur qui les exécute. Vérifiez le fichier eFuse, les clés privées, les images FWBL1 signées, LK / sboot.bin, et l'appareil cible avant d'exécuter toute procédure de fusion.

Sommaire

• Structure du dépôt
• Prérequis
• Préparation des images
• Construction du payload
• Génération d'images SBoot signées
• Modes d'exploitation
• Chaîne de démarrage Exynos 9830
• Disposition des images Exynos 9830
• Adresses de chargement
• Identifiants de source de démarrage
• Payload de dump /mem
• Attribution amont
• Crédits

Structure du dépôt

Chemin	Description
bootLoaderFiles/	Binaires du bootloader, parties de bootloader découpées, images d'origine, images déchiffrées et artefacts de dump.
bootromNotes/	Notes sur la ROM de démarrage, organigrammes et offsets de contexte USB.
exploit/	Outillage Python, exécuteur d'exploit, scripts de découpage/fusion, assistant de construction de payload et données SoC.
exploit/extra/images/	Images de bootloader fonctionnelles utilisées par les procédures d'exploit.
exploit/extra/payloads/	Binaires de payload construits, copiés depuis external/payloads/.
external/	Sources de payload, Makefile de construction, notes décompilées, matériel de clés partagé et outils auxiliaires.
external/keys/exynos9830_crecker/	Lot de clés personnalisées Exynos9830 / Exynos990 partagé utilisé par la procédure de chargeur signé.
exynos990reverseEng/	Fichiers du projet de rétro-ingénierie Exynos 990.

Prérequis

Chaîne d'outils Linux

sudo apt-get update
sudo apt-get install -y gcc-aarch64-linux-gnu binutils-aarch64-linux-gnu

Chaîne d'outils macOS

brew tap messense/macos-cross-toolchains
brew install aarch64-unknown-linux-gnu

Dépendances Python

python3 -m pip install -r requirements.txt

requirements.txt inclut coloredlogs, cryptography, hexdump, libusb, pyusb et pycryptodome.

Pilote USB Windows

Sous Windows, le périphérique USB BootROM 04e8:1234 doit utiliser un pilote compatible WinUSB/libusb avant que PyUSB puisse l'ouvrir. Voir exploit/windows/README.md.

Le dépôt inclut un package de pilote WinUSB dans exploit/windows/Exynos_USB_Device.inf, avec son catalogue correspondant et le fichier d'import de certificat dans le même répertoire.

Préparation des images

Découpage de sboot.bin

python3 exploit/split.py bootLoaderFiles/originalSboot_K/sboot.bin -o exploit/extra/images

Le script de découpage écrit les parties d'image et un fichier split_manifest.json dans le répertoire de sortie.

Correctif de clé personnalisée LK

L'image LK doit utiliser les identifiants de commande de la clé 2 de démarrage sécurisé ROM pour la procédure de clé personnalisée :

Commande clé 1	Valeur	Commande clé 2	Valeur
CMD_W_ROM_SEC_BOOT_KEY1	0x001	CMD_W_ROM_SEC_BOOT_KEY2	0x016
CMD_W_USE_ROM_SEC_BOOT_KEY1	0x002	CMD_W_USE_ROM_SEC_BOOT_KEY2	0x017
CMD_C_ROM_SEC_BOOT_KEY1	0x100	CMD_C_ROM_SEC_BOOT_KEY2	0x114
CMD_R_USE_ROM_SEC_BOOT_KEY1	0x101	CMD_R_USE_ROM_SEC_BOOT_KEY2	0x115

Lors de l'application du TSV de correctif LK dans le projet Ghidra, l'assistant a été appelé via Ghidra headless comme ceci :

GHIDRA=/path/to/ghidra_12.0.4_PUBLIC
REPO=$(pwd)
"$GHIDRA/support/analyzeHeadless" "$REPO/exynos990reverseEng" exynos990 \
  -process lk.bin \
  -noanalysis \
  -scriptPath "$REPO/external/ghidra" \
  -postScript ApplyLkPatches.java "$REPO/external/ghidra/lk_985_selected_patches.tsv"

Intégrez la clé eFuse de 32 octets dans lk.bin à l'offset 0x205008, en remplaçant la clé d'origine :

dd if=external/keys/exynos9830_crecker/crecker.efuse of=exploit/extra/images/lk.bin bs=1 seek=$((0x205008)) count=32 conv=notrunc
xxd -g1 -s $((0x205008)) -l 32 exploit/extra/images/lk.bin

Fusion des parties découpées

python3 exploit/merge.py exploit/extra/images Exynos9830

Le script de fusion écrit sboot.bin dans le répertoire de travail actuel.

Construction du payload

Construisez les projets de payload dans external/payloads/ et copiez les binaires obtenus dans exploit/extra/payloads/ :

./exploit/build_payloads.sh

Payload	Chemin de sortie	Objectif
mem.bin	exploit/extra/payloads/mem.bin	Payload de dump mémoire de la ROM de démarrage.
loader.bin	exploit/extra/payloads/loader.bin	Payload de la voie UFS utilisé par --ufs.
Exynos990_boot_custom_key.bin	exploit/extra/payloads/Exynos990_boot_custom_key.bin	Payload de chargeur signé à clé personnalisée utilisé par --signed.

Le chargeur UFS et le payload à clé personnalisée intègrent un fichier efuse de 32 octets lors de la construction. Par défaut, le Makefile lit external/keys/exynos9830_crecker/crecker.efuse ; remplacez-le avec CUSTOM_KEY_EFUSE=/path/to/crecker.efuse si nécessaire.

Génération d'images SBoot signées

L'étape de vérification préalable exécutée par exploit/exploit.py re-signe sur place le jeu d'images SBoot dans exploit/extra/images/ avant chaque exécution signée. Aucune sortie signée séparée n'est conservée. L'étape de signature utilise le lot de clés partagé délibérément suivi sous external/keys/exynos9830_crecker/.

Commande équivalente à exécuter à la racine du dépôt pour le jeu d'images complet :

python3 external/tools/sign_sboot_images.py \
  --images-dir exploit/extra/images \
  --keys-dir external/keys/exynos9830_crecker

Cette commande signe :