SindriKit

Offensive Development verdient eine bessere Architektur.
Eine C-Bibliothek zum Aufbau offensiver Fähigkeiten.

Kernkonzept

Die meisten offensiven Werkzeuge kodieren ihre Ausführungsmechanik fest in die Logik der Technik. Ein reflektiver Loader mappt nicht einfach ein Image; er mappt es unter Verwendung einer bestimmten, fest kodierten Kette von VirtualAlloc- oder nativen NTAPI-Aufrufen. Wenn eine EDR beginnt, diese spezifische Kette zu überwachen, sind Sie gezwungen, das gesamte Werkzeug neu zu schreiben.

SindriKit löst dies, indem es eine Trennung der Belange durch Interface-Abstraktionstabellen erzwingt:

Die Technik-Logik: (z. B. Loader, Injektionen, Patcher) befasst sich mit Zustandsverfolgung und Datenorchestrierung. Sie hat keine Kenntnis davon, wie Speicher zugewiesen oder Threads erstellt werden.
Die Ausführungsmechanik: (z. B. Win32-API, Native NTAPI, Direct Syscalls) befindet sich in unabhängigen API-Tabellen und wird zur Laufzeit in die Technik injiziert.

Indem die Ausführungsmechanik auf Laufzeit-Funktionszeiger verlagert wird, können Sie Ihre gesamte Strategie von Win32-Aufrufen auf rohe Direct Syscalls mit einer einzigen Codezeile umstellen – ohne Ihre Payload-Ausführungslogik zu ändern.

Design-Architektur

Entkoppelte Ausführungsprofile: Tauschen Sie zugrunde liegende Speicher-, Modul- und Thread-Manipulationsverhalten über Funktionszeigertabellen aus, ohne die aufrufende Technik zu brechen.
Kaskadierende Syscall-Fallbacks: Austauschbare SSN-Resolver (snd_syscall_resolve_ssn_scan, snd_syscall_resolve_ssn_sort) mit einer Prioritätskette – tauschen Sie Strategien aus oder erweitern Sie sie, ohne den Domänencode zu berühren.
Compile-Time-Obfuskation: String- und API-Hashing-Algorithmen (DJB2, FNV1A) können global über CMake ausgetauscht werden. Das Kompilieren randomisiert automatisch den globalen Seed, um statische Signaturen zu verändern.
Mutations-Engine: Ermöglicht tiefe Polymorphie über SND_MORPH. Generiert bei jedem Build einzigartige binäre Signaturen, indem volatile opake Prädikate in C-Code, funktional äquivalente Math/NOPs in Assembly-Stubs injiziert und das Speicherlayout der Kernstrukturen verwürfelt wird.
Release-Builds: Eine stille Stufe entfernt alle diagnostischen Strings, Dateideskriptoren und Tracking-Frames aus der finalen Binärdatei und reduziert Ihren statischen Footprint auf bloße Primitive.

SindriKit integrieren

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

Nur zwei Zeilen, damit Ihr Werkzeug alle Fähigkeiten von SindriKit erbt: PE-Parsing, Syscall-Auflösung, reflektives Laden...

Die Engine

API-Abstraktionsschicht

        ┌────────────────────────────────────────────────────────────────────────────┐
        │                          JEDE OFFENSIVE ABSICHT                            │
        │    Loader · Injector · Spoofer · Patcher · Bypasser · Harvester · ...      │
        ├────────────────────────────────────────────────────────────────────────────┤
        │                     SINDRIKIT API-ABSTRAKTIONSSCHICHT                       │
        │      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  │
        │      [ zukünftige Tabellen ] ->  thread · object · ...                     │
        ├──────────────────┬──────────────────────┬──────────────────────────────────┤
        │   Win32-Profil   │    Natives Profil    │    Eigene Mechanik mitbringen    │
        │  VirtualAlloc    │  NtAllocateVirtual   │  Driver · ROP · Exotisch         │
        │  LoadLibraryA    │  PEB Walk + EAT      │  Operator-definierte Funktionen  │
        └──────────────────┴──────────────────────┴──────────────────────────────────┘

In der Praxis bedeutet dies, dass jede Domäne demselben Vertrag folgt:

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

Kaskadierende Syscall-Pipeline

SindriKit behandelt die Syscall-Auflösung als eine injizierbare Mechanik, die Strategien in Prioritätsreihenfolge stapelt. Die Engine fällt durch, bis eine erfolgreich ist:

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

Der Invoker ist von der SSN-Auflösung entkoppelt – wechseln Sie zwischen direkten und indirekten Syscalls, ohne den Domänencode zu ändern. Der indirekte Aufruf springt zu einem legitimen NTDLL-Gadget und hält die Syscall-Rücksprungadresse innerhalb von ntdll.dll.

Compile-Time-Algorithmus-Agilität

Jeder API-Name und Modul-String wird zur Kompilierzeit über eine einzige CMake-Variable aus der finalen Binärdatei entfernt:

set(SND_HASH_ALGO "FNV1A")  # or DJB2 recomputes everything automatically
set(SND_RANDOMIZE_SEED ON)  # generates a fresh 32-bit seed on next configure

Jeder Hash wird mit einem zufällig generierten Seed berechnet (wenn SND_RANDOMIZE_SEED=ON). Der statische Footprint verschiebt sich vollständig zwischen Kompilierungen, ohne eine Zeile C zu berühren.

Architektur-bewusste dynamische FFI

Eine benutzerdefinierte MASM-Assembly-Brücke für beliebige Laufzeit-Funktionsaufrufe. x64-Builds folgen präzise der Microsoft x64-Aufrufkonvention (Shadow Space, Register-Argumentplatzierung, Stack-Ausrichtung). x86-Builds pushen Argumente in umgekehrter Reihenfolge mit Unterstützung für sowohl cdecl- als auch stdcall-Ziele.

Bounds-geprüfter PE-Parser

Ein einheitlicher PE32/PE32+-Parser mit einem is_mapped-Flag, das sowohl rohe On-Disk-Images als auch speichergemappte Views korrekt handhabt. Jeder Datenverzeichniszugriff wird gegen verfolgte Puffergrenzen validiert, bevor dereferenziert wird. Die Export-Auflösung unterstützt Forwarder-Ketten bis zu einer Tiefe von 4 mit hash-basiertem Lookup.

Getestet gegen:

Über 40 Kern-Testkombinationen, die auf Edge-Case-EXEs, DLLs, fehlerhafte Argumente, fehlende Exporte und TLS-Callbacks über x86 und x64 abzielen.
Über 100 dynamische PE-Mutationen, die vom pe_mutator-Modul generiert wurden: genullte Section-Namen, Integer-Overflows, ungültige e_lfanew-Grenzen, verstümmelte Importe.
Vollständiger Corkami-Korpus: lädt gültige Samples sauber, lehnt fehlerhafte ohne Absturz über 99 % der Samples sauber ab.

SindriKit v1.5.0