youssefnoob003/sindrikitUna libreria C fondamentale per costruire capacità offensive credibili a livello operativo
<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>Lo sviluppo offensivo merita un'architettura migliore.</strong><br>
<em>Una libreria C per costruire capacità offensive.</em>
</p>
---
## Concetto di base
La maggior parte delle utility offensive codifica in modo rigido le proprie meccaniche di esecuzione all'interno della logica della tecnica. Un reflective loader non si limita a mappare un'immagine; la mappa utilizzando una catena specifica e hardcoded di chiamate `VirtualAlloc` o NTAPI native. Quando un EDR inizia a monitorare quella catena specifica, sei costretto a riscrivere l'intero strumento.
SindriKit risolve questo problema imponendo una separazione delle responsabilità tramite tabelle di astrazione delle interfacce:
1. **La logica della tecnica:** (ad es. loader, injection, patcher) si occupa del tracciamento dello stato e dell'orchestrazione dei dati. Non ha alcuna conoscenza di come viene allocata la memoria o di come vengono creati i thread.
2. **Le meccaniche di esecuzione:** (ad es. Win32 API, Native NTAPI, Direct Syscalls) risiedono in tabelle API indipendenti e vengono iniettate nella tecnica a runtime.
Spostando le meccaniche di esecuzione su puntatori a funzione a runtime, puoi scambiare l'intera strategia da chiamate Win32 a syscall dirette raw con una singola riga di codice—senza modificare la logica di esecuzione del payload.
---
## Architettura di progettazione
* **Profili di esecuzione disaccoppiati:** Scambia le meccaniche di memoria, moduli, mapping, processi, thread e file tramite tabelle indipendenti di puntatori a funzione (`snd_memory_api_t`, `snd_module_api_t`, `snd_process_api_t`, `snd_thread_api_t`, `snd_mapping_api_t`, `snd_file_api_t`) senza toccare la logica della tecnica.
* **Copertura delle tecniche:** Caricamento riflessivo **PE** (EXE/DLL) e **COFF/BOF**, injection **classica** ed **early-bird APC** su shellcode/PE/COFF, più FFI architecture-aware e Heaven's Gate — tutto sugli stessi profili componibili.
* **Pipeline di syscall a cascata:** Resolver SSN pluggable (`snd_syscall_resolve_ssn_scan`, `snd_syscall_resolve_ssn_sort`) con una catena di priorità, disaccoppiati dagli invoker: **direct**, **indirect** (gadget NTDLL), o **spoofed** (spoofing dinamico dello stack di chiamata Fat-Frame).
* **Stato codificato per facility:** Ogni chiamata fallibile restituisce `snd_status_t` — un codice facility/locale impacchettato più l'errore OS catturato, con stringhe di contesto che vengono eliminate in fase di compilazione nel tier silent.
* **Offuscamento a compile-time:** Gli algoritmi di hashing di stringhe e API (DJB2, FNV1A) possono essere scambiati globalmente tramite CMake. La compilazione randomizza automaticamente il seed globale per alterare le firme statiche.
* **Motore di mutazione:** Abilita un polimorfismo profondo tramite `SND_MORPH`. Genera firme binarie uniche a ogni build iniettando predicati opachi volatili nel codice C, math/NOP funzionalmente equivalenti negli stub Assembly, e rimescolando il layout di memoria delle strutture core.
* **Build di release:** Un tier silent rimuove tutte le stringhe diagnostiche, i descrittori di file e i frame di tracciamento; le build `SND_CRTLESS` vanno oltre con `/NODEFAULTLIB`, nessun header SDK, un frontend PEB, e solo backend nativi.
---
## Avvio rapido
Il repository fornisce una singola CLI `unified` che esercita ogni profilo:
```sh
build.bat pocs
build64\pocs\Release\unified.exe load pe -f payload.dll -e Run --sys
```
`unified` supporta `load pe|coff`, `inject classic|apc|hijack` (shell, PE, COFF), e `hg`, ciascuno su `--win`/`--nt`/`--sys`. Vedi [Esempi & PoC](https://github.com/youssefnoob003/sindrikit/blob/main/docs/examples/README.md) e [Guida introduttiva](https://github.com/youssefnoob003/sindrikit/blob/main/docs/getting_started/README.md).
---
## Integrare 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 due righe perché il tuo strumento erediti tutte le capacità di SindriKit: parsing PE e COFF, caricamento riflessivo, syscall a cascata, e profili di injection.
---
## Il motore
### Livello di astrazione delle API
```
┌────────────────────────────────────────────────────────────────────────────┐
│ ANY OFFENSIVE INTENT │
│ Loader · Injector · Spoofer · Patcher · Bypasser · Harvester · ... │
├────────────────────────────────────────────────────────────────────────────┤
│ SINDRIKIT API ABSTRACTION LAYER │
│ 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 │
├──────────────────┬──────────────────────┬──────────────────────────────────┤
│ Win32 Profile │ Native Profile │ Bring Your Own Mechanic │
│ VirtualAlloc │ NtAllocateVirtual │ Driver · ROP · Exotic │
│ LoadLibraryA │ PEB Walk + EAT │ Operator-defined functions │
└──────────────────┴──────────────────────┴──────────────────────────────────┘
```
In pratica, questo significa che ogni dominio segue lo stesso contratto:
```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 di syscall a cascata
SindriKit tratta la risoluzione delle syscall come una meccanica iniettabile, impilando strategie in ordine di priorità. Il motore procede a cascata finché una non riesce:
```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);
```
L'invoker è disaccoppiato dalla risoluzione SSN — passa tra syscall dirette, indirette e spoofed senza modificare il codice del dominio. L'invocazione indiretta salta a un gadget NTDLL legittimo così l'indirizzo di ritorno rimane dentro `ntdll.dll`; l'invocazione spoofed pianta inoltre un indirizzo di ritorno del chiamante genuino dentro un "Fat Frame" scoperto dinamicamente, così gli unwind dello stack di chiamata rimangono coerenti.
### Agilità degli algoritmi a compile-time
Ogni nome di API e stringa di modulo viene rimosso dal binario finale in fase di compilazione tramite una singola variabile 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
```
Ogni hash viene calcolato con un seed generato casualmente (se `SND_RANDOMIZE_SEED=ON`). L'impronta statica cambia completamente tra le compilazioni senza toccare una riga di C.
### FFI dinamica architecture-aware
Un bridge assembly MASM personalizzato per l'invocazione arbitraria di funzioni a runtime. Le build x64 seguono precisamente la calling convention Microsoft x64 (shadow space, posizionamento degli argomenti nei registri, allineamento dello stack). Le build x86 spingono gli argomenti in ordine inverso con supporto sia per target `cdecl` che `stdcall`.
### Parser PE con controllo dei limiti
Un parser unificato PE32/PE32+ con un flag `is_mapped` che gestisce correttamente sia immagini raw su disco che viste memory-mapped. Ogni accesso alle data directory viene validato rispetto ai limiti del buffer tracciato prima della dereferenziazione. La risoluzione degli export supporta catene di forwarder fino a profondità 4 con lookup basato su hash.
Testato contro:
- Oltre 40 combinazioni di test core mirate a EXE, DLL, argomenti errati, export mancanti e callback TLS su x86 e x64.
- Oltre 100 mutazioni PE dinamiche generate dal modulo `pe_mutator`: nomi di sezione azzerati, integer overflow, limiti `e_lfanew` non validi, import manomessi.
- Corpus completo Corkami: carica correttamente i campioni validi, rifiuta correttamente quelli malformati senza crashare sul 99% dei campioni.
### Loader COFF / BOF
Una seconda tecnica di loader gestisce file oggetto COFF non linkati (Beacon Object Files): parsing con limiti di header, sezioni, simboli e rilocazioni; risoluzione di simboli esterni `MODULE$Function` tramite il `mod_api` iniettato; trampolini x64 `JMP [RIP+0]` per chiamate fuori range; ed esecuzione di un entry point denominato (default `go`) — localmente o marshallato in un processo remoto.
### Contesti di dominio con stato tracciato
Ogni operazione offensiva è gestita tramite una struttura di contesto discreta con enumerazione delle fasi. Le operazioni possono essere messe in pausa tra le fasi per sleep obfuscation o deployment a stadi, riprese in modo pulito, e ispezionate per il punto esatto di fallimento fino al sottosistema e alla causa.
---
## La filosofia di progettazione delle API
Inizializza la pipeline di syscall una volta (pattern tipico):
```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);
```
L'invoker è disaccoppiato dalla risoluzione SSN — passa tra syscall dirette, indirette e spoofed senza modificare il codice del dominio. L'invocazione indiretta salta a un gadget NTDLL legittimo così l'indirizzo di ritorno rimane dentro `ntdll.dll`; l'invocazione spoofed pianta inoltre un indirizzo di ritorno del chiamante genuino dentro un "Fat Frame" scoperto dinamicamente, così gli unwind dello stack di chiamata rimangono coerenti.
Scambia il profilo di esecuzione con un'assegnazione:
```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 risoluzione dei moduli segue lo stesso pattern (`snd_mod_win` vs `snd_mod_nt`). Non esiste un backend di moduli basato su syscall — gli import usano PEB walk + EAT anche nei profili `_sys` completi.
---
## Tier di build
### Tier Debug — `SND_ENABLE_DEBUG=ON`
Per lo sviluppo locale. `snd_status_t` si espande per includere `file`, `line`, e un buffer di stringa `context` da 128 byte. `SND_ERR_CTX` e `SND_DEBUG_PRINT` emettono transizioni della macchina a stati, valori dei campi PE parsati, e esiti della risoluzione delle syscall. Usa `SND_USE_PRINTF=ON` per indirizzare l'output a `stdout` invece che alla debug console.
### Tier Silent — `SND_ENABLE_DEBUG=OFF`
La configurazione di deployment standard per binari operativi. Ogni stringa diagnostica, riferimento a file e numero di riga viene completamente eliminato in fase di compilazione. `snd_status_t` si riduce a due interi. Nient'altro. Una build `SND_CRTLESS=ON` aggiunge `/NODEFAULTLIB`, nessun header Windows SDK, un frontend a riga di comando basato su PEB, e solo backend nativi.
```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)
```
---
## Documentazione
Riferimento completo sotto [`docs/`](https://github.com/youssefnoob003/sindrikit/blob/main/docs/README.md):
- **[Riferimento API](https://github.com/youssefnoob003/sindrikit/blob/main/docs/api_reference.md)** — l'API C pubblica completa (funzioni, tipi, tabelle DI, codici di stato)
- **[Guida introduttiva](https://github.com/youssefnoob003/sindrikit/blob/main/docs/getting_started/README.md)** — tier di build, integrazione CMake, bootstrap delle syscall, primo workflow di loader/injection
- **[Architettura](https://github.com/youssefnoob003/sindrikit/blob/main/docs/architecture/README.md)** — dependency injection, macchine a stati, sistema di stato codificato per facility
- **[Primitive](https://github.com/youssefnoob003/sindrikit/blob/main/docs/primitives/README.md)** — memoria, moduli, processi, mapping, file, thread, syscall, esecuzione (FFI, Heaven's Gate)
- **[Loader](https://github.com/youssefnoob003/sindrikit/blob/main/docs/loaders/README.md)** — caricamento riflessivo PE e COFF/BOF
- **[Injection](https://github.com/youssefnoob003/sindrikit/blob/main/docs/injection/README.md)** — injection classica, early-bird APC, e thread-hijack (shellcode, PE, COFF)
- **[Parser](https://github.com/youssefnoob003/sindrikit/blob/main/docs/parsers/README.md)** — parsing PE, COFF, e env (PEB/NTDLL)
- **[Common](https://github.com/youssefnoob003/sindrikit/blob/main/docs/common/README.md)** — helper CRT-free, buffer, hashing, stato
- **[Esempi & PoC](https://github.com/youssefnoob003/sindrikit/blob/main/docs/examples/README.md)** — la CLI `unified` (`load pe|coff`, `inject classic|apc|hijack`, `hg`)
- **[Test](https://github.com/youssefnoob003/sindrikit/blob/main/docs/tests/README.md)** — runner di integrazione e il PE mutator
*In programma: un dominio **Evasion**.*
---
## Disclaimer
**SindriKit è costruito solo per scopi educativi, di ricerca e Red Teaming autorizzato.** Per il disclaimer legale completo e informazioni sulle considerazioni OpSec, vedi la [Security Policy](https://github.com/youssefnoob003/sindrikit/blob/main/SECURITY.md).
---
## Licenza
[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>