Exynos 990 / Exynos9830 Unified BootROM-Exploit

Einheitliches CVE-2024-56426-Tooling für die Exynos-990-Familien Galaxy S20, S20 FE und Note20. Der Exploit akzeptiert alle zehn Modellnamen und ordnet sie sechs verifizierten Serien-Bootloader-Familien zu.

[!CAUTION] Das verfolgte Schlüsselbündel und die erzeugten Images sind fusing-fähig. Fusing ist irreversibel. Ein Telefon, das auf einen Schlüssel gefused wurde, kann nur Images booten, die mit diesem Schlüssel kompatibel sind. Ein falsches Modell, eine falsche Rollback-Revision, ein falscher Patch-Satz oder ein falsches Schlüsselbündel kann das Gerät in eine gefusete Boot-Schleife bringen. Verwenden Sie Entwicklungs-Schlüssel und die UFS-Payload während der Iteration. Fügen Sie --no-fuse zu jedem Vorbereitungs-/Signierbefehl hinzu, sofern Custom-Key-Fusing nicht ausdrücklich beabsichtigt ist.

Unterstützte Modelle

Das ausgewählte Modell steuert sowohl die BL1-Modell-ID als auch den exakten Modell-LK-Patch-TSV. Runtime artifact steuert, welche Serien-Firmware und verschlüsselten Split-Images von Preflight verwendet werden. Die vier Nicht-5G-Flags, die gepaarte 5G-Runtime-Artefakte verwenden, patchen auch LKs Modell-ID-Prüfung und den Modell-ID-Programmierpfad.

Modell-Flag	Runtime-Artefakt	Runtime-Firmware	Modell-ID	EVT	Rollback	Getestet
`G780F`	`G780F`	`G780FXXSOFYJ1`	`0x154`	`11`	`24`	❌
`G980F`	`G981B`	`G981BXXSNHYB1`	`0x143`	`11`	`23`	✅
`G981B`	`G981B`	`G981BXXSNHYB1`	`0x13D`	`11`	`23`	❌
`G985F`	`G986B`	`G986BXXSNHYB1`	`0x142`	`11`	`23`	✅
`G986B`	`G986B`	`G986BXXSNHYB1`	`0x13C`	`11`	`23`	✅
`G988B`	`G988B`	`G988BXXSNHYB1`	`0x13E`	`11`	`23`	❌
`N980F`	`N981B`	`N981BXXSIHYH3`	`0x153`	`11`

Exynos 990 KVM- und EL2-Modus

Alle zehn unterstützten Galaxy-S20-, S20-FE- und Note20-Modell-Flags haben ein optionales CLI-only-KVM-Boot-Profil. Erstellen Sie einen Branch des Exynos-990-Kernels, dessen Name kvm enthält, und fügen Sie --kvm zum exakten Modellbefehl hinzu, zum Beispiel:```bash python3 exploit/exploit.py --build-sboot --model G985F --no-fuse --kvm

Dieses Profil entfernt den LK H-Arx/UH-Pfad, veranlasst EL3, den Kernel auf EL2 zu starten, und wendet die passende
entschlüsselte/erneut verschlüsselte EL3-Monitor-Patch-Tabelle an. Es bleibt für Stock-/manipulierte Bootloader-Flash-Modi
nicht verfügbar. Das Web-Kontrollzentrum hat bewusst keine KVM-Steuerung. Mit dem passenden Kernel
und [WindowsInQemu](https://github.com/Creeeeger/WindowsInQemu) kann Windows in QEMU auf dem Telefon mit voller Geschwindigkeit
über KVM ausgeführt werden.

## Schnellstart

Behandle nicht jeden Modus als eine nummerierte Installationssequenz. Wähle ein Ziel:

| Ziel                              | Pfad                                                                                                                     |
|-----------------------------------|--------------------------------------------------------------------------------------------------------------------------|
| Eine signierte Custom-ROM installieren | Exaktes Modell/Setup → EUB → temporäre `--signed --no-fuse`-Kette → die vollständige signierte Ausgabe der ROM flashen → UFS-Erststart |
| Den Exploit testen                 | Optional `--prepare --no-fuse` → EUB → `--signed --no-fuse` → stoppen                                                    |
| Die Boot-Kette entwickeln (nur CLI) | Temporärer No-Fuse-Test → bauen → generierte SBoot/TZSW/LDFW flashen → UFS                                                   |
| Dump / Wiederherstellung           | Den separaten Workflow und die Fuse-Zustandsprüfungen verwenden                                                          |

`--prepare` ist ein empfohlener Probelauf, kein erforderlicher Vorgänger: `--signed`
wiederholt die Vorprüfung. Der generierte dreiteilige Heimdall-Befehl ist ein Werkzeug zur Boot-Ketten-Entwicklung; er ist kein
Custom-ROM-Flash.

Lies [USER_GUIDE.md](https://github.com/creeeeger/cve-2024-56426/blob/exynos990/USER_GUIDE.md) und wähle den passenden Workflow, bevor du ein Gerät anfasst. Er enthält die
Übergabe der vollständigen ROM sowie die Regeln für die Wiederherstellung im ungefussten, gefussten und unklaren Zustand.

## Optionale lokale UI

Die Browser-UI verwendet nur die Standardbibliothek von Python und ruft die vorhandene
`exploit/exploit.py`-CLI auf. Die Boot-Ketten-Entwicklung und ihr generierter dreiteiliger Heimdall-Befehl bleiben reine
Terminal-Werkzeuge.

Starte sie vom Repository-Stammverzeichnis aus:```bash
python3 exynos990_control_center.py

Der Launcher bindet an 127.0.0.1, generiert ein neues Zugriffstoken, gibt die vollständige lokale URL aus und öffnet sie im Standardbrowser. Verwenden Sie --no-browser, wenn ein Browser nicht automatisch geöffnet werden soll:```bash python3 exynos990_control_center.py --no-browser

Die Oberfläche bietet:

- rot/grün-Prüfungen für Abhängigkeiten und Repository-Assets;
- eine globale Zielmodell-Auswahl und genau zwei Fuse-Entscheidungen: Stay unfused oder Fuse;
- einen Workflow-Auswähler, der nur die Schritte des ausgewählten Workflows anzeigt und nummeriert;
- Install-ROM-, Exploit-Test-, BootROM-Dump- und Stock-Recovery-Workflows;
- eine exakte Modell-Tampered-Loader-Aktion, die UH validiert und es mit Heimdall in den BOOTLOADER-Slot flasht, um
  EUB zu betreten;
- eine permanente Fuse-Warnung und den konfigurierten Schlüssel-/eFuse-SHA-256-Fingerabdruck;
- eine nur für unfused verfügbare Stock-Boot-Chain-Wiederherstellungskarte, die nach der Wahl von Fuse nicht mehr verfügbar ist;
- Live-Prozessausgabe, Abbruch und Verifikationsmarkierungen pro Stufe.

Außerdem zeigt es einen nur für die CLI verfügbaren Exynos-990-KVM-Hinweis, legt aber bewusst keine KVM-Option offen und leitet `--kvm` an keine
Web-Aktion weiter.

Der USB-Zugriff folgt den Berechtigungen des Prozesses, der das Kontrollzentrum gestartet hat. Konfigurieren Sie die mitgelieferten udev-/Treiber-
Berechtigungen, bevor Sie es starten. Die Oberfläche fordert keine Berechtigungsnachweise an, speichert sie nicht und leitet sie nicht weiter. Halten Sie das gedruckte
Token-URL privat und stoppen Sie den Server sofort nach der Verwendung.

Terminalnutzer können `exynos990_control_center.py` ignorieren; jeder unten dokumentierte CLI-Befehl bleibt unverändert und vollständig
unterstützt.

## Anforderungen

Python 3.10 oder neuer ist erforderlich.

Windows 10/11 (natives PowerShell):```powershell
.\windows\setup.ps1
. .\windows\activate.ps1
python .\exploit\exploit.py --prepare --model G985F --no-fuse

Das Setup installiert eine festgelegte native AArch64-Toolchain, LZ4, Heimdall und eine virtuelle Umgebung des Repositorys und erstellt anschließend alle Payloads. Der BootROM-WinUSB-Treiber ist eine ausdrückliche Administrator-Option, da sein selbstsigniertes Upstream-Zertifikat die Vertrauensspeicher des Rechners verändert. Siehe WINDOWS.md für das vollständige Setup, die Treiberinstallation, die Unterscheidung des Download-Modus, die Verifizierung und den Fehlerbehebungsprozess.

Nach der Windows-Aktivierung verwenden Sie python, wo in den übrigen plattformübergreifenden Beispielen python3 angezeigt wird.

Linux:```bash sudo apt-get update sudo apt-get install -y gcc-aarch64-linux-gnu binutils-aarch64-linux-gnu lz4

macOS:```bash
brew tap messense/macos-cross-toolchains
brew install aarch64-unknown-linux-gnu lz4

Repository-Layout

Preflight

Vorbereitung, Signierung und Payload-Modi führen dasselbe modellbewusste Preflight aus:

Das ausgewählte Modell zu seiner kanonischen Artefaktfamilie auflösen.
exploit/extra/images/<model>/ durch eine saubere Kopie der unveränderten verschlüsselten Split-Images ersetzen.
Das passende LK-TSV mit strengen Stock-Byte-Prüfungen anwenden. Mit --no-fuse zuerst eine effektive TSV-Kopie generieren, bei der die fünf Fusing-Zeilen deaktiviert sind. Mit --kvm zusätzlich die als kvm markierten LK-Zeilen aktivieren, das passende EL3-Monitor-TSV entschlüsseln und patchen sowie dessen geschützten Bereich neu verschlüsseln.
mem.bin, loader.bin und Exynos990_boot_custom_key.bin erstellen.
Bestätigen, dass EPBL und EL3-Monitor verschlüsselt sind, und nur bei Bedarf neu verschlüsseln.
Stock-FWBL1-Modell-/EVT-/Rollback-Metadaten und jeden Stage2-Rollback-Footer vor der Signierung validieren.
FWBL1 mit der ausgewählten Modell-ID signieren und alle Stage2-Komponenten mit der Stock-Rollback-Revision signieren.
Jede generierte Stage2-Signatur vor der USB-Übertragung verifizieren.

Der Prozess stoppt bei der ersten Firmware-, Patch-, Metadaten- oder Signatur-Unstimmigkeit. Er patcht die unveränderlichen Quellverzeichnisse niemals direkt.

Exploit-Modi

Alle Befehle erfordern --model.

--no-fuse ist ein Modifikator, kein eigenständiger Modus. Er deaktiviert fünf identifizierte Custom-Key-OTP-Zeilen beim Neuerstellen des Arbeits-LK. Verwenden Sie ihn für jeden Befehl, der eine ungefusste Entwicklungskette vorbereitet, sendet oder erstellt. Er macht eine bestehende Fuse nicht rückgängig.

Die CLI akzeptiert den Modifikator bei UFS- und Dump-Modi, da diese Befehle ebenfalls Preflight ausführen, ihre USB-Operationen jedoch den neu erstellten LK nicht übertragen. Der bereits auf dem Telefon geflashte LK bestimmt das UFS-Fuse-Verhalten. Folglich bietet die UI bewusst keine No-Fuse-Steuerung für den UFS- oder BootROM-Dump-Modus. Beide Bootloader-Flash-Modi lehnen --no-fuse ab, da sie kein LK-Patching oder keine Signierung durchführen.

--kvm ist ebenfalls ein Modifikator. Er wird bei jedem exakten Modell-Workflow akzeptiert, der Preflight ausführt. KVM-Zeilen in den TSVs werden ignoriert, sofern dieses Flag nicht vorhanden ist, und die Browser-UI liefert es niemals.

Beispiel:```bash python3 exploit/exploit.py --signed --model N986B --no-fuse

Erzeuge den entsprechenden signierten Bootloader, ohne USB zu öffnen:```bash
python3 exploit/exploit.py --build-sboot --model N986B --no-fuse

Der Befehl erstellt das Modell-Image-Verzeichnis aus sauberen Stock-Eingaben neu, wendet den LK-Patch an, signiert und verifiziert jede Komponente, führt sboot.bin zusammen, prüft die eingebetteten Komponenten und den Tail und gibt dessen Größe, SHA-256 sowie einen Heimdall-Befehl aus, der sboot.bin, signiertes tzsw.img und signiertes ldfw.img sendet.

Nur auf einem Gerät, das bekanntermaßen nicht gefused ist, stellen Sie die exakte Stock-Boot-Kette aus dem ursprünglichen BL-Tar des ausgewählten Modells wieder her:```bash python3 exploit/exploit.py --flash-stock --model N986B --wait

Der Befehl extrahiert nur `sboot.bin.lz4`, `tzsw.img.lz4` und
`ldfw.img.lz4`, dekomprimiert sie in einem temporären Verzeichnis, prüft, ob alle drei Ausgabedateien vorhanden und nicht leer sind, und
führt einen einzigen Heimdall-Flash-Vorgang aus. Die temporären Dateien werden anschließend entfernt. `--no-reboot` und `--verbose` werden ebenfalls
unterstützt. Das Telefon muss sich bereits in einem Heimdall-kompatiblen Download-Modus befinden, und das ausgewählte Modell muss exakt mit
dem physischen Gerät übereinstimmen.

Dadurch werden Android, AP, Modem, CSC, Userdata oder eine vollständige Stock-ROM nicht wiederhergestellt. Führen Sie dies niemals auf einem Gerät mit benutzerdefiniertem Fuse-Schlüssel aus.
Ein solches Telefon erfordert eine auf Stock basierende Software, die mit dem exakten Fuse-Schlüssel neu signiert wurde; die benutzerdefinierte Vertrauenswurzel bleibt
dauerhaft bestehen. Wenn der Fuse-Status unbekannt ist, stoppen Sie.

## Hinweis zu FRP / PERSISTENT-Wiederherstellung

> [!CAUTION]
> Dieser Vorgang ist nur für ein Gerät gedacht, das Ihnen persönlich gehört und für das Sie
> zur Wartung autorisiert sind. Die Verwendung auf dem Gerät einer anderen Person ist strengstens
> untersagt. Ein falscher Partitionspfad kann zu dauerhaftem Datenverlust führen oder das
> Gerät am Booten hindern. Sichern Sie die Zielpartition und überprüfen Sie ihren aufgelösten
> Block-Device-Pfad und ihre Größe, bevor Sie etwas schreiben.

Dieses Repository entfernt den Factory Reset Protection (FRP) nicht automatisch. Auf Geräten, die den Android-
`PersistentDataBlockService` verwenden, wird der FRP-Status in der Partition gespeichert, die üblicherweise `PERSISTENT` genannt wird. Siehe die
[AOSP-Implementierung](https://android.googlesource.com/platform/frameworks/base/+/bc56632da95b/services/core/java/com/android/server/PersistentDataBlockService.java).

Nachdem die Exploit-Kette eine benutzerdefinierte Recovery gebootet hat, die `adb` und
`dd` bereitstellt, identifizieren und sichern Sie die Partition. Ersetzen Sie keinen geschätzten numerischen Block-Device-Pfad:```bash
adb shell ls -l /dev/block/by-name/PERSISTENT
adb shell dd if=/dev/block/by-name/PERSISTENT of=/tmp/PERSISTENT.backup.img bs=4096
adb pull /tmp/PERSISTENT.backup.img

Nur nachdem das Backup erstellt wurde, nullen Sie die Partition und lassen Sie Android eine frische persistent-data-block-Struktur initialisieren:```bash adb shell dd if=/dev/zero of=/dev/block/by-name/persistent reboot

Diese Methode ist getestet und funktioniert, FRP ist entfernt und das Gerät ist entsperrt.

## LK-Patches

Die Patch-Auswahl folgt der Artefakt-Zuordnung:```text
G780F -> lk_g780f_selected_patches.tsv
G980F -> lk_g980f_selected_patches.tsv  (applied to G981B LK)
G981B -> lk_g981b_selected_patches.tsv
G985F -> lk_g985f_selected_patches.tsv  (applied to G986B LK)
G986B -> lk_g986b_selected_patches.tsv
G988B -> lk_g988b_selected_patches.tsv
N980F -> lk_n980f_selected_patches.tsv  (applied to N981B LK)
N981B -> lk_n981b_selected_patches.tsv
N985F -> lk_n985f_selected_patches.tsv  (applied to N986B LK)
N986B -> lk_n986b_selected_patches.tsv

Validiere eine TSV-Datei gegen den Standard-LK, ohne sie zu ändern:```bash python3 external/tools/apply_lk_patches.py
bootLoaderFiles/sbootSplitParts_original/G986B/lk.bin
external/ghidra/lk_g986b_selected_patches.tsv
--check

`external/ghidra/ApplyLkPatches.java` akzeptiert dasselbe sechsspaltige TSV-Format und schlägt nun bei Abweichungen der alten Bytes fehl,
anstatt einen Patch blind anzuwenden. Zeilen, deren erste Spalte `kvm` ist, erfordern ein zusätzliches `--kvm`-Skriptargument.
Die veralteten `check_signature`- und `check_ext4_signature`-Zeilen mit Rückgabewert null verwenden
Profil `0`: Sie dokumentieren die alten Bypass-Stellen, werden aber bewusst nicht
angewendet, sodass erstellte Images den echten Samsung-Signaturprüfungen von LK entsprechen müssen.

## Signierung

`external/tools/sign_sboot_images.py` erfordert ein Modell und leitet die Modell-ID, EVT und Rollback-Revision aus
[model_data.py](https://github.com/creeeeger/cve-2024-56426/blob/exynos990/external/tools/model_data.py) ab:```bash
python3 external/tools/sign_sboot_images.py \
  --images-dir exploit/extra/images/G986B \
  --keys-dir external/keys/exynos9830_crecker \
  --model G986B

Die Stage2-Signaturen werden nach dem Signieren verifiziert. Das Tool generiert keine Samsung-AVB-Metadaten für ldfw.img oder tzsw.img neu; das Ändern der Secure-Boot-Bytes innerhalb dieser Wrapper erfordert weiterhin die separate AVB-Richtlinie, die vom Ziel- Boot-Ablauf verwendet wird. Ein vollständig signiertes ROM muss das exakte AVB-Modell und denselben Schlüsselsatz verwenden und anschließend mit seinem vollständigen generierten Paket geflasht werden. Siehe das CreckerROM-Repository und den Installationsablauf in USER_GUIDE.md.

Manipulierte Loader

Die enthaltenen manipulierten Pakete bewahren jedes Original-BL-Element außer sboot.bin.lz4. Dieses Element wird entfernt und das dekomprimierte uh.bin des Pakets wird als sboot.bin gespeichert, passend zum EUB-auslösenden Layout.

Die Benutzeroberfläche kann den entsprechenden Heimdall-Ablauf direkt ausführen. Sie wählt das manipulierte Archiv des exakten physischen Modells aus, verifiziert, dass sboot.bin byte-identisch mit dem dekomprimierten uh.bin.lz4 ist, und flasht die validierte UH-Nutzlast in den BOOTLOADER-Slot:```bash python3 exploit/exploit.py --flash-tampered --model G986B --wait

Dies verhindert absichtlich den normalen Bootvorgang und erzwingt den nächsten Boot in den EUB. Es flasht nicht die verbleibenden Mitglieder des
BL-Tars.

Ein Paket neu generieren mit:```bash
python3 external/tools/build_tampered_loader.py \
  bootLoaderFiles/originalBl/G986B/BL_G986BXXSNHYB1.tar \
  bootLoaderFiles/tamperedLoader/G986B/BL_G986BXXSNHYB1_tampered.tar

Verwende den manipulierten Loader des physischen Modells, wenn dessen Verzeichnis vorhanden ist. Das gekoppelte Laufzeit-Mapping gilt für das Exploit-Preflight und die Signierung, nicht für die Auswahl des archivierten Original-/manipulierten BL-Pakets.

Beachte, dass du, falls du das Gerät gefused hast, ein signiertes uh.bin auf deinen BOOTLOADER-Slot flashen musst, da das Original-uh derzeit mit dem falschen Schlüssel signiert ist.

Analysetools

Aufteilen und zusammenführen:```bash python3 exploit/split.py sboot.bin -o /tmp/G986B-splits python3 exploit/merge.py /tmp/G986B-splits

Der eigenständige Merger benötigt `tzsw.img` und `ldfw.img` im Verzeichnis `parts` und gibt den entsprechenden dreiteiligen
Heimdall-Befehl aus. Verwenden Sie diesen Befehl nur, wenn diese beiden Images bereits für das ausgewählte Modell signiert wurden;
`--build-sboot` führt diese Signierung automatisch durch und verifiziert sie.

Einzelne LDFW-Datensätze extrahieren:```bash
python3 external/tools/extract_ldfw.py ldfw.img -o LDFWs

Die bereitgestellte Split-Anordnung rekonstruiert jedes kanonische Serien-sboot.bin Byte für Byte. EPBL- und EL3-Monitor-Entschlüsselung/-Wiederverschlüsselung funktionieren ebenfalls Byte für Byte für alle Firmware-Familien, wenn der EPBL-Header unverändert gelassen wird.

Payload-Kompatibilität

Alle unterstützten Telefone verwenden denselben Exynos-990-BootROM. Die Payloads verwenden gemeinsame BootROM-Einstiegspunkte und IRAM-Adressen anstelle von modellspezifischen LK-Offsets. Die generierten Binärdateien lösen sich zu diesen Einstiegspunkten auf:

Modellspezifisches Verhalten ist auf die LK-TSV, die FWBL1-Modell-ID und die Serien-Rollback-Revision beschränkt.

Image-Layout

Danksagungen und Namensnennung

Chimera Tool: früheste bekannte Entdeckung und praktische Nutzung dieses Exploits, etwa 2021–2022.
Samsungs CVE-2024-56426-Hinweis: dokumentiert die von diesem Projekt verwendete Schwachstelle.
Christopher Wade: meldete CVE-2024-56426 an Samsung.
Umer Uddin (halal-beef), über halal-beef/hubble: der Backend-Code, der von exploit/exploit.py verwendet wird; das SoC- Layout, das von exploit/split.py und exploit/merge.py verwendet wird; sowie run_exploit(), das die Adress-/Überschreiboperation implementiert.
VDavid003 (David), über VDavid003/exynos-usbdl: das Payload-Gerüst, aus dem die Exynos990- Custom-Key-Payload abgeleitet wurde.

`bootLoaderFiles/originalBl/<model>/`	Saubere exakte Modell-`BL_<firmware>.tar`-Pakete für alle zehn Modelle.
`bootLoaderFiles/sbootSplitParts_original/<model>/`	Unveränderte exakte Modell-encrypted-SBoot-Splits, `ldfw.img`, `tzsw.img`, Manifest und Tail.
`bootLoaderFiles/exynos9830Decrypted/<model>/`	Exakte Modell-entschlüsselte EPBL-, EL3-, TZSW- und LDFW-Analysedateien.
`bootLoaderFiles/tamperedLoader/<model>/`	Exakte Modell-EUB-auslösende BL-Pakete.
`bootLoaderFiles/MODEL_COMPARISON.md`	Vergleich exakter versus gekoppelter Firmware sowie Patch-Kompatibilitätshinweise.
`bootLoaderFiles/exynos990Bootrom/`	Gemeinsamer Exynos-990-BootROM-Dump.
`bootromNotes/`	Gemeinsame BootROM-Ablauf- und USB-Kontextnotizen.
`drivers/windows/winusb/`	Gebündeltes Houston-WinUSB-Paket für BootROM/EUB `04e8:1234`.
`windows/`	Natives Windows-Setup, Umgebungsaktivierung und Hash-prüfender Treiberinstaller.
`exploit/extra/images/<model>/`	Wegwerfbare modellspezifische Preflight-Ausgabe.
`external/ghidra/`	Exakte Modell-LK- und KVM-EL3-TSVs plus das Ghidra-Patch-Skript.
`external/decompiled_G985F/`	Nur-G985F-dekompilierte Referenzdateien.
`exynos990reverseEng_G985F/`	Nur-G985F-Ghidra-Projekt.
`external/keys/exynos9830_crecker/`	Gemeinsames Custom-Key-Bündel.
`exploit/exploit.py`	Stabiler CLI-Einstiegspunkt und Workflow-Koordinator.
`exploit/build_payloads.py`	Plattformübergreifender nativer Payload-Builder, der von Preflight unter Windows, Linux und macOS verwendet wird.
`exploit/preflight.py`	Arbeitsimage-Vorbereitung, LK-Patching, Signierung und Merge-Verifizierung.
`exploit/usb_transport.py`	PyUSB-Framing, Geräteerkennung, Überschreib- und Dump-Transport.
`exploit/tampered_loader.py`	Exakte Modell-UH-Extraktion, Tampered-Loader-Validierung und Heimdall-EUB-Flash.
`exploit/stock_restore.py`	Exakte Modell-Stock-Archivextraktion und Heimdall-Befehlsaufbau.
`control_center/`	Browser-Backend-Aktionen, Abhängigkeitsprüfungen, Jobs und HTTP-API.
`external/tools/*_crypto.py`	Gemeinsame EPBL/EL3-AES- und ECDSA-Kodierungs-/Signatur-Primitive.

`--prepare`	Preflight ohne Öffnen von USB ausführen.
`--build-sboot`	Preflight ausführen und ein verifiziertes signiertes `sboot.bin` im Modell-Image-Verzeichnis erstellen.
`--signed`	Custom-Key-Payload und signierte Boot-Kette von EUB senden.
`--ufs`	UFS-Boot-Pfad mit `loader.bin` starten.
`--dump`	`mem.bin` ausführen und `0x20000` Bytes BootROM dumpen.
`--flash-tampered`	Exakte Modell-UH validieren und zum Erzwingen von EUB auf BOOTLOADER flashen.
`--flash-stock`	Exakte Modell-Stock-SBoot, TZSW und LDFW aus dem Original-BL-Tar extrahieren und flashen.

`fwbl1.img`	BL1-privater Schlüssel plus Stage2-TEE/REE-öffentliche Blobs
`epbl.img`, `el3_mon.img`	Stage2 TEE
`bl2.img`, `lk.bin`	Stage2 REE
`ldfw.img`, `tzsw.img`	Stage2 TEE, innere und äußere Stage2-Footer

`mem.bin`	`0x02022010`	`0x02022010`
`loader.bin`	`0x02022010`	`0x02022010`
`Exynos990_boot_custom_key.bin`	`0x02022000`	positionsunabhängige Stufe 1

`fwbl1.img`	`0x000000`	`0x003000`
`epbl.img`	`0x003000`	`0x016000`
`bl2.img`	`0x016000`	`0x082000`
`lk.bin`	`0x0DB000`	`0x35B000`
`el3_mon.img`	`0x35B000`	`0x39B000`

BL1	`0x02022000`
EPBL	`0x02026000`
BL2	`0x15600000`
LK	`0xE8000000`
EL3-Monitor	`0xBFE80000`

CVE-2024-56426

Beliebteste