krixx1337/burner-net
ゼロトラストのアンチフォレンジックHTTPクライアント。機密情報を消去。痕跡を断つ。ステルスタンクの中のCPR。👻
# BurnerNet
**ゼロトラスト、アンチフォレンジックHTTPクライアント。秘密を消去し、痕跡を断つ。ステルスタンクのCPR。👻**
BurnerNetはC++20の**アンチフォレンジックHTTPクライアント**です。ローカルマシンを完全には信頼できないアプリケーション向けに、流暢なCPRライクなAPIを提供します。RAMから秘密を物理的に消去し、実行痕跡を断ち切ることで、スキャナやデバッガからロジックを隠します。
通常のHTTP向けには慣れたホスト互換のデフォルトを、敵対的な環境向けには明示的なHardenedプロファイルを提供します。どちらのパスも短命なクライアントを推奨し、高度な信頼はアプリケーションが所有します。
BurnerNetでダウンロードしたペイロードを保護したい場合は、[RipStop Codec](https://github.com/Krixx1337/ripstop-codec) をチェックしてください。インメモリアセットのスクランブル解除に役立ちます。
[Principles](https://github.com/krixx1337/burner-net/blob/main/PRINCIPLES.md) • [Getting Started](#getting-started) • [Integration Paths](#integration-paths) • [Security Reality](#security-reality--the-white-box-defense)
## 概要
| 領域 | BurnerNet |
| :--- | :--- |
| **言語** | C++20 |
| **プラットフォーム** | Windows x64/x86（**第一級**）、Linux（確認済み） |
| **トランスポート** | `libcurl`ベースのHTTP(S) |
| **メモリ衛生** | 安全な消去ユーティリティと消去アロケータ |
| **フォレンジック衛生** | BurnerNet管理のトランスポート状態全体での自動ヒープ/スタックスクラビング |
| **動的解析** | コールスタック分離により、コンシューマとトランスポートの間のリンクを断つことができます |
| **ビルド強化** | 診断文字列削除（オプション）、難読化リテラル、強化ビルドでのC++ランタイムメタデータ削減 |
| **ランタイム強化** | DoHサポート、プロバイダベースのシークレット、より厳格な信頼制御 |
| **統合** | CMakeまたはVisual Studioソースドロップ |
## なぜ使うのか
通常のHTTPクライアントが環境に対して信頼しすぎている場合にBurnerNetを使用します。
次の場合に役立ちます：
- リクエストクライアントを共有のグローバルトランスポートではなく短命にしたい
- ローカルDNSやその他のホストデフォルトへの依存を減らしたい
- トークン、証明書、検証シークレットを必要なときだけ取得したい
- レスポンス検証ロジックをアプリケーションコード内に保持したい
- 強化ビルドで平文の文字列やメタデータを減らしたい
## 誰のためのものか
BurnerNetは次のようなプロジェクトに適しています：
- 高価値の認証、ライセンス、またはアップデートリクエストを行うWindowsデスクトップアプリ
- 完全には信頼できないホストで動作する組み込みコードまたはインジェクションコード
- 流暢なC++ APIを諦めずに、より厳格なトランスポートチェックを必要とするツール
## 標準スタック vs BurnerNet
| 項目 | 典型的なHTTPスタック | BurnerNet |
| :--- | :--- | :--- |
| **クライアントの寿命** | 共有され、長寿命であることが多い | 使い捨てクライアントとバーストスコープでの使用向けに設計 |
| **機密値** | 秘密が設定やメモリに必要以上に留まることが多い | プロバイダコールバックが使用直前に秘密を取得 |
| **DNSと信頼** | 通常、ローカルリゾルバとホストデフォルトを継承 | DoHフォールバックやピン留めキーを含む、より厳格な信頼制御をサポート |
| **検証** | アプリ固有の整合性チェックは後付けされることが多い | プリフライト、トランスポート、レスポンス検証フックと連携するよう設計 |
## 防御的成果
- **Zero-Ghost Memory Architecture（ゼロゴーストメモリアーキテクチャ）**: BurnerNetはカスタムの**Prefix-Size Scrubber**を使用して、`libcurl`およびOpenSSLバックエンドのフローの内部メモリ割り当てパスをフックします。機密性の高いトランスポートバッファは、BurnerNet管理のライフタイムを離れる際に消去されます。**この衛生状態は、ドキュメントに記載された監査済み構成において、WindowsとLinuxの両方で検証されています。**
- **Stack-Frame Swiping（スタックフレームスワイピング）**: リクエストごとに、ライブラリは自身のスレッドスタックを積極的にスクラブします（ハイウォーターマークスクラビング）。これにより、アプリケーションに制御が戻る前に、一時的なトランスポート断片が破壊されることを意図しています。
- **Moving-Target Heap（移動標的ヒープ）**: 使い捨てトランスポートとアラインメントされたメタデータヘッダの組み合わせにより、高いアドレス空間分散が生まれ、プロセスメモリが予測不可能になり、安定したポインタマッピングに対して耐性が生まれます。
- **短命なリクエスト状態**: BurnerNetはプロセス全体のシングルトントランスポートではなく、使い捨てクライアントを中心に設計されています。
- **ホストへの信頼を減らす**: DoHサポート、ピン留めキーサポート、トランスポート監査により、侵害されたローカルデフォルトへの依存を減らします。
- **平文露出の軽減**: プロバイダコールバックと安全な消去ユーティリティにより、証明書、キー、トークン、その他の機密バッファの寿命を短縮します。
- **アプリ所有の検証**: レスポンス検証は、共有ライブラリにハードコードされる代わりに、`WithResponseVerifier(...)` を介してコード内に残ります。
- **静的フィンガープリントの困難化**: 強化ビルドでは `BURNERNET_DIAGNOSTIC_STRINGS=0` を設定できるため、`ErrorCodeToString(...)` はシンボリックなエラー名を埋め込まずに安定した `E<番号>` 値を返します。
- **インポート軽量なデプロイオプション**: `BURNERNET_HARDEN_IMPORTS=1` により、Windows上のBurnerNetの `KernelResolver` パスを使用して、インポートテーブルに直接公開する代わりに、ランタイム依存関係を動的に解決できます。
- **Call Stack Isolation（コールスタック分離）（Async Handoff）**: `.WithStackIsolation(true)` で有効にすると、ライブラリはトランスポートライフサイクルをデタッチされたワーカースレッドで実行します。これにより、呼び出し元のコールスタックを物理的に切断し、アプリケーションロジックの直接的なトップダウントレースを減らすことができます。
## 検証済みステルス
BurnerNetは、インポート軽量な強化モードを主張するだけでなく、特定のテスト構成に関する監査ノートも同梱しています。Windows x64 Releaseで `BURNERNET_HARDEN_IMPORTS=ON` の監査において：
- **IAT Blackout（IATブラックアウト）**: 監査対象バイナリでは、`libcurl.dll`、`ws2_32.dll`、`bcrypt.dll`、`crypt32.dll` のエントリは観測されませんでした。
- **Memory Dark-out（メモリダークアウト）**: フォレンジックスキャン（Cheat Engineの「すべての文字列」）では、機密性の高いカナリアURLやヘッダがプロセスヒープやスタックで発見されませんでした。
- **Debugger Blindness（デバッガブラインドネス）**: 統合テストでは、ライブラリが「アイデンティティシフト」をトリガーすることを確認しています。意思決定者（アプリ）とトランスポーター（BurnerNet）は異なるスレッドIDで動作し、ライブデバッグセッション中のトップダウントレースを低減します。
- **Noise-to-Signal（ノイズ対シグナル）**: ライブラリは、その消去権限内でのフォレンジック衛生を目指していますが、OSやランタイム環境に残るシステムレベルの「影」を認めています。
監査の詳細と方法論：
- [docs/BINARY_STEALTH_AUDIT.md](https://github.com/krixx1337/burner-net/blob/main/docs/BINARY_STEALTH_AUDIT.md)
## はじめに
最速のパス：
- CMakeまたはVisual StudioソースドロップでBurnerNetをビルドに追加します。
- `<burner/net.h>` をインクルードします。
- スタッククライアントを作成し、リクエストを送信し、スコープ外にします。
最小限の例：
```cpp
#include <iostream>
#include <burner/net.h>
int main() {
burner::net::Client client;
if (!client.IsReady()) {
std::cerr << burner::net::ErrorCodeToString(client.InitError()) << '\n';
return 1;
}
const auto response = client
.Get("https://example.com")
.WithHeader("Accept", "text/html")
.WithTimeoutSeconds(10)
.Send();
if (!response.TransportOk()) {
std::cerr << burner::net::ErrorCodeToString(response.transport_error) << '\n';
return 1;
}
std::cout << "HTTP " << response.status_code << '\n';
return 0;
}
```
`Client` はStandardデフォルトを使用します：システムCA、DNS、プロキシ、TLSピアおよびホスト名検証が有効です。`WithCasualDefaults()` はStandard互換性エイリアスとして引き続き利用可能です。
セキュリティ重視のトラフィックには、Hardenedプロファイルを使用します。`Build()` はリクエスト前に不足している制御を拒否します：
```cpp
auto secure = burner::net::ClientBuilder(burner::net::ClientProfile::Hardened)
.WithMtlsProvider(ProvideMtlsCredentials)
.WithSecurityPolicy(AppSecurityPolicy{})
.WithDnsFallback(burner::net::DnsMode::Doh,
"https://resolver.example/dns-query",
"Primary DoH")
.AllowSystemDns(true) // explicit fallback, after DoH
.WithResponseVerifier(VerifySignedResponse)
.Build();
```
Hardenedでは、ピアおよびホスト名検証、スタック分離、DoHファーストルーティング、アプリレスポンス検証、アプリ所有のトラストマウントが必要です。永続的な `WithMtls(...)` 資格情報は拒否されます。`WithMtlsProvider(...)` を使用してください。
## 統合パス
### 1. 標準CMake
下流のプロジェクトが既にCMakeを使用していて、最もクリーンな依存関係管理パスを希望する場合に使用します。
ドキュメント：
- [docs/CMAKE_INTEGRATION.md](https://github.com/krixx1337/burner-net/blob/main/docs/CMAKE_INTEGRATION.md)
- [examples/cmake-consumer/README.md](https://github.com/krixx1337/burner-net/blob/main/examples/cmake-consumer/README.md)
### 2. Visual Studioソースドロップ
環境がMSBuildファーストであるか、BurnerNetを `.vcxproj` 内で直接コンパイルしたい場合に使用します。
ドキュメント：
- [docs/VISUAL_STUDIO_INTEGRATION.md](https://github.com/krixx1337/burner-net/blob/main/docs/VISUAL_STUDIO_INTEGRATION.md)
- [examples/vs-consumer/README.md](https://github.com/krixx1337/burner-net/blob/main/examples/vs-consumer/README.md)
### 3. 強化ランタイムインポート
ランタイム依存関係の露出を減らし、ブートストラップローディングを明示的に管理する準備ができている場合に使用します。
有効化：
- `BURNERNET_HARDEN_IMPORTS=1`
- Windows上のBurnerNetの `KernelResolver` パスを使用して、よりインポート軽量なランタイムフットプリントをサポート
参考：
- [docs/USAGE_BEST_PRACTICES.md](https://github.com/krixx1337/burner-net/blob/main/docs/USAGE_BEST_PRACTICES.md)
- [docs/CMAKE_INTEGRATION.md](https://github.com/krixx1337/burner-net/blob/main/docs/CMAKE_INTEGRATION.md)
- [docs/VISUAL_STUDIO_INTEGRATION.md](https://github.com/krixx1337/burner-net/blob/main/docs/VISUAL_STUDIO_INTEGRATION.md)
> **Linuxサポート：** BurnerNetはLinux上で完全なフォレンジックパリティ（メモリ消去とスタック分離）を提供します。ビルド手順については [docs/LINUX_USAGE.md](https://github.com/krixx1337/burner-net/blob/main/docs/LINUX_USAGE.md) を参照してください。
## 使用上の注意
推奨されるデフォルト：
- クライアントを使い捨てトランスポートとして扱う
- 高信頼トラフィックと低信頼トラフィックを異なるクライアントに分離する
- mTLS素材、ベアラトークン、レスポンス検証シークレットにはプロバイダコールバックを使用する
- ビジネスルールとトラストアンカーはアプリケーションに保持する
## 例とドキュメント
例：
- [examples/01_basic_usage.cpp](https://github.com/krixx1337/burner-net/blob/main/examples/01_basic_usage.cpp)
- [examples/02_zero_trust_pipeline.cpp](https://github.com/krixx1337/burner-net/blob/main/examples/02_zero_trust_pipeline.cpp)
- [examples/03_custom_security_policy.cpp](https://github.com/krixx1337/burner-net/blob/main/examples/03_custom_security_policy.cpp)
- [examples/04_bootstrap_runtime.cpp](https://github.com/krixx1337/burner-net/blob/main/examples/04_bootstrap_runtime.cpp)
- [examples/05_mtls_usage.cpp](https://github.com/krixx1337/burner-net/blob/main/examples/05_mtls_usage.cpp)
- [examples/06_hmac_custom_verifier.cpp](https://github.com/krixx1337/burner-net/blob/main/examples/06_hmac_custom_verifier.cpp)
ドキュメント：
- [PRINCIPLES.md](https://github.com/krixx1337/burner-net/blob/main/PRINCIPLES.md)
- [docs/USAGE_BEST_PRACTICES.md](https://github.com/krixx1337/burner-net/blob/main/docs/USAGE_BEST_PRACTICES.md)
- [docs/CMAKE_INTEGRATION.md](https://github.com/krixx1337/burner-net/blob/main/docs/CMAKE_INTEGRATION.md)
- [docs/VISUAL_STUDIO_INTEGRATION.md](https://github.com/krixx1337/burner-net/blob/main/docs/VISUAL_STUDIO_INTEGRATION.md)
- [docs/LINUX_USAGE.md](https://github.com/krixx1337/burner-net/blob/main/docs/LINUX_USAGE.md)
## 要件
- C++20
- Windows x64/x86 または Linux（GCC 13+ / Clang 15+）
- `libcurl` 7.87.0+ および `OpenSSL` ヘッダ
- **Linuxガイド：** [docs/LINUX_USAGE.md](https://github.com/krixx1337/burner-net/blob/main/docs/LINUX_USAGE.md) を参照
## セキュリティの現実とホワイトボックス防御
BurnerNetは、攻撃コストをプロフェッショナルレベルに引き上げるために設計された強化レイヤーです。私たちは、**ステルスは表面的なものではなく、アーキテクチャに基づくべきである**という原則に基づいています。
**攻撃者がソースコードを持っていれば、BurnerNetを迂回できるのでしょうか？**
BurnerNetのソースコードを知っていることは、それだけで全てのダウンストリームアプリケーションへのマスターキーにはなりません。BurnerNetはKerckhoffsの原理に従っています。ライブラリは、アプリ固有のトラストアンカー（HMACシークレット、ピン留めキー、UIロジック、ポリシーフック）がアプリケーションによって所有されたままになるように設計されています。トランスポート層を知っていても、特定のセキュリティフローを自動的に普遍的に迂回できるわけではありません。
- **ステルスは遅延として：** 強化により、攻撃者は標準的な便利なツールから離れ、面倒な命令レベルの分析へと追いやられます。
- **データをルートとして：** **Functional Dependency（関数依存性）**（原則6）を使用して、サーバー提供のデータなしではアプリが文字通り壊れるようにします。
- **ゴーストの利点：** 攻撃者がリクエストロジックを見つける頃には、**スタック分離**と**メモリ消去**が、彼らが必要とするフォレンジック証拠をすでに破壊しています。