ハッカーのメモリをフラクタル構造で膨張させ、自壊させる能動型セキュリティエンジンを開発中です。
(zenodo.org)一般的なセキュリティエンジンは侵入遮断と隔離に重点を置きますが、私はハッカーが攻撃を試みた瞬間、その攻撃ロジックを逆利用して自ら計算資源を枯渇させ、自滅させる――タールピット方式の非対称防御体系を考える中で、このプロジェクトを始めました。
C++コアエンジンをベースに、ハッカーの攻撃プロセスを誘導・追跡し、最終的に OOM (Out of Memory) を誘発する能動型セキュリティエンジン「フィジカル・ゴースト」の初期骨格を固めました。
中核概念およびアプリケーションのアドレスは https://zenodo.org/records/19988807 です。
数学的証明および公理系は https://zenodo.org/records/20113591 に整理してあります。（二項係数の p 進法符号化とクンマーの定理を活用した情報深度解析です）
アーキテクチャ構成は次のようになります。
絶対的隔離: おとりポート（ハニーポット）への接続が検知された瞬間、エンジンは最小権限のゴーストアカウントとして自らを隔離し、本システムへの拡散を根本的に遮断します。
ファントムトラッキング: ネットワークフィンガープリントを非同期で抽出し、エンジンの性能低下なしに即座に外部（Telegram/Discord）へ攻撃者の情報を送信します。
中核機能（コンピュータ融解）: ハッカーが解析・復号のためにおとりデータへデバッガをアタッチした瞬間、p 進キャリー動力学（p-adic Carry Dynamics）ベースのシェルピンスキー四面体構造が発動します。敵のメモリ内でデータが再帰的に膨張し、最終的に CPU/RAM 資源を枯渇させます。
自己消滅: コアエンジンの完全性が 0.1 バイトでも歪められると、自らプロセスを終了（Self-Destruct）し、エンジンがトロイの木馬へ変質する状況を防ぎます。
現在の状況: 現在、中核防御ロジックの骨格とライセンス認証モジュールを実装し、GitHub を整備中です。フラクタルメモリ膨張ロジックに対する数学的クロス検証と C++ コアへのポーティングを並行して進めています。
既存の定型化されたセキュリティパターンを超え、攻撃者の攻撃意図と計算資源を逆利用する方式に関心のある方々の鋭いフィードバックを伺いたいです。特に p 進位相構造を利用した計算複雑性制御についてご意見をいただければ、エンジン高度化に大いに役立つと思います。ありがとうございます。
34件のコメント
これらは本当に意味のある技術用語なのでしょうか?? 不必要に衒学的な表現が多いように思います。
少し前に上がっていた Show GN: データのベクトル構造を数学的に崩壊させて永久削除するVANIを開発しました と同じような感じがして、やや否定的に見えますね…
自分もまさにこれを思い出してその記事の GitHub を見に行ったら、
not foundエンドでしたね/ご意見ありがとうございます！
正直、私もAIに助けてもらいながら研究を進めたので、AIに頼ってボタンを押しただけのように感じられるかもしれません……
ひとまずC++へのポーティング作業を進めているところなので、完了したらもう一度持ってきます
ご意見ありがとうございます！
タールピット方式をネットワーク層からメモリやアプリケーション段階へ引き上げようと試みたものです。
シェルピンスキー四面体やフラクタル構造は、これといって説明する言葉がなく、ホワイトペーパーに載せた表現をそのまま使うしかありませんでした。申し訳ありません。だからといって、無限ループやガベージデータを大量投入すると書くのも違うので……
上のホワイトペーパーのうち、数学的証明および公理系のホワイトペーパーをご覧いただければ、これが超距離木の形状のため、特定の閾値を超えるたびに構造が再帰的に拡張されることはあります……。ただ、ハッカーのリバースエンジニアリングツールがデータの深さを掘り下げる際、シェルピンスキー四面体のように自己相似性を持って拡張するメモリボムアルゴリズムを指すための表現だとご理解いただければ幸いです。
種類を問わず、どんなリバースエンジニアリングツールでもデバッグを試みると、自律的に動作するもう1つの実行体だとおっしゃっているのでしょうか？ リバースエンジニアリングしてみれば、決められた形式のファイルヘッダー情報でなければ、そもそもおっしゃるような動作は不可能なのですが……
ご意見ありがとうございます。
実は思いもつきませんでした。本当に良い情報をありがとうございます。
AIに聞いてみたところ、このように答えてくれました。
"フィジカルゴースト SWエディションのアンチリバースエンジニアリング（Anti-Reversing）の核心は、『ローダーがメモリにコードを載せた後の展開方式』にあります。既存のプログラムはデバッガ（IDA、Ghidra など）で解析すると線形的なアセンブリ命令の流れが見えますが、提案するアーキテクチャでは実行フローそのものが『キャリーピラミッド（多次元フラクタル位相）』構造として絡み合っています。"
"リバースエンジニアリングツールがメモリをダンプしたり、ブレークポイントを設定してトレース（Single-stepping）を試みると、この構造的演算の流れ（p-adic キャリー動力学）が途切れます。つまり、外部から無理やり構造を解き明かそうとする『観測行為』そのものがシェルピンスキー四面体のような位相的亀裂を引き起こし、元のデータやコードが無意味なノイズへ崩壊するよう設計された、内在的な難読化および防御メカニズムです。"
おかげで一つ勉強になりました。ありがとうございます！
つまり、そのセキュリティエンジンでエンコードされたデータは、観測を試みるだけで自動的に実行されて自己崩壊したり、あるいはハッカーのリソースを消耗させたりするということですか？ だから、それは不可能だと申し上げているのですが……
お返事が遅くなり申し訳ありません！(__)
観測を、単に停止している静的データを目で見る行為だと考えると、不可能に見えるのはそのとおりです。しかし、デジタル世界における観測は、必ず対象システムに刺激を与える相互作用を伴います。
このセキュリティエンジンは静的ファイルではなく、攻撃者が観測を試みる行為、あるいはリクエストそのものを入力値-Trigger-として、リアルタイムで動作する動的アーキテクチャです。観測を試みた瞬間に内部ループが実行され、データの論理的連続性を無効化し、観測を完了するために待機する攻撃者のセッションを強制的にホールドしてリソースを消費させるメカニズムです。
そして、正規の権限を持つユーザーのアクセス-ハンドシェイク完了セッション-は、認証メカニズムによってタープットフィルターを通過することなく、そのまま通されます。観測時に自己崩壊およびリソース消費が発生する領域は、あくまで不正な偵察および許可されていないスキャン要求をふるい分けるために配置された仮想化デコイデータ-Decoy-空間のみです。正常なサービスリソースには1%たりとも影響を与えず、攻撃者のセッションだけを隔離して沼に閉じ込める、精密な動的防御アーキテクチャです
それがどのような仕組みで可能なのかを理解したうえで回答されているのでしょうか？ 上では「暗号化されたデータを観測するとき」とおっしゃっていましたが、回答ではセキュリティエンジンがそれを検知して動作するとされていましたよね？ ですが、ハッカーが復号を、そのセキュリティエンジンが動作しているはずのリモートサーバー上で実行するのでしょうか？ データを外部に流出させた後、隔離環境で復号を試みるはずですが、この環境ではおっしゃるセキュリティエンジンはメモリにロードされていない状態なのに、観測をトリガーとして動作できるのでしょうか？ それとも、あらゆる暗号化を行うデータに、実行可能な形のセキュリティエンジンをあらかじめ一緒に入れておく、という意味なのでしょうか？
自分でも何を言っているのか分かりません、文脈がゼロですね。すみません..
こういう文章に真面目にコメントする行為自体が、コミュニティに悪影響を与えるのではないかと…。
数学的なアプローチは新鮮ですが、現代のコンピュータアーキテクチャではほとんど不可能だと見ざるを得ませんね
Openclaw系を使って「作った」code slop感がかなり強いですね。
ご意見ありがとうございます！
はぁ lol
デジタル・フォートレスっぽいですね。
ただ、技術的には理解できません。
文章が支離滅裂に見えるのは気のせいでしょうか
ご意見ありがとうございます。文章をもう少し整えてみます！
整合性が壊れたら、どうやって検知するんですか..
ご意見ありがとうございます
従来の完全性検証は、データのハッシュ値を1対1で照合する平面的な方式であるのに対し、フィジカルゴーストはデータを3次元のシェルピンスキー四面体にマッピングして演算します。したがって、構造的安定性によって判断するのです。
AIの回答では、「システム内でデータがたとえ1ビットでも改ざんされると、p-adicキャリー動力学によってその微細な誤差が3次元構造全体へ連鎖的に増幅されます。攻撃者がデータを改ざんした瞬間、データが形作っている『数学的建築物（位相）』そのものがずれて崩壊するため、この位相の亀裂を通じて完全性の毀損を即座に検知できます。」とのことです
私もそれなりにPE構造のパース、REジン、Ghidra、ドライバー開発くらいはやってみましたが、理解できませんね
ご意見ありがとうございます。
これは既存システムのフックのようなものとは異なり、アルゴリズム自体が難読化や暗号化によって構成されているからだと思います。
正直、自信がありません……申し訳ありません。
興味深いアプローチだと思い、いくつか気になる点があるので質問させてください。
メモリ膨張のトリガーは「攻撃者が実際にペイロードを実行／デバッグする」ことを前提にしているように見えますが、静的解析中心でアプローチされたり、cgroups、Firejail、gVisor のようなリソース制限付きサンドボックス内で動かされたりした場合、OOM はホストではなくサンドボックス内でのみ発生するはずです。このケースはどのように扱うのか気になります。
アンチデバッグのトリガーも ptrace ベースの検知だとすると、ハードウェアブレークポイントやハイパーバイザーレベルのデバッグの前では痕跡が残らないはずですが、こうしたレイヤーで解析されるシナリオに対する対応は別途設計されていますか。
「0.1バイトでも歪められたら自己消滅」とおっしゃっていましたが、整合性チェックルーチン自体をパッチしたり、メモリダンプ後にオフライン解析したりして迂回する経路はどのように防いでいるのか気になります！
能動的に攻撃者のリソースを枯渇させる挙動は、実質的に hack-back に該当し得るようにも見えますが、情報通信網法上の積極的防御の法的境界はどのように整理されていますか。特に、攻撃トラフィックがボットネット経由であれば、実際の被害者が別にいる可能性もあるので。
C++ コアエンジン自体がデコイポートパーサー、フィンガープリント抽出器、外部送信チャネルまで担っていて、攻撃面がかなり広そうに見えますが、エンジン自身のメモリ安全性はどのような方法で検証していますか。Webhook トークンのような秘密情報がバイナリに入るはずですが、その点も気になります。
数学的モデリング自体は興味深く拝見しました。上記の点がどのように解決されているのか分かると、コンセプトを理解する助けになると思います。ありがとうございます。
ご意見ありがとうございます！
1つ目のメモリ膨張トリガーの第一の目的は、攻撃者のホスト物理機器を破壊することではなく、分析に必要な計算資源の閾値を強制的に超えさせることです。cgroups や gVisor のようなサンドボックス内で OOM によりプロセスが落ちるのであれば、それ自体が成功した防御ではないでしょうか。p-adic 演算の無限キャリー拡張を通じて、分析ツールにデータを解釈する時間的・空間的余裕を与えず、分析環境そのものを自発的に停止させることが目的です。
2つ目として、システムコールやデバッグ API は監視していません。代わりに、多次元フラクタル位相やシェルピンスキー四面体構造内でデータが演算される時間的一貫性と、キャリー動力学の連続性だけを見ています。ハイパーバイザーでブレークポイントを置いて停止すると、演算のタイミングウィンドウがずれ、その後の位相演算がゴミ値へ崩壊するように数学的に Entangled されています。
3つ目は、非常に重要なポイントをご指摘いただきましたが、このシステムには攻撃者が NOP 化できる独立した整合性チェック関数（if 回避）そのものが存在しません。整合性検証ロジックは、コアロジックおよび位相幾何学と結合したホワイトボックス（White-box）暗号に近い形です。
また、メモリダンプを取得してオフライン分析を行っても、ダンプされたデータは継続的に変異する3次元位相構造のある時点における 2D 断面にすぎません。全体の動的ルール、つまりキャリーピラミッドモデルを知らなければ、ダンプデータだけから元のペイロードを逆算することは不可能だと思います。（少なくとも数学的には……）
4つ目は、私自身も悩んでいたポイントです。おっしゃるような積極的防御は、外部の C&C サーバーなどに向けて逆攻撃を仕掛ける場合、違法性が高くなり得ますが、私が提案しているシステムはあくまでインバウンドトラップに徹しています。外部へ悪性トラフィックを送るのではなく、攻撃者がバイナリを自分の環境に持ち帰って自ら実行したとき、その内部でのみ迷路のように計算資源を消耗させる構造なので、外部被害を引き起こす問題は回避できるのではないかと考えています。（希望的観測ですが）
5つ目の、C++ ベースのモノリシック構造におけるメモリ安全性リスクは、私も懸念しています。今後 Rust を導入するなどして、継続的に検証していく必要がありますね。
そして Webhook トークンのようなシークレット値は、平文や単純な難読化の形では存在しません。先ほど述べた正規の多次元位相演算が最後まで完了すると、その結果値を復号鍵として使い、一時的にメモリ上で組み立てます。分析のために構造をねじ曲げると、トークンの組み立て自体が不可能になるのです。
おかげでとても勉強になりました。ありがとうございます！
まずはご回答ありがとうございます。ただ、いくつかもう少し確認したい点があります。
（メモリ膨張）: 本文では攻撃者のリソース枯渇／自滅とおっしゃっていましたが、回答では「サンドボックス内の OOM も防御」と、ややトーンが変わったように見えます。だとすると、42.zip や billion laughs との違いは何でしょうか？ また、Ghidra/IDA の静的解析ではトリガー自体が発動しないはずですが..
アンチデバッグ: Entangled という表現が比喩なのかメカニズムなのか分かりませんが、内容自体は RDTSC タイミング検知の亜種のように聞こえます。VMProtect が 90 年代から使っていた手法ですが、あえて新しい名前が必要なのでしょうか？ そして、HyperDbg の TSC scaling 環境ではどう動作しますか？
完全性: ホワイトボックス AES は BGE attack 以降ほぼ破られている分野ですが、ホワイトペーパーにされたのであれば、それ自体が別個の論文級です。「ダンプは 3D の 2D 断面」という比喩も、WinDbg TTD や Intel PT の前では成り立たない表現です。最後の「数学的にだけ…」という一文も、回答全体を要約しているように感じました...
ご返信が遅くなり申し訳ありません(__) いつも貴重なご意見をありがとうございます
42.zip のような古典的な爆弾は、静的データの単純な膨張なので、OOM（メモリ不足）を引き起こして終わるだけです。ですが、このアーキテクチャはデータではなく、ホワイトペーパーにある通り、キャリー・ピラミッドの p 進数繰り上がり（p-adic carry）演算ループを強制する計算的な泥沼（Computational Tarpit）です。
Ghidra や IDA で静的解析をしてもトリガーが発動しないのは、その通りです。そうでなければなりません。静的バイナリの中には本物のロジックがないからです。攻撃者がランタイム（動的）環境で相互作用を始めたときに初めて、位相幾何学的な難読化がリアルタイムで展開されるため、静的解析ツールからは空っぽの外殻しか見えないのです。
RDTSC を利用した単純なタイミング検出が、すでに古い手法であるのはその通りです。HyperDbg の TSC Scaling で時間をごまかせば、当然回避できるでしょう。
ですが、私がホワイトペーパーで述べたエンタングルメント（Entangled）は時間チェックではありません。ランタイムで進行する数学的な位相変化（11 の n 乗へと伸びていくキャリー構造）の演算位相（Phase）そのものが、実行環境の負荷と数学的に結合する構造です。HyperDbg で環境を偽装し、演算タイミングを人為的にねじ曲げたらどうなるか。防御エンジンが「あ、デバッガだ」と判断して弾くのではなく、キャリー・ピラミッドの位相展開の公式そのものが見当違いの次元へ伸びていき、結果として完全に無意味なゴミデータを自ら復号してしまいます。ごまかした瞬間に、自分で罠にはまるわけです。
ホワイトボックス AES は固定された数学的暗号鍵を隠す方式なので、BGE 攻撃に脆弱です。これは事実です。ですが、このアーキテクチャは固定鍵を隠すのではなく、アクセスされるたびに位相が変わる動的ランタイム・トポロジーを使います。
WinDbg TTD や Intel PT で CPU のすべての命令フローを 100% 録画し、タイムマシンのように巻き戻して見たと仮定しても、その録画された経路自体が、すでに攻撃者の観測行為によって崩壊し歪められて生成されたゴミの泥沼（タールピット）をさまよう軌跡にすぎません。迷路の中で道に迷ってさまよった足跡を、どれだけ精密に 100% 録画しても、迷路の出口を見つける助けにはまったくならないのと同じです。
従来のパラダイムとはかなり違うので、申し訳ありません..
詳しいご説明ありがとうございます。既存のパラダイムに慣れすぎていて、私にはうまくついていけていないようです。PoCが公開されたら、ぜひまた見に来ます。応援しています :)
どれほど天才ハッカーなのか、まったく想像もつかない
ご意見ありがとうございます！
天才でもハッカーでもなく、ただ数学をやっている人です..
自己消滅: コアエンジンの完全性が0.1バイトでも歪められると、自らプロセスを終了(Self-Destruct)して、エンジンがトロイの木馬に変質する状況を防ぎます。
コンピュータに0.1バイトなんてあるんですか？
1バイトは8ビットなので、0.1バイトは0.8ビットですよね。1ビット未満の情報があるという話は初めて聞きました
私もそう思いました
ご意見ありがとうございます！
私が、その、コアエンジンの極度の敏感さを強調しようとしていたのですが、申し訳ありません！
表現を修正いたします！ 0.1バイトなんてあり得ませんよね