notrequiem/antidbgUna biblioteca anti-depuración de espacio de usuario en C/C++ sigilosa y totalmente basada en llamadas al sistema para Windows, diseñada para proteger el software de la ingeniería inversa
antidbg es una librería anti-depuración en modo usuario para x64 en Windows, diseñada para proteger software contra la depuración.
Considera la librería como una base para tu protección anti-depuración, no como tu única defensa.
La librería es:
El modelo de amenaza asume que un depurador puede interceptar software protegido por este sistema de protección desde cualquier nivel de privilegio, siendo las detecciones menos efectivas cuanto mayor sea el nivel de privilegio.
Este software está endurecido para eludir la interceptación trivial con CPL > 0, mediante:
RAX detectando y/o sobrescribiendo callbacks de instrumentación no legítimos..text monitorizadas mediante una comparación en disco vs en memoria.VEH, SEH, ) y breakpoints de software.LPTOP_LEVEL_EXCEPTION_FILTERPAGE_GUARD.TLS callbacks contra la conexión de depuradores, realizando inspección de la dirección de inicio de hilos.DbgBreakPoint y DbgUiRemoteBreakin, para hacer crashear el proceso o retornar.Si la única forma de hacer una comprobación es usar una función exportada no invocable por syscall, la función en cuestión es revertida manualmente y reconstruida para ejecutarse en el espacio de direcciones del módulo del hilo de protección. Todas las estructuras de memoria en modo usuario son recorridas con introspección directa de memoria en lugar de usar APIs.
Las rutinas de protección dejan explícitamente algunas rutas de ejecución sin protección contra hooks en modo usuario, actuando como honeypots de memoria. Se usan para comparación de estado y para confundir a atacantes.
Las rutinas de protección se ejecutan de forma pseudoaleatoria. La entropía se decide con puro ASLR basado en hardware, comportamiento de la pila y un poco de matemáticas; sin llamar al kernel, usando APIs en modo usuario, o emitiendo instrucciones de salida condicional o incondicionalmente por hipervisores.
Cuando se detecta una violación de seguridad, el sistema de protección hace crashear el proceso actual invocando INT 29h con STATUS_SXS_EARLY_DEACTIVATION, eludiendo todos los manejadores de excepciones. En algunos casos, también encola un APC al kernel para terminar el proceso actual.
Encontradas en el punto de entrada principal (abdg.c) de esta librería, explicadas en orden.
Explicaciones resumidas; una detección específica puede realizar más comprobaciones extra/sub-comprobaciones de las que se explican aquí.
Puedes encontrar más código fuente de otros conceptos de detección en la carpeta antidebug\archived.
1. Lee el campo BeingDebugged del PEB usando la función exportada de kernel32.2. Llama a la exportación IsRemoteDebuggerPresent para ver si el proceso objetivo está siendo depurado desde fuera de su propio contexto.3. Ejecuta la interrupción de software INT 2D, comprobando si el byte que sigue a dicha instrucción es saltado y no enrutado a través del manejador EXCEPTION_BREAKPOINT.4. Ejecuta la interrupción de breakpoint INT 3D, luego observa si la excepción es interceptada o pasada normalmente.5. Invoca ICE/0xF1, lanzando EXCEPTION_SINGLE_STEP y comprobando si el depurador considerará esta excepción como la excepción normal generada al ejecutar la instrucción con el bit de paso único establecido en los registros RFlags6. Sondea los registros de segmento de pila estableciendo el flag TF y comprobando si el depurador lo limpia de RFLAGS, ya que normalmente los depuradores limpian el flag de trampa después de que cada evento de depurador es entregado.7. Usa un caso límite de flujo de instrucciones basado en prefijos y comprueba si 0xF3 0x64, que se desensambla como PREFIX REP, fuerza un salto de 0xF1.8. comprueba si después de establecer un flag de trampa e invocar pushfd mov dword ptr [esp], 0x100 popfd nop, se alcanza nop en lugar de entrar en el manejador EXCEPTION_SINGLE_STEP.9. Lanza un evento DBG_CONTROL_C y un DBG_RIPEXCEPTION para ver si la excepción es interceptada y no enrutada a través de un SEH.10. Comprueba si hay un handle de objeto de depuración adjunto, consultando ProcessDebugObjectHandle con NtQueryInformationProcess.11. Consulta la presencia de un depurador de kernel usando SystemKernelDebuggerInformation con NtQuerySystemInformation, y leyendo directamente la página de memoria KUSER_SHARED_DATA para el campo KdDebuggerEnabled. Adicionalmente, comprueba si los ISRs del temporizador del kernel están haciendo tic de forma asíncrona.12. Lee el flag global de NT para una máscara de FLG_HEAP_ENABLE_TAIL_CHECK (0x10), FLG_HEAP_ENABLE_FREE_CHECK (0x20) y FLG_HEAP_VALIDATE_PARAMETERS (0x40)13. Inspecciona ProcessDebugFlags, para inferir si la depuración está habilitada o suprimida.14. Duplica handles de proceso y comprueba si un depurador toca handles, hereda handles, o los reabre / duplica; ¿Puedo crear un handle duplicado protegido, luego duplicarlo de nuevo limpiamente?15. Examina la cadena de procesos padre para detectar lanzadores de depuradores o ascendencia sospechosa como vsjitdebugger, x64dbg, o similares.16. Comprueba los campos del PEB de depuración sin usar exportaciones, leyendo directamente desde la base (__readgsqword(0x60)) en el offset *(BYTE*)((uintptr_t)peb + 2.17. Consulta el ProcessDebugPort para el proceso actual.18. Comprueba breakpoints de hardware inspeccionando los registros de depuración del hilo (Dr0–Dr7).19. Comprueba si la memoria virtual fue afectada por depuradores colocando honeypots y monitorizando cambios.20. Realiza dos pruebas de cierre de handle inválido con handles de proceso y ventana, observa si ERROR_INVALID_WINDOW_HANDLE y EXCEPTION_INVALID_HANDLE no son interceptados.21. Comprueba si los objetos de depuración son interceptados por el depurador y si ocurre stripping de handles.22. Intenta abrir un proceso de una manera que revele si el acceso está siendo filtrado o redirigido por depuradores.23. Comprueba si un handle de mutex marcado como HANDLE_FLAG_PROTECT_FROM_CLOSE puede cerrarse directamente.24. Llama a NtSystemDebugControl con SysDbgGetTriageDump y comprueba si un depurador de kernel bloquea la llamada o falsifica la llamada pero no toca nuestro búfer de memoria.25. Comprueba si las lecturas de memoria de nuestra propia pila están siendo instrumentadas o interceptadas.26. Comprueba si el proceso está dentro de un objeto job no incluido en la lista blanca creado por un depurador.27. Usa una prueba de acceso estilo breakpoint de memoria, normalmente esperando comportamiento de page-guard o fallo si los watchpoints están activos.28. Dispara un escenario de breakpoint por excepción de página e inspecciona si la cadena de excepciones entrega correctamente STATUS_GUARD_PAGE_VIOLATION.29. Mide el tiempo de ejecución para detectar la sobrecarga introducida por el paso único, breakpoints, o instrumentación binaria dinámica/recompilación JIT.30. Busca ventanas o artefactos de UI de depuradores enumerando ventanas/clases/títulos asociados con herramientas de depuración.31. Comprueba si un depurador limpia bits LBR/BTF previamente establecidos en DR7 para realizar su propio paso único, resultando en un array ExceptionInformation vacío, o si se detectan direcciones de rama en modo kernel si el depurador decide dejar LBR habilitado pero aún intercepta EXCEPTION_SINGLE_STEP invocado por icebp.32. Recorre el heap directamente y comprueba valores mágicos 0xABABABAB y 0xFEEEFEEE. Efectivamente lo mismo que 12 pero usando APIs de Heap hookeables.33. Comprueba si ha ocurrido un Copy-On-Write en memoria virtual comprobando si la página previamente compartida fue tocada por un depurador.34. Envía un evento de consola (CTRL_C_EVENT) y comprueba si un depurador lo intercepta y cambia su entrega a nuestro manejador de control, o lanza DBG_CONTROL_C.35. Comprueba si el proceso está suspendido externamente para intentos de inyección; detecta cualquier llamada externa a NtResumeProcess apuntando a nuestro proceso.36. Llama a NtSetDebugFilterState con diferentes niveles de privilegio SE_DEBUG_PRIVILEGE y comprueba si un depurador de kernel maneja incorrectamente el acceso.37. Analiza objetos de dispositivo, también comprueba si un depurador de kernel intercepta la lectura de archivo.38. Pone hilos compitiendo tanto contra un depurador de kernel como contra el propio kernel leyendo la estructura ContextFlags; comprueba si DEBUG_REGISTERS es eliminado/si Dr0 no fue establecido.39. Congela algunos depuradores creando y mapeando una vista extremadamente grande de una sección virtual; detecta si las llamadas a NtMapViewOfSection son manipuladas.40. Comprueba syscalls no implementadas (común en emuladores).41. Establece cuatro breakpoints de ejecución de hardware desde DR0 hasta DR3 en cuatro NOPs consecutivos y cuenta las entregas resultantes de EXCEPTION_SINGLE_STEP a través de un VEH.42. Prueba la implicación del depurador mediante efectos secundarios de OutputDebugString en Windows XP/2000 heredados y mediante excepciones DBG_PRINTEXCEPTION_{C,WIDE_C} que un depurador puede interceptar.43. Comprueba si el primer byte de nuestra propia imagen en disco es 0xCC y explota el comportamiento del handle de archivo del cargador de Windows donde LoadLibrary puede dejar el archivo accesible de forma no exclusiva bajo un depurador.Ejemplo:
#include "adbg.h"
int main() {
StartDebugProtection();
return 0;
}
Ejemplo:
#include "adbg.h"
int main() {
if (isProgramBeingDebugged()) {
printf("Debugger detected.\n");
}
else {
printf("No debugger was detected.\n");
}
return 0;
}
Para compilar el ejecutable de prueba, habilita -DBUILD_EXAMPLE=ON. Esto compila example/main.c y lo enlaza contra antidebug sin contaminar la librería principal con un punto de entrada.
.sln generado).antidebug_runner como proyecto de inicio y haz clic en Build (o presiona F5 para ejecutar).Desde la raíz del proyecto:
cmake -B build -S . -DBUILD_EXAMPLE=ON
cmake --build build --config Release
El ejecutable estará ubicado en:
build/Release/antidebug_runner.exebuild/antidebug_runner.exeNota sobre compilaciones Debug: Compilar en modo Debug (
--config Debug) habilita logs de diagnóstico de consola/depurador víacore/debug.c. El modo Release elimina el logging completamente.
Por defecto, CMake produce una librería estática (antidebug.lib o libantidebug.a). Para compilar una librería de enlace dinámico (DLL), pasa -DBUILD_SHARED_LIBS=ON.
cl.exe)Usando el generador de 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 con 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
Lanza tu shell LLVM-MinGW de 64 bits (x86_64-w64-mingw32-clang en tu PATH) y usa 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 la librería compilada y los headers en un prefijo local:
cmake --install build --prefix "C:/local/antidebug"
Esto produce:
C:/local/antidebug/
├── bin/
│ └── antidebug.dll (if BUILD_SHARED_LIBS=ON)
├── lib/
│ └── antidebug.lib (or libantidebug.a)
└── include/
└── antidebug/
├── adbg.h
└── ...
No soy responsable ni tengo responsabilidad por cualquier daño que causes a través de cualquier uso malicioso de este proyecto.
La generación de la documentación de BUILD fue hecha con IA, reporta cualquier problema.
Licencia: MIT