SindriKit

攻击性开发值得更好的架构。
一个用于构建攻击性能力的 C 库。

核心概念

大多数攻击性工具将执行机制硬编码在技术逻辑内部。一个反射加载器不仅仅是映射一个映像；它使用特定的、硬编码的 VirtualAlloc 或原生 NTAPI 调用链来映射它。当 EDR 开始监控那条特定的调用链时，你就被迫重写整个工具。

SindriKit 通过接口抽象表强制实现关注点分离来解决这个问题：

技术逻辑：（例如加载器、注入、补丁器）处理状态跟踪和数据编排。它不知道内存是如何分配的，也不知道线程是如何创建的。
执行机制：（例如 Win32 API、原生 NTAPI、直接系统调用）位于独立的 API 表中，并在运行时注入到技术中。

通过将执行机制转移到运行时函数指针，你可以用一行代码将整个策略从 Win32 调用切换为原始直接系统调用——而无需更改你的载荷执行逻辑。

设计架构

解耦的执行配置文件： 通过函数指针表交换底层的内存、模块和线程操作行为，而不会破坏调用技术。
级联系统调用回退： 可插拔的 SSN 解析器（snd_syscall_resolve_ssn_scan、snd_syscall_resolve_ssn_sort）具有优先级链——无需触及领域代码即可交换或扩展策略。
编译时混淆： 字符串和 API 哈希算法（DJB2、FNV1A）可通过 CMake 全局交换。编译时会自动随机化全局种子以改变静态特征。
变异引擎： 通过 SND_MORPH 实现深度多态。通过在 C 代码中注入易变的 opaque predicates、在汇编桩中注入功能等价的数学/NOP，以及打乱核心结构体的内存布局，在每次构建时生成唯一的二进制特征。
发布构建： 一个静默层级会从最终二进制中剥离所有诊断字符串、文件描述符和跟踪帧，将你的静态足迹减少到裸原语。

集成 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

只需两行代码，你的工具就能继承 SindriKit 的所有能力：PE 解析、系统调用解析、反射加载……

引擎

API 抽象层

        ┌────────────────────────────────────────────────────────────────────────────┐
        │                          任意攻击性意图                                     │
        │    加载器 · 注入器 · 欺骗器 · 补丁器 · 绕过器 · 收集器 · ...                 │
        ├────────────────────────────────────────────────────────────────────────────┤
        │                     SINDRIKIT API 抽象层                                    │
        │      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  │
        │      [ 未来表 ]         ->  thread · object · ...                           │
        ├──────────────────┬──────────────────────┬──────────────────────────────────┤
        │   Win32 配置文件  │    原生配置文件       │    自带机制                      │
        │  VirtualAlloc    │  NtAllocateVirtual   │  驱动 · ROP · 奇异               │
        │  LoadLibraryA    │  PEB 遍历 + EAT      │  操作者定义的函数                │
        └──────────────────┴──────────────────────┴──────────────────────────────────┘

在实践中，这意味着每个领域都遵循相同的契约：

// 反射加载器
snd_ldr_pe_ctx_t ctx = {0};
ctx.raw_source = &payload;
ctx.mem_api    = &snd_mem_win;   // 或 snd_mem_nt / snd_mem_sys
ctx.mod_api    = &snd_mod_win;   // 或 snd_mod_nt
snd_ldr_pe_prepare_image(&ctx);
snd_ldr_pe_execute_image(&ctx);

// 经典注入
snd_inj_ctx_t inj = {0};
inj.target_pid = 1337;
inj.payload    = &shellcode;
inj.proc_api   = &snd_proc_sys;  // 或 snd_proc_win / snd_proc_nt
snd_inj_classic_shell(&inj);
snd_inj_cleanup(&inj);

级联系统调用管道

SindriKit 将系统调用解析视为一种可注入的机制，按优先级顺序堆叠策略。引擎会依次回退，直到有一个成功：

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);
// 或用于间接系统调用：
// snd_syscall_set_invoker(snd_syscall_indirect_invoke_asm);
// snd_syscall_set_gadget_finder(snd_syscall_find_gadget_scan);

调用器与 SSN 解析解耦——无需修改领域代码即可在直接和间接系统调用之间切换。间接调用会跳转到合法的 NTDLL gadget，使系统调用返回地址保持在 ntdll.dll 内。

编译时算法敏捷性

每个 API 名称和模块字符串都会在编译时通过单个 CMake 变量从最终二进制中移除：

set(SND_HASH_ALGO "FNV1A")  # 或 DJB2 会自动重新计算一切
set(SND_RANDOMIZE_SEED ON)  # 在下次配置时生成新的 32 位种子

每个哈希都使用随机生成的种子计算（如果 SND_RANDOMIZE_SEED=ON）。静态足迹在编译之间完全改变，而无需触及一行 C 代码。

架构感知的动态 FFI

一个自定义的 MASM 汇编桥接，用于任意运行时函数调用。x64 构建精确遵循 Microsoft x64 调用约定（影子空间、寄存器参数放置、栈对齐）。x86 构建按相反顺序压入参数，并支持 cdecl 和 stdcall 目标。

边界检查的 PE 解析器

一个统一的 PE32/PE32+ 解析器，带有 is_mapped 标志，能够正确处理原始磁盘映像和内存映射视图。每次数据目录访问在解引用之前都会根据跟踪的缓冲区边界进行验证。导出解析支持深度达 4 的转发器链，并具有基于哈希的查找。

已针对以下内容测试：

40+ 核心测试组合，针对 x86 和 x64 上的边缘情况 EXE、DLL、错误参数、缺失导出和 TLS 回调。
100+ 由 pe_mutator 模块生成的动态 PE 变异：清零的节名称、整数溢出、无效的 e_lfanew 边界、损坏的导入。
完整的 Corkami 语料库：干净地加载有效样本，干净地拒绝畸形样本，在 99% 的样本中不会崩溃。

状态跟踪的领域上下文

每个攻击性操作都通过一个离散的上下文结构进行管理，并带有阶段枚举。操作可以在阶段之间暂停以进行睡眠混淆或分阶段部署，干净地恢复，并检查确切的失败点，精确到子系统和原因。

API 设计哲学

一次性引导系统调用管道（典型模式）：

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);
// 或用于间接系统调用：
// snd_syscall_set_invoker(snd_syscall_indirect_invoke_asm);
// snd_syscall_set_gadget_finder(snd_syscall_find_gadget_scan);

通过一次赋值交换执行配置文件：

ctx.mem_api = &snd_mem_win;   // 诊断
ctx.mem_api = &snd_mem_nt;    // 通过 PEB + EAT 的 NT 桩
ctx.mem_api = &snd_mem_sys;   // 直接系统调用（需要管道）

模块解析遵循相同的模式（snd_mod_win 与 snd_mod_nt）。没有由系统调用支持的模块后端——即使在完整的 _sys 配置文件中，导入也使用 PEB 遍历 + EAT。

构建层级

调试层级 — `SND_ENABLE_DEBUG=ON`

用于本地开发。snd_status_t 扩展为包含 file、line 和一个 128 字节的 context 字符串缓冲区。SND_ERR_CTX 和 SND_DEBUG_PRINT 输出状态机转换、解析的 PE 字段值和系统调用解析结果。使用 SND_USE_PRINTF=ON 将输出路由到 stdout 而不是调试控制台。

静默层级 — `SND_ENABLE_DEBUG=OFF`

用于操作型二进制的标准部署配置。每个诊断字符串、文件引用和行号都会完全编译掉。snd_status_t 折叠为两个整数。仅此而已。

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)

文档

完整参考位于 docs/：

入门指南 — CMake、构建层级、DI 引导、首个加载器/注入工作流
架构 — 依赖注入、状态机、状态系统
原语 — 内存、模块、进程、映射、系统调用、执行（FFI）
加载器 — 反射 PE 管道
注入 — 经典 shellcode 和 PE 注入
解析器 — PE 和环境（PEB）子领域
通用 — 无 CRT 辅助函数、缓冲区、哈希、状态
示例与 PoC — unified 可执行配置文件（load、inject、hg）
测试 — 集成运行器、PE 变异器

计划中：规避领域。

免责声明

SindriKit 仅用于教育、研究和授权的红队目的。 有关完整的法律免责声明和 OpSec 注意事项的信息，请参阅安全政策。

许可证

MIT

SindriKit v2.0.0

分类