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

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

サポート情報

ホーム > サポート情報一覧 > 仮想メモリ内の難読化

仮想メモリ内の難読化

目次へ

 では、仮想メモリに展開されたプログラムの内容の追跡に移りましょう。事前に注意事項が1点あります。調査についても、記事を書くにあたっても、プログラムを何度も停止と再実行を行っています。当然、その度にVirtualAllocが発生し、そのメモリ上にプログラムが展開されるわけですが、このVirtualAllocの返すアドレスが、毎回一致するとは限りません。そこで、メモリ上のプログラムのアドレスは、取得できたメモリの開始位置をベースアドレスとし、そこからのオフセットで表記するものとします。表記方法は、便宜的に[00000]と、[]カッコでくくり、中に16進数5桁のアドレスを記述します。

 メモリ内部の処理に移行すると、その処理の開始位置の部分に実行コードがあります。このコードは、先に述べたとおり、メモリに展開されたあと、変換をかけられて初めて表示されました。しかし、メモリ内部のプログラムに対しAnalyzeをかけると、メモリの上位のコードが解析できません。これは何故でしょうか?解析を進めてみると、難読化のため、実行しているメモリ上の上位の値に対し、さらに入れ替えをしていることが判明しました。step intoで処理を進めていくと、[0001E]に妙な処理があります(【図42】参照)。

CryptoWall_IDA_Step013

【図42】[0001E]の不審な処理

 

 ここで演算の対象になっているのは、今行っている処理を呼び出した[00016]のコールでの戻りアドレスです。これに対し演算を行うということは、callの戻りアドレスを変える、ということになります。処理はsubで減算ですが、値が0xFFFFFF86となっており、一周することを考えると、実質0x7Aの加算ということになります。加算の結果は[0001B]+7Aのため、[00095]となります。では、この0x0012FDF8の4バイトの値に注意して解析を進めましょう。

 さらに処理を進めると、call [0003E]が行われます。注目すべきは、この先の[00048]の「mov esi, [ebp+8]」です(【図43】参照)。これを実行すると、先ほどの0x0012FDF8に格納されたアドレスがesiに格納されるのです。さらに、ediもesiの値と揃えています。esi、ediはデータ移動時のソースアドレス、ディスティネーションアドレスとして用いられることが多いですから、どうもデータ移動の下準備のように見えます。この解析では、ともに[00095]になっています。

CryptoWall_IDA_Step014

【図43】esiにスタックの値が設定されている状況

 

 さらに処理を進めていくと、[00064]にlodsb、[0006B]にstosbがありました(【図44】参照)。これは、それぞれesiから1バイトをALに格納する処理、ediに1バイトをALから格納する処理です。そして、この間に「xor eax, ebx」を行っています。これにより、[00095]の値が変換されることが分かります。これを、[0005C]の条件で合致するまで続けられます。つまり、[00095]以降のデータが0x2A4C=10948バイト書き換えられることになります。xorの対象となるebxの値も、毎回演算で変更されており、暗号化のOFBモードのようなことを行っています。

 実際に、再実行してこの処理の前後のメモリ状態を確認してみます。やはり、[0002B]のcallの前後で、[00095]以降のメモリが書き換えられることが確認できます(【図45】参照)。このようにして、メモリに展開された後も、今後自身が実行するプログラムの領域を動的に変換していたのです。この手法は処理内で使用するAPIの文字列の復号化にも度々用いられており、プログラムの全容の把握を困難にしています。解析においては、call [0003E]は要注意と言えます。

CryptoWall_IDA_Step015

【図44】lodsb、stosbとその間のxorによる変換

 

CryptoWall_IDA_Step016

【図45-1】変換前のメモリ情報

 

CryptoWall_IDA_Step017

【図45-2】変換後のメモリ情報

 

< 仮想メモリ取得した方法の正体   目 次 仮想メモリ内のWindows APIの使用 >