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

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 :

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

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 :

Le signataire par lot transmet la valeur décimale 23 pour chaque image et ne réutilise pas une ancienne valeur de rollback déjà présente dans un pied de page existant.

epbl.img est d'abord ré-chiffré si nécessaire, puis signé sur les octets finaux. ldfw.img et tzsw.img nécessitent toujours la procédure AVB externe si leur contenu AVB doit être actualisé.

La commande limitée à FWBL1 est :

python3 external/tools/sign_tool.py \
  -i exploit/extra/images/fwbl1.img \
  -o exploit/extra/images/fwbl1.img \
  -k external/keys/exynos9830_crecker/crecker_private.pem \
  -H external/keys/exynos9830_crecker/crecker.hmac \
  -s 0x3000 \
  -r 23 \
  -ma 0x9830 \
  -m 0x142 \
  -e 11 \
  -t external/keys/exynos9830_crecker/crecker_stage2_tee_pubkey.bin \
  -re external/keys/exynos9830_crecker/crecker_stage2_ree_pubkey.bin

Forme abrégée lorsque sign_tool.py, fwbl1.img et les fichiers crecker_* se trouvent dans le répertoire courant :

python3 sign_tool.py -i fwbl1.img -o fwbl1.img -k crecker_private.pem -H crecker.hmac -s 0x3000 -r 23 -ma 0x9830 -m 0x142 -e 11 -t crecker_stage2_tee_pubkey.bin -re crecker_stage2_ree_pubkey.bin

Modes d'exploitation

Exécutez les commandes depuis la racine du dépôt sauf indication contraire.

Notes sur la procédure côté appareil

Chaîne de démarrage Exynos 9830

La procédure de démarrage Exynos 9830 observée est la suivante :

Disposition des images Exynos 9830

Adresses de chargement

Identifiants de source de démarrage

Identifiants bruts de source de démarrage

Valeurs de source de démarrage

Payload de dump /mem

Remarque : le payload de dump mem.bin ne peut être utilisé que lorsqu'aucun sboot fonctionnel n'est installé.

1. Envoyez uh.bin via Heimdall au bootloader :

   root@kitploit:~

   heimdall flash --BOOTLOADER uh.bin
   

2. Exécutez la procédure de dump :

   root@kitploit:~

   python3 exploit/exploit.py --dump
   

3. Examinez le dump exynos990.bootrom.bin généré.

Attribution amont

Certaines parties de l'outillage de récupération Python de ce dépôt ont été adaptées de halal-beef/hubble.

Ce projet amont est publié sous la GNU GPL v2.0, et ce dépôt conserve une licence GPL-2.0 par compatibilité. Voir LICENSE et NOTICE.md.

Le payload à clé personnalisée Exynos990 sous external/payloads/exynos990_boot_custom_key/ est basé sur le squelette de payload boot-custom-key et l'idée de flux de contrôle de VDavid003/exynos-usbdl, un fork de frederic/exynos-usbdl. Il a été considérablement réécrit et adapté pour la chaîne GET_CONFIGURATION Exynos9830 / Exynos990, et n'est pas une copie textuelle du payload amont. Comme le projet amont référencé est sous licence GNU GPL v3.0, ce payload est conservé sous GPL-3.0-only ; voir external/payloads/exynos990_boot_custom_key/LICENSE.

Crédits