サポート情報 | フォーカスシステムズ サイバーフォレンジックセンター

お問い合わせはこちら
東京証券取引所 プライバシーマーク ISMS JUSE

サポート情報

ホーム > サポート情報一覧 > コード上の「int 3」

コード上の「int 3」

目次へ

 この記事を読んでおられる方は、IDA Proをはじめとしたデバッガを使われている、もしくは基礎知識がある方が多いかと思います。そういった方々がピンとくると思われるのが、この「int 3」です。

 デバッガでデバッグをするときには、「ブレークポイント」を設定して実行していくことが基本となり、今回の記事を書くための調査でも多用しています。そして、「int 3」は、そのブレークポイントを設定するために、ブレークポイントを設定した位置に一時的に設定される値です。デバッガは、「int 3」の割り込みで一時停止し、再開するときは「int 3」の位置のコードを元のコードに戻して実行します。

 さて、今回Explorer上の解析を行っているときに、不意に「int 3」に当たってしまうケースがありました(【図92】参照)。私はこれを見たとき、ここの本来のコードではないことは明らかで、ランサムウェアにアンチデバッグのためのコードが仕込まれているのか?と思いました。しかし、これはよく考えてみると、デバッガによる調査の影響であることに気づきました。

 理由は、Explorer上のメモリに、「ransom.exeで再展開されたメモリ上のコードをコピー」したことにあったのです。そのため、「自身が設定したブレークポイント(int 3)が残った状態」でExplorer上のメモリにコピーされてしまい、Explorer上のCryptoWallの解析中にint 3にヒットしてしまった、というのが真相でした。これを回避するには、「メモリのコピーのタイミングで、全てのブレークポイントを解除する」必要があったのです。

 実行中のメモリ領域をコピーする、という時点で気づくべきと言われればそれまでで、今回の私の恥ずかしいドジの一つです。これは、デバッガの仕組みを知らないと気づけない原因でしたので、参考までにここで触れておきます。

IDA_Cryptowall_int3_1

【図92】コード上の不自然な「int 3」

 

 また、こういった場合、データを書き換える方法で、コードを戻すことも可能です。これについては、アセンブラコードについて予め調べておく必要があります(行う作業が、ハンドアセンブルに近いものになります)。

 今回の例では、当該箇所に「int 3」にあたる0xCCが設定されています。しかし、ここのコードは、本来「call edx」であるべきです。と、なると、この0xCCの箇所が0xFFであれば解決するように見えます。そこで、Hex Viewの「Edit」機能を用いてパラメータを修正してみましょう。

 まず、Hex Viewで右クリックし、ポップアップメニューを表示して「Edit…」をクリックします(【図93】参照)。

IDA_Cryptowall_int3_2

【図93】Hex Viewのポップアップメニュー

 

 そして、修正したい箇所にカーソルを合わせ、パラメータを入力します。今回は、0x00069653の0xCCを0xFFに変更しています。編集が終わったら、再度ポップアップメニューを表示して「Apply changes」をクリックします(【図94】参照)。

IDA_Cryptowall_int3_3

IDA_Cryptowall_int3_4

【図94】Hex Viewの編集と結果の反映

 

 「Apply changes」の後、当該箇所をIDA Viewで見ると、「int 3」だった箇所が正しく「call edx」に置き換わっていることが確認できます(【図95】参照)。このようにしてパッチを当てることで、プログラムを修正し、処理を続行することができます。

IDA_Cryptowall_int3_5

【図95】「int 3」が「call edx」に修正された結果

 

 

< svchostの起動とVolume Shadow Copyの消去 目 次svchost上のImportテーブル >