SindriKit

攻撃的開発には、より優れたアーキテクチャがふさわしい。
攻撃能力を構築するための C ライブラリ。

中核コンセプト

ほとんどの攻撃用ユーティリティは、実行メカニズムをテクニックのロジック内にハードコードしています。リフレクティブローダーは単にイメージをマッピングするのではなく、特定のハードコードされた VirtualAlloc やネイティブ NTAPI 呼び出しの連鎖を使ってマッピングします。EDR がその特定の連鎖を監視し始めると、ツール全体を書き直さざるを得なくなります。

SindriKit は、インターフェース抽象化テーブルを介して関心の分離を強制することで、この問題を解決します：

テクニックロジック:（例：ローダー、インジェクション、パッチャー）は、状態追跡とデータオーケストレーションを扱います。メモリがどのように割り当てられ、スレッドがどのように作成されるかを知りません。
実行メカニズム:（例：Win32 API、ネイティブ NTAPI、ダイレクトシステムコール）は独立した API テーブル内にあり、実行時にテクニックに注入されます。

実行メカニズムを実行時の関数ポインタに移行することで、ペイロード実行ロジックを変更することなく、わずか 1 行のコードで戦略全体を Win32 呼び出しから生のダイレクトシステムコールに切り替えることができます。

設計アーキテクチャ

分離された実行プロファイル: 呼び出し側のテクニックを壊すことなく、関数ポインタテーブルを介して基盤となるメモリ、モジュール、スレッド操作の動作を交換できます。
カスケード型システムコールフォールバック: 優先順位チェーンを持つプラグ可能な SSN リゾルバ（snd_syscall_resolve_ssn_scan、snd_syscall_resolve_ssn_sort）— ドメインコードに触れることなく戦略を交換または拡張できます。
コンパイル時難読化: 文字列および API ハッシュアルゴリズム（DJB2、FNV1A）は CMake を介してグローバルに交換できます。コンパイル時にグローバルシードが自動的にランダム化され、静的シグネチャが変化します。
ミューテーションエンジン: SND_MORPH を介して深いポリモーフィズムを実現します。C コードに揮発性の不透明述語を、アセンブリスタブに機能的に等価な数学/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

わずか 2 行で、あなたのツールは SindriKit のすべての機能を継承します：PE パース、システムコール解決、リフレクティブローディング...

エンジン

API 抽象化レイヤー

        ┌────────────────────────────────────────────────────────────────────────────┐
        │                          あらゆる攻撃的意図                                │
        │    Loader · Injector · Spoofer · Patcher · Bypasser · Harvester · ...      │
        ├────────────────────────────────────────────────────────────────────────────┤
        │                     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 Walk + EAT      │  オペレータ定義関数              │
        └──────────────────┴──────────────────────┴──────────────────────────────────┘

実際には、これはすべてのドメインが同じ契約に従うことを意味します：

// 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);

インボーカーは SSN 解決から分離されています — ドメインコードを変更することなく、ダイレクトシステムコールと間接システムコールを切り替えることができます。間接呼び出しは正規の NTDLL ガジェットにジャンプし、システムコールの戻りアドレスを 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

任意の実行時関数呼び出しのためのカスタム MASM アセンブリブリッジ。x64 ビルドは Microsoft x64 呼び出し規約に正確に従います（シャドウスペース、レジスタ引数の配置、スタックアライメント）。x86 ビルドは引数を逆順にプッシュし、cdecl と stdcall の両方のターゲットをサポートします。

境界チェック付き PE パーサー

is_mapped フラグを持つ統合 PE32/PE32+ パーサーで、生のオンディスクイメージとメモリマップドビューの両方を正しく処理します。すべてのデータディレクトリアクセスは、逆参照する前に追跡されたバッファ境界に対して検証されます。エクスポート解決は、ハッシュベースのルックアップによる深さ 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_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);

1 つの代入で実行プロファイルを交換します：

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 を使用します。

ビルドティア

デバッグティア — `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 は 2 つの整数に縮小されます。それだけです。

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 パイプライン
インジェクション — クラシックシェルコードおよび PE インジェクション
パーサー — PE および env（PEB）サブドメイン
共通 — CRT フリーのヘルパー、バッファ、ハッシュ、ステータス
例と PoC — unified 実行可能プロファイル（load、inject、hg）
テスト — 統合ランナー、PE ミューテーター

予定: 回避ドメイン。

免責事項

SindriKit は、教育、研究、および許可されたレッドチーミングの目的のみのために構築されています。 完全な法的免責事項および OpSec に関する考慮事項については、セキュリティポリシーを参照してください。

ライセンス

MIT

SindriKit v2.0.0

カテゴリ