
SindriKit v2.0.0
運用上信頼性のある攻撃能力を構築するための基礎的なCライブラリ
SindriKit
攻撃的開発には、より優れたアーキテクチャがふさわしい。
攻撃能力を構築するための C ライブラリ。
中核概念
ほとんどの攻撃用ユーティリティは、実行メカニズムをテクニックのロジック内にハードコードしています。リフレクティブローダーは単にイメージをマッピングするのではなく、特定のハードコードされた VirtualAlloc やネイティブ NTAPI 呼び出しの連鎖を用いてマッピングします。EDR がその特定の連鎖を監視し始めると、ツール全体を書き直さざるを得なくなります。
SindriKit は、インターフェース抽象化テーブルを介して関心の分離を強制することで、この問題を解決します:
- テクニックロジック:(例:ローダー、インジェクション、パッチャー)は、状態追跡とデータオーケストレーションを扱います。メモリがどのように割り当てられ、スレッドがどのように作成されるかを知りません。
- 実行メカニズム:(例:Win32 API、ネイティブ NTAPI、ダイレクトシステムコール)は独立した API テーブル内にあり、実行時にテクニックへ注入されます。
実行メカニズムを実行時の関数ポインタへ移行することで、ペイロード実行ロジックを変更することなく、戦略全体を Win32 呼び出しから生のダイレクトシステムコールへ 1 行のコードで切り替えられます。
設計アーキテクチャ
- 分離された実行プロファイル: テクニックロジックに触れることなく、独立した関数ポインタテーブル(
snd_memory_api_t、snd_module_api_t、snd_process_api_t、snd_thread_api_t、snd_mapping_api_t、snd_file_api_t)を通じてメモリ、モジュール、マッピング、プロセス、スレッド、ファイルのメカニズムを差し替え可能。 - テクニックカバレッジ: リフレクティブ PE(EXE/DLL)および COFF/BOF ローディング、shellcode/PE/COFF に対する classic および early-bird APC インジェクション、さらにアーキテクチャ対応の FFI と Heaven's Gate — すべて同一のコンポーザブルプロファイル上で動作。
- カスケード型システムコールパイプライン: プラグ可能な SSN リゾルバ(
snd_syscall_resolve_ssn_scan、snd_syscall_resolve_ssn_sort)を優先度チェーンで構成し、呼び出し側から分離:direct、indirect(NTDLL ガジェット)、または spoofed(動的 Fat-Frame コールスタック偽装)。 - ファシリティエンコードされたステータス: 失敗しうるすべての呼び出しは
snd_status_tを返します — パックされたファシリティ/ローカルコードとキャプチャされた OS エラー、さらに silent ティアではコンパイル時に除去されるコンテキスト文字列を含みます。 - コンパイル時難読化: 文字列および API ハッシュアルゴリズム(DJB2、FNV1A)は CMake を介してグローバルに差し替え可能。コンパイル時にグローバルシードが自動的にランダム化され、静的シグネチャが変化します。
- ミューテーションエンジン:
SND_MORPHを介して深いポリモーフィズムを実現。C コードに揮発性の不透明述語を、アセンブリスタブに機能的に等価な数学/NOP を注入し、コア構造体のメモリレイアウトをスクランブルすることで、ビルドごとに固有のバイナリシグネチャを生成します。 - リリースビルド: silent ティアはすべての診断文字列、ファイル記述子、追跡フレームを除去します。
SND_CRTLESSビルドはさらに/NODEFAULTLIB、SDK ヘッダなし、PEB フロントエンド、ネイティブバックエンドのみで構成されます。
クイックスタート
リポジトリには、すべてのプロファイルを実行できる単一の unified CLI が同梱されています:
build.bat pocs
build64\pocs\Release\unified.exe load pe -f payload.dll -e Run --sys
unified は load pe|coff、inject classic|apc|hijack(shell、PE、COFF)、および hg をサポートし、それぞれ --win/--nt/--sys 上で動作します。Examples & PoCs および Getting Started を参照してください。
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
わずか 2 行で、あなたのツールは SindriKit のすべての機能を継承します:PE および COFF パース、リフレクティブローディング、カスケード型システムコール、インジェクションプロファイル。
エンジン
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 │
│ snd_mapping_api_t -> open · view · close (KnownDlls bootstrap) │
│ snd_thread_api_t -> queue_apc · resume · suspend │
│ snd_file_api_t -> load │
├──────────────────┬──────────────────────┬──────────────────────────────────┤
│ 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_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);
呼び出し側は SSN 解決から分離されています — ドメインコードを変更することなく、direct、indirect、spoofed システムコールを切り替えられます。indirect 呼び出しは正規の NTDLL ガジェットへジャンプするため、戻りアドレスは ntdll.dll 内に留まります。spoofed 呼び出しはさらに、動的に発見された「Fat Frame」内に本物の呼び出し元戻りアドレスを配置するため、コールスタックのアンワインドが一貫した状態を保ちます。
コンパイル時アルゴリズム俊敏性
すべての 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 のコードを 1 行も触れることなく、コンパイル間で静的フットプリントが完全に変化します。
アーキテクチャ対応の動的 FFI
任意の実行時関数呼び出しのためのカスタム MASM アセンブリブリッジ。x64 ビルドは Microsoft x64 呼び出し規約(シャドウスペース、レジスタ引数配置、スタックアライメント)に正確に従います。x86 ビルドは引数を逆順にプッシュし、cdecl と stdcall の両方のターゲットをサポートします。
境界チェック付き PE パーサー
is_mapped フラグを備えた統合 PE32/PE32+ パーサーで、生のオンディスクイメージとメモリマップドビューの両方を正しく処理します。すべてのデータディレクトリアクセスは、逆参照の前に追跡されたバッファ境界に対して検証されます。エクスポート解決は、ハッシュベースのルックアップによる深さ 4 までのフォワーダーチェーンをサポートします。
以下に対してテスト済み:
- エッジケースの EXE、DLL、不正な引数、欠落したエクスポート、TLS コールバックを x86 と x64 にわたって対象とした 40 以上のコアテスト組み合わせ。
pe_mutatorモジュールによって生成された 100 以上の動的 PE ミューテーション:ゼロ化されたセクション名、整数オーバーフロー、無効なe_lfanew境界、破損したインポート。- 完全な Corkami コーパス:有効なサンプルをクリーンにロードし、不正なサンプルをクラッシュせずにクリーンに拒否、サンプルの 99% にわたって成功。
COFF / BOF ローダー
2 つ目のローダーテクニックは、未リンクの COFF オブジェクトファイル(Beacon Object Files)を処理します:ヘッダ、セクション、シンボル、リロケーションの境界付きパース、注入された mod_api を介した MODULE$Function 外部シンボル解決、範囲外呼び出しのための x64 JMP [RIP+0] トランポリン、および名前付きエントリポイント(デフォルト go)の実行 — ローカルまたはリモートプロセスへのマーシャリング。
状態追跡されたドメインコンテキスト
すべての攻撃的操作は、ステージ列挙を備えた個別のコンテキスト構造体を通じて管理されます。操作はスリープ難読化や段階的デプロイのためにステージ間で一時停止でき、クリーンに再開でき、サブシステムと理由に至るまで正確な失敗ポイントを検査できます。
API 設計哲学
システムコールパイプラインを一度ブートストラップします(典型的なパターン):