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

Pfad	Zweck
bootLoaderFiles/	Bootloader-Binärdateien, aufgeteilte Bootloader-Teile, Original-Images, entschlüsselte Images und Dump-Artefakte.
bootromNotes/	Boot-ROM-Notizen, Flussdiagramme und USB-Kontext-Offsets.
exploit/	Python-Werkzeuge, Exploit-Runner, Split-/Merge-Skripte, Payload-Build-Helfer und SoC-Daten.
exploit/extra/images/	Verwendbare Bootloader-Images, die von den Exploit-Abläufen verwendet werden.
exploit/extra/payloads/	Erstellte Payload-Binärdateien, kopiert aus external/payloads/.
external/	Payload-Quellen, Build-Makefile, dekompilierte Notizen, gemeinsames Schlüsselmaterial und Hilfswerkzeuge.
external/keys/exynos9830_crecker/	Gemeinsames Exynos9830-/Exynos990-Custom-Key-Paket, das vom Signed-Loader-Ablauf verwendet wird.
exynos990reverseEng/	Projektdateien des Exynos-990-Reverse-Engineering-Projekts.

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:

Schlüssel-1-Befehl	Wert	Schlüssel-2-Befehl	Wert
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

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

Payload	Ausgabepfad	Zweck
mem.bin	exploit/extra/payloads/mem.bin	Payload für den Boot-ROM-Speicherdump.
loader.bin	exploit/extra/payloads/loader.bin	UFS-Pfad-Payload, verwendet von --ufs.
Exynos990_boot_custom_key.bin	exploit/extra/payloads/Exynos990_boot_custom_key.bin	Custom-Key-Signed-Loader-Payload, verwendet von --signed.

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: