
Um PoC da vulnerabilidade CVE-2024-56426.
Ferramentas unificadas para CVE-2024-56426 para as famílias Exynos 990 Galaxy S20, S20 FE e Note20. O exploit aceita todos os dez nomes de modelo e os mapeia para seis famílias de bootloader stock verificadas.
[!CAUTION] O pacote de chaves rastreado e as imagens geradas são capazes de fusing. O fusing é irreversível. Um telefone com fusing aplicado a uma chave só pode inicializar imagens compatíveis com essa chave. Um modelo, revisão de rollback, conjunto de patches ou pacote de chaves incorreto pode deixar o dispositivo em um loop de boot com fusing. Use chaves de desenvolvimento e o payload UFS durante a iteração. Adicione
--no-fusea todo comando de preparação/assinatura, a menos que o fusing com chave personalizada seja explicitamente pretendido.
O modelo selecionado controla tanto o ID de modelo do BL1 quanto o TSV de patch LK específico do modelo. O Runtime artifact controla qual
firmware stock e imagens divididas criptografadas são usados pelo preflight. As quatro flags não-5G que usam artefatos de runtime 5G
emparelhados também aplicam patch na verificação de ID de modelo do LK e no caminho de programação do ID de modelo.
[!IMPORTANT] Nas builds de firmware stock listadas abaixo, G780F, N980F, N981B, N985F e N986B não podem usar o método UH-to-BOOTLOADER para entrar no EUB. Seus bootloaders LK chamam
Check_signinfo(), que compara oBinaryNameembutido na imagem (uh.bin) com o nome de arquivo esperado da partição BOOTLOADER (sboot.bin). A incompatibilidade produzBinaryname has changed (uh.bin) -> (sboot.bin)e rejeita o flash.Use os pontos de teste apropriados para cada modelo para entrar no EUB nesses dispositivos em vez do método UH.
| Flag de modelo | Artefato de runtime | Firmware de runtime | ID de modelo | EVT | Rollback | Testado | Método UH / entrada EUB |
|---|---|---|---|---|---|---|---|
G780F | G780F | G780FXXSOFYJ1 | 0x154 | 11 | 24 | ❌ | Bloqueado — use pontos de teste |
G980F | G981B | G981BXXSNHYB1 | 0x143 | 11 | 23 | ✅ | Sem bloqueio de nome de arquivo |
G981B | G981B | G981BXXSNHYB1 | 0x13D | 11 | 23 | ❌ | Sem bloqueio de nome de arquivo |
G985F | G986B | G986BXXSNHYB1 | 0x142 | 11 | 23 | ✅ | Sem bloqueio de nome de arquivo |
G986B | G986B | G986BXXSNHYB1 | 0x13C | 11 | 23 | ✅ | Sem bloqueio de nome de arquivo |
G988B | G988B | G988BXXSNHYB1 | 0x13E | 11 | 23 | ❌ | Sem bloqueio de nome de arquivo |
N980F | N981B | N981BXXSIHYH3 | 0x153 | 11 | 18 | ❌ | Bloqueado — use pontos de teste |
N981B | N981B | N981BXXSIHYH3 | 0x14E | 11 | 18 | ❌ | Bloqueado — use pontos de teste |
N985F | N986B | N986BXXSIHYH3 | 0x152 | 11 | 18 | ❌ | Bloqueado — use pontos de teste |
N986B | N986B | N986BXXSIHYH3 | 0x14D | 11 | 18 | ❌ | Bloqueado — use pontos de teste |
Todas as dez flags de modelo suportadas do Galaxy S20, S20 FE e Note20 têm um perfil de boot KVM
opt-in apenas via CLI. Construa um branch
do kernel Exynos 990
cujo nome contenha kvm, e adicione --kvm ao comando específico do modelo, por exemplo:
python3 exploit/exploit.py --build-sboot --model G985F --no-fuse --kvm
Este perfil remove o caminho LK H-Arx/UH, solicita ao EL3 que entre no kernel em EL2 e aplica a tabela correspondente de patches do monitor EL3 descriptografados/recriprografados. Ele permanece indisponível para modos de flash de bootloader stock/adulterado. O centro de controle web intencionalmente não possui controle KVM. Com o kernel correspondente e o WindowsInQemu, o Windows pode ser executado no QEMU no telefone com velocidade total via KVM.
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 → build → flash do SBoot/TZSW/LDFW gerados → UFS |
| Dump / recuperação | Use seu fluxo de trabalho separado e verificações de estado de fuse |
--prepare realiza preparação apenas no host: substitui imagens de trabalho geradas e compila e assina arquivos locais,
sem abrir USB. Não é um dry-run somente leitura nem um predecessor obrigatório: --signed repete o preflight.
O comando Heimdall de três partes gerado é uma ferramenta de desenvolvimento da cadeia de boot; não é um flash de ROM personalizada.
Leia USER_GUIDE.md e escolha seu fluxo de trabalho correspondente antes de tocar em um dispositivo. Ele inclui a transferência de ROM completa, além das regras de recuperação para estados unfused, fused e incerto.
O servidor HTTP da UI do navegador usa a biblioteca padrão do Python e chama a CLI existente exploit/exploit.py.
A validação do key-bundle e a execução de ferramentas também exigem os pacotes em requirements.txt. O desenvolvimento da cadeia de boot e
seu comando Heimdall de três partes gerado permanecem ferramentas somente de terminal.
Inicie-o a partir da raiz do repositório:
python3 exynos990_control_center.py
O launcher se vincula a 127.0.0.1, gera um novo token de acesso, imprime a URL local completa e a abre no navegador
padrão. Use --no-browser quando um navegador não deve ser aberto automaticamente:
python3 exynos990_control_center.py --no-browser
A interface fornece:
Também mostra um aviso de KVM do Exynos 990 apenas para CLI, mas deliberadamente não expõe uma opção de KVM nem encaminha --kvm para qualquer
ação web.