SindriKit

Lo sviluppo offensivo merita un'architettura migliore.
Una libreria C per costruire capacità offensive.

Concetto fondamentale

La maggior parte delle utility offensive codifica in modo rigido i propri meccanismi 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:

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.
I meccanismi di esecuzione: (ad es. Win32 API, NTAPI native, Direct Syscalls) risiedono in tabelle API indipendenti e vengono iniettati nella tecnica a runtime.

Spostando i meccanismi 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 i comportamenti sottostanti di manipolazione di memoria, moduli e thread tramite tabelle di puntatori a funzione senza rompere la tecnica chiamante.
Fallback a cascata per le syscall: resolver SSN pluggable (snd_syscall_resolve_ssn_scan, snd_syscall_resolve_ssn_sort) con una catena di priorità — scambia o estendi le strategie senza toccare il codice di dominio.
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 silenzioso rimuove tutte le stringhe diagnostiche, i descrittori di file e i frame di tracciamento dal binario finale, riducendo il tuo footprint statico a primitive pure.

Integrare SindriKit

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)

cmake -B build && cmake --build build --config Release

Solo due righe perché il tuo strumento erediti tutte le capacità di SindriKit: parsing PE, risoluzione delle syscall, reflective loading...

Il motore

Livello di astrazione delle API

        ┌────────────────────────────────────────────────────────────────────────────┐
        │                          QUALSIASI INTENTO OFFENSIVO                       │
        │    Loader · Injector · Spoofer · Patcher · Bypasser · Harvester · ...      │
        ├────────────────────────────────────────────────────────────────────────────┤
        │                     LIVELLO DI ASTRAZIONE API DI 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  │
        │      [ tabelle future ] ->  thread · object · ...                          │
        ├──────────────────┬──────────────────────┬──────────────────────────────────┤
        │   Profilo Win32  │   Profilo Nativo     │    Porta il Tuo Meccanismo       │
        │  VirtualAlloc    │  NtAllocateVirtual   │  Driver · ROP · Esotico          │
        │  LoadLibraryA    │  PEB Walk + EAT      │  Funzioni definite dall'operatore│
        └──────────────────┴──────────────────────┴──────────────────────────────────┘

In pratica, questo significa che ogni dominio segue lo stesso contratto:

// 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 a cascata per le syscall

SindriKit tratta la risoluzione delle syscall come un meccanismo iniettabile, impilando le strategie in ordine di priorità. Il motore procede a cascata finché una non riesce:

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);

L'invoker è disaccoppiato dalla risoluzione SSN — passa tra syscall dirette e indirette senza modificare il codice di dominio. L'invocazione indiretta salta a un gadget legittimo di NTDLL, mantenendo l'indirizzo di ritorno della syscall all'interno di ntdll.dll.

Agilità degli algoritmi a compile-time

Ogni nome di API e stringa di modulo viene rimosso dal binario finale a compile-time tramite una singola variabile 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). Il footprint statico cambia completamente tra le compilazioni senza toccare una riga di C.

FFI dinamica consapevole dell'architettura

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 mappate in memoria. Ogni accesso a una data directory viene validato rispetto ai limiti del buffer tracciati 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 ai limiti tra x86 e x64.
Oltre 100 mutazioni PE dinamiche generate dal modulo pe_mutator: nomi di sezione azzerati, overflow di interi, 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.

SindriKit v1.5.0