youssefnoob003/sindrikitUne bibliothèque C fondamentale pour la construction de capacités offensives opérationnellement crédibles
<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>Le développement offensif mérite une meilleure architecture.</strong><br>
<em>Une bibliothèque C pour construire des capacités offensives.</em>
</p>
---
## Concept central
La plupart des utilitaires offensifs codent en dur leurs mécanismes d'exécution au sein de la logique de la technique. Un loader réflexif ne se contente pas de mapper une image ; il la mappe en utilisant une chaîne spécifique et codée en dur d'appels `VirtualAlloc` ou NTAPI natifs. Lorsqu'un EDR commence à surveiller cette chaîne spécifique, vous êtes contraint de réécrire l'outil entier.
SindriKit résout ce problème en imposant une séparation des responsabilités via des tables d'abstraction d'interface :
1. **La logique de la technique :** (par ex., loaders, injections, patchers) gère le suivi d'état et l'orchestration des données. Elle n'a aucune connaissance de la manière dont la mémoire est allouée ou dont les threads sont créés.
2. **Les mécanismes d'exécution :** (par ex., API Win32, NTAPI natif, syscalls directs) résident dans des tables d'API indépendantes et sont injectés dans la technique à l'exécution.
En déplaçant les mécanismes d'exécution vers des pointeurs de fonction à l'exécution, vous pouvez remplacer toute votre stratégie, passant des appels Win32 aux syscalls directs bruts, avec une seule ligne de code — sans modifier la logique d'exécution de votre payload.
---
## Architecture de conception
* **Profils d'exécution découplés :** Remplacez les mécanismes de mémoire, module, mapping, processus, thread et fichier via des tables de pointeurs de fonction indépendantes (`snd_memory_api_t`, `snd_module_api_t`, `snd_process_api_t`, `snd_thread_api_t`, `snd_mapping_api_t`, `snd_file_api_t`) sans toucher à la logique de la technique.
* **Couverture des techniques :** Chargement réflexif **PE** (EXE/DLL) et **COFF/BOF**, injection **classique** et **early-bird APC** sur shellcode/PE/COFF, plus FFI sensible à l'architecture et Heaven's Gate — le tout sur les mêmes profils composables.
* **Pipeline de syscalls en cascade :** Résolveurs de SSN enfichables (`snd_syscall_resolve_ssn_scan`, `snd_syscall_resolve_ssn_sort`) avec une chaîne de priorité, découplés des invokers : **direct**, **indirect** (gadget NTDLL), ou **spoofé** (spoofing dynamique de pile d'appels Fat-Frame).
* **Statut encodé par facility :** Chaque appel susceptible d'échouer retourne `snd_status_t` — un code facility/local compacté plus l'erreur OS capturée, avec des chaînes de contexte qui disparaissent à la compilation dans le tier silencieux.
* **Obfuscation à la compilation :** Les algorithmes de hachage de chaînes et d'API (DJB2, FNV1A) peuvent être échangés globalement via CMake. La compilation randomise automatiquement la graine globale pour altérer les signatures statiques.
* **Moteur de mutation :** Permet un polymorphisme profond via `SND_MORPH`. Génère des signatures binaires uniques à chaque build en injectant des prédicats opaques volatils dans le code C, des math/NOPs fonctionnellement équivalents dans les stubs Assembly, et en brouillant la disposition mémoire des structures principales.
* **Builds de release :** Un tier silencieux supprime toutes les chaînes de diagnostic, descripteurs de fichiers et trames de suivi ; les builds `SND_CRTLESS` vont plus loin avec `/NODEFAULTLIB`, aucun en-tête SDK, un frontend PEB, et uniquement des backends natifs.
---
## Démarrage rapide
Le dépôt fournit un unique CLI `unified` qui exerce chaque profil :
```sh
build.bat pocs
build64\pocs\Release\unified.exe load pe -f payload.dll -e Run --sys
```
`unified` prend en charge `load pe|coff`, `inject classic|apc|hijack` (shell, PE, COFF), et `hg`, chacun via `--win`/`--nt`/`--sys`. Voir [Exemples & PoCs](https://github.com/youssefnoob003/sindrikit/blob/main/docs/examples/README.md) et [Prise en main](https://github.com/youssefnoob003/sindrikit/blob/main/docs/getting_started/README.md).
---
## Intégrer 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
```
Seulement deux lignes pour que votre outil hérite de toutes les capacités de SindriKit : parsing PE et COFF, chargement réflexif, syscalls en cascade, et profils d'injection.
---
## Le moteur
### Couche d'abstraction d'API
```
┌────────────────────────────────────────────────────────────────────────────┐
│ TOUTE INTENTION OFFENSIVE │
│ Loader · Injector · Spoofer · Patcher · Bypasser · Harvester · ... │
├────────────────────────────────────────────────────────────────────────────┤
│ COUCHE D'ABSTRACTION D'API 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 │
│ snd_mapping_api_t -> open · view · close (KnownDlls bootstrap) │
│ snd_thread_api_t -> queue_apc · resume · suspend │
│ snd_file_api_t -> load │
├──────────────────┬──────────────────────┬──────────────────────────────────┤
│ Profil Win32 │ Profil natif │ Apportez votre mécanique │
│ VirtualAlloc │ NtAllocateVirtual │ Driver · ROP · Exotique │
│ LoadLibraryA │ PEB Walk + EAT │ Fonctions définies par l'opérateur │
└──────────────────┴──────────────────────┴──────────────────────────────────┘
```
En pratique, cela signifie que chaque domaine suit le même contrat :
```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 de syscalls en cascade
SindriKit traite la résolution des syscalls comme une mécanique injectable, empilant les stratégies par ordre de priorité. Le moteur passe à la suivante jusqu'à ce que l'une réussisse :
```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 est découplé de la résolution des SSN — basculez entre syscalls directs, indirects et spoofés sans modifier le code du domaine. L'invocation indirecte saute vers un gadget NTDLL légitime afin que l'adresse de retour reste à l'intérieur de `ntdll.dll` ; l'invocation spoofée plante en plus une véritable adresse de retour d'appelant à l'intérieur d'un « Fat Frame » découvert dynamiquement, afin que les déroulements de pile d'appels restent cohérents.
### Agilité algorithmique à la compilation
Chaque nom d'API et chaîne de module est retiré du binaire final à la compilation via une seule variable 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
```
Chaque hash est calculé avec une graine générée aléatoirement (si `SND_RANDOMIZE_SEED=ON`). L'empreinte statique change complètement entre les compilations sans toucher une ligne de C.
### FFI dynamique sensible à l'architecture
Un pont assembly MASM personnalisé pour l'invocation arbitraire de fonctions à l'exécution. Les builds x64 suivent précisément la convention d'appel Microsoft x64 (shadow space, placement des arguments dans les registres, alignement de pile). Les builds x86 empilent les arguments en ordre inverse avec prise en charge des cibles `cdecl` et `stdcall`.
### Parser PE avec vérification des bornes
Un parser PE32/PE32+ unifié avec un flag `is_mapped` qui gère correctement à la fois les images brutes sur disque et les vues mappées en mémoire. Chaque accès à un répertoire de données est validé par rapport aux bornes du buffer suivi avant déréférencement. La résolution des exports prend en charge les chaînes de forwarders jusqu'à une profondeur de 4 avec recherche basée sur le hash.
Testé contre :
- Plus de 40 combinaisons de tests principaux ciblant des EXE et DLL aux cas limites, des arguments invalides, des exports manquants et des callbacks TLS sur x86 et x64.
- Plus de 100 mutations PE dynamiques générées par le module `pe_mutator` : noms de sections mis à zéro, dépassements d'entiers, bornes `e_lfanew` invalides, imports altérés.
- Corpus Corkami complet : charge proprement les échantillons valides, rejette proprement les malformés sans planter sur 99 % des échantillons.
### Loader COFF / BOF
Une seconde technique de loader gère les fichiers objets COFF non liés (Beacon Object Files) : parsing borné des en-têtes, sections, symboles et relocations ; résolution des symboles externes `MODULE$Function` via le `mod_api` injecté ; trampolines x64 `JMP [RIP+0]` pour les appels hors portée ; et exécution d'un point d'entrée nommé (par défaut `go`) — localement ou marshallé dans un processus distant.
### Contextes de domaine avec suivi d'état
Chaque opération offensive est gérée via une structure de contexte discrète avec énumération des étapes. Les opérations peuvent être mises en pause entre les étapes pour l'obfuscation de sommeil ou le déploiement par étapes, reprises proprement, et inspectées pour identifier le point de défaillance exact jusqu'au sous-système et à la raison.
---
## La philosophie de conception de l'API
Initialisez le pipeline de syscalls une fois (schéma typique) :
```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 est découplé de la résolution des SSN — basculez entre syscalls directs, indirects et spoofés sans modifier le code du domaine. L'invocation indirecte saute vers un gadget NTDLL légitime afin que l'adresse de retour reste à l'intérieur de `ntdll.dll` ; l'invocation spoofée plante en plus une véritable adresse de retour d'appelant à l'intérieur d'un « Fat Frame » découvert dynamiquement, afin que les déroulements de pile d'appels restent cohérents.
Remplacez le profil d'exécution avec une seule affectation :
```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 résolution de module suit le même schéma (`snd_mod_win` vs `snd_mod_nt`). Il n'existe pas de backend de module basé sur les syscalls — les imports utilisent PEB walk + EAT même dans les profils `_sys` complets.
---
## Tiers de build
### Tier Debug — `SND_ENABLE_DEBUG=ON`
Pour le développement local. `snd_status_t` s'étend pour inclure `file`, `line`, et un buffer de chaîne `context` de 128 octets. `SND_ERR_CTX` et `SND_DEBUG_PRINT` émettent les transitions de machine à états, les valeurs de champs PE parsés, et les résultats de résolution de syscalls. Utilisez `SND_USE_PRINTF=ON` pour router la sortie vers `stdout` au lieu de la console de debug.
### Tier silencieux — `SND_ENABLE_DEBUG=OFF`
La configuration de déploiement standard pour les binaires opérationnels. Chaque chaîne de diagnostic, référence de fichier et numéro de ligne disparaît complètement à la compilation. `snd_status_t` se réduit à deux entiers. Rien d'autre. Un build `SND_CRTLESS=ON` ajoute `/NODEFAULTLIB`, aucun en-tête Windows SDK, un frontend de ligne de commande PEB, et uniquement des backends natifs.
```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)
```
---
## Documentation
Référence complète sous [`docs/`](https://github.com/youssefnoob003/sindrikit/blob/main/docs/README.md) :
- **[Référence API](https://github.com/youssefnoob003/sindrikit/blob/main/docs/api_reference.md)** — l'API C publique complète (fonctions, types, tables DI, codes de statut)
- **[Prise en main](https://github.com/youssefnoob003/sindrikit/blob/main/docs/getting_started/README.md)** — tiers de build, intégration CMake, bootstrap des syscalls, premier workflow loader/injection
- **[Architecture](https://github.com/youssefnoob003/sindrikit/blob/main/docs/architecture/README.md)** — injection de dépendances, machines à états, système de statut encodé par facility
- **[Primitives](https://github.com/youssefnoob003/sindrikit/blob/main/docs/primitives/README.md)** — mémoire, modules, processus, mapping, fichiers, thread, syscalls, exécution (FFI, Heaven's Gate)
- **[Loaders](https://github.com/youssefnoob003/sindrikit/blob/main/docs/loaders/README.md)** — chargement réflexif PE et COFF/BOF
- **[Injection](https://github.com/youssefnoob003/sindrikit/blob/main/docs/injection/README.md)** — injection classique, early-bird APC, et thread-hijack (shellcode, PE, COFF)
- **[Parsers](https://github.com/youssefnoob003/sindrikit/blob/main/docs/parsers/README.md)** — parsing PE, COFF, et env (PEB/NTDLL)
- **[Common](https://github.com/youssefnoob003/sindrikit/blob/main/docs/common/README.md)** — helpers sans CRT, buffers, hachage, statut
- **[Exemples & PoCs](https://github.com/youssefnoob003/sindrikit/blob/main/docs/examples/README.md)** — le CLI `unified` (`load pe|coff`, `inject classic|apc|hijack`, `hg`)
- **[Tests](https://github.com/youssefnoob003/sindrikit/blob/main/docs/tests/README.md)** — runners d'intégration et le mutateur PE
*Prévu : un domaine **Evasion**.*
---
## Avertissement
**SindriKit est conçu uniquement à des fins éducatives, de recherche et de Red Teaming autorisé.** Pour l'avertissement légal complet et les informations concernant les considérations OpSec, voir la [Politique de sécurité](https://github.com/youssefnoob003/sindrikit/blob/main/SECURITY.md).
---
## Licence
[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>