Exploit Unificado do BootROM Exynos 990 / Exynos9830

Ferramentas unificadas para CVE-2024-56426 nas famílias Galaxy S20, S20 FE e Note20 com Exynos 990. O exploit aceita todos os dez nomes de modelos e os mapeia em seis famílias verificadas de bootloader de estoque.

[!CAUTION] O pacote de chaves rastreado e as imagens geradas são capazes de fusão. A fusão é irreversível. Um telefone fundido a uma chave só pode inicializar imagens compatíveis com essa chave. Um modelo errado, revisão de rollback, conjunto de patches ou pacote de chaves pode deixar o dispositivo em um boot loop fundido. Use chaves de desenvolvimento e o payload UFS durante a iteração. Adicione --no-fuse a todos os comandos de preparação/assinatura, a menos que a fusão de chave personalizada seja explicitamente pretendida.

Modelos Suportados

O modelo selecionado controla tanto o ID de modelo BL1 quanto o TSV de patch LK do modelo exato. Runtime artifact controla qual firmware de estoque e imagens divididas criptografadas são usadas pelo preflight. As quatro flags não-5G que usam artefatos de runtime 5G emparelhados também corrigem a verificação de ID de modelo e o caminho de programação de ID de modelo do LK.

Flag de modelo	Runtime artifact	Firmware de runtime	ID de modelo	EVT	Rollback	Testado
`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`

Modo KVM e EL2 do Exynos 990

Todas as dez flags de modelo suportadas do Galaxy S20, S20 FE e Note20 têm um perfil de boot KVM opcional apenas via CLI. Compile um branch do kernel Exynos 990 cujo nome contenha kvm, e adicione --kvm ao comando do modelo exato, por exemplo:```bash python3 exploit/exploit.py --build-sboot --model G985F --no-fuse --kvm

Este perfil remove o caminho LK H-Arx/UH, pede ao EL3 para entrar no kernel em EL2 e aplica a tabela de patches correspondente do monitor EL3 descriptografada/re-criptografada. Ele permanece indisponível para modos de flash de bootloader padrão/adulterado. O centro de controle web intencionalmente não tem controle KVM. Com o kernel correspondente e o [WindowsInQemu](https://github.com/Creeeeger/WindowsInQemu), o Windows pode rodar no QEMU no telefone em velocidade total via KVM.

## Início Rápido

Não trate cada modo como uma sequência de instalação numerada. Escolha um objetivo:

| Objetivo                              | Caminho                                                                                                                     |
|---------------------------------------|-----------------------------------------------------------------------------------------------------------------------------|
| Instalar uma ROM personalizada assinada | Modelo/configuração exatos → EUB → cadeia temporária `--signed --no-fuse` → flash da saída assinada completa da ROM → primeiro boot UFS |
| Testar o exploit                  | Opcional `--prepare --no-fuse` → EUB → `--signed --no-fuse` → parar                                                       |
| Desenvolver a cadeia de boot (somente CLI) | Teste temporário no-fuse → compilar → flash do SBoot/TZSW/LDFW gerado → UFS                                                   |
| Dump / recuperação                   | Use seu fluxo de trabalho separado e verificações de estado de fusível                                                                          |

`--prepare` é uma simulação recomendada, não um pré-requisito obrigatório: `--signed`
repete a pré-verificação. O comando Heimdall de três partes gerado é uma ferramenta de desenvolvimento da cadeia de boot; não é um flash de ROM personalizada.

Leia o [USER_GUIDE.md](https://github.com/creeeeger/cve-2024-56426/blob/exynos990/USER_GUIDE.md) e escolha o fluxo de trabalho correspondente antes de tocar em um dispositivo. Ele inclui a entrega da ROM completa, além das regras de recuperação para estados sem fusível, com fusível e de estado incerto.

## UI Local Opcional

A UI do navegador usa apenas a biblioteca padrão do Python e chama a CLI existente
`exploit/exploit.py`. O desenvolvimento da cadeia de boot e seu comando Heimdall de três partes gerado permanecem ferramentas somente de terminal.

Inicie-a a partir da raiz do repositório:```bash
python3 exynos990_control_center.py

O launcher liga-se a 127.0.0.1, gera um novo token de acesso, imprime o URL local completo e abre-o no navegador predefinido. Utilize --no-browser quando o navegador não deva ser aberto automaticamente:```bash python3 exynos990_control_center.py --no-browser

A interface fornece:

- verificações verde/vermelho de dependências e ativos do repositório;
- uma escolha global de modelo-alvo e exatamente duas decisões de fusível: Permanecer sem fusível ou Fundir;
- um seletor de fluxo de trabalho que mostra e numera apenas as etapas do fluxo de trabalho selecionado;
- fluxos de trabalho de instalação de ROM, teste de exploit, despejo de BootROM e recuperação de estoque;
- uma ação de carregador adulterado específica do modelo que valida a UH e a grava no slot BOOTLOADER com o Heimdall para entrar no
  EUB;
- um aviso permanente de fusível e a impressão digital SHA-256 configurada da chave/eFuse;
- um cartão de restauração da cadeia de inicialização de estoque apenas sem fusível, indisponível após escolher Fundir;
- saída de processo ao vivo, cancelamento e marcadores de verificação por etapa.

Também mostra um aviso do KVM do Exynos 990 apenas via CLI, mas deliberadamente não expõe uma opção de KVM nem encaminha `--kvm` para nenhuma
ação web.

O acesso USB segue as permissões do processo que iniciou o centro de controle. Configure as permissões de udev/driver fornecidas antes de iniciá-lo. A interface não solicita, retém nem encaminha credenciais de privilégio. Mantenha o URL do token impresso privado e pare o servidor imediatamente após o uso.

Usuários de terminal podem ignorar `exynos990_control_center.py`; todos os comandos CLI documentados abaixo permanecem inalterados e totalmente suportados.

## Requisitos

Python 3.10 ou mais recente é necessário.

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

A configuração instala uma toolchain nativa AArch64 fixada, LZ4, Heimdall e um ambiente virtual do repositório, e então compila todos os payloads. O driver WinUSB do BootROM é uma adesão explícita do Administrador porque o certificado autoassinado upstream altera os repositórios de confiança da máquina. Consulte WINDOWS.md para o processo completo de configuração, instalação do driver, distinção do Modo Download, verificação e resolução de problemas.

Após a ativação do Windows, use python onde os exemplos multiplataforma restantes mostram 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

Layout do Repositório

Pré-verificação

Preparação, assinatura e modos de payload executam a mesma pré-verificação ciente do modelo:

Resolver o modelo selecionado para sua família de artefatos canônica.
Substituir exploit/extra/images/<model>/ por uma cópia limpa das imagens divididas criptografadas intactas.
Aplicar o TSV de LK correspondente com verificações estritas de bytes stock. Com --no-fuse, gerar uma cópia TSV efetiva com as cinco linhas de fusão desabilitadas primeiro. Com --kvm, também habilitar as linhas de LK marcadas kvm, descriptografar e aplicar patch no TSV do monitor EL3 correspondente e re-criptografar sua região protegida.
Construir mem.bin, loader.bin e Exynos990_boot_custom_key.bin.
Confirmar que EPBL e monitor EL3 estão criptografados, re-criptografando apenas quando necessário.
Validar os metadados de modelo/EVT/rollback do FWBL1 stock e cada rodapé de rollback do Stage2 antes de assinar.
Assinar FWBL1 com o ID de modelo selecionado e assinar todos os componentes do Stage2 com a revisão de rollback stock.
Verificar cada assinatura gerada do Stage2 antes da transferência USB.

O processo para no primeiro erro de firmware, patch, metadados ou assinatura. Ele nunca aplica patch nos diretórios de origem imutáveis no local.

Modos de Exploit

Todos os comandos exigem --model.

--no-fuse é um modificador, não um modo independente. Ele desabilita cinco linhas OTP identificadas de chave personalizada ao reconstruir o LK de trabalho. Use-o para todo comando que prepara, envia ou constrói uma cadeia de desenvolvimento sem fusão. Ele não desfaz uma fusão existente.

A CLI aceita o modificador com modos UFS e dump porque esses comandos também executam pré-verificação, mas suas operações USB não transmitem o LK reconstruído. O LK já gravado no telefone determina o comportamento de fusão UFS. Consequentemente, a interface deliberadamente não oferece controle de no-fuse para UFS ou modo de dump do BootROM. Ambos os modos de flash do bootloader rejeitam --no-fuse porque não realizam patch ou assinatura de LK.

--kvm também é um modificador. Ele é aceito com todo fluxo de trabalho exato por modelo que executa pré-verificação. Linhas KVM nos TSVs são ignoradas a menos que este sinalizador esteja presente, e a interface do navegador nunca o fornece.

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

Gere o bootloader assinado correspondente sem abrir o USB:```bash
python3 exploit/exploit.py --build-sboot --model N986B --no-fuse

O comando reconstrói o diretório de imagens do modelo a partir de entradas stock limpas, aplica o patch LK, assina e verifica cada componente, mescla sboot.bin, verifica os componentes incorporados e a cauda, e imprime o seu tamanho, SHA-256 e um comando Heimdall que envia sboot.bin, tzsw.img assinado e ldfw.img assinado.

Apenas num dispositivo conhecido por estar não fundido, restaure a cadeia de boot stock exata a partir do tar BL original do modelo selecionado:```bash python3 exploit/exploit.py --flash-stock --model N986B --wait

O comando extrai apenas `sboot.bin.lz4`, `tzsw.img.lz4` e
`ldfw.img.lz4`, descompacta-os num diretório temporário, verifica se os três resultados estão presentes e não vazios, e
invoca uma operação de flash do Heimdall. Os ficheiros temporários são removidos depois. `--no-reboot` e `--verbose` também são
suportados. O telemóvel já deve estar num modo de download compatível com Heimdall, e o modelo selecionado deve corresponder exatamente
ao dispositivo físico.

Isto não restaura Android, AP, modem, CSC, userdata ou uma ROM stock completa. Nunca o execute num dispositivo com
fusão de chave personalizada. Tal telemóvel requer software baseado em stock re-assinado com a chave fundida exata; a raiz de confiança personalizada permanece
permanente. Se o estado da fusão for desconhecido, pare.

## Nota sobre Recuperação FRP / Persistente

> [!CAUTION]
> Este procedimento destina-se apenas a um dispositivo que possui pessoalmente e para o qual está
> autorizado a efetuar manutenção. Usá-lo no dispositivo de outra pessoa é estritamente
> proibido. Um caminho de partição errado pode causar perda permanente de dados ou deixar
> o dispositivo sem capacidade de arranque. Faça uma cópia de segurança da partição de destino e verifique o seu caminho
> de dispositivo de bloco resolvido e o tamanho antes de escrever qualquer coisa.

Este repositório não remove automaticamente a Proteção de Reposição de Fábrica (FRP). Em dispositivos que usam o
`PersistentDataBlockService` do Android, o estado de FRP é armazenado na partição normalmente chamada `PERSISTENT`. Consulte a
[implementação AOSP](https://android.googlesource.com/platform/frameworks/base/+/bc56632da95b/services/core/java/com/android/server/PersistentDataBlockService.java).

Depois de a cadeia de exploração ter arrancado uma recuperação personalizada que fornece `adb` e
`dd`, identifique e faça uma cópia de segurança da partição. Não substitua por um caminho de dispositivo de bloco numérico adivinhado:```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

Apenas depois de o backup ter sido extraído, zere a partição e deixe o Android inicializar uma nova estrutura de bloco de dados persistentes:```bash adb shell dd if=/dev/zero of=/dev/block/by-name/persistent reboot

Este método é testado e funciona, o FRP é removido e o dispositivo é desbloqueado.

## Patches de LK

A seleção de patches segue o mapeamento de artefatos:```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

Valide um TSV contra o LK padrão sem alterá-lo:```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` aceita o mesmo formato TSV de seis colunas e agora falha em incompatibilidades de bytes antigos
em vez de aplicar um patch às cegas. Linhas cuja primeira coluna é `kvm` exigem um argumento de script adicional `--kvm`.
As linhas legadas `check_signature` e `check_ext4_signature` com retorno zero usam o
perfil `0`: elas documentam os locais antigos de bypass, mas deliberadamente não são
aplicadas, portanto as imagens construídas devem satisfazer as verificações de assinatura reais da Samsung do LK.

## Assinatura

`external/tools/sign_sboot_images.py` exige um modelo e deriva o ID do modelo, EVT e revisão de rollback de
[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

As assinaturas Stage2 são verificadas após a assinatura. A ferramenta não regenera os metadados AVB da Samsung para ldfw.img ou tzsw.img; alterar os bytes de secure-boot dentro desses wrappers ainda exige a política AVB separada usada pelo fluxo de boot de destino. Uma ROM assinada completa deve usar o modelo AVB exato e o mesmo conjunto de chaves, e então ser gravada com seu pacote gerado completo. Consulte o repositório CreckerROM e o fluxo de instalação em USER_GUIDE.md.

Loaders adulterados

Os pacotes adulterados incluídos preservam todos os membros BL originais, exceto sboot.bin.lz4. Esse membro é removido e o uh.bin descompactado do pacote é armazenado como sboot.bin, correspondendo ao layout que aciona o EUB.

A interface pode executar o fluxo Heimdall correspondente diretamente. Ela seleciona o arquivo adulterado do modelo físico exato, verifica se sboot.bin é byte-idêntico ao uh.bin.lz4 descompactado e grava o payload UH validado no slot BOOTLOADER:```bash python3 exploit/exploit.py --flash-tampered --model G986B --wait

Isto impede intencionalmente o arranque normal e força o próximo arranque para o EUB. Não grava os restantes membros do
tar BL.

Regenerar um pacote com:```bash
python3 external/tools/build_tampered_loader.py \
  bootLoaderFiles/originalBl/G986B/BL_G986BXXSNHYB1.tar \
  bootLoaderFiles/tamperedLoader/G986B/BL_G986BXXSNHYB1_tampered.tar

Use the exact physical model's tampered loader when its directory is present. The coupled runtime mapping applies to exploit preflight and signing, not to the archived stock/tampered BL package selection.

Keep in mind that if you fused the device, you will need to flash a signed uh.bin to your BOOTLOADER slot, since the stock uh is currently signed with the wrong key.

Analysis Tools

Split and merge:```bash python3 exploit/split.py sboot.bin -o /tmp/G986B-splits python3 exploit/merge.py /tmp/G986B-splits

O merger autónomo requer `tzsw.img` e `ldfw.img` no diretório de partes e imprime o comando Heimdall correspondente de três partes.
Use esse comando apenas quando essas duas imagens já tiverem sido assinadas para o modelo selecionado;
`--build-sboot` executa e verifica essa assinatura automaticamente.

Extraia registros LDFW individuais:```bash
python3 external/tools/extract_ldfw.py ldfw.img -o LDFWs

O layout dividido fornecido reconstrói cada sboot.bin canônico de estoque byte por byte. O EPBL e o monitor EL3 também fazem descriptografia/re-criptografia de ida e volta byte por byte para todas as famílias de firmware quando o cabeçalho do EPBL é deixado inalterado.

Compatibilidade de Payload

Todos os telefones suportados compartilham o mesmo BootROM Exynos 990. Os payloads usam pontos de entrada comuns do BootROM e endereços de IRAM em vez de offsets de LK específicos do modelo. Os binários gerados resolvem para estes pontos de entrada:

O comportamento específico do modelo está confinado ao TSV do LK, ao ID do modelo FWBL1 e à revisão de rollback de estoque.

Layout da Imagem

Créditos e Atribuição

Chimera Tool: descoberta conhecida mais antiga e uso prático deste exploit, por volta de 2021–2022.
Aviso CVE-2024-56426 da Samsung: documenta a vulnerabilidade usada por este projeto.
Christopher Wade: relatou a CVE-2024-56426 à Samsung.
Umer Uddin (halal-beef), por meio de halal-beef/hubble: o código de backend usado por exploit/exploit.py; o layout do SoC usado por exploit/split.py e exploit/merge.py; e run_exploit(), que implementa a operação de endereço/sobrescrita.
VDavid003 (David), por meio de VDavid003/exynos-usbdl: o esqueleto de payload do qual o payload de chave personalizada Exynos990 foi derivado.

`bootLoaderFiles/originalBl/<model>/`	Pacotes `BL_<firmware>.tar` limpos e exatos por modelo para todos os dez modelos.
`bootLoaderFiles/sbootSplitParts_original/<model>/`	Divisões SBoot criptografadas exatas por modelo intactas, `ldfw.img`, `tzsw.img`, manifesto e cauda.
`bootLoaderFiles/exynos9830Decrypted/<model>/`	Arquivos de análise EPBL, EL3, TZSW e LDFW descriptografados exatos por modelo.
`bootLoaderFiles/tamperedLoader/<model>/`	Pacotes BL que acionam EUB exatos por modelo.
`bootLoaderFiles/MODEL_COMPARISON.md`	Comparação de firmware exato versus acoplado e notas de compatibilidade de patch.
`bootLoaderFiles/exynos990Bootrom/`	Despejo compartilhado do BootROM do Exynos 990.
`bootromNotes/`	Notas compartilhadas de fluxo do BootROM e contexto USB.
`drivers/windows/winusb/`	Pacote Houston WinUSB fixado para BootROM/EUB `04e8:1234`.
`windows/`	Configuração nativa do Windows, ativação de ambiente e instalador de driver com verificação de hash.
`exploit/extra/images/<model>/`	Saída de pré-verificação descartável específica por modelo.
`external/ghidra/`	TSVs exatos por modelo de LK e KVM EL3 mais o script de patch do Ghidra.
`external/decompiled_G985F/`	Arquivos de referência descompilados exclusivos do G985F.
`exynos990reverseEng_G985F/`	Projeto Ghidra exclusivo do G985F.
`external/keys/exynos9830_crecker/`	Pacote de chaves personalizadas compartilhado.
`exploit/exploit.py`	Ponto de entrada CLI estável e coordenador de fluxo de trabalho.
`exploit/build_payloads.py`	Construtor de payloads nativo multiplataforma usado pela pré-verificação no Windows, Linux e macOS.
`exploit/preflight.py`	Preparação da imagem de trabalho, patch de LK, assinatura e verificação de mesclagem.
`exploit/usb_transport.py`	Enquadramento PyUSB, descoberta de dispositivo, sobrescrita e transporte de despejo.
`exploit/tampered_loader.py`	Extração de UH exata por modelo, validação de loader adulterado e flash EUB via Heimdall.
`exploit/stock_restore.py`	Extração de arquivo stock exato por modelo e construção de comando Heimdall.
`control_center/`	Ações de backend do navegador, verificações de dependência, tarefas e API HTTP.
`external/tools/*_crypto.py`	Primitivas compartilhadas de codificação/assinatura AES e ECDSA de EPBL/EL3.

`--prepare`	Executar pré-verificação sem abrir USB.
`--build-sboot`	Executar pré-verificação e construir um `sboot.bin` assinado e verificado no diretório de imagem do modelo.
`--signed`	Enviar o payload de chave personalizada e a cadeia de inicialização assinada do EUB.
`--ufs`	Iniciar o caminho de inicialização UFS com `loader.bin`.
`--dump`	Executar `mem.bin` e despejar `0x20000` bytes do BootROM.
`--flash-tampered`	Validar UH exato por modelo e gravá-lo no BOOTLOADER para forçar EUB.
`--flash-stock`	Extrair e gravar SBoot, TZSW e LDFW stock exatos por modelo do tar BL original.

`fwbl1.img`	Chave privada BL1 mais blobs públicos Stage2 TEE/REE
`epbl.img`, `el3_mon.img`	Stage2 TEE
`bl2.img`, `lk.bin`	Stage2 REE
`ldfw.img`, `tzsw.img`	Stage2 TEE, rodapés Stage2 internos e externos

`mem.bin`	`0x02022010`	`0x02022010`
`loader.bin`	`0x02022010`	`0x02022010`
`Exynos990_boot_custom_key.bin`	`0x02022000`	estágio 1 independente de posição

`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

Mais Populares