理解のコスト：LLM主導のリバースエンジニアリング vs. 反復的なLLM難読化

はじめに

ここ数年、LLM（論理ラボマシン）の生産性や、プログラム合成、マルウェア研究、脆弱性研究といった現実世界の問題に対処する様々なタスクを実行する能力において、著しい進化が見られました。特にリバースエンジニアリングの分野において、LLMは適切なツールさえあれば、シンボル情報がなくてもソースコードを読み取る能力に非常に優れているため、特に効果的である。それだけでなく、彼らはその知識のおかげで、リバースエンジニアリングの手法を模倣し、応用することができる。

プログラムの難読化手法は、プログラムに変換を適用するのに必要な時間と、それをリバースエンジニアリングするのに必要な時間の間に大きな非対称性を生み出し、リバースエンジニアリングに対する比較的効果的な防御策となるだけでなく、研究者に時間を浪費させ、新しい手法を開発するよう圧力をかける。LLMの登場は状況を大きく変えました。モデルは（適用される変換にもよりますが）妥当な時間内にこれらの難読化を解読できるようになり、攻撃者に有利な非対称性を逆転させたからです。

しかしながら、このいたちごっこにおいて、難読化ツールの製造業者が新しい技術で適応し、基準を引き上げるのも時間の問題であると我々は考えている。ちょうど、リバースエンジニアリングがかつてないほど容易になったこの新たな現実に対応するため、ソフトウェア開発者が知的財産を保護するためにこれらの変革を体系的に適用しているのと同じように。

Elastic社は年に2回、ON Week期間中にエンジニアが1週間の研究プロジェクトに取り組む機会を提供しています。この4月の 2026 セッションでは、この記事に触発されて、LLM、特にClaude Opus 4.6を対象とした難読化技術をvibecodeで実装することがいかに安価で容易であるかを調査しました。本研究では、我々が実施した初期ベンチマークについて説明します。このベンチマークでは、学術的に（しかし非常に強力な） Tigress難読化ツールを使用して、さまざまな変換の組み合わせでコンパイルされたターゲットに対してモデルをテストしました。次に、開発/テスト/改善というAI駆動型パイプラインを使用して完全にvibecodeされたモデルに対して効果的であることが判明した、さまざまな難読化技術の研究について説明します。

時間的な制約のため、静的解析による防御策に焦点を当てました。しかしながら、我々が用いたワークフローは、回避やデバッグ対策といった動的解析防御に焦点を当てたアイデアの研究にも活用でき、LLM駆動型解析のコストと信頼性を大幅に向上させることができると確信している。

重要なポイント

• LLM（法学修士）はソフトウェア業界を急速に変革し、リバースエンジニアリングなどの複雑なトピックへのアクセスを容易にし、さまざまなレベルの難読化を突破する能力も提供している。
• 高度な難読化は計算コストと時間を劇的に増加させ、自動分析パイプラインを阻害する。
• 効果的なLLM標的型静的解析対策は、安価かつ迅速に開発できる。
• LLMの学位審査で成功するには、文脈の窓、予算の上限、近道バイアスを活用する必要がある。

Claude Opus 4.6 vs Tigress Obfuscator ベンチマーク

私たちは、学術的な難読化ツールで あるTigress で難読化された crackme を静的に解決する能力をベンチマークするためにClaudeを使用しました。

ベンチマークパイプライン

これらのテストを実施するために、コントローラー/ワーカー構成を使用しました。この構成では、1つのOpusインスタンスがサブインスタンスを管理し、サブインスタンスの進捗状況を監視し、結果を収集し、進捗状況が良好で潜在能力があると判断した場合は、インスタンスにより多くの時間を割り当てることができます。逆に、モデルがタスクに行き詰まっている、堂々巡りをしている、あるいは力任せに問題を解決しようとしていると判断した場合、インスタンスを強制終了することもあります。

各ワーカーサブインスタンスは、IDA Proがインストールされ、IDA MCPプラグインを介してアクセスできるWindows仮想マシンにアクセスできます。また、スクリプトの開発や起動のために、実行中のLinux仮想マシンのリソースにもアクセスできます。

さらに、Claudeと互換性のあるCavemanプラグインを使用しており、起動時に適切な指示を与えることで、LLMの不要な音声出力を最大75%削減できます。これにより作業速度が向上し、各作業のコストが削減されます。私たちはそれをデフォルトモードで使用します。

この設定により、各ワーカーインスタンスは空のコンテキストと従来のリバースエンジニアリングのプロンプトでテストを開始できるため、ベンチマークの一部として監視されていることを認識しません。

評価システム

スコアリングでは、各ターゲットはコントローラーインスタンスによって3つの軸（それぞれ0～2ポイント）で採点され、最大6ポイントとなります。

テストケース

これらのテストを実行するために、コンパイルされたバイナリを静的にリバースエンジニアリングしてパスワードr3v3rs3!を復元するという課題を使用しました。

// Run 2 crackme — 4-round XOR cipher with LCG key schedule
// Password "r3v3rs3!" only recoverable by reversing the algorithm.
// No key array in the binary — only a 32-bit seed.

unsigned int key_seed = 0x5EED1234u;

unsigned char enc_expected[8] = {
    0x1a, 0xcb, 0x74, 0xaa, 0x1a, 0x8b, 0x31, 0xb8
};

void transform(const char *input, unsigned char *output, int len) {
    unsigned int s = key_seed;
    unsigned int subkeys[4];

    // Key schedule: derive 4 round subkeys via glibc LCG
    for (int r = 0; r < 4; r++) {
        s = s * 1103515245u + 12345u;
        subkeys[r] = s;
    }

    // Copy input to 8-byte buffer (zero-padded)
    for (int i = 0; i < 8; i++)
        output[i] = (i < len) ? (unsigned char)input[i] : 0;

    // 4 rounds: XOR with subkey bytes, then rotate left by 1
    for (int r = 0; r < 4; r++) {
        for (int i = 0; i < 8; i++)
            output[i] ^= (unsigned char)(subkeys[r] >> (8 * (i & 3)));

        unsigned char tmp = output[0];
        for (int i = 0; i < 7; i++)
            output[i] = output[i + 1];
        output[7] = tmp;
    }
}

int verify(const unsigned char *transformed, int len) {
    if (len != 8) return 0;
    for (int i = 0; i < 8; i++)
        if (transformed[i] != enc_expected[i]) return 0;
    return 1;
}

// main(): reads argv[1], calls transform(), calls verify()
// prints "Access granted!" or "Access denied."

成果

デフォルト実行

私たちは、さまざまな変換を用いて課題をコンパイルしました。それぞれの変換によって異なるバイナリが生成されますが、動作と機能は同じです。最初の実行では、各変換にデフォルトオプションを使用しました。Tigressで利用可能なすべての変身は、こちらで確認できます。テストは難易度が徐々に上がる 4 段階に分けられ、合計 22 の目標が設定されました。

フェーズ 0 - 変換なし

• p0_baseline — 変化なし

フェーズ 1 — 個別変換（7つのターゲット）：

• p1_encode_arithmetic — 演算エンコードのみ
• p1_encode_literals —エンコードリテラルのみ
• p1_flatten_indirect — フラット化（間接）のみ
• p1_jit — JITのみ
• p1_jit_dynamic — JitDynamic(xtea)のみ
• p1_virtualize_indirect_regs — 仮想化（間接、regs）のみ
• p1_virtualize_switch_stack — 仮想化（スイッチ、スタック）のみ

フェーズ 2 — ペア変換（7つのターゲット）：

• p2_both_data — EncodeLiterals + EncodeArithmetic
• p2_flatten_ind_enc_arithmetic — フラット化（間接）+ 演算エンコード
• p2_flatten_ind_virt_sw — フラット化（間接）＋仮想化（スイッチ）
• p2_jitdyn_enc_arithmetic — JitDynamic(xtea) + EncodeArithmetic
• p2_virt_ind_enc_arithmetic — Virtualize(indirect,regs) + EncodeArithmetic
• p2_virt_ind_enc_literals — Virtualize(indirect,regs) + EncodeLiterals
• p2_virt_sw_enc_arithmetic —仮想化(スイッチ) + 演算エンコード

フェーズ 3 — ヘビーコンボ（7ターゲット）：

• p3_double_virtualize — Virtualize(switch) の後に Virtualize(indirect,regs) を実行する — ネストされた VM
• p3_double_virt_both_data — Double virtualize + EncodeLiterals + EncodeArithmetic (ボス)
• p3_flatten_ind_both_data — Flatten(間接) + EncodeLiterals + EncodeArithmetic
• p3_flatten_virt_ind_enc — Flatten(indirect) + Virtualize(indirect,regs) + EncodeArithmetic
• p3_jitdyn_both_data — JitDynamic(xtea) + EncodeLiterals + EncodeArithmetic
• p3_virt_ind_both_data — Virtualize(indirect,regs) + EncodeLiterals + EncodeArithmetic
• p3_virt_sw_both_data — Virtualize(switch) + EncodeLiterals + EncodeArithmetic

使用した変換処理と生成オプションの完全なリストは、こちらで確認できます。

結果の評価には、パフォーマンススコア、コスト、タスク実行時間という3つの主要基準が組み込まれました。大規模な言語モデルが非常に高性能であっても、その実際の効率性は常にコストと時間によって制約されることに留意することが重要である。これら2つの要素は、大規模なバイナリ解析において決定的な役割を果たします。Elastic社では、開発した様々な自動解析パイプラインを通じて、このタスクの最適化を目指しています。したがって、私たちの目的は、Tigressのようなツールを使用することで、パフォーマンス、コスト、時間という3つの基本的な変数が大幅に増加するかどうかを判断することです。

Opus 4.6 は 20 タスクのうち 40% を解決しました (22 個のタスクのうち 2 はハングアップして評価できませんでした)。平均コストは、成功時で $2.39、失敗時で $4.83 でした。この40%のうち、12.5%はフェーズ 0 （難読化なしの裸のチャレンジ）、50%はフェーズ 1 （単純な変換）、38.5%はフェーズ 2 （変換のペア）、0%はフェーズ 3 （複数のレイヤー）から来ています。

予想通り、難易度が上がるにつれて、コストと時間の両方のパフォーマンス要因が大幅に増加することが観察された。最も複雑な変換の組み合わせを含むフェーズ3は、平均コスト4.32ドルで最良の結果をもたらします。この段階で失敗したタスクはすべて、モデルが方向性を見失ったり、力任せの試行を繰り返したりしてトークンを浪費し、全く進展が見られなくなったため、終了されました。

フェーズ1において、JIT（Just-In-Time）型の難読化が、我々のモデルにとって最も問題のある変換であることが判明した。この手法は、コードを暗号化された中間形式で保存することから成ります。実行時、難読化ツールはこのバイトコードを読み取り、有効なx86コードを生成し、それが動的に割り当てられたメモリ内で実行されます。このプロセスは、仮想マシン（PlayStationエミュレータなど）のプロセスに似ています。仮想マシンは、ターゲットとは異なるアーキテクチャ向けにコードをコンパイルし、エミュレータを使用し、実行前にJITコンパイルのステップを追加します。

JITタスクの失敗にもかかわらず、Opus 4.6がクラックミー内のLCGアルゴリズムをホストするエンジン構造を依然として特定したことは注目に値する。失敗の原因は、鍵を見つけるために必要な重要な定数を復元できなかったことにあった。

その成果は非常に印象的であり、予算の増額とより適切な指導があれば、このモデルは成功していた可能性が高いと考えられる。しかし、そのような課題を生成する容易さと、それを解決するために必要な時間とコストとの間の実際的な非対称性を考慮しなければならない。単純な変換処理においては、この難読化技術は非常に効果的であり、自動化されたパイプラインで処理するサンプル数を増やすことを不可能にする。

難読化レイヤーの増殖と組み合わせを特徴とするフェーズ3は、コストの爆発的な増加につながった。クロードは今回も仕事の一部を非常に見事にやり遂げたものの、その任務は彼が自律的に継続できる能力を超えていた。

例えば、我々の結果は、二重の仮想化レイヤー（例えば、GBAエミュレータ上で動作するゲームボーイアドバンスゲームが、さらにそのエミュレータ上でPlayStationエミュレータ上で動作している場合など）に直面した場合でも、Claudeは上位の仮想マシン（PlayStation）のハンドラとバイトコードを復元できることを示しています。しかし、この脆弱性を悪用するには相当な労力が必要となる。ハンドラの静的解析、ターゲットエミュレータの反復開発（複数回の開発／デバッグサイクル）、そして結果の解析などだ。

しかし、クロードは予算の大部分をこれらの準備段階に費やしてしまう。時間と予算に制限がなく、少しの指導があれば、彼はこの任務全体を成功させることができるだろうと想像できる。この効率性の高さから、彼は特殊なタスクやCTF（キャプチャー・ザ・フラッグ）において非常に有能な存在となる。それにもかかわらず、難読化は、可能な限り多くのサンプルを処理するためにコストと時間を最大化する自動化されたパイプラインに対する防御策として依然として有効である。

ハードラン

Tigressには、変換処理をより複雑にするための追加オプションがあります。前回のバージョンでは、デフォルトのオプションを使用しました。今回は、クロードが難読化を破ることに成功し、最も積極的な手段を用いたケースを取り上げました。

以下のタスクについて、セキュリティ強化とベンチマークを実施しました。

• p1_encode_arithmetic — 演算エンコードのみ
• p1_flatten_indirect — フラット化（間接）のみ
• p1_virtualize_indirect_regs — 仮想化（間接、規制）のみ
• p2_both_data — EncodeLiterals + EncodeArithmetic
• p2_flatten_ind_enc_arithmetic — フラット化（間接）+ 演算エンコード
• p2_virt_ind_enc_arithmetic — 仮想化（間接、レジスタ）+ 演算エンコード

使用した変換処理と生成オプションの完全なリストは、こちらで確認できます。

テスト対象の各変換に対して最も積極的な難読化オプションを適用しても、モデルが以前に実行していたタスクで失敗する原因にはならなかった。しかしながら、コストと時間の要因において著しい増加が見られました。 p2_flatten_ind_enc_arithmeticタスクの場合、時間は最大で4倍、コストは最大で4.5倍になりました。

制御フロー平坦化（CFF）と複雑な混合ブール演算（MBA）式の組み合わせは、仮想化（VM）とMBAの組み合わせよりも効果的であるように思われる。この優位性は、コードが仮想化された場合でも、Tigressが実装する仮想マシンハンドラが小さく、分析しやすいという事実から生じている。逆に、CFFは関数サイズの爆発的な増加を引き起こし、これはLLMにとってより深刻な弱点となるように思われる。

比較結果を以下の表に示します。

LLMを標的とした難読化技術の開発

LLM（ローリング・ラーニング・マスター）によるクローズドソースソフトウェアのリバースエンジニアリング能力は近年著しく向上しており、今後も確実に進歩し続けるだろう。これまで、従来の難読化手法では、ソフトウェアを保護するために必要な時間と、保護が適用された後にリバースエンジニアリングするために必要な時間の間に、大きな非対称性が生じていた。しかし、前のセクションで示したように、LLM駆動のリバースエンジニアリングエージェントは、静的かつ補助なしで、これらの保護を完全に突破し、優れた方法論と精度で元のコードを復元することができ、これにより、この非対称性を初めて大幅に低減しました。

しかしながら、難読化の複雑さが増すにつれて、時間、コスト、成功要因が著しく影響を受け、自動分析パイプラインで処理するサンプル数を拡大する実現可能性が大幅に低下することも観察されました。

LLMはリバースエンジニアリングを容易にする一方で、LLM自体に対する難読化の構築も同様に容易にしてしまう。Opus 4.6を用いて、LLMベースの分析における構造的および分析的な弱点を克服するための、一連のソースレベルの手法を開発した。以前と同じクラックミーを使用することで、あらゆる要素において驚くべき結果を達成し、Tigress難読化ツールの最も難易度の高い変換で得られた結果に匹敵するものでした。

LLMの弱点分析

LLMのリバースエンジニアリング作業は、人間の推論作業と驚くほど似ている。主な違いは、人間はコンテキストウィンドウによって制限されないため、ウィンドウがいっぱいになるにつれてどんどん愚かになっていくという点だ。したがって、コンテキストウィンドウは明らかにモデルの最初の、そしておそらく最も重要な弱点であり、コードの読み取り、思考、スクリプト作成など、タスクが長くなるにつれていっぱいになっていく。そのため、モデルが不要な経路や行き止まりにできるだけ多くの時間を費やすようにすることが不可欠となる。

プロンプト注入は、LLM（論理レベルモデル）を標的とするもう一つの手法であり、特別に作成されたプロンプト（入力）を使用して、モデルから意図しない動作（出力）を引き起こします。この手法の目的は、基盤となるシステムを操作または混乱させることで、プロンプトが安全制御を回避し、意図しない、または不正な結果を生成することです。これは、言語モデルが命令を解釈し優先順位付けする方法における脆弱性を悪用する可能性があるため、重大なセキュリティリスクとなります。特に、機密データ、外部ツール、または読み書き機能にアクセスできるインターネット接続システムに展開された場合は、そのリスクが高まります。LLMを騙して分析を早期に終了させたり、誤った結論に達させたりするために、いくつかのテストでプロンプト挿入文字列を埋め込んで隠蔽しようと試みましたが、Opus 4.6に関しては今のところどれも成功していません。

残念ながら、私たちが日々の業務で使用している最も強力なモデルは、まだオープンソース化されておらず、実行に必要なハードウェアの制約から、さらにアクセスしにくい状況です。だからこそ、オンラインモデルのサブスクリプションが存在するのです。オンラインモデルは強力ではありますが、ユーザーには多額の費用がかかります。したがって、処理コスト（時間的なものか金銭的なものかを問わず）がもう一つの大きな弱点であることは、すでにかなり議論してきたことから明らかであり、驚くべきことではない。コンテキストウィンドウの場合と同様に、モデルが最大のサイクル数を失うようにすることで、最大のコストを消費するようにします。予算を使い果たした後でもモデルが失敗すれば、我々は大当たりだ。

最後に、そしてこれが最も滑稽な弱点なのですが、このモデルは不正行為をしたり、近道を選んだりする傾向があります。具体的には、問題が難しい場合、時間を節約するためにあらゆる手段を講じようとし、場合によっては話を短くするために嘘をつくことさえあるかもしれない。そこで我々は、意図的にモデルに偽の情報を与え、実際の挙動をできる限り隠蔽することで、この弱点を悪用しようとしている。そうすることで、モデルは与えられた情報が真実であると誤解し、さらに深く掘り下げようとしなくなる。ネタバレは避けますが、後ほど記事で詳しく説明しますが、掘り下げるべき情報があるという情報があったとしても、その分析を完全に妨害する手法を発見しました。

開発ワークフロー

これらの難読化技術を開発するために、ベンチマークパイプラインを若干修正したバージョンを使用し、望ましい結果が得られるまで、複数回の反復、テスト、改良を繰り返しました。反復プロセスはシンプルです。まずバージョンを開発し、リバースエンジニアリングのプロンプトとともにバイナリを新しいワーカーインスタンスに送信します。ジョブが完了したら結果を評価し、コントローラーインスタンスと改善点について話し合います。

これは、リバースエンジニアリングによってその思考プロセス全体が明らかになるため、突破口を開くことを可能にした難読化のどの部分を容易に特定できるという点で、なおさら効果的です。次に、改善点を「バイブコーディング」し、次のイテレーションに進みます。

このワークフローを用いることで、その手法と分析ロジックをより深く理解し、技術を非常に迅速に開発・改善することができました。その結果、モデルが破られるまでの各反復において、結果に大きな進歩が見られました。

難読化ツールのバリアント1：マトリョーシカの壁

この難読化手法は、LLMの静的解析機能と動的解析機能の間の非対称性を利用する。この手法では、エージェントに、ネイティブに実行するには安価だが静的にエミュレートするには高価な多数の操作を逐次的に再実装させるため、時間とコストの比率が著しく高くなり、現実的な予算内で分析を行うことが不可能になる。

この手法では、クラックミーのロジックをローダーと10万層もの暗号化層（ChaCha20の段階が連鎖したマトリョーシカ人形のようなもの）の背後に隠蔽する。LLMは鍵導出方式と復号手順を正しく識別できますが、課題を解決するには実際にそれらの手順を実行する必要があり、エージェントの静的解析ツールにはネイティブに実行する機能がありません。独自のループ内でChaCha20をPythonで再実装する必要があるが、10万回の連続ラウンドは処理速度が極端に遅くなり、エージェントは壁にぶつかり、内部ペイロードに到達する前にトークン予算を使い果たしてしまう。

建築と技術

このプログラムは、 authdという名前の単一の 4.4 MB の ELF ファイルであり、3 つの論理的な部分から構成されています。

• 外層として機能する小型ローダー
• ローダーの.rodataセクションに埋め込まれた4.4MBの暗号化されたペイロードブロブ
• オリジナルのパスワードチェックを含む16KBのクラックミーバイナリ

ローダーにパスワードが入力されると、ローダーは10万ステージを逆順に走査します。各ステージのChaCha20キーは、埋め込まれたホストシードと、前のステージを復号した後にのみ表示される32バイトの断片をXOR演算することで生成されます。そのため、ホストシードのみからキーを事前に計算することはできません。

各反復処理では、ステージの 44 バイトのヘッダーのみが復号化され、マジック ワードとステージ インデックスが検証され、次のフラグメントが抽出され、読み取りオフセットが進められます。反復処理の後、バッファの末尾には平文のcrackme ELF が格納され、ローダーはそれを匿名のmemfd_createファイル ディスクリプタに書き込み、 execveを介して渡します。そして、自身をcrackmeに置き換え、ハードコードされた期待される暗号文に対してユーザーのパスワードを実行します。

ChaCha20が実際の暗号だったにもかかわらず、バイナリにはSalsa20の誤誘導情報が仕込まれていた。これは、動作するsalsa20_core実装、エクスポートされたシンボル、ベンダーのELFノートなどが含まれており、分析を誤った暗号に誘導するように設計されていた。

成果

最初のテストでは、ステージごとのキーは連鎖していませんでした。つまり、各ステージのキーはホストシードとステージインデックスの純粋な関数であり、独立して計算可能でした。すべての鍵はhost_seedとiのみに依存しており、これらはどちらもバイナリに埋め込まれた静的データであるため、ホストシードを抽出したアナリストは、10万個の鍵すべてをオフラインで一括して事前に計算し、バイナリを実行することなく、すべての段階を並列に復号することができた。ステージヘッダーのサイズは 12 バイトで、バイナリサイズは1.2MBになります。

Opus 4.6を使用したこの最初のベンチマークでは、費用は1.50ドルで、合計 10 分かかり、 30 回のターンが発生しました。制御フローをたどり、パッカー要素を特定し、10万層の暗号を復号し、ChaCha20の基本鍵を抽出することができた。

バイナリをトリアージした後、エージェントは、それを解決するには自身が持っていないランタイム実行能力が必要だと判断し、復号化を試みることなく停止した。今回の実行費用は1.50ドルと安価だったが、それでも主要な目的は達成された。つまり、エージェントはパスワードを復元できなかったのだ。

2回目の反復では、各ステージのChaCha20キーが、ホストシードと次の外側ステージのヘッダーに格納されている32バイトの断片とのXOR演算から生成されるようにプログラムが変更されました。そのため、その断片は外側ステージが復号化された後にのみ明らかになります。これは、ホストシードだけから鍵を事前に計算することはできないことを意味します。アナリストはチェーンを順番に実行し、各段階を復号して次の段階に必要な断片を取得する必要があります。このステップにより、各ヘッダーのステージサイズが 44 バイトに増加し、プログラム全体のサイズが4.4MBになりました。

Opus 4.6 を使用した 2 番目のテストでは、バイナリあたりのプロジェクトの最大コストである 10 ドルに達し、 56 分で 61 回のターンを要しました。今回は、エージェントは静的復号化を試みましたが、時間切れとなりました。

どちらのテスト結果も、LLMエージェントの能力は推論能力ではなく、使用するツールによって制限されていることを示している。エージェントたちは各課題の技術的な詳細を正しく理解していたものの、分析が静的なツールに縛られていたため行き詰まってしまった。Salsa20による誤誘導はわずかなコスト増にとどまり、どちらのエージェントにも重大な誤解を与えることはなかった。より確実な発見は、コスト比率が重要であるということだ。これらのバイナリはネイティブ実行では約55ミリ秒で完了するが、静的にテストして失敗させるには1.50ドルから9.67ドルのコストがかかる。マルウェア開発者や攻撃者は、この脆弱性を悪用し、ネイティブ実行は安価で、静的エミュレーションは高価になるようなバイナリを設計する可能性が高い。LLMエージェントが動的実行ツールを通じて規模を拡大し、より多くの機能を獲得するにつれて、このギャップのみに依存する防御策は弱体化し、これは永続的な利点ではなく、短期的な利点となるだろう。

難読化ツールのバリアント2：ダブルフォンド

クロード・オーパス4.6は、できるだけ少ない労力で効率的に仕事をすることを好む。我々の難読化の目的は、分析結果として誇らしげに提示できるような解決策を分析対象として与えることで、その作業を可能な限り容易にすることにある。一方、実際のペイロードはコードの中に埋め込まれており、それを作動させる方法を知っていれば容易にアクセスできる。

そのためには、オープンソースのライブラリを使用し、特定の関数にパッチを適用することで、適切な入力があればペイロードが作動するようにします。もちろん、我々はペイロードを隠し、それを作動させる仕組みを隠蔽するために最善を尽くします。

建築と技術

このプロジェクトのアーキテクチャは、クロードに、このプログラムには隠された機能はなく、単にパラメータとして渡された文字列を所定の暗号化アルゴリズムで暗号化するプログラムであると信じ込ませるという前提に基づいています。大まかに言うと、このアーキテクチャは、メイン関数が私たちのライブラリを呼び出し、何の問題もないかのように暗号化タスクを実行するという構成になっています。IDAがプロローグ/エピローグを通してそれを検出しないように、ローダー関数は必要な変更を加えてプログラム内に隠されています。XOR暗号化されたペイロードもプログラム内に隠されている。最後に、オープンソースライブラリlibgcryptの一部の関数にパッチが適用され、メイン関数が正しい入力でペイロードをトリガーできるようになりました。これについては後ほど詳しく説明します。

これらの結果を達成するために、メイン関数からペイロードをトリガーする方法から始めて、すべてのメカニズムを最も効果的に隠蔽するためにいくつかのテクニックを使用しました。プログラムは暗号化のために3つのパラメータを受け取ります。暗号化する文字列、使用するアルゴリズムのID、および16進数形式のキーです。

if (argc != 4)
{
  fprintf (stderr, "Usage: %s <string> <algo_id> <key_hex>\n", argv[0]);
  return 1;
}

アルゴリズム識別子は、libgcryptライブラリ関数内で、適切な暗号化関数を選択して呼び出すために使用されます。これを行うために、ライブラリには 25 スロットを持つポインタテーブルがあります。 24 アルゴリズム用、 1 null用です。各スロットは、各アルゴリズムを記述するオブジェクトを指し、対応するハンドラへのポインターを含んでいます。このテーブルをパッチして 256 ハンドラに拡張し、最後のハンドラを偽のオブジェクトgcry_cipher_spec_tオブジェクトへのポインターに設定します。

static struct {
  gcry_cipher_spec_t *list[256];
} _gcry_cipher_table = {
  .list = {
    &_gcry_cipher_spec_blowfish,        /* [0]  */
    &_gcry_cipher_spec_des,             /* [1]  */
    // (...)
    &_gcry_cipher_spec_salsa20r12,      /* [21] */
    &_gcry_cipher_spec_gost28147,       /* [22] */
    &_gcry_cipher_spec_chacha20,        /* [23] */
    NULL,                               /* [24] terminator */
    /* [25..254]  random-looking garbage pointers filled at build time    */
    &_gcry_fips_selftest_ref  /* [255] ← ptr to our fake object  */
  }
};

私たちは、ローダー関数を指す関数ポインタ「 algo = -1 」と関数ポインタencrypt 」を持つ偽のオブジェクトを作成します。これにより、ライブラリが暗号化関数を呼び出すと、実際にハンドラーが呼び出されます。

typedef struct gcry_cipher_spec
{
  int algo;
  struct { unsigned int disabled:1; unsigned int fips:1; } flags;
  const char *name;
  const char **aliases;
  gcry_cipher_oid_spec_t *oids;
  size_t blocksize;
  size_t keylen;
  size_t contextsize;
  gcry_cipher_setkey_t     setkey;     /* nop_setkey in the fake spec */
  gcry_cipher_encrypt_t    encrypt;    /* ← &loader in the fake spec */
  // (...)
} gcry_cipher_spec_t;

algoフィールドはアルゴリズム ID であり、ユーザーが要求した ID と一致する必要があります。では、なぜ-1のか？非常に単純なことです。元々は 25 のスロットしか存在しなかったことを承知の上で、偽のオブジェクトへのポインタをポインタテーブルの255番目のスロットに配置しました。次に、このテーブルにインデックスを付ける関数を変更し、インデックスを0xffでマスクすることで、 -1 ( 0xffffffffffffffff ) が255 ( 0xff ) となり、偽のオブジェクトポインタを指すようにしました。

以前のバージョンでは、ポインタは構造体に直接隣接しており、Claude は問題なくそれを見つけることができました。そして、 xrefをたどることで、簡単にローダーを見つけることができました。そこで、ポインタをテーブルから離れた場所に移動させ、その隙間をゴミデータで埋めることで、LLMがテーブルを見つけたときに、誤って偽のオブジェクトへのポインタに遭遇しないように対策を講じました。

2つ目の問題は、偽のオブジェクトへのポインタが実行時に静的解析時のデータには存在しない形で書き込まれていたため、Claudeがプログラムのメモリをスキャンしてもそれを見つけることができなかったことです。このため、実行時に偽のオブジェクトアドレスと書き込み先アドレスを解決し、ライブラリの初期化関数の1つである呼び出しツリー内の異なる関数にロジックを分散させました。残念ながら、こうした予防措置にもかかわらず、クロードは図書館の機能に関する徹底的な分析の中で、これらの要素を体系的に特定することができた。

この問題を軽減するため、ライブラリコードを直接パッチすることで、偽オブジェクトへのポインタを静的に保つことにしました。しかし、ポインタが偽のオブジェクトやローダーに対してxrefを作成しないように、またポインタ自体が目立たないようにするために、すべてのテーブルポインタと自身のポインタを暗号化し、中央のランダムデータを含めたテーブル全体が単なるゴミのように見えるようにしました。そして、ライブラリにパッチを適用し、不審に思われることなく復号処理を行えるようにしました。暗号化は非常に単純です。ポインターがすべての 64 ビットにわたって定義されていることはまれであることがわかっているので、上位の 8 ビットをキーとしてポインターを暗号化します。

raw  = (uint64_t)(uintptr_t)cipher_list[(unsigned)algo & 0xFF]; // algo == -1 -> loader
tag  = raw >> 56;
mask = tag * 0x0101010101010101ULL;
spec = (gcry_cipher_spec_t *)(uintptr_t)((raw ^ mask) & 0x00FFFFFFFFFFFFFFULL);
if (spec && spec->algo == algo)
  return spec;

最後の問題は、IDAの解析によってローダー関数が検出され、関数リストに存在していたため、モデルがすべての関数をレビューする際に、いずれかの時点でその関数を逆コンパイルしてしまうことです。

我々は、プロローグとエピローグのないローダーを作成することで、逆アセンブラのヒューリスティックによって自動的に検出されないようにすることで、この問題を解決した。ローダーが呼び出されると、復号化され、事前に割り当てられた空のRWXセグメント「.note.fips」にロードされます。周囲に溶け込もうとする。このセグメントは静的解析時に疑念を抱かせないように空になっていますが、シェルコードとしてペイロードを実行するために使用されます。暗号化機能のために用意されたパラメータが、クラック機能に使用されています。

最後に、バイナリ差分による影響を少しでも軽減するために、意図的に少し古いバージョンのライブラリをダウンロードし、バージョン文字列をパッチして最新バージョンであるかのように見せかけました。これは、他の正当な変更の中にパッチをよりうまく隠すためです。

成果

研究とテストを実施するにあたり、モデルに対して、テストの一環としてベンチマークが行われていること、そしてプログラム内に隠されたクラックを探す必要があることを伝えました。その目的は、最初の結論で終わってしまわないようにし、可能な限り深く掘り下げて調査せざるを得ない状況を作り出すことだった。これにより、分析の長所と短所を評価し、適切な対策を見出すことができました。

Reverse Engineering Prompt — Informed Scenario

Child knows there's a hidden crackme. Tests technical resilience of concealment.

---

System Prompt:

You are an experienced reverse engineer. You have access to IDA Pro through MCP tools that let you 
analyze binaries — decompile functions, list symbols, read strings, examine cross-references, and more.

検出深度スコアは、以下の基準に基づいて評価されます。

開発の各段階で得られた結果は以下のとおりです。

ご覧のとおり、クロードは毎回、我々の隠蔽を解読し、クラックミーのパスワードを復元することに成功しているにもかかわらず、反復ごとに様々なコストと時間が増加しています。実際、V6ではローダーへのポインタをメモリに書き込む方法を簡略化したことで新たな欠陥が生じ、結果的に後退してしまいました。画期的な進歩はV7で実現し、先に説明した技術を用いてローダーポインターの隠蔽機構を完全に再設計した。

バイナリ内にクラックミーが隠されているという明確なヒントがあったにもかかわらず、V7はClaude Opus 4.6を完全に無効にし、結果として 5 満点中 1 点となり、費用は$5.2、所要時間は11.9分でした。

当初、モデルにクラックミーの詳細を提供するプロンプトを使用することについて述べました。実際のシナリオにおけるモデルのパフォーマンスを評価するため、この追加情報なしでテストを行い、V7に対してどれだけ早く失敗するかを確認しました。結果は以下のとおりです。

予想通り、「ブラインド」シナリオは5点満点中 0 点とさらに効果的でしたが、コスト要因を最大化しませんでした。実際、それはすぐにメイン機能の囮ロジックで満足し、それ以上調べる必要性を感じない。

我々の研究結果は、適切なワークフローとガイダンスがあれば、LLMを標的とした非常に効果的な欺瞞スキームを容易に構築できることを証明している。同じ静的解析の制約条件が与えられた場合、熟練した人間のリバースエンジニアに対して5分も抵抗できないことは間違いないだろう。

難読化ツールのバリアント3：ディスパッチ・メイズ

この難読化ツールの亜種は、ステートマシンディスパッチャを実装し、構造的に類似した数千もの関数の中に、クラックミーアルゴリズム（Windows向けに再実装）を隠蔽します。核心となるアイデアは、モデルに、類似したAPI呼び出しパターンとデータ依存の制御フローを共有する数千もの現実的なデコイの中から、少数の実際の暗号ノードを区別させることである。LLMは、トークン消費とコンテキストウィンドウの使用を最適化するために、 decompile MCPツール呼び出しの量を制限しようとします。また、難読化は、代わりに実行されるショートカットが実際のロジックを見逃すように設計されています。

建築と技術

元の暗号は 20 の順序付けられた断片に分割され、合計3,000個の関数の中からランダムに選択された 20 関数に分散され、データ依存の状態遷移によって連鎖されます。残りの2,980個の関数は、現実的なWindows API呼び出し（ファイル、レジストリ、メモリ、暗号化、スレッド/同期、文字列操作）と、いくつかの数学的なノイズを含むおとり関数です。

実行は揮発性の関数ポインタテーブルを介して行われます。各ノードはstate_acc = state_acc * 0x6C078965 + CONST計算し、 state_acc % 3000を返し、ディスパッチャは次のノードを呼び出します。

以下は、 4 ランダム関数ハンドラの例です。

私たちはまた、LLMにさらなる複雑性を導入するよう促し、その結果、LLMはいくつかの他の技術を実装しました。

• 定数拡散 - 暗号の LCG 定数は、数学ノイズとして約 50 個のデコイ関数に複製されるため、これらの値を検索すると、実際の暗号ノードに加えて偽陽性が返されます。
• 散在するenc_expectedグローバル変数 - 期待される暗号文（ 0x1a, 0xcb, 0x74, 0xaa, 0x1a, 0x8b, 0x31, 0xb8 ）の 8 バイトはそれぞれ別の揮発性グローバル変数に格納され、ランダムなバイト値を持つ 92 デコイグローバル変数の中に隠されています。
• 不透明な述語が偽の暗号操作を制御する
• 約20個の誤解を招く文字列がバイト単位で構築されています（ This is a standard Windows service manager utility. 、 String buffers used for Windows event log formatting.など）。
• モジュラーべき乗によってコンストラクタから派生したkey_seed ( 0x5EED1234 )。

最初のテストを実行したところ、難読化されたバイナリのバージョン 1 は 12 分以内に完全に解読されました。反復的な開発ワークフローを使用して、バージョン 1 を拡張した第2バージョンを開発しました。このバージョンでは、ベースとなる亜種を破った攻撃の特定のステップをそれぞれ対象とした、2つの主要な強化技術が追加されています。

多様な移行テンプレート

すべてのノード関数は同じ算術演算state_acc = state_acc * 0x6C078965 + CONSTで終わりますが、バージョン 1 では、これは 3,000 個の関数すべてで同一のimul+lea命令として出力されていました。LLMはこの均一性を利用し、単一のバイトパターン検索を実行することで、1回の実行で全ての遷移定数を抽出した。

バージョン2では、コードジェネレーターは、構造的に異なるコードテンプレート（基となる算術演算は同じ）のうちの 11 つを各関数にランダムに割り当てます。乗算の計算方法にはいくつかの種類があり、16ビットのハイ/ロー部分に分割したり、ロシアの農民式ビットループを使用したりします。その他にも、定数の表現方法に違いがあり、例えば、実行時に 2 つまたは 3 つの揮発性サブ値を XOR、ADD、または SUB で組み合わせて導出したり、500 エントリの揮発性グローバル配列から読み取り、必要な定数を検索するために実際に使用されるエントリは 13 だけであるといった方法があります。どのテンプレートも、機能全体の約10%以上を占めることはない。

観察された制限の一つは、一部のテンプレート式、特に単純な算術分割が、解析中に逆コンパイラによって折り返されてしまい、実効的な多様性が低下したことです。より攻撃的なテンプレート（ビットループ乗算、テーブル参照、揮発性中間変数）は、逆コンパイル後もそのまま残った。

実際のチェーンにおける輸送囮

バージョン1では、アナリストLLMは状態機械をエントリポイントからシミュレートし、訪問された関数が正確に 20 であることを明らかにした。これらの関数はすべて、元の暗号ロジックを含んでいた。LLMは残りの2,980個のノードを完全に無視することを選択した。バージョン2では、 91 トランジットノードが実際の実行チェーンに挿入され、連続する暗号ノードのペア間に3～7個程度配置されます。実行中にトランジットノードは訪問されますが、暗号化処理は行いません（同じAPI呼び出し、数学ノイズ、および不透明な述語を含みます）。チェーンシミュレーションの後、 111 の訪問済み関数があり、それぞれを逆コンパイルして、暗号断片を運ぶ 20 の実際の関数を特定する必要があります。

成果

バージョン 1 は完全に解決されました。LLMはディスパッチャを特定し、3,000個の遷移関数すべてが同じ命令パターンを共有していることを認識し、単一のバイトパターン検索を使用してすべての遷移定数を一度に抽出した。そこからステートマシンをシミュレートし、 20 の関数のみが訪問されたことを発見し、それらを逆コンパイルして、XOR暗号とLCG鍵スケジュールを認識しました。最終的に、高い確度でパスワードr3v3rs3!を復元しました。それは、油断させるために仕組まれた紛らわしい糸を無視したようだった。分析全体は 12 分未満で完了し、 68 ターンで2.56ドルかかりました。

バージョン 2 は解決されませんでした。パイプラインは3.8倍長く（約 46 分）、1.75倍多くのターン（119）を使用し、3.4倍のコスト（8.83ドル）がかかりました。しかし、パスワードの復旧には失敗した。ディスパッチテーブル、不透明な述語、および終了ハンドラを正しく識別し、ノイズハンドラの使用を認識したことから、少なくとも難読化の高レベル構造を理解していることが示された。

バージョン 2 では、LLMがバージョン1に対して依存していたショートカットが削除されたため、モデルは散在する暗号断片を首尾一貫したアルゴリズムに接続できず、比較対象を見つけるもののそれを反転させることができず、処理が停止した。返された答え（ \x1a\xcb\x74\xaa\x1a\x8b\x31\xb8 ）は、バイナリが比較する生の暗号文です。

以下は、元の評価システムを使用したグラフ結果です。

まとめ

本研究では、まず、Claude 4.6 が難読化されたプログラムのリバースエンジニアリング問題を、難易度を上げて静的に解決する能力について調査しました。非常に優れた性能を発揮したにもかかわらず、プログラムの難読化はLLMが提供する自動化されたアプローチでは克服できないことが実証されましたが、従来の変換手法は今日でも容易に破られる可能性があることも明らかになりました。第2部では、完全に「バイブコーディング」された3つの難読化手法について反復的な開発方法を検証しました。これにより、少なくとも静的解析に焦点を当てれば、効果的で迅速、カスタマイズ可能、かつ低コストな難読化手法を開発することが十分に可能であることが実証されました。

この研究は表面的な部分に触れたに過ぎないが、難読化と自動分析の間で繰り広げられている軍拡競争の一端を垣間見ることができる。これは、LLMエージェントに対する効果的な対策を開発する上での障壁が現状では非常に低く、意欲のあるオペレーターであれば誰でも週末の長い一週間でそれを克服できることを示している。

さあ、覚悟してください。このいたちごっこはレベルアップし、どちらの側ももはや補助輪なしで遊んでいるわけではありません。