SM-G985F / Exynos9830-Bootrom-Exploit

[!CAUTION] Das aktuelle Schlüsselpaket und die erzeugten Dateien sind fusing-fähig. Sobald ein Gerät gefused wurde, ist die eFuse-Änderung irreversibel und das Gerät muss weiterhin Boot-Images und Schlüsselmaterial verwenden, das zum gefused Schlüssel passt. Die Verwendung dieser Dateien oder Abläufe erfolgt wegen des Fusing-Verhaltens auf eigenes Risiko; alle Konsequenzen bleiben in der Verantwortung des Benutzers, der sie ausführt. Überprüfen Sie die eFuse-Datei, die privaten Schlüssel, die signierten FWBL1-, LK-/sboot.bin-Images und das Zielgerät, bevor Sie einen Fusing-Ablauf ausführen.

Inhaltsverzeichnis

• Repository-Struktur
• Anforderungen
• Image-Vorbereitung
• Payload-Erstellung
• Erzeugung signierter SBoot-Images
• Exploit-Modi
• Exynos-9830-Bootkette
• Exynos-9830-Image-Layout
• Ladeadressen
• Boot-Quell-IDs
• Dump-/mem-Payload
• Upstream-Anerkennung
• Credits

Repository-Struktur

Anforderungen

Linux-Toolchain

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

macOS-Toolchain

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

Python-Abhängigkeiten

python3 -m pip install -r requirements.txt

requirements.txt enthält coloredlogs, cryptography, hexdump, libusb, pyusb und pycryptodome.

Windows-USB-Treiber

Unter Windows muss das BootROM-USB-Gerät 04e8:1234 einen WinUSB-/libusb-kompatiblen Treiber verwenden, bevor PyUSB es öffnen kann. Siehe exploit/windows/README.md.

Das Repository enthält ein WinUSB-Treiberpaket unter exploit/windows/Exynos_USB_Device.inf, zusammen mit dem zugehörigen Katalog und der Zertifikat-Importdatei im selben Verzeichnis.

Image-Vorbereitung

sboot.bin aufteilen

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

Das Split-Skript schreibt die Image-Teile und eine split_manifest.json-Datei in das Ausgabeverzeichnis.

LK-Custom-Key patchen

Das LK-Image muss für den Custom-Key-Ablauf die Command-IDs des ROM Secure Boot Key 2 verwenden:

Beim Anwenden der LK-Patch-TSV im Ghidra-Projekt wurde der Helfer wie folgt über Ghidra Headless aufgerufen:

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"

Betten Sie den 32-Byte-eFuse-Schlüssel bei Offset 0x205008 in lk.bin ein und ersetzen Sie damit den werkseitigen Schlüssel:

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

Aufgeteilte Teile zusammenführen

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

Das Merge-Skript schreibt sboot.bin in das aktuelle Arbeitsverzeichnis.

Payload-Erstellung

Erstellen Sie die Payload-Projekte unter external/payloads/ und kopieren Sie die resultierenden Binärdateien in exploit/extra/payloads/:

./exploit/build_payloads.sh

Der UFS-Loader und das Custom-Key-Payload betten zur Build-Zeit eine 32-Byte-eFuse-Datei ein. Standardmäßig liest das Makefile external/keys/exynos9830_crecker/crecker.efuse; überschreiben Sie dies bei Bedarf mit CUSTOM_KEY_EFUSE=/path/to/crecker.efuse.

Erzeugung signierter SBoot-Images

Der von exploit/exploit.py ausgeführte Preflight-Schritt signiert den SBoot-Image-Satz in exploit/extra/images/ vor jedem signierten Lauf direkt an Ort und Stelle neu. Es wird keine separate signierte Ausgabe aufbewahrt. Der Signierungsschritt verwendet das bewusst im Repository geführte gemeinsame Schlüsselpaket unter external/keys/exynos9830_crecker/.

Entsprechender Befehl im Repository-Stammverzeichnis für den vollständigen Image-Satz:

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

Dies signiert:

Der Batch-Signer übergibt für jedes Image den Dezimalwert 23 und verwendet keinen älteren Rollback-Wert wieder, der bereits in einem vorhandenen Footer enthalten ist.

epbl.img wird bei Bedarf zuerst erneut verschlüsselt und anschließend über die endgültigen Bytes signiert. ldfw.img und tzsw.img benötigen weiterhin den externen AVB-Ablauf, wenn ihr AVB-Inhalt aktualisiert werden soll.

Der Nur-FWBL1-Befehl lautet:

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

Kurzform, wenn sich sign_tool.py, fwbl1.img und die crecker_*-Dateien im aktuellen Verzeichnis befinden:

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

Exploit-Modi

Führen Sie die Befehle aus dem Repository-Stammverzeichnis aus, sofern nicht anders angegeben.

Hinweise zum Geräteablauf

Exynos-9830-Bootkette

Der beobachtete Boot-Ablauf des Exynos 9830 ist:

Exynos-9830-Image-Layout

Ladeadressen

Boot-Quell-IDs

Rohe Boot-Quell-IDs

Boot-Quell-Werte

Dump-/mem-Payload

Hinweis: Das mem.bin-Dump-Payload kann nur verwendet werden, wenn kein funktionierendes sboot installiert ist.

1. Senden Sie uh.bin über Heimdall an den Bootloader:

   root@kitploit:~

   heimdall flash --BOOTLOADER uh.bin
   

2. Führen Sie den Dump-Ablauf aus:

   root@kitploit:~

   python3 exploit/exploit.py --dump
   

3. Prüfen Sie den erzeugten exynos990.bootrom.bin-Dump.

Upstream-Anerkennung

Teile der Python-Recovery-Werkzeuge in diesem Repository wurden von halal-beef/hubble übernommen und angepasst.

Dieses Upstream-Projekt ist unter der GNU GPL v2.0 veröffentlicht, und dieses Repository behält aus Kompatibilitätsgründen eine GPL-2.0-Lizenz bei. Siehe LICENSE und NOTICE.md.

Das Exynos990-Custom-Key-Payload unter external/payloads/exynos990_boot_custom_key/ basiert auf dem Boot-Custom-Key-Payload-Gerüst und der Kontrollfluss-Idee von VDavid003/exynos-usbdl, einem Fork von frederic/exynos-usbdl. Es wurde erheblich umgeschrieben und an die Exynos9830-/Exynos990-GET_CONFIGURATION-Kette angepasst und ist keine wörtliche Kopie des Upstream-Payloads. Da das referenzierte Upstream-Projekt unter der GNU GPL v3.0 lizenziert ist, wird dieses Payload unter GPL-3.0-only gehalten; siehe external/payloads/exynos990_boot_custom_key/LICENSE.

Credits