●「Debugger」メニュー
本製品の大きな特徴である、デバッガ機能です。
この機能を使うにあたり、最初にちょっとコツがあります。検体を読み込んで分析が終わった直後では、下図のような画面になるはずです。
「Select debugger...」だけで、他にメニュー項目が出ません。これは、検体を実行するデバッガを選択した後に、そのデバッガの各機能が使えるようになるためです。
「Select debugger...」をクリックすると、下図のようなダイアログが表示されます。
利用可能なデバッガが表示されます。それぞれのデバッガの特徴を把握して使い分けできればいいのですが・・・今のところ、「Local Windows debugger」以外は使ったことがないですね。これで今まで困ったことがない、というのが正直なところですが、そのうちそれぞれの違いを確認しておきますかね。
「Local Windows debugger」を選択してOKを押すと、メニューが下図のように変わります。
「Start Process」は、実際にプログラムを実行します。いきなり実行すると、本当にそのままマルウェアが実行されるので注意してください。
通常は、ある程度静的解析をして、目星をつけてブレークポイントを張って実行します。ただし、ルートの見落とし、予想外のジャンプ（Exceptionなど特に）は往々にして発生します。
そのため、以下を強く推奨します。
- 解析環境は、仮想環境を使う。もしマルウェアがうっかり実行されても、環境を戻してなかったことにできる。
- 仮想環境は、可能ならスナップショットが取れるものが望ましい。都度VMをコピーして取っておくのは結構な作業ロス。
- 通信は繋がらない状態にしておくこと。
考えれば分かる、もしくはそんなこともう知っている（自分が前にも記事に書いている）とは思いますが、大事なことなのでしつこく書いておきます。
仮想環境を使うのは、マルウェアが不時動作しても、解析環境を守るためです。クラッシュして、その度にOSから再インストールしていては、とてもじゃないですが解析になりません。もちろん、ちょっと知っている人は、「解析回避のためにVMを回避しているマルウェアがあるから」と思うかもしれません。確かにそういうマルウェアはありますが、デバッガを使った解析で、「VM回避技術」を回避して進めることが可能です。少なくとも、私が解析した検体でもVM回避技術を見られましたが、VMかどうかの判定をTrueからFalseに逆転させてマルウェアを騙すことで、問題なく解析を継続することができました（秘技：犯罪者なんぞ騙してナンボ）。
また、通信も、C&C他攻撃者のサーバと通信することになるので、基本的にはおススメしません。
もちろん、マルウェアが動作するうえで、C&Cと通信してデータを取得しないと、続きが解析できないものがあります。また、マルウェア解析のサンドボックスによっては、実際にC&Cサーバとの通信も行って解析をしている、といわれている製品もあるそうです（どこの製品とはここには書きませんが）。そういった場合、確かに通信は必要といえば必要なのですが。
しかし、ここの記事を読みながらチュートリアル的にやってるレベルの人は、冗談抜きでまだ早いので、やめたほうがいいです。
場合によっては、攻撃者にこちらの情報を教えてしまいます。マルウェア次第ですが、マシン名や環境情報だけでなく、送信元のIPアドレスだって含まれています。マルウェアとしようとしている通信、Torを経由するなどといった細工はしていますか？（もっとも、最近はTorの出口ポートからの通信だと遮断してくるサーバもありますけどね。とあるフィッシングサイトは、Torで参照すると、ページも見れず、マルウェア感染もしませんでした。Torの出口ノードを日本にしてもダメだったので、単純にIPアドレスからのロケールで遮断しているわけではないことは確定でした。しかたないので、そういう時はリスクを勘案して使い捨てSIMの携帯のテザリングなどで。木を隠すなら森の中・・・。）
マルウェアとC&Cとの通信は、どこでやっているかを見極めてからやらないと危険なうえ、意味がないこともあります。例えば、マルウェアとC&Cの通信を記録しておくことで再現性を持とうと、Wiresharkで通信を記録していたとします。しかし、最近のマルウェアは、C&Cとの通信で暗号化を用いています。こういうときに、ご丁寧に乱数を使って都度鍵を作っていたりします。つまり、ちゃんと解析して、この鍵（しかも、一つとは言ってない）を記録した上で通信しないと、鍵が分からないWiresharkの通信記録はただのジャンクデータになります。
C&Cの通信も含めた解析をするなら、このあたりは見切れてからすべきではないでしょうか。
最初のうちは、REMnuxをVMでもう一つ立ち上げて、fakednsやinetsim、accept-all-ipsあたりを使って、どんな通信の振る舞いをしているかをよく観察したほうがいいと思います。
「Step into」と「Step over」は、１ステップ実行します。違いは、「call」をステップ実行した際、「Step into」はcallの中にEIPを移動するのに対し、「Step over」はそのcallの処理を実行して、リターンしてきたところで止まります。ここの使い分けは大事なので注意してください。「Step over」で進めると、その中の処理で重要な処理をしたり、別スレッドや別プロセスを立ち上げても見逃すことがあります。一方、全て「Step into」にしてしまうと、追う必要がない細かな部分まで見ていくことになり、効率が下がります。どちらを使うかは、解析の状況や目的によりケース・バイ・ケースになるので、考えながら（悩みながら）使っていくことになります。
また、「Run until return」は、現在実行している関数が終了してリターンするまで実行します。
また、デバッガでよく使う画面は、「Debugger windows」でウィンドウを追加して表示することができます。
特によく使うのは、「General registers」ですかね。デバッグ開始時に自動的に開きますが、うっかり閉じちゃって開きなおすときなどはここからです。MMX、XMMレジスタはあんまりみたことないです。ランサムウェアのときにAES-NIの命令を使ってる検体のときにちょっとだけ見たかな、程度ですね。
それ以外のサブメニューは以下のとおり。名前でだいたいのイメージをしていただければ。ちなみに、私はトレース機能をあんまり使えてないです。詳しい人いないかなぁ。
ホントはまだ書くことがあるのだけれど、長くなったのでとりあえず次回に。