Next Step

「Analyzing Malware」を一通りやり終えた。かなりやさしい説明で書かれているとはいえ、それでも一元さんには難しい内容で、この本を完全にマスターするには次のものをきちんと理解している必要があると感じた。上から優先度高。

• Win32 API
• 機械語, アセンブラ言語 (x86)
• PEフォーマット
• OS Kernel
• コンパイラ

...Windows PCの仕組みをまるっと覚えなさい、ということですね、わかりますん。というわけで、このAnalyzing Malwareを基幹にして以下の本に触手を伸ばしていこうかと思っています。実はいくつかはもうすでにチェックしていたりします。技術本の理解はとても大変であるということが身にしみた一方、だんだんとわかる範囲が広がっていくことの実感も楽しめるようになりました。上半期を目標にMalware解析が始められるようにしたいと思っています。

Win32 API

本はたくさんあるし、Webにも情報がたくさんありますね。実践を積むにはプログラミングをしていくしかないかと思っています。

APIで学ぶWindows徹底理解 (日経BPパソコンベストムック)

一通り読みました。Win32 APIで知っておくべき必要十分が書かれていて、入門編として最適かとおもいました。もう一度熟読したい。ただ、このほんの大きさは何かと不便です。A4にまとめて再販希望です。

Windowsはなぜ動くのか

購入リストの本。Win32 APIに関わらずWindows Overallとしてよさそう？

機械語、アセンブラ

新しい本は少ないですが、昔いやというほどテーマになった分野なので、情報は豊富。実践をどのようにこなしていくかが課題だと思っています。

x86アセンブラ入門―PC/ATなどで使われている80x86のアセンブラを習得 (TECHI―Processor)

今読んでいます。x86のアセンブラについてここまで丁寧に説明されている本は今は珍しいのではと思います。やはり本の大きさが難。

はじめて読むMASM―ソフトウェア環境のからくりを学ぶ

一通り読みました。時代が古いので実践に移す環境づくりが難しそうでしたが、x86 PCのアーキテクチャのコンパチビリティを知ることができる歴史的価値のある本だと思いました。

独習アセンブラ

購入検討本。実践でアセンブラを身に着ける方法を模索中で、見つかったら買わないかもしれません。

PEフォーマット

テーマにした本は今確認していません。Webでフォローできるのではと考えています。
下の記事がとても素敵だと思いました。
http://codezine.jp/article/detail/412
http://codezine.jp/article/detail/403?p=1

MSDNのサイトではPEフォーマットのスペックも配っています。
http://msdn.microsoft.com/ja-jp/windows/hardware/gg463119

OS Kernel

やるのは、WindowsなのでできればWindows OS Kernelのソースコードがあれば・・・なのですが、もちろん開示しているわけもなく、Linuxの技術書で行くしかないですよね。ただ、Kernelの基礎の理解、イメージ作りは重要ですが、今回の目的の直接的な知識の習得にはならないかもしれません。

詳解 Linuxカーネル 第3版

Linuxカーネル2.6解読室

あとは、FreeDOSというDOSコマンドを利用できるOpen OSのソースを解読していくのもいいかと思いました。ちらっとみましたが、16bit OSでもハードルが高そう。
http://www.freedos.org/

コンパイラ

これはおまけですね。上のが理解できればあまり深くやる必要はないかと思っています。

ふつうのコンパイラをつくろう

こんな感じですかね。ある程度体系だてて効率よく学習をしていく必要性を感じています。あくまでもAnalyzing Malwareの補足になることを忘れないようにして・・・（脱線も楽しいのですが）。このプロジェクトとは別に、暗号化の理解と、Pythonも学習していきたいと思っています。うーん、ちょっと大変だぞ。

MSFCONSOLE がうまくいかない話 [未解決]

PDFファイルに実行ファイルを埋め込めるという触れ込みのMSFCONSOLEがHJの11月号で紹介されていた。ちょっくらためして見るかとBlack Track5をInstallして実行してみたもののうまくいかないでやんの。
エラーメッセージは後で貼る。

WindowsXP

いやー、焦った。現在トリプルブートの環境でセキュリティ系の実験をしているんだけど、Linux用のパーティションのOSを入れなおしたとたんWindowsに入れなくなってしまった。

表示されたメッセージがこちら。

Windows could not start because the following file is missing or corrupt.
Windows root\system32\hall.dll.
Please re-install a copy of the above file.

Windowsを入れたてならまぁ、上書きインストールしてもいいんけど、いろいろ入れた後だったからどうしても復活させたかった。いい加減Full Installで解決っていうのも卒業しなきゃだし。

解決は、WindowsのBoot.iniでした。しかもこのファイルはWindowsのBoot専用パーティションに入っているので、修正しにいくのはちょっと大変。簡単な方法はCD ブートしたLinuxファイルからWindowsのブートパーティションをマウントする方法。
Windows XPを入れた人はNTFS形式のパーティションが2つあるはず。そのうちの「入れた覚えのない」ほうにアクセスすると、boot.iniがあるはず。

これを編集する。あけると次の行がみえるはず。

default=multi(0)disk(0)rdisk(0)partition(6)\WINDOWS

このpartition(X)の数値の部分を（多分）、入れた覚えのある法のNTFS形式のパーティションを指定すればいいはずなのだ。
この作業で必要になってくるのがパーティションの番号で、Dual Bootするのはきちんとどの番号にどのOSが入っているのかをメモしておくととても助かります。

Immunity Debugger メモ

Malwareの解析で大活躍の Immunity Debugger について、3.2.3を終えて理解し始めたことメモ。

• Breakpoint condition でBreakpointを設定するための条件文を追加することができる。
  • STRINGESP+4=="\\\\.\\Global\\ProcmonDebugLogger"
  • この条件文で設定したポジションのときのレジスタの値でBreakするかどうかを設定している。この文字列だったらBreakするという意味
  • その後、Debugメニューの"Execute till return" をすることで、関数が帰るところまで進めることができる。そのときの戻り値(EAXに代入される値)を変更する（検出された返り値から未検出の返り値[0xFFFFFFFF]）ことによって、Malwareの解析を回避している。

3章 動的解析を妨害するマルウェアの解析 その２

アナライジング・マルウェア ―フリーツールを使った感染事案対処 (Art Of Reversing)

「3.2.3 動的解析ツールが利用するデバイスファイルを検出する方法」終了。

レポート

サンプルコード detect_devicefile.c −　著者のサポートページより

• コードのサマリー
  • Malwareが自分がDebugされることを避けるための手法に、解析ツールで用いられるデバイスファイルの検出がある。ここでは　Process Monitor　　（\\.\Global\ProcmonDebugLogger） を検出するサンプルプログラムを例としてあげている。
• 問題　（2012/02/11）
  • 前回（3.2.2）同様、ここでImmunity Debugを利用しているにも関わらず、例として示されているデバイスファイル（\\.\Global\ProcmonDebugLogger）が検出されない。ググッてみたもののこのデバイスに関する情報が得られず。
  • そこで、以下のようにやり方の変更してこの項目をすすめた。
    • 解析の練習をやりたかったので、代わりのデバイスファイルを検出するようにサンプルプログラムを改変し、それを回避するようにした。この試み自体は成功。
    • 変わりに検出するようにしたデバイスファイルは　"\\.\C:" そう、Cドライブですｗ

WindowsのOSの仕組みをもっと勉強すべきだと、この本を薦めるたびに痛感しています。。。

3章 動的解析を妨害するマルウェアの解析

アナライジング・マルウェア ―フリーツールを使った感染事案対処 (Art Of Reversing)

ブログに書くと時系列がまとまらなくなりそうなので、Google Siteを使ってみることにしました。引き続きこのブログもへいようしてみます。日記でも書こうかなぁ。

• 3.2.1 プロセス一覧から動的解析用のツールを探し出す方法 - Beyond 0xFF
• https://sites.google.com/site/beyond0xff/test/3-2-2-u-indouwo-jian-chusuru-fang-fa

実はこの本自体は一通り読み終わりました。あとはコードを実際に走らせて見ていろいろ挙動を確認してレポートしていこうと思っています。この本の内容を理解できればかなりのスキルアップにつながると思ってがんばっています。

「Analyzing Malware」２章 パックされているマルウェアの解析 俺的備忘録

アナライジング・マルウェア ―フリーツールを使った感染事案対処 (Art Of Reversing)

２章を一通り読み終わりました。備忘録的にまとめてみます。

PEファイルフォーマット
Windowsのexeやdllなどの実行ファイルで用いられているフォーマット。この形式を知らずしてMalwareを語ることなかれ、というぐらい重要みたい

• PEファイルフォーマットはwinnt.hで定義されている
• 仕様書がMicrosoftより公開されている。→
• 仕様書や実技を何度も繰り返してファイルフォーマットへの慣れが必要っぽい

アンパックのながれ
1. デバッガでOEPまで実行する
いくつかテクニックがあるとのこと

• pushadに対応するpopadに着目する
• 動的に生成されたエリア（圧縮されたデータの展開されたエリア）への制御が移動したところに着目
• jmp/call命令に着目する

2. OEPが見つかったらメモリのダンプ
3. IATの再構築　IATはローダによって書き換えられているので、ロード前の値に修復する

アンパックを妨害するテクニック

• Stolen Bytes　動的に確保された領域にオリジナルコードの一部分をコピーしたコードの実行後、元のコードを続けて実行する。メモリダンプの習得を妨害する
• SizeOfImageの改変　PEヘッダ内のOptionalHeader構造体に含まれる値。メモリにロードされるファイルのサイズを示す値で、異常に大きい値をいれることでデバッガのアッタチやメモリダンプを妨害する
• Import Redirection　IATの再構築時や、逆アセンブラでの解析時にImport中のAPIをわかりにくくする。レジスタにアドレスを格納してJump命令で読み出すなどすると、Call命令の読み出しと違いAPIの情報がとりにくくなる。

２章読み終えた時点ですでに理解がおいつくのが大変です。何べんも読み直してマスターしていきたいと思います。