DriverBuddyReloaded
ver Buddy Reloaded v1.6
Copie a pasta DriverBuddyReloaded e o arquivo de script DriverBuddyReloaded.py na pasta IDA Plugins, por exemplo:
%APPDATA%Hex-RaysIDA PropluginsC:Program FilesIDA Pro 7.6plugins~/.idapro/plugins/ Se você usar o Python v. 3.x, execute o binário idapyswitch.exe (localizado na pasta da IDA) a partir de um prompt de comando de administrador.
Nota: O IDA SDK> v.7.5 é necessário para que este script seja executado.
Para usar o recurso de análise automática:
Edit -> Plugins -> Driver Buddy Reloaded ou pressione CTRL+ALT+A para iniciar a auto -análise.<DRIVER_NAME>.sys-YYYY-MM-DD-TIME_STAMP-DriverBuddyReloaded_autoanalysis.txt arquivo contendo os resultados da análise, será escrito no diretório DB da IDA.Para decodificar um IOCTL:
Driver Buddy Reloaded -> Decode IOCTL ; Como alternativa, pressione o atalho CTRL+ALT+D .Para decodificar todos os IOCTLs dentro de uma função:
DispatchDeviceControl , DispatchInternalDeviceControl , Possible_DispatchDeviceControl_# )Driver Buddy Reloaded -> Decode ALL IOCTLs in Function ; Como alternativa, pressione o atalho CTRL+ALT+F .DriverName.sys-2021-12-10-TIME_STAMP-IOCTLs.txt / DriverName.sys-2021-12-10-TIME_STAMP-IOCTLs.txt_dumb.txt , contendo todos os ioctls decodificados até esse momento, será escrito sob o db do DB. O diretório vulnerable_function_lists contém uma lista de funções potencialmente perigosas/problemáticas, APIs do Windows e OPCodes; Uma breve descrição sobre por que uma função/API específica foi listada é fornecida. Você pode editar a lista custom , incluindo funções específicas do driver.
NOTA : winapi_function_prefixes será correspondente parcial para o início do nome da função (por exemplo, Zw corresponderá ZwClose , ZwCommitComplete e assim por diante) enquanto winapi_functions executará apenas correspondências exatas.
Em find_opcodes.py, a opção find_opcode_data impedirá que o Buddy do motorista seja recarregado para encontrar o código de dados nas seções de dados. A troca de True imprimirá algo ao longo desta linha: Found jnz short loc_15862 in sub_15820 at 0x00015852 normalmente, indo no endereço exibido e redefinindo a seleção como código trará a Opcode pesquisada de volta.
Cuidado : alterná -lo para True , gera mais falsos positivos!
O Driver Buddy Reloaded é um plugin IDA Pro Python que ajuda a automatizar algumas tarefas de engenharia reversa de drivers de kernel do Windows tediosos. Possui vários recursos úteis, como:
DispatchDeviceControl / DispatchInternalDeviceControlWDF e WDMIRP e IO_STACK_LOCATIONWDF que normalmente não seriam marcadasDeviceNamePooltags 
A ferramenta pode localizar e identificar automaticamente a rotina DispatchDeviceControl . Esta função é usada para rotear todos os códigos de DeviceIoControl recebido para a função de driver específica associada a esse código. A identificação automaticamente dessa função torna a descoberta dos códigos DeviceIoControl válido para cada driver muito mais rápido. Além disso, ao investigar possíveis vulnerabilidades em um driver devido a uma falha, o conhecimento da localização dessa função ajuda a restringir o foco à chamada de função específica associada ao código de DeviceIoControl .
Quando a análise for bem -sucedida, alguns subs serão renomeados da seguinte forma:
DriverEntry : a primeira rotina original fornecida pelo driver que é chamada depois que um driver é carregado. É responsável por inicializar o driver.Real_Driver_Entry : geralmente a função em que a execução do DriverEntry foi transferida para. Geralmente é onde o DeviceName é inicializado.DispatchDeviceControl / DispatchInternalDeviceControl : Se a ferramenta puder recuperar as funções em alguns compensações específicas, as funções serão renomeadas com o nome apropriado.Possible_DispatchDeviceControl_# : Se a ferramenta não puder recuperar DispatchDeviceControl ou DispatchInternalDeviceControl , emprega uma pesquisa experimental, após o fluxo de execução e verificação de casos em que a função está carregando IO_STACK_LOCATION e IRP ; indicando que a função pode ser o DispatchDeviceControl. Como é baseado na heurística, pode retornar mais de um resultado e é propenso a falsos positivos. 
Várias estruturas de motorista são compartilhadas entre todos os drivers WDM / WDF . A ferramenta é capaz de identificar automaticamente essas estruturas, como as estruturas IO_STACK_LOCATION , IRP e DeviceObject e pode ajudar a economizar tempo durante o processo de engenharia reversa e fornecer contexto às áreas do driver onde essas funções estão em uso.
Enquanto reverte os drivers, é comum encontrar os códigos IOCTL como parte da análise. Esses códigos, quando decodificados, revelam informações úteis e podem atrair foco em partes específicas do driver onde é mais provável que as vulnerabilidades existam.
Ao clicar com o botão direito do mouse em um código IOCTL em potencial, uma opção de menu de contexto é apresentada (alternativamente usando o atalho Ctrl+Alt+D quando o cursor está na linha que contém um código de IOCTL suspeito) e pode ser usado para decodificar o valor. Isso imprimirá uma tabela com todos os códigos IOCTL decodificados. Ao clicar com o botão direito do mouse em um código IOCTL decodificado, na visão de desmontagem, é possível marcá-lo como inválido; Isso deixará intacto qualquer comentário que não seja do IOCTL.
Se você clicar com o botão direito do mouse, alternativamente, usando o atalho Ctrl+Alt+F , na primeira instrução da função que você acredita ser o Dispatcher IOCTL ( DispatchDeviceControl , DispatchInternalDeviceControl , Possible_DispatchDeviceControl_# ) sob o Menu Relassocrato do Buddy, A “ DispEngDeaChode '' DispatchDeviceControl_ #) sob a tentativa de Buddy Relloaded Menu, A“ Dechode 'All' All '' Isso é um pouco hacky, mas na maioria das vezes pode acelerar as coisas.
DriverName.sys-2021-12-10-TIME_STAMP-IOCTLs.txt / DriverName.sys-2021-12-10-TIME_STAMP-IOCTLs.txt_dumb.txt , contendo todos os ioctls decodificados até esse momento, será escrito sob o db do DB. 
O Driver Buddy Reloaded possui listas de funções C/C ++, OPCODES e APIs do Windows (definidos no diretório Vulnerable_function_lists) que são geralmente vulneráveis ou que podem facilitar as condições de transbordamento de buffer. Todas as instâncias encontradas são relatadas durante a auto-análise e podem ajudar enquanto procuram possíveis caminhos de código controlado pelo usuário que atingem funções sensíveis.
A ferramenta tenta automaticamente encontrar os caminhos de dispositivo registrados ( DeviceName ), se nenhum caminho puder ser encontrado analisando as cordas Unicode dentro do binário, o analista poderá tentar manualmente usar o fio dental de Madiant na tentativa de encontrar caminhos ofuscados.
Durante a análise automática, a ferramenta também despeja as Pooltags usadas pelo binário em um formato que trabalha com pooltags.txt . A saída pode ser copiada no final do arquivo e posteriormente apanhada pelo Windbg.
DriverName.sys-2021-12-10-TIME_STAMP-pooltags.txt , contendo todas as Pooltags despejados, será escrito no diretório DB da IDA. 
0x10000 serão decodificados automaticamente, para evitar um alto número de falsos positivos. Edição #15DispatchDeviceControl Pesquisa funciona apenas para drivers X64find_opcode_data impedirá que o Buddy do motorista seja recarregado para encontrar o código de dados nas seções de dados. A troca de True imprimirá algo ao longo desta linha: Found jnz short loc_15862 in sub_15820 at 0x00015852 normalmente, indo no endereço exibido e redefinindo a seleção como código trará a Opcode pesquisada de volta. Cuidado : é propenso a falsos positivos! 
