voidsec/driverbuddyreloadedDriver Buddy Reloaded é um plugin Python para IDA Pro que ajuda a automatizar algumas tarefas tediosas de engenharia reversa de Drivers de Kernel do Windows.
O método de instalação depende da sua versão do IDA, pois o gerenciador de plugins embutido (e, portanto, a ferramenta hcli e o manifesto ida-plugin.json) existe apenas no IDA 9.0 ou superior. IDA 7.6 e 8.x não possuem gerenciador de plugins e apenas escaneiam o nível superior da pasta de plugins.
hcli)O repositório inclui um manifesto ida-plugin.json, então o IDA 9.0+ carrega o plugin a partir do seu próprio subdiretório. Instale-o com:```
hcli plugin install DriverBuddyReloaded
Isto coloca o plugin num subdiretório da sua pasta de plugins de utilizador (por exemplo,
`%APPDATA%\Hex-Rays\IDA Pro\plugins\DriverBuddyReloaded\` ou `~/.idapro/plugins/DriverBuddyReloaded/`), mantendo o
ponto de entrada `DriverBuddyReloaded.py` *dentro* desse subdiretório. Esta é a estrutura pretendida: o IDA lê o manifesto,
carrega o ponto de entrada declarado a partir do subdiretório e coloca o subdiretório em `sys.path` para que o ponto de
entrada possa importar o pacote `DriverBuddyReloaded` irmão. **Não** é necessário mover `DriverBuddyReloaded.py` para o
nível superior.
Verifique a instalação com `hcli plugin status` e, em seguida, inicie o IDA e confirme que o plugin aparece em
`Edit -> Plugins` (verifique a janela Output para quaisquer erros de Python no arranque).
Para instalar a partir de uma cópia local para teste (por exemplo, após as suas próprias alterações), execute
`hcli plugin install .` a partir da raiz do repositório; `hcli plugin lint .` valida primeiro o manifesto/estrutura.
### IDA 7.6 / 8.x (cópia manual)
Estas versões não possuem gestor de plugins, pelo que um plugin de subdiretório instalado via `hcli` **não** será
detetado. Copie a pasta `DriverBuddyReloaded` e o ficheiro de script `DriverBuddyReloaded.py` diretamente para o
**nível superior** da pasta de plugins do IDA, por exemplo:
- `%APPDATA%\Hex-Rays\IDA Pro\plugins\`
- `C:\Program Files\IDA Pro 8.4\plugins\`
- `~/.idapro/plugins/`
A estrutura resultante é `plugins\DriverBuddyReloaded.py` juntamente com `plugins\DriverBuddyReloaded\` (a pasta do
pacote).
### Notas
Se o seu IDA estiver configurado para Python 2, execute o binário `idapyswitch` (localizado na pasta do IDA) para
mudar para Python 3.
**NOTA:** O Driver Buddy Reloaded funciona no IDA 7.6+, 8.x (incluindo 8.4) e 9.0+ com Python 3. Todas as diferenças
da API do IDA específicas de versão (a remoção de `get_inf_structure`, o módulo `ida_struct` e os helpers
`idc.*struc*` no IDA 9.0, etc.) são tratadas internamente pela camada de compatibilidade
`DriverBuddyReloaded/ida_compat.py`.
## Utilização Rápida
Para utilizar a funcionalidade de análise automática:
1. Inicie o IDA e carregue um driver de kernel Windows.
2. Vá a `Edit -> Plugins -> Driver Buddy Reloaded` ou prima `CTRL+ALT+A` para iniciar a análise automática.
3. Verifique a janela "Output" para os resultados da análise e a janela **Driver Buddy Reloaded - Findings** que abre
no final da execução (clique duas vezes numa linha para saltar para o seu endereço).
4. Os seguintes ficheiros são escritos no diretório DB do IDA (todos prefixados com `<DRIVER_NAME>-YYYY-MM-DD-TIMESTAMP-`):
- `findings.json` - descobertas legíveis por máquina (IOCTLs, funções sinalizadas, nomes de dispositivos, pooltags, cadeias de chamadas, heurísticas, auditoria ACL de dispositivos, links simbólicos, auditoria de exportações, opcodes privilegiados)
- `report.html` - um relatório HTML autónomo, agrupado por gravidade
- `pooltags.txt` - Pooltags descarregados no formato `pooltags.txt` para WinDbg
- `autoanalysis.txt` - o registo de análise de texto completo (espelha a janela Output)
Para descodificar um IOCTL:
1. Coloque o cursor do rato na linha que contém um código IOCTL suspeito.
2. Clique com o botão direito e selecione `Driver Buddy Reloaded -> Decode IOCTL`; alternativamente, prima o atalho
`CTRL+ALT+D`.
Para reabrir a janela de IOCTLs ou a janela de descobertas a qualquer momento (sem reexecutar a análise):
- Prima `CTRL+ALT+I` para abrir a janela de IOCTLs.
- Prima `CTRL+ALT+F` para abrir a janela de descobertas.
### Utilização Avançada
- O diretório [vulnerable_function_lists](https://github.com/voidsec/driverbuddyreloaded/blob/HEAD/DriverBuddyReloaded/vulnerable_functions_lists) contém listas de funções,
APIs Windows e opcodes potencialmente perigosos/problemáticos; é fornecida uma breve descrição sobre o motivo pelo
qual uma função/API específica foi listada. Pode editar a lista `custom` incluindo funções específicas do driver.
**Nota**: `winapi_function_prefixes` fará correspondência parcial com o início do nome da função (por exemplo,
`Zw` corresponderá a `ZwClose`, `ZwCommitComplete` e assim por diante), enquanto `winapi_functions` fará apenas
correspondências exatas.
- Em [find_opcodes.py](https://github.com/voidsec/driverbuddyreloaded/blob/HEAD/DriverBuddyReloaded/find_opcodes.py), a opção `find_opcode_data` (predefinido `False`)
suprime correspondências de opcode que caem em secções de dados
([issue #11](https://github.com/VoidSec/DriverBuddyReloaded/issues/11)). Mudá-la para `True` também revela
correspondências de bytes brutos em dados; se um opcode real foi perdido desta forma, ir para o endereço reportado
e redefinir os bytes como código geralmente recupera-o. As correspondências são reportadas como qualquer outra
fase (janela de resultados, `findings.json`, `report.html`).
**Cuidado**: mudá-la para `True` gera mais falsos positivos!
## Sobre o Driver Buddy Reloaded
**Driver Buddy Reloaded** é um plugin Python para IDA Pro que ajuda a automatizar algumas tarefas tediosas de
engenharia reversa de drivers de kernel Windows. Possui várias funcionalidades úteis, tais como:
* Identificar o tipo de driver (WDM, KMDF, UMDF, WDF, Mini-Filter, Stream Minidriver, AVStream, PortCls)
* Localizar funções `DispatchDeviceControl` / `DispatchInternalDeviceControl` para **cada** tipo de driver
(uma pesquisa de armazenamento `MajorFunction[IRP_MJ_DEVICE_CONTROL]` encontra o manipulador mesmo num driver
minifilter/WDF que também expõe um dispositivo de controlo legado, e mesmo quando a atribuição vive num helper
em vez de `DriverEntry`)
* Popular estruturas comuns para drivers `WDF` e `WDM`
* Tenta identificar e rotular estruturas como `IRP` e `IO_STACK_LOCATION`
* Rotula chamadas a funções `WDF` que normalmente não seriam rotuladas
* Cria uma enumeração IDA `IRP_MJ_FUNCTION` e aplica-a a slots do array `MajorFunction` em `DriverEntry` (WDM)
* Encontrar e descodificar códigos IOCTL
* Pesquisa multi-estratégia automática de funções de despacho identificadas (sem necessidade de colocação do
cursor): ctree do descompilador (recupera códigos ocultos por tabela de saltos ou pesquisa binária que nunca
aparecem como imediatos), recuperação de tabela de saltos do IDA e uma alternativa de operando imediato bruto
(a alternativa executa apenas numa função que realmente lê o IoControlCode do IRP, pelo que um helper de
biblioteca mal identificado não pode vazar as suas constantes internas como IOCTLs falsos)
* Valores NTSTATUS resolvidos dinamicamente a partir da base de dados de tipos do IDA (com uma alternativa
hardcoded abrangente), e IOCTLs de **saída** que o driver apenas envia a jusante
(`IoBuildDeviceIoControlRequest` / `ZwDeviceIoControlFile` / ...) são excluídos para que não sejam confundidos
com a superfície de ataque do próprio driver
* Sinalizar funções propensas a uso indevido
* Encontrar potenciais `DeviceName` (pesquisa mmap + alternativa Strings DB do IDA, com endereço de origem)
* Descarregar `Pooltags` (primária baseada em importações + alternativa propagada por registo para tags
colocadas num registo)
* **Verificações heurísticas de vulnerabilidade** sobre cada despacho e as funções que ele chama transitivamente:
cópia de utilizador não validada, TOCTOU/double-fetch, use-after-free (intra-função e cross-função via um global
libertado), gate de privilégio em falta, incompatibilidade IRQL, mapeamento MDL inseguro, buffers alocados na
pilha (`_alloca`), alocação de pool sem validação de tamanho, instruções CPU privilegiadas (I/O de porta `in`/`out`,
`mov cr*`), escrita arbitrária (write-what-where) e referências a `\Device\PhysicalMemory` (padrão BYOVD) - ver
[Verificações Heurísticas de Vulnerabilidade](#verificações-heurísticas-de-vulnerabilidade)
* **Auditoria ACL de dispositivos e rastreio de links simbólicos**: sinaliza dispositivos `IoCreateDevice` criados
sem descritor de segurança (acessível mundialmente) / SDDLs fracos `IoCreateDeviceSecure`, e descodifica caminhos
alvo de `IoCreateSymbolicLink`
* **Auditoria de exportações**: sinaliza exportações de driver com zero referências cruzadas internas (potencial
superfície de ataque)
* **Pontuação de risco** de IOCTLs descodificados por IOCTL (priorizando `METHOD_NEITHER` / `FILE_ANY_ACCESS`,
e aumentando um IOCTL apenas para os sinks/opcodes perigosos alcançáveis a partir do seu **próprio** manipulador
de caso - `MmMapIoSpace`, `memcpy`, `__writemsr`, I/O de porta, acesso PCI-config - de modo que um código benigno
num despacho monolítico já não é manchado pelos sinks de um irmão perigoso; quando a atribuição é imprecisa, o
aumento é limitado em vez de forçado a CRITICAL) e apresentando todas as descobertas, por gravidade, numa janela
de resultados clicável (clique duplo para saltar para o endereço)
* **Rastreio de cadeias de chamadas** desde manipuladores de despacho / IOCTL até sinks perigosos (heurístico,
baseado em nomes)
* Exportar resultados como ficheiro **JSON** legível por máquina e relatório **HTML** autónomo
### Encontrar DispatchDeviceControl
A ferramenta pode localizar e identificar automaticamente a rotina `DispatchDeviceControl`. Esta função é usada para
encaminhar todos os códigos `DeviceIoControl` recebidos para a função específica do driver associada a esse código.
Identificar automaticamente esta função torna a descoberta dos códigos `DeviceIoControl` válidos para cada driver
muito mais rápida. Além disso, ao investigar possíveis vulnerabilidades num driver devido a um crash, saber a
localização desta função ajuda a focar a atenção na chamada de função específica associada ao código
`DeviceIoControl` que causou o crash.
Quando a análise é bem-sucedida, algumas subs serão renomeadas da seguinte forma:
- `DriverEntry`: a primeira rotina original fornecida pelo driver que é chamada após o carregamento do driver. É
responsável por inicializar o driver.
- `Real_Driver_Entry`: geralmente a função para onde a execução de `DriverEntry` foi transferida. É normalmente
onde o `DeviceName` é inicializado.
- `DispatchDeviceControl`/`DispatchInternalDeviceControl`: se a ferramenta conseguiu recuperar as funções em alguns
offsets específicos, as funções serão renomeadas com o nome apropriado.
- `Possible_DispatchDeviceControl_#`: se a ferramenta não conseguiu recuperar `DispatchDeviceControl`
ou `DispatchInternalDeviceControl`, utiliza uma pesquisa experimental, seguindo o fluxo de execução e verificando
casos onde a função está a carregar endereços conhecidos de `IO_STACK_LOCATION` & `IRP`; indicando que a função
poderia ser o DispatchDeviceControl. Como é baseado em heurística, pode retornar mais de um resultado e é propenso
a falsos positivos.
### Rotulagem de Estruturas WDM e WDF
Várias estruturas de driver são partilhadas entre todos os drivers `WDM`/`WDF`. A ferramenta é capaz de identificar
automaticamente estas estruturas, como `IO_STACK_LOCATION`, `IRP` e `DeviceObject`, e pode ajudar a poupar tempo
durante o processo de engenharia reversa, fornecendo contexto a áreas do driver onde estas funções estão em uso.
### Encontrar e Descodificar Códigos IOCTL
Ao fazer engenharia reversa de drivers, é comum encontrar códigos IOCTL como parte da análise. Estes códigos, quando
descodificados, revelam informações úteis e podem chamar a atenção para partes específicas do driver onde as
vulnerabilidades são mais prováveis de existir.
Ao clicar com o botão direito num potencial código IOCTL, é apresentada uma opção de menu de contexto
(alternativamente usando o atalho `Ctrl+Alt+D` quando o cursor está na linha que contém um código IOCTL suspeito)
e pode ser usada para descodificar o valor. Isto imprimirá uma tabela com todos os códigos IOCTL descodificados.
Ao clicar com o botão direito num código IOCTL descodificado, na vista de desmontagem, é possível marcá-lo como
inválido; isto deixará intacto qualquer comentário não relacionado com IOCTL.
- Os IOCTLs descodificados são impressos na janela Output e listados na janela de IOCTLs colorida por gravidade;
após a análise automática, também são registados em `findings.json` / `report.html`.
A análise automática executa adicionalmente uma pesquisa multi-estratégia sobre as funções de despacho identificadas
para descobrir IOCTLs automaticamente, sem necessidade de colocação manual do cursor. Para cada despacho, usa o
descompilador Hex-Rays (quando disponível) para ler rótulos de switch-case e constantes de comparação `==`/`!=`
diretamente do fluxo de controlo reconstruído, recorrendo aos metadados da tabela de saltos do IDA e, em seguida,
a uma pesquisa de operando imediato bruto. O caminho do descompilador recupera códigos que nunca aparecem
literalmente na desmontagem - por exemplo, drivers cujo despacho o compilador emitiu como uma tabela de saltos
(apenas a base/limite da tabela sobrevivem como imediatos) ou como uma árvore de comparação de pesquisa binária
(os códigos intermédios sobrevivem apenas como deltas). Num corpus representativo, isto aumentou a recuperação de
7/28 para 28/28 (HEVD) e 4/17 para 17/17 (ALSysIO64) sem falsos positivos.
### Sinalizar Funções
O Driver Buddy Reloaded possui listas de funções C/C++, opcodes e APIs Windows (definidas no
diretório [vulnerable_function_lists](https://github.com/voidsec/driverbuddyreloaded/blob/HEAD/DriverBuddyReloaded/vulnerable_functions_lists)) que são comumente vulneráveis
ou que podem facilitar condições de buffer overflow. Todas as instâncias encontradas são reportadas durante a análise
automática e podem ajudar ao procurar possíveis caminhos de código controlados pelo utilizador que alcançam funções
sensíveis.
### Encontrar DeviceName
A ferramenta tenta automaticamente encontrar os caminhos de dispositivos registados pelo driver (`DeviceName`); se
nenhum caminho puder ser encontrado ao procurar por strings Unicode dentro do binário, o analista pode tentar
manualmente usar o [FLOSS](https://github.com/mandiant/flare-floss/) da Madiant para tentar encontrar caminhos
ofuscados.
### Descarregar Pooltags
Durante a análise automática, a ferramenta também descarrega os `Pooltags` usados pelo binário num formato que
funciona com `pooltags.txt`. A saída pode então ser copiada e colada no final do ficheiro e posteriormente
recolhida pelo WinDbg.
- Um ficheiro `DriverName.sys-DATE-TIME_STAMP-pooltags.txt`, contendo todos os Pooltags descarregados, será escrito
no diretório DB do IDA.
### Verificações Heurísticas de Vulnerabilidade
O módulo `heuristics.py` executa após o rastreio de cadeias de chamadas e examina cada despacho **e as funções que
ele chama transitivamente** - por isso, os manipuladores por IOCTL, não apenas o prólogo do despacho, são analisados.
A correspondência de callee é ciente de importações (um `call cs:__imp_<Name>` importado corresponde ao mesmo nome que
um call local). Emite descobertas na categoria **heurística** (as descobertas de instruções privilegiadas usam a
categoria **opcode**):
| Verificação | O que é sinalizado | Gravidade |
|---|---|---|
| Cópia de utilizador não validada | `memcpy`/`RtlCopyMemory`/etc. sem `ProbeForRead`/`ProbeForWrite`/proteção safe-string nas proximidades | HIGH (manipulador), MEDIUM (outro) |
| TOCTOU / double fetch | uma releitura de campo de ponteiro de modo de utilizador num caminho de fluxo de controlo sem `ProbeForRead` interveniente (apenas em manipuladores METHOD_NEITHER, para que releituras de buffer do kernel não sejam sinalizadas) | MEDIUM |
| Use-after-free | um ponteiro libertado reutilizado intra-função (caminho de registo CFG), ou um global libertado sem ser anulado e depois desreferenciado de outra função | HIGH |
| Gate de privilégio em falta | um op sensível (`ZwOpenProcess`/`MmMapIoSpace`/PCI-config/etc.) alcançável a partir de um despacho sem `SeAccessCheck`/`SeSinglePrivilegeCheck`/verificação de token em qualquer ponto do caminho | HIGH |
| Incompatibilidade IRQL | Chamada Pageable / `Zw*` / `MmMap*` quando uma função que aumenta IRQL também está presente | MEDIUM |
| Mapeamento MDL inseguro | `MmMapLockedPages`/`MmProbeAndLockPages`/etc. com `UserMode` na desmontagem | HIGH, senão MEDIUM |
| Alocação na pilha | Chamada `_alloca`/`_malloca`/`_chkstk` (alocação grande ou dinâmica na pilha) | LOW |
| Alocação de pool sem validação de tamanho | Chamada `ExAllocatePool*` sem proteção aritmética segura nas proximidades (padrão de integer-overflow-antes-de-alocar) | HIGH |
| Instrução privilegiada | I/O de porta (`in`/`out`), movimento de registo de controlo/debug (`mov cr*`/`mov dr*`), carregamento de tabela de descritores, `cli`/`sti`/`hlt` alcançável a partir de um manipulador (primitiva de acesso a hardware BYOVD) | CRITICAL (`out`) / HIGH (`in`) / MEDIUM |
| Escrita arbitrária (write-what-where) | um armazenamento através de um ponteiro de utilizador duplamente desreferenciado `*(*p) = c`; uma cópia controlada `*p = *q` é reportada como uma pista mais fraca | HIGH / MEDIUM |
| Referência a `\Device\PhysicalMemory` | Referência cruzada à string do objeto de dispositivo de memória física (padrão BYOVD via `ZwOpenSection`/`ZwMapViewOfSection`) | HIGH (manipulador), MEDIUM (outro) |
Estes são **geradores de pistas**, não vulnerabilidades confirmadas. Trate as descobertas HIGH/CRITICAL como pontos
de partida para revisão manual.
## Flags de Funcionalidades
Todas as fases opcionais de análise são controladas por `DriverBuddyReloaded/config.py`. Edite a classe `Feature` para
ativá-las ou desativá-las:
| Flag | Predefinido | Descrição |
|---|---|---|
| `IOCTL_SCAN` | `True` | Descobrir e descodificar IOCTLs (pesquisa de despacho + alternativa `IoControlCode`) |
| `IOCTL_DECOMPILER` | `True` | Usar a ctree do Hex-Rays na pesquisa de despacho (recupera códigos de tabela de saltos / pesquisa binária) |
| `HEURISTICS` | `True` | Verificações heurísticas de vulnerabilidade (ver tabela acima) |
| `TOCTOU_CHECK` | `True` | Heurística de double-fetch / TOCTOU |
| `UAF_DETECT` | `True` | Heurísticas de use-after-free (caminho de registo intra-função + global cross-função) |
| `ACL_AUDIT` | `True` | Sinalizar `IoCreateDevice` acessível mundialmente / SDDL fraco `IoCreateDeviceSecure` |
| `SYMLINK_TRACK` | `True` | Descodificar caminhos alvo de `IoCreateSymbolicLink` |
| `CALLCHAIN` | `True` | Rastreio de cadeias de chamadas BFS desde manipuladores até sinks perigosos |
| `EXPORTS_AUDIT` | `True` | Sinalizar exportações de driver com zero referências cruzadas internas |
| `POOLTAG_FALLBACK` | `True` | Scanner de pool tag propagado por registo (usado quando a pesquisa baseada em importações não encontra nada) |
| `IRP_MJ_ENUM` | `True` | Criar enumeração IDA `IRP_MJ_FUNCTION` e aplicar a slots `MajorFunction` (apenas WDM) |
| `RISK_SCORING` | `True` | Pontuação de risco de IOCTL (pesos METHOD/ACCESS + aumento de sink por manipulador) |
| `RESULTS_WINDOW` | `True` | Mostrar a janela de descobertas do Driver Buddy Reloaded após a análise |
| `JSON_EXPORT` | `True` | Escrever `findings.json` |
| `HTML_REPORT` | `True` | Escrever `report.html` |
| `SEGMENT_OPCODE_SCAN` | `False` | Pesquisa linear de opcode ao nível do segmento (barulhento, desligado por predefinição) |
## Testes
Três camadas, da rápida à exaustiva:
- **Regressão pura em Python** (não é necessário IDA) - abrange toda a lógica que não toca na base de dados ativa: ```
python tests/test_dbr.py
DBR_SDK=900 python tests/test_dbr.py # simulate the IDA 9.0 import paths
.sys reais e imprime uma tabela de aprovação/reprovação: pwsh tests/run_cross_version.ps1.pwsh tests/run_golden.ps1 executa novamente a análise completa em uma cópia intacta de cada driver de referência em tests/drivers/ e compara os resultados com a linha de base tests/drivers/<driver>.golden.json consolidada (insensível à ordem em categoria, título, gravidade e código/método/acesso IOCTL). Qualquer descoberta adicionada (falso positivo), descoberta ausente (falso negativo) ou alteração de gravidade falha a execução. Regere uma dourada apenas quando uma alteração intencionalmente modifica os resultados e revise o diff. As douradas estão vinculadas à versão do descompilador IDA com a qual foram capturadas (8.4), portanto execute a regressão com essa versão.CTL_CODE por _is_valid_ctl_code(): o campo DeviceType (bits 31-16) deve ser diferente de zero, e o valor não deve corresponder a um código NTSTATUS conhecido ou ao sentinela 0xFFFFFFFF (DWORD)-1 (uma constante de comparação vista dentro de despachantes reais, ex. WinRing0). Isso elimina contadores de loop, imediatos pequenos e códigos de erro, preservando todos os IOCTLs válidos, incluindo tipos de dispositivo definidos pelo fornecedor (0x8000+). O mesmo filtro é aplicado a todos os quatro caminhos de descoberta: a varredura de referência cruzada IoControlCode e os três coletores de despachante (ctree do descompilador, recuperação de tabela de switch do IDA e a varredura bruta de operandos imediatos).DriverBuddyReloaded/config.py.DispatchDeviceControl funciona apenas para drivers x64find_opcode_data (padrão ) suprime correspondências de opcode que caem em seções de dados. Mudá-la para também revela correspondências brutas de bytes em dados, o que é propenso a falsos positivos; se um opcode real foi perdido, ir ao endereço reportado e redefinir os bytes como código geralmente o recupera. As correspondências são reportadas como em qualquer outro estágio (janela de resultados, , ).FalseTruefindings.jsonreport.html