notrequiem/antidbgUma biblioteca anti-debugging de userland em C/C++ furtiva e totalmente baseada em syscalls para Windows, projetada para proteger software contra engenharia reversa
antidbg é uma biblioteca anti-depuração em modo usuário x64 para Windows, projetada para proteger software contra depuração.
Considere a biblioteca como uma base para sua proteção anti-depuração, não como sua única defesa.
A biblioteca é:
O modelo de ameaça assume que um depurador pode interceptar software protegido por este sistema de proteção a partir de qualquer nível de privilégio, sendo as detecções menos eficazes quanto maior for o nível de privilégio.
Este software é reforçado para contornar interceptação trivial de CPL > 0, ao:
RAX ao detectar e/ou sobrescrever callbacks de instrumentação não legítimos..text monitoradas ao fazer uma comparação em disco vs em memória.VEH, SEH, ) e breakpoints de software.LPTOP_LEVEL_EXCEPTION_FILTERPAGE_GUARD.TLS callbacks contra anexação de depurador, realizando inspeção do endereço de início da thread.DbgBreakPoint e DbgUiRemoteBreakin, para travar o processo ou retornar.Se a única maneira de fazer uma verificação é usar uma função exportada não syscallable, a função em questão é manualmente engenharia reversa e reconstruída para executar no espaço de endereço do módulo da thread de proteção. Todas as estruturas de memória em modo usuário são percorridas com introspecção direta de memória em vez de usar APIs.
As rotinas de proteção explicitamente deixam alguns caminhos de execução sem proteção contra hooks em modo usuário, atuando como honeypots de memória. Eles são usados para comparação de estado e para confundir atacantes.
As rotinas de proteção executam pseudo-aleatoriamente. A entropia é decidida com ASLR puramente baseado em hardware, comportamento de pilha e um pouco de matemática; sem chamar o kernel, usando APIs em modo usuário, ou emitindo instruções de saída condicional ou incondicional por hypervisors.
Quando uma violação de segurança é detectada, o sistema de proteção trava o processo atual invocando INT 29h com STATUS_SXS_EARLY_DEACTIVATION, contornando todos os handlers de exceção. Em alguns casos, também enfileira um APC para o kernel a fim de encerrar o processo atual.
Encontradas no entrypoint principal (abdg.c) desta biblioteca, explicadas em ordem.
Explicações resumidas; uma detecção específica pode realizar mais verificações extras/sub-verificações do que o explicado aqui.
Você pode encontrar mais código-fonte de outros conceitos de detecção na pasta antidebug\archived.
1. Lê o campo BeingDebugged do PEB usando a função exportada da kernel32.2. Chama a exportação IsRemoteDebuggerPresent para ver se o processo alvo está sendo depurado de fora de seu próprio contexto.3. Executa a interrupção de software INT 2D, verificando se o byte seguinte a tal instrução é ignorado e não roteado através do handler EXCEPTION_BREAKPOINT.4. Executa a interrupção de breakpoint INT 3D, então observa se a exceção é interceptada ou passada normalmente.5. Invoca ICE/0xF1, levantando EXCEPTION_SINGLE_STEP e verificando se o depurador considerará esta exceção como a exceção normal gerada pela execução da instrução com o bit de passo único definido nos registradores RFlags6. Sonda registradores de segmento de pilha definindo o flag TF e verificando se o depurador o limpa de RFLAGS, já que normalmente depuradores limpam o flag de trap após cada evento de depurador ser entregue.7. Usa um caso extremo de fluxo de instrução baseado em prefixo e verifica se 0xF3 0x64, que desmonta como PREFIX REP, força um salto 0xF1.8. verifica se após definir um flag de trap e invocar pushfd mov dword ptr [esp], 0x100 popfd nop, nop é alcançado em vez de entrar no handler EXCEPTION_SINGLE_STEP.9. Levanta um evento DBG_CONTROL_C e um DBG_RIPEXCEPTION para ver se a exceção é interceptada e não roteada através de um SEH.10. Verifica um handle de objeto de depuração anexado, consultando ProcessDebugObjectHandle com NtQueryInformationProcess.11. Consulta a presença de um depurador de kernel usando SystemKernelDebuggerInformation com NtQuerySystemInformation, e lendo diretamente a página de memória KUSER_SHARED_DATA para o campo KdDebuggerEnabled. Adicionalmente, verifica se os ISRs do timer do kernel estão tiquetaqueando assincronamente.12. Lê o flag global do NT para uma máscara de FLG_HEAP_ENABLE_TAIL_CHECK (0x10), FLG_HEAP_ENABLE_FREE_CHECK (0x20) e FLG_HEAP_VALIDATE_PARAMETERS (0x40)13. Inspeciona ProcessDebugFlags, para inferir se a depuração está habilitada ou suprimida.14. Duplica handles de processo e verifica se um depurador toca handles, herda handles, ou reabre / duplica eles; Posso criar um handle duplicado protegido, então duplicá-lo novamente de forma limpa?15. Examina a cadeia de processos pais para identificar lançadores de depurador ou ancestralidade suspeita como vsjitdebugger, x64dbg, ou similar.16. Verifica os campos de depuração do PEB sem usar exportações, lendo diretamente da base (__readgsqword(0x60)) no offset *(BYTE*)((uintptr_t)peb + 2.17. Consulta o ProcessDebugPort para o processo atual.18. Verifica breakpoints de hardware inspecionando registradores de depuração de thread (Dr0–Dr7).19. Verifica se a memória virtual foi atingida por depuradores colocando honeypots e monitorando mudanças.20. Realiza dois testes de fechamento de handle inválido com handles de processo e janela, observa se ERROR_INVALID_WINDOW_HANDLE e EXCEPTION_INVALID_HANDLE não são interceptados.21. Verifica se objetos de depuração são interceptados pelo depurador e se ocorre remoção de handle.22. Tenta abrir um processo de uma forma que revele se o acesso está sendo filtrado ou redirecionado por depuradores.23. Verifica se um handle de mutex marcado como HANDLE_FLAG_PROTECT_FROM_CLOSE pode ser fechado diretamente.24. Chama NtSystemDebugControl com SysDbgGetTriageDump e verifica se um depurador de kernel bloqueia a chamada ou falsifica a chamada mas não toca nosso buffer de memória.25. Verifica se leituras de memória de nossa própria pilha estão sendo instrumentadas ou interceptadas.26. Verifica se o processo está dentro de um objeto job não listado em whitelist criado por um depurador.27. Usa um teste de acesso estilo breakpoint de memória, geralmente esperando comportamento de page-guard ou falha se watchpoints estiverem ativos.28. Dispara um cenário de breakpoint de exceção de página e inspeciona se a cadeia de exceção entrega corretamente STATUS_GUARD_PAGE_VIOLATION.29. Mede o tempo de execução para detectar a sobrecarga introduzida por passo único, breakpoints, ou instrumentação binária dinâmica/recompilação JIT.30. Procura por janelas de depurador ou artefatos de UI enumerando janelas/classes/títulos associados a ferramentas de depurador.31. Verifica se um depurador limpa bits LBR/BTF previamente definidos em DR7 para realizar seu próprio passo único, resultando em um array ExceptionInformation vazio, ou se endereços de branch em modo kernel são detectados se o depurador decidir deixar LBR habilitado mas ainda interceptar EXCEPTION_SINGLE_STEP invocado por icebp.32. Percorre o heap diretamente e verifica valores mágicos 0xABABABAB e 0xFEEEFEEE. Efetivamente o mesmo que 12 mas usando APIs de Heap hookáveis.33. Verifica se ocorreu um Copy-On-Write na memória virtual verificando se a página previamente compartilhada foi tocada por um depurador.34. Envia um evento de console (CTRL_C_EVENT) e verifica se um depurador o intercepta e muda sua entrega para nosso handler de controle, ou levanta DBG_CONTROL_C.35. Verifica se o processo está suspenso externamente para tentativas de injeção; detecta qualquer chamada externa a NtResumeProcess apontando para nosso processo.36. Chama NtSetDebugFilterState com diferentes níveis de privilégio SE_DEBUG_PRIVILEGE e verifica se um depurador de kernel lida incorretamente com o acesso.37. Analisa objetos de dispositivo, também verifica se um depurador de kernel intercepta a leitura do arquivo.38. Coloca threads competindo contra tanto um depurador de kernel quanto o próprio kernel lendo a estrutura ContextFlags; verifica se DEBUG_REGISTERS é removido/se Dr0 não foi definido.39. Congela alguns depuradores criando e mapeando uma visão extremamente grande de uma seção virtual; detecta se chamadas a NtMapViewOfSection são adulteradas.40. Verifica syscalls não implementadas (comum em emuladores).41. Define quatro breakpoints de execução de hardware de DR0 a DR3 em quatro NOPs consecutivos e conta as entregas resultantes de EXCEPTION_SINGLE_STEP via um VEH.42. Testa envolvimento de depurador via efeitos colaterais de OutputDebugString em Windows XP/2000 legado e via exceções DBG_PRINTEXCEPTION_{C,WIDE_C} que um depurador pode interceptar.43. Verifica se o primeiro byte de nossa própria imagem em disco é 0xCC e explora o comportamento de handle de arquivo do loader do Windows onde LoadLibrary pode deixar o arquivo acessível de forma não exclusiva sob um depurador.Exemplo:
#include "adbg.h"
int main() {
StartDebugProtection();
return 0;
}
Exemplo:
#include "adbg.h"
int main() {
if (isProgramBeingDebugged()) {
printf("Debugger detected.\n");
}
else {
printf("No debugger was detected.\n");
}
return 0;
}
Para construir o executável de teste, habilite -DBUILD_EXAMPLE=ON. Isso compila example/main.c e o vincula contra antidebug sem poluir a biblioteca principal com um entrypoint.
.sln gerado).antidebug_runner como o projeto de inicialização e clique em Build (ou pressione F5 para executar).Da raiz do projeto:
cmake -B build -S . -DBUILD_EXAMPLE=ON
cmake --build build --config Release
O executável estará localizado em:
build/Release/antidebug_runner.exebuild/antidebug_runner.exeNota sobre Builds de Debug: Compilar em modo Debug (
--config Debug) habilita logs de diagnóstico de console/depurador viacore/debug.c. O modo Release remove o logging completamente.
Por padrão, o CMake produz uma biblioteca estática (antidebug.lib ou libantidebug.a). Para construir uma biblioteca de vínculo dinâmico (DLL), passe -DBUILD_SHARED_LIBS=ON.
cl.exe)Usando o gerador do Visual Studio:
# Static Library (.lib)
cmake -B build -S . -A x64 -DBUILD_SHARED_LIBS=OFF
cmake --build build --config Release
# Dynamic Library (.dll + import .lib)
cmake -B build -S . -A x64 -DBUILD_SHARED_LIBS=ON
cmake --build build --config Release
Usando Ninja com clang-cl:
# Ensure clang-cl is in your PATH or run from the VS x64 Native Tools Command Prompt
cmake -B build -S . -G Ninja -DCMAKE_C_COMPILER=clang-cl -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF
cmake --build build
Inicie seu shell LLVM-MinGW de 64 bits (x86_64-w64-mingw32-clang em seu PATH) e use Ninja:
# Static Library (.a)
cmake -B build -S . -G Ninja -DCMAKE_C_COMPILER=clang -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF
cmake --build build
# Shared Library (.dll)
cmake -B build -S . -G Ninja -DCMAKE_C_COMPILER=clang -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=ON
cmake --build build
Para instalar a biblioteca compilada e os cabeçalhos em um prefixo local:
cmake --install build --prefix "C:/local/antidebug"
Isso produz:
C:/local/antidebug/
├── bin/
│ └── antidebug.dll (if BUILD_SHARED_LIBS=ON)
├── lib/
│ └── antidebug.lib (or libantidebug.a)
└── include/
└── antidebug/
├── adbg.h
└── ...
Não sou responsável nem liable por qualquer dano que você cause através de qualquer uso malicioso deste projeto.
A geração da documentação de BUILD foi feita com IA, reporte quaisquer problemas.
Licença: MIT