youssefnoob003/sindrikitUna biblioteca C fundamental para construir capacidades ofensivas operativamente creíbles.
<p align="center">
<img src="https://assets.kitploit.com/production/public/readmes/735/ac7a3259ddf602d9e7d0c2f683f22497afec347da32bb930d5369acf66ae34f5.png" width="100%">
</p>
<h1 align="center">SindriKit</h1>
<p align="center">
<strong>El desarrollo ofensivo merece una mejor arquitectura.</strong><br>
<em>Una biblioteca en C para construir capacidades ofensivas.</em>
</p>
---
## Concepto central
La mayoría de las utilidades ofensivas codifican de forma rígida sus mecánicas de ejecución dentro de la lógica de la técnica. Un cargador reflexivo no solo mapea una imagen; la mapea usando una cadena específica y codificada de llamadas a `VirtualAlloc` o a la NTAPI nativa. Cuando un EDR comienza a monitorear esa cadena específica, te ves obligado a reescribir toda la herramienta.
SindriKit resuelve esto imponiendo una separación de responsabilidades mediante tablas de abstracción de interfaces:
1. **La lógica de la técnica:** (p. ej., cargadores, inyecciones, parcheadores) se ocupa del seguimiento de estado y la orquestación de datos. No tiene conocimiento de cómo se asigna la memoria ni de cómo se crean los hilos.
2. **Las mecánicas de ejecución:** (p. ej., Win32 API, NTAPI nativa, syscalls directas) residen en tablas de API independientes y se inyectan en la técnica en tiempo de ejecución.
Al trasladar las mecánicas de ejecución a punteros a función en tiempo de ejecución, puedes cambiar toda tu estrategia de llamadas Win32 a syscalls directas en bruto con una sola línea de código, sin cambiar la lógica de ejecución de tu payload.
---
## Arquitectura de diseño
* **Perfiles de ejecución desacoplados:** Intercambia las mecánicas de memoria, módulo, mapeo, proceso, hilo y archivo mediante tablas de punteros a función independientes (`snd_memory_api_t`, `snd_module_api_t`, `snd_process_api_t`, `snd_thread_api_t`, `snd_mapping_api_t`, `snd_file_api_t`) sin tocar la lógica de la técnica.
* **Cobertura de técnicas:** Carga reflexiva de **PE** (EXE/DLL) y **COFF/BOF**, inyección **clásica** y **early-bird APC** sobre shellcode/PE/COFF, además de FFI consciente de la arquitectura y Heaven's Gate, todo sobre los mismos perfiles componibles.
* **Pipeline en cascada de syscalls:** Resolvedores de SSN conectables (`snd_syscall_resolve_ssn_scan`, `snd_syscall_resolve_ssn_sort`) con una cadena de prioridad, desacoplados de los invocadores: **directo**, **indirecto** (gadget de NTDLL) o **suplantado** (suplantación dinámica de pila de llamadas Fat-Frame).
* **Estado codificado por facility:** Cada llamada que puede fallar devuelve `snd_status_t`: un código de facility/local empaquetado más el error del SO capturado, con cadenas de contexto que se eliminan en la compilación en el nivel silencioso.
* **Ofuscación en tiempo de compilación:** Los algoritmos de hashing de cadenas y API (DJB2, FNV1A) pueden intercambiarse globalmente mediante CMake. La compilación aleatoriza automáticamente la semilla global para alterar las firmas estáticas.
* **Motor de mutación:** Habilita polimorfismo profundo mediante `SND_MORPH`. Genera firmas binarias únicas en cada compilación inyectando predicados opacos volátiles en el código C, matemáticas/NOPs funcionalmente equivalentes en los stubs de ensamblador, y alterando la disposición en memoria de las estructuras principales.
* **Compilaciones de release:** Un nivel silencioso elimina todas las cadenas de diagnóstico, descriptores de archivo y marcos de seguimiento; las compilaciones `SND_CRTLESS` van más allá con `/NODEFAULTLIB`, sin cabecera del SDK, un frontend de PEB y solo backends nativos.
---
## Inicio rápido
El repositorio incluye una única CLI `unified` que ejercita todos los perfiles:
```sh
build.bat pocs
build64\pocs\Release\unified.exe load pe -f payload.dll -e Run --sys
```
`unified` admite `load pe|coff`, `inject classic|apc|hijack` (shell, PE, COFF) y `hg`, cada uno sobre `--win`/`--nt`/`--sys`. Consulta [Ejemplos y PoCs](https://github.com/youssefnoob003/sindrikit/blob/main/docs/examples/README.md) y [Primeros pasos](https://github.com/youssefnoob003/sindrikit/blob/main/docs/getting_started/README.md).
---
## Integrar SindriKit
```cmake
cmake_minimum_required(VERSION 3.16)
project(MyTool C ASM_MASM)
set(SND_BUILD_PAYLOADS OFF CACHE BOOL "")
set(SND_ENABLE_DEBUG OFF CACHE BOOL "")
set(SND_HASH_ALGO "DJB2" CACHE STRING "")
set(SND_RANDOMIZE_SEED ON CACHE BOOL "")
set(SND_MORPH ON CACHE BOOL "")
add_subdirectory(libs/SindriKit)
add_executable(my_tool src/main.c)
target_link_libraries(my_tool PRIVATE sindri::engine)
```
```sh
cmake -B build && cmake --build build --config Release
```
Solo dos líneas para que tu herramienta herede todas las capacidades de SindriKit: análisis de PE y COFF, carga reflexiva, syscalls en cascada y perfiles de inyección.
---
## El motor
### Capa de abstracción de API
```
┌────────────────────────────────────────────────────────────────────────────┐
│ CUALQUIER INTENCIÓN OFENSIVA │
│ Loader · Injector · Spoofer · Patcher · Bypasser · Harvester · ... │
├────────────────────────────────────────────────────────────────────────────┤
│ CAPA DE ABSTRACCIÓN DE API DE SINDRIKIT │
│ snd_memory_api_t -> alloc · free · protect │
│ snd_module_api_t -> load_library · get_proc_address · ... │
│ snd_process_api_t -> open · alloc_remote · write · protect · thread │
│ snd_mapping_api_t -> open · view · close (KnownDlls bootstrap) │
│ snd_thread_api_t -> queue_apc · resume · suspend │
│ snd_file_api_t -> load │
├──────────────────┬──────────────────────┬──────────────────────────────────┤
│ Perfil Win32 │ Perfil Nativo │ Trae tu propia mecánica │
│ VirtualAlloc │ NtAllocateVirtual │ Driver · ROP · Exótico │
│ LoadLibraryA │ PEB Walk + EAT │ Funciones definidas por el │
│ │ │ operador │
└──────────────────┴──────────────────────┴──────────────────────────────────┘
```
En la práctica, esto significa que cada dominio sigue el mismo contrato:
```c
// Reflective loader
snd_ldr_pe_ctx_t ctx = {0};
ctx.raw_source = &payload;
ctx.mem_api = &snd_mem_win; // or snd_mem_nt / snd_mem_sys
ctx.mod_api = &snd_mod_win; // or snd_mod_nt
snd_ldr_pe_prepare_image(&ctx);
snd_ldr_pe_execute_image(&ctx);
// Classic injection
snd_inj_ctx_t inj = {0};
inj.target_pid = 1337;
inj.payload = &shellcode;
inj.proc_api = &snd_proc_sys; // or snd_proc_win / snd_proc_nt
snd_inj_classic_shell(&inj);
snd_inj_cleanup(&inj);
```
### Pipeline en cascada de syscalls
SindriKit trata la resolución de syscalls como una mecánica inyectable, apilando estrategias en orden de prioridad. El motor va cayendo por la cadena hasta que una tiene éxito:
```c
snd_ntdll_set_clean(clean_ntdll);
snd_syscall_set_resolver(snd_syscall_resolve_ssn_scan);
snd_syscall_add_resolver(snd_syscall_resolve_ssn_sort);
snd_syscall_set_invoker(snd_syscall_direct_invoke_asm);
// or for indirect syscalls:
// snd_syscall_set_invoker(snd_syscall_indirect_invoke_asm);
// snd_syscall_set_gadget_finder(snd_syscall_find_gadget_scan);
// or for spoofed syscalls:
// snd_syscall_set_invoker(snd_syscall_spoofed_invoke_asm);
// snd_syscall_set_spoof_finder(snd_syscall_find_spoof_scan);
```
El invocador está desacoplado de la resolución de SSN: cambia entre syscalls directas, indirectas y suplantadas sin modificar el código del dominio. La invocación indirecta salta a un gadget legítimo de NTDLL para que la dirección de retorno permanezca dentro de `ntdll.dll`; la invocación suplantada además coloca una dirección de retorno genuina del llamador dentro de un "Fat Frame" descubierto dinámicamente, de modo que los unwinds de la pila de llamadas se mantienen coherentes.
### Agilidad de algoritmos en tiempo de compilación
Cada nombre de API y cadena de módulo se elimina del binario final en tiempo de compilación mediante una única variable de CMake:
```cmake
set(SND_HASH_ALGO "FNV1A") # or DJB2 recomputes everything automatically
set(SND_RANDOMIZE_SEED ON) # generates a fresh 32-bit seed on next configure
```
Cada hash se calcula con una semilla generada aleatoriamente (si `SND_RANDOMIZE_SEED=ON`). La huella estática cambia por completo entre compilaciones sin tocar una sola línea de C.
### FFI dinámica consciente de la arquitectura
Un puente de ensamblador MASM personalizado para la invocación arbitraria de funciones en tiempo de ejecución. Las compilaciones x64 siguen con precisión la convención de llamadas de Microsoft x64 (shadow space, colocación de argumentos en registros, alineación de pila). Las compilaciones x86 empujan los argumentos en orden inverso con soporte tanto para objetivos `cdecl` como `stdcall`.
### Parser de PE con comprobación de límites
Un parser unificado PE32/PE32+ con un flag `is_mapped` que maneja correctamente tanto imágenes en bruto en disco como vistas mapeadas en memoria. Cada acceso a un directorio de datos se valida contra los límites del búfer rastreado antes de desreferenciarlo. La resolución de exportaciones admite cadenas de forwarders de hasta profundidad 4 con búsqueda basada en hash.
Probado contra:
- Más de 40 combinaciones de pruebas principales dirigidas a EXEs y DLLs de casos límite, argumentos incorrectos, exportaciones faltantes y callbacks TLS en x86 y x64.
- Más de 100 mutaciones dinámicas de PE generadas por el módulo `pe_mutator`: nombres de sección puestos a cero, desbordamientos de enteros, límites inválidos de `e_lfanew`, importaciones alteradas.
- Corpus completo de Corkami: carga limpiamente muestras válidas, rechaza limpiamente las malformadas sin fallar en el 99% de las muestras.
### Cargador COFF / BOF
Una segunda técnica de carga maneja archivos objeto COFF no enlazados (Beacon Object Files): análisis acotado de cabeceras, secciones, símbolos y reubicaciones; resolución de símbolos externos `MODULE$Function` a través del `mod_api` inyectado; trampolines x64 `JMP [RIP+0]` para llamadas fuera de rango; y ejecución de un punto de entrada con nombre (por defecto `go`), ya sea localmente o marshaled hacia un proceso remoto.
### Contextos de dominio con seguimiento de estado
Cada operación ofensiva se gestiona mediante una estructura de contexto discreta con enumeración de etapas. Las operaciones pueden pausarse entre etapas para ofuscación de sueño o despliegue por etapas, reanudarse limpiamente e inspeccionarse para determinar el punto exacto de fallo hasta el subsistema y la razón.
---
## La filosofía de diseño de la API
Inicializa el pipeline de syscalls una vez (patrón típico):
```c
PVOID clean_ntdll = NULL;
snd_om_knowndll_map(&snd_map_nt, L"ntdll.dll", &clean_ntdll);
snd_ntdll_set_clean(clean_ntdll);
snd_syscall_set_resolver(snd_syscall_resolve_ssn_scan);
snd_syscall_add_resolver(snd_syscall_resolve_ssn_sort);
snd_syscall_set_invoker(snd_syscall_direct_invoke_asm);
// or for indirect syscalls:
// snd_syscall_set_invoker(snd_syscall_indirect_invoke_asm);
// snd_syscall_set_gadget_finder(snd_syscall_find_gadget_scan);
// or for spoofed syscalls:
// snd_syscall_set_invoker(snd_syscall_spoofed_invoke_asm);
// snd_syscall_set_spoof_finder(snd_syscall_find_spoof_scan);
```
El invocador está desacoplado de la resolución de SSN: cambia entre syscalls directas, indirectas y suplantadas sin modificar el código del dominio. La invocación indirecta salta a un gadget legítimo de NTDLL para que la dirección de retorno permanezca dentro de `ntdll.dll`; la invocación suplantada además coloca una dirección de retorno genuina del llamador dentro de un "Fat Frame" descubierto dinámicamente, de modo que los unwinds de la pila de llamadas se mantienen coherentes.
Cambia el perfil de ejecución con una sola asignación:
```c
ctx.mem_api = &snd_mem_win; // diagnostic
ctx.mem_api = &snd_mem_nt; // NT stubs via PEB + EAT
ctx.mem_api = &snd_mem_sys; // direct syscalls (pipeline required)
```
La resolución de módulos sigue el mismo patrón (`snd_mod_win` frente a `snd_mod_nt`). No existe un backend de módulos respaldado por syscalls: las importaciones usan PEB walk + EAT incluso en perfiles `_sys` completos.
---
## Niveles de compilación
### Nivel Debug — `SND_ENABLE_DEBUG=ON`
Para desarrollo local. `snd_status_t` se expande para incluir `file`, `line` y un búfer de cadena `context` de 128 bytes. `SND_ERR_CTX` y `SND_DEBUG_PRINT` emiten transiciones de la máquina de estados, valores de campos PE analizados y resultados de resolución de syscalls. Usa `SND_USE_PRINTF=ON` para dirigir la salida a `stdout` en lugar de la consola de depuración.
### Nivel silencioso — `SND_ENABLE_DEBUG=OFF`
La configuración de despliegue estándar para binarios operativos. Cada cadena de diagnóstico, referencia a archivo y número de línea se elimina por completo en la compilación. `snd_status_t` se reduce a dos enteros. Nada más. Una compilación `SND_CRTLESS=ON` añade `/NODEFAULTLIB`, sin cabecera del Windows SDK, un frontend de línea de comandos basado en PEB y solo backends nativos.
```cmake
set(SND_ENABLE_DEBUG OFF CACHE BOOL "")
set(SND_BUILD_PAYLOADS OFF CACHE BOOL "")
set(SND_RANDOMIZE_SEED ON CACHE BOOL "")
set(SND_USE_DEFAULTS ON CACHE BOOL "")
set(SND_HASH_ALGO "DJB2" CACHE STRING "")
add_subdirectory(vendor/SindriKit)
target_link_libraries(my_tool PRIVATE sindri::engine)
```
---
## Documentación
Referencia completa en [`docs/`](https://github.com/youssefnoob003/sindrikit/blob/main/docs/README.md):
- **[Referencia de API](https://github.com/youssefnoob003/sindrikit/blob/main/docs/api_reference.md)** — la API pública completa en C (funciones, tipos, tablas DI, códigos de estado)
- **[Primeros pasos](https://github.com/youssefnoob003/sindrikit/blob/main/docs/getting_started/README.md)** — niveles de compilación, integración con CMake, bootstrap de syscalls, primer flujo de trabajo de carga/inyección
- **[Arquitectura](https://github.com/youssefnoob003/sindrikit/blob/main/docs/architecture/README.md)** — inyección de dependencias, máquinas de estados, sistema de estado codificado por facility
- **[Primitivas](https://github.com/youssefnoob003/sindrikit/blob/main/docs/primitives/README.md)** — memoria, módulos, proceso, mapeo, archivos, hilo, syscalls, ejecución (FFI, Heaven's Gate)
- **[Cargadores](https://github.com/youssefnoob003/sindrikit/blob/main/docs/loaders/README.md)** — carga reflexiva de PE y COFF/BOF
- **[Inyección](https://github.com/youssefnoob003/sindrikit/blob/main/docs/injection/README.md)** — inyección clásica, early-bird APC y thread-hijack (shellcode, PE, COFF)
- **[Parsers](https://github.com/youssefnoob003/sindrikit/blob/main/docs/parsers/README.md)** — análisis de PE, COFF y env (PEB/NTDLL)
- **[Common](https://github.com/youssefnoob003/sindrikit/blob/main/docs/common/README.md)** — helpers sin CRT, búferes, hashing, estado
- **[Ejemplos y PoCs](https://github.com/youssefnoob003/sindrikit/blob/main/docs/examples/README.md)** — la CLI `unified` (`load pe|coff`, `inject classic|apc|hijack`, `hg`)
- **[Pruebas](https://github.com/youssefnoob003/sindrikit/blob/main/docs/tests/README.md)** — ejecutores de integración y el mutador de PE
*Planeado: un dominio de **Evasión**.*
---
## Aviso legal
**SindriKit está construido únicamente con fines educativos, de investigación y de Red Teaming autorizado.** Para el aviso legal completo y la información sobre consideraciones de OpSec, consulta la [Política de seguridad](https://github.com/youssefnoob003/sindrikit/blob/main/SECURITY.md).
---
## Licencia
[MIT](https://github.com/youssefnoob003/sindrikit/blob/main/LICENSE)
---
<p align="center">
<img src="https://assets.kitploit.com/production/public/readmes/735/c6b18a5428e9f22275a36c38df781706c1ddd2639451b49276a6cc0634dcb175.png" width="100%">
</p>