SindriKit

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

---

Kernkonzept

Die meisten offensiven Utilities hardcodieren ihre Ausführungsmechaniken innerhalb der Logik der Technik. Ein reflektiver Loader mappt nicht einfach ein Image; er mappt es unter Verwendung einer bestimmten, hardcodierten Kette von VirtualAlloc- oder nativen NTAPI-Aufrufen. Wenn eine EDR beginnt, diese spezifische Kette zu überwachen, sind Sie gezwungen, das gesamte Tool neu zu schreiben.

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

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

Indem Ausführungsmechaniken auf Laufzeit-Funktionszeiger verlagert werden, 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 Speicher-, Modul-, Mapping-, Prozess-, Thread- und Dateimechaniken über unabhängige Funktionszeiger-Tabellen (snd_memory_api_t, snd_module_api_t, snd_process_api_t, snd_thread_api_t, snd_mapping_api_t, snd_file_api_t) aus, ohne die Technik-Logik zu berühren.
• Technik-Abdeckung: Reflektives PE- (EXE/DLL) und COFF/BOF-Laden, klassische und Early-Bird-APC-Injection über Shellcode/PE/COFF, plus architekturbewusste FFI und Heaven's Gate – alles über dieselben komponierbaren Profile.
• Kaskadierende Syscall-Pipeline: Austauschbare SSN-Resolver (snd_syscall_resolve_ssn_scan, snd_syscall_resolve_ssn_sort) mit einer Prioritätskette, entkoppelt von Invokern: direct, indirect (NTDLL-Gadget) oder spoofed (dynamisches Fat-Frame-Call-Stack-Spoofing).
• Facility-kodierter Status: Jeder fehleranfällige Aufruf gibt snd_status_t zurück – ein gepackter Facility/Local-Code plus der erfasste OS-Fehler, mit Kontextstrings, die in der Silent-Tier herauskompilieren.
• 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 Silent-Tier entfernt alle diagnostischen Strings, Dateideskriptoren und Tracking-Frames; SND_CRTLESS-Builds gehen weiter mit /NODEFAULTLIB, keinem SDK-Header, einem PEB-Frontend und ausschließlich nativen Backends.

---

Schnellstart

Das Repository liefert eine einzige unified-CLI, die jedes Profil ausübt:

build.bat pocs
build64\pocs\Release\unified.exe load pe -f payload.dll -e Run --sys

unified unterstützt load pe|coff, inject classic|apc|hijack (shell, PE, COFF) und hg, jeweils über --win/--nt/--sys. Siehe Examples & PoCs und Getting Started.

---

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 Tool alle Fähigkeiten von SindriKit erbt: PE- und COFF-Parsing, reflektives Laden, kaskadierende Syscalls und Injection-Profile.

---

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 │
        │      snd_mapping_api_t  ->  open · view · close   (KnownDlls bootstrap)    │
        │      snd_thread_api_t   ->  queue_apc · resume · suspend                   │
        │      snd_file_api_t     ->  load                                           │
        ├──────────────────┬──────────────────────┬──────────────────────────────────┤
        │   Win32-Profil   │    Natives Profil    │    Bring Your Own Mechanic       │
        │  VirtualAlloc    │  NtAllocateVirtual   │  Driver · ROP · Exotic           │
        │  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 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);
// or for spoofed syscalls:
// snd_syscall_set_invoker(snd_syscall_spoofed_invoke_asm);
// snd_syscall_set_spoof_finder(snd_syscall_find_spoof_scan);

Der Invoker ist von der SSN-Auflösung entkoppelt – wechseln Sie zwischen direkten, indirekten und gespooften Syscalls, ohne Domänencode zu ändern. Indirekte Invocation springt zu einem legitimen NTDLL-Gadget, sodass die Rückkehradresse innerhalb von ntdll.dll bleibt; gespoofte Invocation platziert zusätzlich eine echte Aufrufer-Rückkehradresse innerhalb eines dynamisch entdeckten "Fat Frame", sodass Call-Stack-Unwinds kohärent bleiben.

Compile-Time-Algorithmus-Agilität

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