SindriKit

攻击性开发需要更优秀的架构。
一个用于构建攻击性能力的 C 库。

## 核心理念 大多数攻击性工具将其执行机制硬编码在技术逻辑中。一个反射式加载器不仅仅是映射一个镜像；它使用特定的、硬编码的 `VirtualAlloc` 链或原生 NTAPI 调用来映射它。当 EDR 开始监控这一特定调用链时，你将被迫重写整个工具。 SindriKit 通过接口抽象表强制实行关注点分离来解决此问题： 通过将执行机制转移到运行时的函数指针，你可以仅用一行代码将整个策略从 Win32 调用切换为原始的直接系统调用——而无需更改你的 payload 执行逻辑。 ## 设计架构 * **解耦的执行配置：** 通过函数指针表替换底层的内存、模块和线程操作行为，而不会破坏调用方的技术逻辑。 * **级联系统调用回退：** 可插拔的 SSN 解析器（`snd_syscall_resolve_ssn_scan`、`snd_syscall_resolve_ssn_sort`）带有优先级链 —— 无需触碰领域代码即可替换或扩展策略。 * **编译时混淆：** 字符串和 API 哈希算法（DJB2、FNV1A）可以通过 CMake 进行全局切换。编译时会自动随机化全局种子以改变静态特征。 * **静默级别构建：** 一个静默层级会从最终二进制文件中剥离所有诊断字符串、文件描述符和跟踪框架，将你的静态痕迹降低到最基本的原语。 ## 集成 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 "") 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 抽象层 ``` ┌────────────────────────────────────────────────────────────────────────────┐ │ ANY OFFENSIVE INTENT │ │ Loader · Injector · Spoofer · Patcher · Bypasser · Harvester · ... │ ├────────────────────────────────────────────────────────────────────────────┤ │ SINDRIKIT API ABSTRACTION LAYER │ │ 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 │ │ [ future tables ] -> thread · object · ... │ ├──────────────────┬──────────────────────┬──────────────────────────────────┤ │ Win32 Profile │ Native Profile │ Bring Your Own Mechanic │ │ VirtualAlloc │ NtAllocateVirtual │ Driver · ROP · Exotic │ │ LoadLibraryA │ PEB Walk + EAT │ Operator-defined functions │ └──────────────────┴──────────────────────┴──────────────────────────────────┘ ``` 在实践中，这意味着每个领域都遵循相同的契约： ``` // 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); ``` ### 级联系统调用流水线 SindriKit 将系统调用解析视为一种可注入的机制，按优先级顺序堆叠策略。引擎会依次进行回退，直到其中一个成功： ``` snd_syscall_set_ntdll(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); ``` 调用方与 SSN 解析相解耦 —— 可以在直接和间接系统调用之间切换，而无需修改领域代码。间接调用会跳转到一个合法的 NTDLL gadget，将系统调用返回地址保持在 `ntdll.dll` 范围内。 ### 编译时算法灵活性 每一个 API 名称和模块字符串都会在编译时通过单个 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 ``` 每个哈希都使用随机生成的种子进行计算（如果启用了 `SND_RANDOMIZE_SEED=ON`）。即使不修改任何一行 C 代码，每次编译之间的静态痕迹也会发生彻底改变。 ### 架构感知的动态 FFI ### 边界检查的 PE 解析器 一个统一的 PE32/PE32+ 解析器，带有 `is_mapped` 标志，能够正确处理磁盘上的原始镜像和内存映射视图。在解引用之前，每次数据目录访问都会根据已跟踪的缓冲区边界进行验证。导出解析支持深度高达 4 的转发链，并支持基于哈希的查找。 已在以下情况下进行测试： - 针对 x86 和 x64 架构下的边缘情况 EXE、DLL、错误参数、缺失导出和 TLS 回调，进行了 40 多种核心测试组合。 - 由 `pe_mutator` 模块生成的 100 多种动态 PE 变异：清零的节名称、整数溢出、无效的 `e_lfanew` 边界、损坏的导入。 - 完整的 Corkami 语料库：能够干净地加载有效样本，并干净地拒绝格式错误的样本，在 99% 的样本中都不会发生崩溃。 ### 状态跟踪的领域上下文 每项攻击性操作都通过一个带有阶段枚举的离散上下文结构进行管理。操作可以在不同阶段之间暂停以进行休眠混淆或分阶段部署，能够顺利恢复执行，并且可以精确检查直到子系统层级的失败点及其原因。 ## API 设计理念 一次性引导系统调用流水线（典型模式）： ``` PVOID clean_ntdll = NULL; snd_om_knowndll_map(&snd_map_nt, L"ntdll.dll", &clean_ntdll); snd_syscall_set_ntdll(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); ``` 调用方与 SSN 解析相解耦 —— 可以在直接和间接系统调用之间切换，而无需修改领域代码。间接调用会跳转到一个合法的 NTDLL gadget，将系统调用返回地址保持在 `ntdll.dll` 范围内。 通过一次赋值即可切换执行配置： ``` 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) ``` 模块解析遵循相同的模式（`snd_mod_win` 对比 `snd_mod_nt`）。这里没有基于系统调用的模块后端 —— 即使在完整的 `_sys` 配置中，导入操作也会使用 PEB 遍历 + EAT。 ## 构建层级 ### Debug 层级 — `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/`](docs/README.md) 目录下： - **[入门指南](docs/getting_started/)** — CMake、构建层级、DI 引导、首个加载器/注入工作流 - **[架构设计](docs/architecture/)** — 依赖注入、状态机、状态系统 - **[原语](docs/domains/primitives/)** — 内存、模块、进程、映射、系统调用、执行 (FFI) - **[加载器](docs/domains/loaders/)** — 反射式 PE 流水线 - **[注入](docs/domains/injection/)** — 经典 shellcode 和 PE 注入 - **[解析器](docs/parsers/)** — PE 和环境 (PEB) 子领域 - **[通用组件](docs/common/)** — 无 CRT 辅助工具、缓冲区、哈希、状态 - **[示例与 PoC](docs/examples/)** — `loader_winapi`、`loader_nowinapi`、`inject_pe`、`inject_shell`、`heavens_gate` - **[测试](docs/tests/)** — 集成运行器、PE 变异器 *计划中：**[规避](docs/domains/evasion/)** 领域。* ## 免责声明 **SindriKit 仅供教育、研究和授权的红队目的使用。** 有关完整的法律免责声明及关于 OpSec 注意事项的信息，请参阅 [安全策略](SECURITY.md)。 ## 许可证 [MIT](LICENSE)

标签：Bash脚本, Linux, 客户端加密