Pesquisa de tese de mestrado sobre CVE-2024-30051 (Windows DWM Heap Overflow). Apresenta um exploit de alta confiabilidade com otimização automatizada de heap spray, registro em tempo real e análise empírica de taxa de sucesso. Peça de portfólio demonstrando exploração avançada de binários Windows, manipulação de layout de heap e LPE via Desktop Window Manager.
devianntsec/cve-2024-30051
Estouro de Buffer Baseado em Heap no Gerenciador de Janelas da Área de Trabalho do Windows (
dwmcore.dll)
Escalação de Privilégio Local → Nível de Integridade SYSTEM via processo DWM
Alvo de compilação: Windows 11 22H2 (10.0.22621.3447) · Patch: KB5037771
Este repositório contém minha pesquisa de Tese de Mestrado sobre CVE-2024-30051,
uma vulnerabilidade de Escalação de Privilégio de alta severidade (CVSS 7.8) na
Biblioteca Principal do Gerenciador de Janelas da Área de Trabalho do Windows (dwmcore.dll).
A vulnerabilidade se origina de um erro de cálculo de tamanho na divisão inteira em
CCommandBuffer::Initialize. O tamanho usado para new() e o tamanho usado para memcpy()
divergem devido a esse erro, produzindo um estouro de heap de 0x8F bytes. Uma
exploração bem-sucedida faz com que dwm.exe carregue uma DLL controlada pelo atacante,
executando código arbitrário sob a conta window manager\dwm-1 com Nível de Integridade SYSTEM.
| Aspecto | Descrição |
|---|---|
| Diferenciação de patch | Análise completa de BinDiff identificando CCommandBuffer::Initialize como o lócus exato da vulnerabilidade (pontuação de similaridade 0,32 vs. global 0,98 em 14.062 funções correspondentes) |
| Análise dinâmica com WinDbg | Verificação passo a passo de todos os 4 hooks, substituição do campo de tamanho e construção do payload |
| Análise empírica de heap spray | 50 sessões controladas em duas configurações de RAM (8.192 MB e 4.096 MB) com testes estatísticos formais |
| Resultados estatísticos | Mann-Whitney U (p = 0,031) e teste t de Welch (p = 0,011) confirmam efeito da RAM; médias observadas 12,9–19× melhores que a previsão teórica de ~64 tentativas |
| Caminho da DLL de payload centralizado | Caminho codificado extraído para a constante de pré-processador #define PAYLOAD_DLL_PATH |
| Registro de sessão | Log completo com timestamp por sessão escrito em %TEMP%\cve_30051_log.txt |
| Documentação acadêmica | Causa raiz, análise de heap spray de 50 sessões e cronologia do CVE |
-orange){kind=icon}
CVE-2024-30051-Masters-Thesis/
├── README.md
├── LICENSE
├── setup.bat # Copia s11.dll para o local necessário
│
├── exploit/
│ ├── C21.sln # Solução Visual Studio 2022
│ ├── exploit_src/
│ │ ├── c26f.vcxproj
│ │ ├── c26f.filters
│ │ └── main.cpp # Exploit — heap spray + hook + estouro
│ └── payload/
│ ├── payload.vcxproj
│ ├── payload.vcxproj.filters
│ ├── dllmain.cpp # DLL de payload — spawna shell SYSTEM + limpeza
│ ├── framework.h
│ ├── pch.h
│ └── pch.cpp
│
└── docs/
├── screenshots/ # Capturas de diferenciação de patch, WinDbg e forense
└── analysis/
├── 01-root-cause.md # Bug de divisão inteira em CCommandBuffer::Initialize
├── 02-heap-spray.md # Dados empíricos de 50 sessões e resultados estatísticos
└── 03-timeline.md # Cronologia de descoberta, divulgação e patch
Abra C21.sln no Visual Studio 2022. Compile o projeto payload em Release x64.
Execute setup.bat a partir da raiz do repositório. Ele copia s11.dll para
C:\Users\Public\Documents\s11.dll (o caminho definido por PAYLOAD_DLL_PATH).
⚠️ A DLL deve estar neste caminho exato antes de executar
C26f.exe. Colocá-la junto ao executável não funcionará.
Compile o projeto C26f em Release x64.
x64\Release\C26f.exe
Execute a partir de um CMD padrão (não elevado). O exploit tenta automaticamente novamente até 10 vezes.
Em caso de sucesso, dwm.exe carrega s11.dll e spawna um CMD com Nível de Integridade SYSTEM.
Um log de sessão é escrito em %TEMP%\cve_30051_log.txt.
#define MAX_ATTEMPTS 10 // Máx. de tentativas automáticas por sessão
#define SPRAY_STEP 0x10 // Índice de espaçamento de buracos (1024 buracos)
#define SPRAY_RANGE_START 0x3000 // Índice inicial do intervalo de spray
#define SPRAY_RANGE_END 0x7000 // Índice final do intervalo de spray
#define SLEEP_POST_SPRAY 0xC8 // ms de espera após spray (200ms)
#define SLEEP_POST_HOLES 0xC8 // ms de espera após liberar buracos (200ms)
#define PAYLOAD_DLL_PATH "C:\\Users\\Public\\Documents\\s11.dll"
Em CCommandBuffer::Initialize (dwmcore.dll 10.0.22621.3447),
CD2DSharedBuffer::GetBufferSize é chamado duas vezes. O tamanho passado para new() sofre
divisão inteira por 0x90 antes da multiplicação, enquanto memcpy() usa o valor bruto:
buffer_size = GetBufferSize() → ex. 0x23F
size_new = (0x23F / 0x90) * 0x90 = 0x1B0 ← alocado
size_memcpy = 0x23F ← copiado
estouro = 0x23F - 0x1B0 = 0x8F bytes
Comparação BinDiff entre o build 10.0.22621.3447 (vulnerável) e 10.0.22621.3593 (corrigido):
| Métrica | Valor |
|---|---|
| Similaridade global | 0,98 |
| Confiança | 0,99 |
| Funções correspondentes | 14.062 (99,1%) |
Similaridade de CCommandBuffer::Initialize | 0,32 |
| Blocos básicos — versão vulnerável | 4 |
| Blocos básicos — versão corrigida | 20 (16 blocos de validação adicionados) |
A pontuação anômala de 0,32 contra uma similaridade global de 0,98 é a assinatura direta do lócus da vulnerabilidade.
1. Hook RtlCreateHeap → capturar handle do heap do dwmcore
2. Hook RtlAllocateHeap → capturar endereço base do chunk
3. Hook NtDCompositionCreateChannel → capturar MappedAddress (região de memória compartilhada)
4. Hook NtDCompositionCommitChannel → sobrescrever campo de tamanho (0x120 → 0x23F)
injetar comandos de lote adicionais
5. Heap spray de 0x10000 objetos CHolographicInteropTexture (tamanho=0x1B0)
6. Liberar buracos a cada 0x10 índices → criar lacunas para o pouso do estouro
7. Escrever payload no buffer de estouro → KCBTable+0x388 + LoadLibraryA + caminho da DLL
8. Liberar todos os objetos do spray → acionar estouro → LoadLibraryA("s11.dll")
9. dwm.exe carrega DLL de payload → spawna CMD como integridade SYSTEM
A RAM disponível influencia o número de tentativas necessárias para um heap spray bem-sucedido?
Dois blocos de 25 sessões cada. Protocolo por sessão: restaurar snapshot limpo pós-inicialização → aguardar 100 segundos de estabilização → lançar exploit → registrar tentativa bem-sucedida.
| Bloco | RAM | Sessões | Sucessos | Falhas |
|---|---|---|---|---|
| A | 8.192 MB | 25 | 24 | 1 |
| B | 4.096 MB | 25 | 24 | 1 |