ブラックボックスを攻撃します。 仮想化および変更されたコードのリバースエンジニアリング

自分のソフトウェアをリバースエンジニアリングから保護することはかなり古い問題であり、かつて多くのシェアウェア開発者の心を苦しめただけでなく、それを苦しめました。 通常、このような目的にはトレッドが使用されますが、トレッドがどんなに急勾配であっ​​ても、常にトレッドを切断してクラックする人がいます。 しかし最近、プロテクターはコード変更技術（突然変異と仮想化）の使用を開始しました。これにより、元のアルゴリズムのブラックボックスのような混乱を作ることができます。 実際、現代の商用プロテクターによる実行可能コードの仮想化と突然変異は万能薬であると確信している人々がいます。 セキュリティの苦い価格を知っている人は、完全な保護のヒントを神話やマーケティングのおとぎ話として感じる可能性が高いため、セキュリティガードがこのような声明にかなり笑い、反対することは明らかです。 この記事では、商用プロテクターのブラックボックスとその攻撃の可能性を探るという私自身の経験とビジョンについてお話します。 このような技術の不利な点を理解することで、実際にそれらをより合理的かつ効果的に適用するか、まったく適用しないかを願っています。

0x00。 コード保護メカニズムの分析

まず、調査するテクノロジーを定義しましょう。



1.ミューテーションは、オリジナルのプログラムアルゴリズムに違反することなく、制御フローの元のグラフが追加の頂点、分岐、ガベージ命令、サイクルによって補完されるコード難読化方法です。 多くの場合、ソース命令は同じジョブを実行する他の命令のサブセットに変換されます。



2.仮想化は、アルゴリズムの元の命令がプロテクターによって生成された仮想マシンの命令に変換されるコード難読化方法です。 元のアルゴリズムの代わりに、実行時に中間命令を渡してそれらを解釈する仮想マシンに入るコードが埋め込まれています。



両方の方法は、実行可能コードの静的および動的分析の両方を複雑にし、多くの場合、プロテクターは方法の組み合わせを許可します。



記事の後半で、 VMProtectとSafengineの 2つのプロテクターの無料デモバージョンを検討します。これらは、難読化の両方の方法を変更、仮想化、および組み合わせることを可能にします。



ミューテーションおよびコード仮想化テクノロジーを適用するために、プロテクターは次の方法を提供します。



1.開発段階で、特別なマーカー（SDK）を使用

ソフトウェア開発者は、ソースコードでトレッドSDKの特別な機能を使用して保護されたコードのフラグメントをマークし、コンパイル後、トレッドのインストール段階でこれらのセクションを検出、切り取り、難読化します。

int main () { VMProtectMutate("Critical_code_mut"); ... // critical code here VMProtectEnd(); return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

VMProtectマーカーでソースコードをマークする例



2.保護の段階で、デバッグファイルを使用

トレッドのインストール中に直接、デバッグファイル（pdb、map）が読み取られ、それに基づいてアプリケーションオブジェクトのマップが決定されます。 次に、開発者は、保護する機能とその方法を選択します。その後、それらは完全にコードから切り離されて処理されます。



保護されたコードが切断されるのはなぜですか？ 実際、コードが希釈されると、そのサイズが大幅に増加するため、元のセグメントに新しい命令を収めることができないため、コードはトレッドメモリの独自のセクションにカットされます。





実行可能関数コードの簡略化された突然変異スキームvoid Test（）{printf（ "Hello"）; }

0x01。 プロテクターの長所と短所

もちろん、突然変異の明らかな利点は、アルゴリズムの視覚的調査が不可能であることです。 研究者の前に、一見すると、スパゲッティの山が付いたプレートがあります。これは手で分解することは非常に難しく、まさに現代の保護者が賭けているものです。



同様に重要なのは、デバッグ対策、パッチ適用対策、フック対策、突然変異などのさまざまな手法の組み合わせです。 一緒に、これはすべて分析プロセスの複雑化につながりますが、それらを停止しません。



そのような技術の欠点も十分です。 1つ目はパフォーマンスの低下です。これは、変更されたコードが数百または数千倍も増加するためです。 これは仮想化にも適用されます。原則として、仮想マシンは変更されたコードよりもはるかに重いです。 両方のアプローチを組み合わせると、コードが肥大化します。 さらに、オーバーヘッドコストは常にこのような難読化を正当化するものではありません。変異技術の使用は、プログラム実行の元のグラフの復元を複雑にすることを目的としています。



プリミティブ関数をトレースする例を次に示します。

 void test() { printf("This is protected message #1\n"); printf("This is protected message #2\n"); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

突然変異前：



Safengineプロテクターによる突然変異後：



上記の例では、コードの変更は最小レベルの複雑さで実行されます。 Safengineを使用すると、この複雑さを最大254倍に増やすことができます。これにより、コードが10命令からソースプログラムのサイズを数倍超えるガベージセットに膨らむことができます。これは非常に冗長です。



また、不幸なことに私の記憶で起こったプログラムの破損のケースに起因するデメリットもあります。 そのような障害が通常のプログラムで発生した場合、それはクラッシュにつながり、ドライバーでクラッシュが発生した場合はまったく異なり、まったく受け入れられません。 ご存知のように、プロテクターはさまざまな実行可能ファイル（exe、dll、ocx、sys）を処理​​できます。



また、マーケティングポリシーには、多くのことが望まれる場合があります。 セキュリティの錯覚を作り出す顧客の耳にある技術的なゴミは良くありません。 確かに、トレッド開発者は製品の説明にこの技術が優れているとは書いていませんが、そのような欠陥があります。

0x02。 不完全なコード保護の問題

最後に、保護者の開発者がさらに複雑で永続的な保護を記述できないようにするには、どうすればよいのでしょうか？ 答えは非常に簡単です-不完全な情報。 デバッグ情報がある場合でも、バイナリファイルを入力として受け取ると、いくつかの制限があり、違反するとトレッドが非ユニバーサルになったり、保護されたアプリケーションが破損したりします。 このような制限の例については、通常のPEアプリケーションの構造を見てみましょう。

 生の仮想名
 ------------------------------------
 00000000 00400000 PEヘッダー
 00000200 00401000コードセクター
 00000400 00402000データセクター
 00000600 00403000リソースセクター

アプリケーションのコードとデータはさまざまなセクションに配置されますが、それらの間には明確なリンクがあります。 したがって、いくつかの異なる関数は同じデータブロックを参照でき、データは他のデータと関数を参照できます。 さらに、この接続は常に明らかではありません。 これに基づいて、プロテクターは実行可能ファイルの構造を自由に操作できません：データの移動、展開、ソースセグメントの機能の移動など。 一度実行可能ファイルのセクションを展開しようとしましたが 、これは特殊なケースであり、普遍的ではありません。 したがって、プロテクターは次のようにデータをスタックします。

 生の仮想名
 ------------------------------------
 00000000 00400000 PEヘッダー
 00000200 00401000コードセクター
 00000400 00402000データセクター
 00000600 00403000プロテクターセクター
 00000800 00404000リソースセクター

コードとデータの元の場所は変更されませんが、他の一部のセクターの移動は可能です（リソース、再配置など）。 保護されたコードは切り取られ、ガベージ命令がその場所に配置されます。ほとんどの場合、これらの命令は変更された実行グラフの一部です。 変換されたグラフと仮想マシンは、トレッドセクターに配置されます。



また、コンピューティングの負荷が増加するため、プロテクターはアプリケーションコード全体を変更できません。 したがって、コードの保護されたセクションの選択はプログラマーにかかっています。 しかし、プログラマーは常にこのオーバーレイをインテリジェントに適用できるとは限りません。 たとえば、一部の暗号化アルゴリズムを突然変異でカバーした場合、プログラマーはこの暗号のすべての呼び出しを突然変異でカバーすることを忘れ、研究者がこのアルゴリズムの入力データを取得し、それらを使用して暗号の構造に関する仮定を構築し、場合によっては分類または再現することさえできることを発見します



これはすべて、変異/仮想化コードからの情報漏洩につながり、その上での攻撃を許可します。 データまたはいくつかの関数のおおよその位置がわかっているので、ブラックボックスからそれらへのアクセスを追跡できます。これにより、もつれを解く代わりに、アルゴリズムのファントムモデルを作成します。 もちろん、このアプローチはプログラムアルゴリズムの全体像を示すふりをしませんが、場合によってはこれで十分です。

0x03。 ブラックボックス漁師

ブラックボックスを探索するための典型的なツールはトレーサーです。 ただし、難読化されたコードのパスは80〜99％のゴミであるため、何らかの方法でこのゴミから有用な情報のみを取得する必要があります。 このプロセスは釣りを連想させます。 ルートが湖であり、トレーサーが釣り竿であり、この餌を追跡するための条件を想像してください。 プロテクターの上記の欠点を使用して、適切な餌を選択し、適切な情報を取得できます。 実際にどのように見えるか見てみましょう。



次のプログラムがあるとします：

 void array_fill(unsigned char *buf, size_t size) { for (int i = 0; i < size; i++) { buf[i] = i; if (i > 0) { buf[i] ^= buf[i - 1]; } } } int main() { unsigned char buf[10]; array_fill(buf, sizeof(buf)); return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

突然変異と仮想化の両方をarray_fill（）関数に重ね合わせます。 array_fill（）関数の呼び出しをトレースしてみましょう。



最初のステップ数： 230

VMProtectの難読化後のステップ数： 83924

難読化後のステップ数Safengine： 250382



数字からわかるように、ルートを手動で解析するのは非現実的です。 そのため、釣りの方法を使用します。



array_fill（）関数について何も知らないと想像してください。 main（）を調べて、そのサブコールが入力でバッファアドレスとそのサイズを受信したことを確認できます。その後、何らかのアルゴリズムに従って、バッファは情報で満たされます。 したがって、トレーサーにルールを設定し、それに基づいて、関数に渡されたバッファーへの読み取り/書き込み呼び出しのみを記録します。 3つのアプリケーションオプションすべての結果は同じになります。



ご覧のように、コードの変更の程度やガベージの数に関係なく、バッファへのすべての呼び出しを説明するきれいなトレースを取得できました。 しかし、元のアルゴリズムをそこから復元できますか？ やってみましょう。



そのため、トラックをよく見ると、サイクルが見えるようになります（これは、004B7898でコードを繰り返し呼び出していることから明らかです）。

  ;  1ステップ
メイン004B7898 MOV BYTE PTR DS：[ECX]、AL EAX = 004B7700、ECX = 0018FF34
 ;  2段階
メイン004B7898 MOV BYTE PTR DS：[ECX]、AL EAX = 004B7701、ECX = 0018FF35
メイン004B7A8E MOV AL、BYTE PTR DS：[ECX] EAX = 004B7A89、ECX = 0018FF34
メイン004B7A8E MOV AL、BYTE PTR DS：[ECX] EAX = 004B7A89、ECX = 0018FF35
メイン004B7898 MOV BYTE PTR DS：[ECX]、AL EAX = 004B7701、ECX = 0018FF35
 ;  3ステップ
メイン004B7898 MOV BYTE PTR DS：[ECX]、AL EAX = 004B7702、ECX = 0018FF36
メイン004B7A8E MOV AL、BYTE PTR DS：[ECX] EAX = 004B7A89、ECX = 0018FF35
メイン004B7A8E MOV AL、BYTE PTR DS：[ECX] EAX = 004B7A89、ECX = 0018FF36
メイン004B7898 MOV BYTE PTR DS：[ECX]、AL EAX = 004B7703、ECX = 0018FF36
 ... 

バッファのサイズに対応するこのようなステップは10個しかありません。 さらに、すべてが非常に単純であり、どの値が取得され、どの値が戻されるかを知っているため、作業のアルゴリズムは手のひらにあります。 ここで推測する唯一のことは、XOR演算の使用ですが、この場合、絶対に難しくありません。



もちろん、この例は人為的なものですが、実際には、ネストされた呼び出しと暗黙のロジックを備えたより複雑なアルゴリズムを処理する必要があります。 このような状況では、より複雑なトレーサー、難読化解除ツール、DBIなどが使用されます。 それにもかかわらず、すべてはトレーサーによる情報の引き抜きと分析に帰着します。 アルゴリズムがアクセスできるアドレスを知っていれば、それに関する十分な有用な情報を収集します。

0x04。 ネストされたコール分析

ブラックボックスから引き出すことができる重要な情報は、ネストされた呼び出しに関する情報です。 これらは、WinAPI呼び出し、ライブラリ関数、アプリケーション自体の関数です。 このような情報は、保護されたアルゴリズムの内部構造と依存関係をより詳細に調査するのに役立ちます。



最も単純なケースでは、ネストされた呼び出しを分析するために、実行可能ファイルの構造に関する既知の情報を使用できます。 つまり、変更されたコードがどのセグメントにあるかを知ると、外部関数の呼び出しに対応するこのセグメントからのすべての出口を追跡できます。 そして、これは実際にはライブラリ関数に対しては機能しますが、プログラム自身の関数を呼び出すと問題が発生する可能性があります。 上記のどこかで述べたように、保護されたコードを切り取り、その代わりにプロテクターは独自のコードの一部（変更されたグラフ、仮想マシン）を置くことができます。 したがって、コードの実行がトレッドセクションからアプリケーションコードセクションに移った場合、これが埋め込み関数の呼び出しであり、変更されたグラフの一部の実行ではないという保証はありません。



この問題の解決策もまたかなり確率的です。 まず、柔軟なトレーサーが必要です。たとえば、最後にOllyDbgに組み込まれたトレーサーを使用したときに、 Intel Pinフレームワークを使用できます。 第二に、コードセクションにあるガベージを除いて、ネストされた呼び出しのみをログに記録できる、適切なトレースルールを作成する必要があります。 ライブラリ関数呼び出しを定義する場合は、調査中のモジュールに属するメモリ領域外への制御の移動を修正するルールを作成するだけで十分です。 ほとんどの場合、これは一部のライブラリへの制御の移行になりますが、一部の非標準的な状況では、一部のベースに依存しないトレッドコードで制御の移行を実行できます。 ただし、このような特殊なケースは考慮しません。 ただし、プログラム自体のネストされた呼び出しをどうすればよいですか？



あるいは、プロローグ署名によってネストされた関数を定義できます。 コンパイラーは通常、関数にかなり一般的な外観を与えます。





テンプレートプロローグ関数



つまり、難読化されたコード（トレッドセクション）からアプリケーションコードセクションに制御を戻す場合、提案されたプロローグの前にあるInt3、Retn命令を確認し、事前準備された署名でプロローグを検証することもできます。 コンパイラーは、特に最適化後に、コードに何でも詰め込むことができるので、これは常に助けになるとは限りませんが、これは何もしません。



また、Safengineのトレッドの難読化に1つの小さな欠陥があることに気付きました。これは他のトレッドには存在する可能性がありますが、VMProtectにはありません。 欠点は、プロテクターが一部の関数を変更し、その中に別の変更された関数への呼び出しがある場合、ネストされた関数は、変更されたコードではなく、元のアドレスにあるアダプター（jmp命令）から呼び出されることです。 また、変更されたコードからの情報の漏洩でもあり、トレーサールールの作成に使用できます。 たとえば、VMProtectでは、ネストされた変換関数はトレッドセグメントですぐに呼び出されますが、この方法でネストされた呼び出しを定義することはできません。 おそらく、この欠陥はSafengineのデモ版にのみ存在します。



Intel Pinのトレーサーのソースコードで記事を詰まらせたわけではありませんが、記事が気に入ったら、トレーサーに関する記事を別に書くことができます。

0x05。 グラフ回復を実行する

私たちはみな、さまざまな方法であらゆる方法を試し、変異コードの完全な分析を回避しようとしましたが、難読化解除と仮想化は神話からはほど遠いものです。 現実には、そのような技術は非常に複雑で、ひざまずいて書かれていないだけです。 大学やウイルス対策研究所の専門家は、すでにこの分野を強力かつメインで習得しており、実装のための豊富なツールセットを持っていると思います。 残念ながら、私はそのような技術を使用する慣習にあまり精通しておらず、それらについて何も言うことはありませんが、それらがそうであり、それがクールであることを除いて:)



この問題に関する知識と経験があれば、コメントにリンクをいくつか入れていただければ幸いです。

0x06。 おわりに

ご覧のとおり、ブラックボックスは実際にはそれほど黒ではありません。 収集された情報に基づいて、保護されたアルゴリズムのロジックを部分的に復元し、場合によっては十分な量にすることができます。



一般的に、仮想化と突然変異のテクノロジーを使用する可能性を、専用のコンパイラーによってのみ発揮させることが最善だと思います。 結局のところ、コンパイラはプロテクターとは異なり、保護されたコードに関するほぼ完全な情報を持ち、保護されたコードの場所と外観を簡単に操作できます。 コンパイラーにいくつかのヒントを実装すると、プログラマーが特定の関数およびメソッドの難読化の複雑さの度合いを独立して選択できるようになり、保護の効率的な分散、したがって負荷が提供されます。



最後に、難読化されたコードを逆にするスキルをテストする場合は、 このcrackmeを解決することを提案します。



ご清聴ありがとうございました。