Exploit BootROM unificato Exynos 990 / Exynos9830

Tooling unificato CVE-2024-56426 per le famiglie Exynos 990 Galaxy S20, S20 FE e Note20. L'exploit accetta tutti e dieci i nomi dei modelli e li mappa su sei famiglie di bootloader stock verificate.

[!CAUTION] Il bundle di chiavi tracciato e le immagini generate sono in grado di eseguire il fusing. Il fusing è irreversibile. Un telefono fuso con una chiave può avviare solo immagini compatibili con quella chiave. Un modello errato, una revisione di rollback, un set di patch o un bundle di chiavi sbagliato può lasciare il dispositivo in un boot loop fuso. Usa chiavi di sviluppo e il payload UFS durante l'iterazione. Aggiungi --no-fuse a ogni comando di preparazione/firma a meno che il fusing con chiave personalizzata non sia esplicitamente previsto.

Modelli supportati

Il modello selezionato controlla sia l'ID modello BL1 sia il TSV di patch LK del modello esatto. Runtime artifact controlla quale firmware stock e quali immagini divise crittografate vengono usate dal preflight. I quattro flag non-5G che usano runtime artifact 5G accoppiati patchano anche il controllo dell'ID modello e il percorso di programmazione dell'ID modello di LK.

Flag modello	Runtime artifact	Firmware runtime	ID modello	EVT	Rollback	Testato
`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`

Modalità KVM e EL2 Exynos 990

Tutti e dieci i flag dei modelli supportati Galaxy S20, S20 FE e Note20 hanno un profilo di avvio KVM solo-CLI opzionale. Compila un branch del kernel Exynos 990 il cui nome contenga kvm, e aggiungi --kvm al comando del modello esatto, ad esempio:```bash python3 exploit/exploit.py --build-sboot --model G985F --no-fuse --kvm

Questo profilo rimuove il percorso LK H-Arx/UH, chiede a EL3 di far entrare il kernel a EL2 e applica la corrispondente
tabella di patch del monitor EL3 decrittata/ricrittata. Rimane non disponibile per le modalità di flash del bootloader stock/manomesso.
Il centro di controllo web non ha intenzionalmente alcun controllo KVM. Con il kernel corrispondente
e [WindowsInQemu](https://github.com/Creeeeger/WindowsInQemu), Windows può essere eseguito in QEMU sul telefono a piena velocità
tramite KVM.

## Avvio rapido

Non trattare ogni modalità come una sequenza di installazione numerata. Scegli un obiettivo:

| Obiettivo                              | Percorso                                                                                                                     |
|-----------------------------------|--------------------------------------------------------------------------------------------------------------------------|
| Installare una ROM personalizzata firmata       | Modello/impostazione esatti → EUB → catena temporanea `--signed --no-fuse` → flash dell'output firmato completo della ROM → primo avvio UFS |
| Testare l'exploit                  | `--prepare --no-fuse` opzionale → EUB → `--signed --no-fuse` → stop                                                       |
| Sviluppare la catena di avvio (solo CLI) | Test temporaneo no-fuse → build → flash di SBoot/TZSW/LDFW generati → UFS                                                   |
| Dump / ripristino                   | Usa il suo flusso di lavoro separato e i controlli dello stato dei fuse                                                                          |

`--prepare` è una prova a secco consigliata, non un prerequisito obbligatorio: `--signed`
ripete il preflight. Il comando Heimdall in tre parti generato è uno strumento di sviluppo della catena di avvio; non è un flash di ROM personalizzata.

Leggi [USER_GUIDE.md](https://github.com/creeeeger/cve-2024-56426/blob/exynos990/USER_GUIDE.md) e scegli il suo flusso di lavoro corrispondente prima di toccare un dispositivo. Include la
consegna della ROM completa oltre alle regole di ripristino per stati senza fuse, con fuse e incerti.

## UI Locale Opzionale

L'interfaccia del browser usa solo la libreria standard di Python e chiama la CLI esistente
`exploit/exploit.py`. Lo sviluppo della catena di avvio e il suo comando Heimdall in tre parti generato rimangono strumenti
solo da terminale.

Avviala dalla radice del repository:```bash
python3 exynos990_control_center.py

Il launcher si collega a 127.0.0.1, genera un nuovo token di accesso, stampa l'URL locale completo e lo apre nel browser predefinito. Usa --no-browser quando il browser non deve essere aperto automaticamente:```bash python3 exynos990_control_center.py --no-browser

L'interfaccia fornisce:

- controlli rosso/verde per dipendenze e asset del repository;
- una scelta globale del modello target e esattamente due decisioni di fusione: Rimani non fuso o Fondi;
- un selettore di flussi di lavoro che mostra e numera solo i passaggi del flusso selezionato;
- flussi di lavoro per installazione-ROM, test-exploit, dump-BootROM e ripristino-stock;
- un'azione di loader manomesso per modello esatto che valida UH e lo flasha nello slot BOOTLOADER con Heimdall per entrare in
  EUB;
- un avviso permanente di fusione e l'impronta SHA-256 configurata di chiave/eFuse;
- una scheda di ripristino della catena di avvio stock solo-non-fuso che non è disponibile dopo aver scelto Fuse;
- output di processo in tempo reale, annullamento e marcatori di verifica per ogni fase.

Mostra inoltre un avviso KVM Exynos 990 solo-CLI, ma deliberatamente non espone un'opzione KVM né inoltra `--kvm` a nessuna
azione web.

L'accesso USB segue i permessi del processo che ha avviato il centro di controllo. Configura i permessi udev/driver forniti
prima di avviarlo. L'interfaccia non richiede, conserva né inoltra credenziali privilegiate. Mantieni privato l'URL del token
stampato e ferma il server immediatamente dopo l'uso.

Gli utenti da terminale possono ignorare `exynos990_control_center.py`; ogni comando CLI documentato di seguito rimane invariato e pienamente
supportato.

## Requisiti

È richiesto Python 3.10 o successivo.

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

L'installazione configura una toolchain nativa AArch64 bloccata, LZ4, Heimdall e un ambiente virtuale del repository, quindi compila tutti i payload. Il driver WinUSB BootROM è un'opzione esplicita da amministratore perché il suo certificato self-signed a monte modifica gli archivi di trust della macchina. Consulta WINDOWS.md per la procedura completa di configurazione, installazione del driver, distinzione della modalità Download, verifica e risoluzione dei problemi.

Dopo l'attivazione di Windows, usa python ovunque gli esempi cross-platform rimanenti mostrino python3.

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

Struttura del Repository

Preflight

Preparazione, firma e modalità payload eseguono lo stesso preflight consapevole del modello:

Risolvi il modello selezionato nella sua famiglia di artefatti canonica.
Sostituisci exploit/extra/images/<model>/ con una copia pulita delle immagini split crittografate intatte.
Applica il TSV LK corrispondente con controlli rigorosi sui byte stock. Con --no-fuse, genera prima una copia TSV effettiva con le cinque righe di fusione disabilitate. Con --kvm, abilita anche le righe LK marcate kvm, decritta e applica la patch al TSV monitor EL3 corrispondente, e ri-critta la sua regione protetta.
Costruisci mem.bin, loader.bin e Exynos990_boot_custom_key.bin.
Conferma che EPBL e monitor EL3 siano crittografati, ri-crittando solo quando necessario.
Valida i metadati modello/EVT/rollback di FWBL1 stock e ogni footer di rollback Stage2 prima della firma.
Firma FWBL1 con l'ID modello selezionato e firma tutti i componenti Stage2 con la revisione di rollback stock.
Verifica ogni firma Stage2 generata prima del trasferimento USB.

Il processo si interrompe al primo disallineamento di firmware, patch, metadati o firma. Non applica mai patch alle directory sorgente immutabili sul posto.

Modalità Exploit

Tutti i comandi richiedono --model.

--no-fuse è un modificatore, non una modalità autonoma. Disabilita cinque righe OTP a chiave personalizzata identificate durante la ricostruzione dell'LK di lavoro. Usalo per ogni comando che prepara, invia o costruisce una catena di sviluppo non fusa. Non annulla una fusione esistente.

La CLI accetta il modificatore con le modalità UFS e dump perché anche quei comandi eseguono il preflight, ma le loro operazioni USB non trasmettono l'LK ricostruito. L'LK già flashato sul telefono determina il comportamento di fusione UFS. Di conseguenza, l'interfaccia utente non offre deliberatamente alcun controllo no-fuse per la modalità UFS o dump BootROM. Entrambe le modalità di flash del bootloader rifiutano --no-fuse perché non eseguono alcuna patch o firma LK.

Anche --kvm è un modificatore. È accettato con ogni flusso di lavoro specifico per modello esatto che esegue il preflight. Le righe KVM nei TSV vengono ignorate a meno che questo flag non sia presente, e l'interfaccia utente browser non lo fornisce mai.

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

Genera il bootloader firmato corrispondente senza aprire la USB:```bash
python3 exploit/exploit.py --build-sboot --model N986B --no-fuse

Il comando ricostruisce la directory delle immagini del modello a partire da input stock puliti, applica la patch LK, firma e verifica ogni componente, unisce sboot.bin, controlla i componenti incorporati e la coda, e ne stampa la dimensione, lo SHA-256 e un comando Heimdall che invia sboot.bin, tzsw.img firmato e ldfw.img firmato.

Solo su un dispositivo noto per essere non fuso, ripristina l'esatta catena di avvio stock dal tar BL originale del modello selezionato:```bash python3 exploit/exploit.py --flash-stock --model N986B --wait

Il comando estrae solo `sboot.bin.lz4`, `tzsw.img.lz4` e
`ldfw.img.lz4`, li decomprime in una directory temporanea, verifica che tutti e tre gli output siano presenti e non vuoti, e
invoca una singola operazione di flash Heimdall. I file temporanei vengono rimossi al termine. Sono supportati anche `--no-reboot` e `--verbose`. Il telefono deve essere già in una modalità download compatibile con Heimdall, e il modello selezionato deve corrispondere esattamente
al dispositivo fisico.

Questa operazione non ripristina Android, AP, modem, CSC, userdata o una ROM stock completa. Non eseguirla mai su un
dispositivo con chiave personalizzata fusa. Un telefono del genere richiede software stock ri-firmato con l'esatta chiave fusa; la root di fiducia personalizzata rimane
permanente. Se lo stato della fusione è sconosciuto, fermati.

## Nota sul ripristino FRP / PERSISTENT

> [!CAUTION]
> Questa procedura è destinata esclusivamente a un dispositivo di tua proprietà e per il quale sei
> autorizzato a eseguire interventi di manutenzione. Usarla sul dispositivo di un'altra persona è severamente
> vietato. Un percorso di partizione errato può causare perdita permanente di dati o lasciare
> il dispositivo incapace di avviarsi. Esegui il backup della partizione di destinazione e verifica il suo percorso
> del dispositivo a blocchi e la dimensione prima di scrivere qualsiasi cosa.

Questo repository non rimuove automaticamente la protezione FRP (Factory Reset Protection). Sui dispositivi che utilizzano il
`PersistentDataBlockService` di Android, lo stato FRP è memorizzato nella partizione comunemente chiamata `PERSISTENT`. Vedi la
[implementazione AOSP](https://android.googlesource.com/platform/frameworks/base/+/bc56632da95b/services/core/java/com/android/server/PersistentDataBlockService.java).

Dopo che la catena di exploit ha avviato una recovery personalizzata che fornisce `adb` e
`dd`, identifica ed esegui il backup della partizione. Non sostituire con un percorso di dispositivo a blocchi numerico ipotizzato:```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

Solo dopo che il backup è stato recuperato, azzera la partizione e lascia che Android inizializzi una nuova struttura persistent-data-block:```bash adb shell dd if=/dev/zero of=/dev/block/by-name/persistent reboot

Questo metodo è testato e funziona, FRP viene rimosso e il dispositivo è sbloccato.

## Patch LK

La selezione delle patch segue la mappatura degli artefatti:```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

Valida un TSV rispetto allo stock LK senza modificarlo:```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` accetta lo stesso formato TSV a sei colonne e ora fallisce in caso di discrepanze nei byte vecchi
invece di applicare una patch alla cieca. Le righe la cui prima colonna è `kvm` richiedono un argomento aggiuntivo `--kvm` per lo script.
Le righe legacy `check_signature` e `check_ext4_signature` con ritorno zero usano il
profilo `0`: documentano le vecchie posizioni di bypass ma non vengono deliberatamente
applicate, quindi le immagini costruite devono soddisfare i controlli di firma Samsung reali di LK.

## Firma

`external/tools/sign_sboot_images.py` richiede un modello e deriva l'ID del modello, l'EVT e la revisione di rollback da
[model_data.py](https://github.com/creeeeger/cve-2024-56426/blob/exynos990/external/tools/model_data.py):```bash
python3 external/tools/sign_sboot_images.py \
  --images-dir exploit/extra/images/G986B \
  --keys-dir external/keys/exynos9830_crecker \
  --model G986B

Le firme Stage2 vengono verificate dopo la firma. Lo strumento non rigenera i metadati AVB Samsung per ldfw.img o tzsw.img; modificare i byte di secure-boot all'interno di questi wrapper richiede comunque la separata policy AVB usata dal flusso di avvio di destinazione. Una ROM firmata completa deve usare il modello AVB esatto e lo stesso bundle di chiavi, quindi essere flashato con il suo pacchetto generato completo. Vedi il repository CreckerROM e il flusso di installazione in USER_GUIDE.md.

Loader manomessi

I pacchetti manomessi inclusi preservano ogni membro BL di serie tranne sboot.bin.lz4. Quel membro viene rimosso e il uh.bin decompresso del pacchetto viene archiviato come sboot.bin, corrispondendo al layout che attiva EUB.

L'interfaccia può eseguire direttamente il flusso Heimdall corrispondente. Seleziona l'archivio manomesso del modello fisico esatto, verifica che sboot.bin sia byte-identico al uh.bin.lz4 decompresso, e flasha il payload UH validato nello slot BOOTLOADER:```bash python3 exploit/exploit.py --flash-tampered --model G986B --wait

Questo impedisce intenzionalmente l'avvio normale e forza il successivo avvio in EUB. Non esegue il flash dei membri rimanenti del
tar BL.

Rigenera un pacchetto con:```bash
python3 external/tools/build_tampered_loader.py \
  bootLoaderFiles/originalBl/G986B/BL_G986BXXSNHYB1.tar \
  bootLoaderFiles/tamperedLoader/G986B/BL_G986BXXSNHYB1_tampered.tar

Usa il loader manomesso del modello fisico esatto quando la sua directory è presente. La mappatura runtime accoppiata si applica al preflight e alla firma dell'exploit, non alla selezione del pacchetto BL stock/manomesso archiviato.

Tieni presente che se hai fuso il dispositivo, dovrai flashare un uh.bin firmato nella tua partizione BOOTLOADER, poiché lo uh stock è attualmente firmato con la chiave sbagliata.

Strumenti di Analisi

Dividi e unisci:```bash python3 exploit/split.py sboot.bin -o /tmp/G986B-splits python3 exploit/merge.py /tmp/G986B-splits

Il merger standalone richiede `tzsw.img` e `ldfw.img` nella directory parts e stampa il corrispondente comando Heimdall in tre parti. Usa quel comando solo quando quelle due immagini sono già state firmate per il modello selezionato; `--build-sboot` esegue e verifica automaticamente quella firma.

Estrai i singoli record LDFW:```bash
python3 external/tools/extract_ldfw.py ldfw.img -o LDFWs

Il layout di split fornito ricostruisce ogni stock sboot.bin canonico byte per byte. Anche la decrittazione/ricrittazione di EPBL e monitor EL3 torna byte per byte per tutte le famiglie di firmware quando l'header EPBL viene lasciato invariato.

Compatibilità dei Payload

Tutti i telefoni supportati condividono lo stesso BootROM Exynos 990. I payload utilizzano punti di ingresso BootROM comuni e indirizzi IRAM piuttosto che offset LK specifici del modello. I binari generati risolvono questi punti di ingresso:

Il comportamento specifico del modello è limitato al TSV LK, all'ID modello FWBL1 e alla revisione di rollback stock.

Layout dell'Immagine

Crediti e Attribuzioni

Chimera Tool: prima scoperta nota e uso pratico di questo exploit, circa 2021–2022.
Avviso CVE-2024-56426 di Samsung: documenta la vulnerabilità utilizzata da questo progetto.
Christopher Wade: ha segnalato CVE-2024-56426 a Samsung.
Umer Uddin (halal-beef), tramite halal-beef/hubble: il codice backend utilizzato da exploit/exploit.py; il layout SoC utilizzato da exploit/split.py e exploit/merge.py; e run_exploit(), che implementa l'operazione di indirizzo/sovrascrittura.
VDavid003 (David), tramite VDavid003/exynos-usbdl: lo scheletro del payload da cui è stato derivato il payload a chiave personalizzata Exynos990.

`bootLoaderFiles/originalBl/<model>/`	Pacchetti `BL_<firmware>.tar` puliti e specifici per modello esatto per tutti e dieci i modelli.
`bootLoaderFiles/sbootSplitParts_original/<model>/`	Split SBoot crittografati intatti e specifici per modello esatto, `ldfw.img`, `tzsw.img`, manifest e coda.
`bootLoaderFiles/exynos9830Decrypted/<model>/`	File di analisi EPBL, EL3, TZSW e LDFW decrittati e specifici per modello esatto.
`bootLoaderFiles/tamperedLoader/<model>/`	Pacchetti BL che attivano EUB e specifici per modello esatto.
`bootLoaderFiles/MODEL_COMPARISON.md`	Note sul confronto firmware esatto-versus-accoppiato e sulla compatibilità delle patch.
`bootLoaderFiles/exynos990Bootrom/`	Dump BootROM condiviso Exynos 990.
`bootromNotes/`	Note condivise sul flusso BootROM e sul contesto USB.
`drivers/windows/winusb/`	Pacchetto Houston WinUSB bloccato per BootROM/EUB `04e8:1234`.
`windows/`	Configurazione Windows nativa, attivazione dell'ambiente e installer driver con verifica hash.
`exploit/extra/images/<model>/`	Output preflight usa-e-getta specifico per modello.
`external/ghidra/`	TSV LK e KVM EL3 specifici per modello esatto più lo script di patch Ghidra.
`external/decompiled_G985F/`	File di riferimento decompilati solo per G985F.
`exynos990reverseEng_G985F/`	Progetto Ghidra solo per G985F.
`external/keys/exynos9830_crecker/`	Bundle di chiavi personalizzate condiviso.
`exploit/exploit.py`	Punto di ingresso CLI stabile e coordinatore del flusso di lavoro.
`exploit/build_payloads.py`	Builder payload nativo multipiattaforma usato dal preflight su Windows, Linux e macOS.
`exploit/preflight.py`	Preparazione dell'immagine di lavoro, patch LK, firma e verifica dell'unione.
`exploit/usb_transport.py`	Framing PyUSB, rilevamento dispositivi, sovrascrittura e trasporto dump.
`exploit/tampered_loader.py`	Estrazione UH specifica per modello esatto, validazione loader manomesso e flash EUB Heimdall.
`exploit/stock_restore.py`	Estrazione archivio stock specifico per modello esatto e costruzione comandi Heimdall.
`control_center/`	Azioni backend browser, controlli dipendenze, job e API HTTP.
`external/tools/*_crypto.py`	Primitive condivise AES e codifica/firma ECDSA EPBL/EL3.

`--prepare`	Esegue il preflight senza aprire la USB.
`--build-sboot`	Esegue il preflight e costruisce un `sboot.bin` firmato e verificato nella directory delle immagini del modello.
`--signed`	Invia il payload a chiave personalizzata e la catena di avvio firmata da EUB.
`--ufs`	Avvia il percorso di avvio UFS con `loader.bin`.
`--dump`	Esegue `mem.bin` e scarica `0x20000` byte di BootROM.
`--flash-tampered`	Valida l'UH specifico per modello esatto e lo flasha su BOOTLOADER per forzare EUB.
`--flash-stock`	Estrae e flasha SBoot, TZSW e LDFW stock specifici per modello esatto dal tar BL originale.

`fwbl1.img`	Chiave privata BL1 più blob pubblici Stage2 TEE/REE
`epbl.img`, `el3_mon.img`	Stage2 TEE
`bl2.img`, `lk.bin`	Stage2 REE
`ldfw.img`, `tzsw.img`	Stage2 TEE, footer Stage2 interni ed esterni

`mem.bin`	`0x02022010`	`0x02022010`
`loader.bin`	`0x02022010`	`0x02022010`
`Exynos990_boot_custom_key.bin`	`0x02022000`	stage 1 indipendente dalla posizione

`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`
Monitor EL3	`0xBFE80000`

CVE-2024-56426

Più Popolari