RAMイメージをクラッシュダンプにコンバート
mddやwin32ddでダンプしたメモリイメージを、クラッシュダンプ形式にコンバートすることができた気がしたのですが、どのツールが対応していたのかを失念...思い出した、Volatility Framework に含まれる raw2dmp ですね。
昨年末に試していて手元ではうまく動いてくれなかった気がするので再度試してみなければ。
ということで、まずは win32dd でメモリをダンプ。
[win32dd] Lets dump it!
[win32dd] Destination: \??\C:\temp\win32dd.1.2.20081105\physmem.bin
[win32dd] Processing.... Done.
[win32dd] Physical memory dumped.
Time elapsed is 861 seconds.
[win32dd] Leaving...
なんか妙に時間がかかっているところが気になるわけですが、それは置いておいて raw2dmp でコンバートを開始。
C:\>c:\temp\Volatility-1.3_Beta\volatility raw2dmp -f c:\temp
\win32dd.1.2.20081105\physmem.bin -o c:\temp\physmem.dmp
c:\temp\Volatility-1.3_Beta\forensics\win32\crashdump.py:31: DeprecationWarning:
the sha module is deprecated; use the hashlib module instead
import sha
Convert: 100% |||||||||||||||||||||||||||||||||||||||||||||||||| Time: 00:01:28
うまくコンバートできた様子なので、これを WinDBG で読み込ませてみてどうなるかですね。
Loading Dump File [C:\case\Evidence\physmem.dmp] Kernel Complete Dump File: Full address space is available Symbol search path is: SRV*c:\WINDOWS\symbols*http://msdl.microsoft.com/download/symbols Executable search path is: Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86 compatible Product: WinNt, suite: TerminalServer SingleUserTS Built by: 2600.xpsp_sp2_rtm.040803-2158 Machine Name: Kernel base = 0x804d9000 PsLoadedModuleList = 0x8055e700 Debug session time: Tue Jan 6 11:12:00.687 2009 (GMT+9) System Uptime: 0 days 20:42:33.372 WARNING: Process directory table base 0A480380 doesn't match CR3 00AD7000 WARNING: Process directory table base 0A480380 doesn't match CR3 00AD7000 Loading Kernel Symbols ............................................................... ............................................... Loading User Symbols ........... Loading unloaded module list .......... Unknown exception - code 00000000 (first/second chance not available) ******************************************************************************* * * * Exception Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. *** ERROR: Module load completed but symbols could not be loaded for win32dd.exe ************************************************************************* *** *** *** *** *** Your debugger is not using the correct symbols *** *** *** *** In order for this command to work properly, your symbol path *** *** must point to .pdb files that have full type information. *** *** *** *** Certain .pdb files (such as the public OS symbols) do not *** *** contain the required information. Contact the group that *** *** provided you with these symbols if you need this command to *** *** work. *** *** *** *** Type referenced: kernel32!pNlsUserInfo *** *** *** ************************************************************************* ************************************************************************* *** *** *** *** *** Your debugger is not using the correct symbols *** *** *** *** In order for this command to work properly, your symbol path *** *** must point to .pdb files that have full type information. *** *** *** *** Certain .pdb files (such as the public OS symbols) do not *** *** contain the required information. Contact the group that *** *** provided you with these symbols if you need this command to *** *** work. *** *** *** *** Type referenced: kernel32!pNlsUserInfo *** *** *** ************************************************************************* Probably caused by : win32dd.exe ( win32dd_400000+10400 ) Followup: MachineOwner
んーなんか WARNING メッセージの部分とか気になるのがありますが、WinDBG へのロード自体は可能な様子ですね。
取得する範囲と探す対象
メモリイメージの解析でどこまでの情報をダンプするとより正確に調査が可能になるか？という点はあまり議論されているのを見たことがないのでそのあたりの話題も興味あるところです。
フォレンジック話を始めることにした。
http://d.hatena.ne.jp/xna/20090105/1231153156
現状、メモリダンプを行う場合、Pagefile.sys は置き去りになっていたりします。ページアウトされたデータは Pagefile.sys にあると思いますので、そっちが無い状況で解析時にどこまで影響があるのかは個人的に素朴な疑問だったりします。もちろん HBgary の FastDump(FDpro)ではメモリダンプ取得後に Pagefile.sys も保全する機能が追加されてきたりしますので、今後は対応は進んでいくことが予想されます。*1
あと、個人的には違和感があるのですが、現状どうしてもダンプした後のお話としては rootkit やマルウェアの検知や解析ということがメインの機能として扱われています。しかし、個人的には何が隠されていたのか、隠されていたプロセスなりが持っているデータの内容に興味がありますし、メモリから取得できるデータとして各プロセスの持つデータの方が重要なのではないかという考えでいます。
あまり良い例ではないですが、例えば電子メールを調べたいと思った時に、電子メールプログラム自体の動作を解析したいわけではなく、送受信されたデータ（メール）の内容の方が重要って言えばいいんでしょうか。
そういえば、電車に乗りながらぼんやり考えていたのですが、プロセスのメモリ（プロセスの仮想メモリって言えばいいのかな？）をダンプした場合、例えば Notepad.exe のプロセスをダンプすると 4GB とかファイルが出来上がります。これはこれでよいとして、その読み出しにより物理メモリ上のデータにはどこまで影響が出るものなのかが気になっているところです。
手順的には物理メモリのダンプを先に実施してから、気になるプロセスのメモリをダンプしないと、上書きされるなどして失われるメモリ情報が多くなるんでしょうかね？
*1:現状はとりあえず保全だけでメモリイメージとPagefile.sysを合わせて解析はこれからなのかな？
門外不出って英語で言うと何？
はなずきんさんの書かれた記事。
第2回 「門外不出」のセキュリティ系勉強会
http://jibun.atmarkit.co.jp/lcom01/rensai/zukin/02/01.html
まぁ勉強会とかセミナーでお話された内容を参考に、実際に不正アクセスとかしちゃう人は最近はいないと信じたいところですが、不正アクセス禁止法についてなんかすごい解釈論とか昨年に出てた気がするので、そうでもないのかもしれませんね。悪意があってやったわけでなくてもダメですからねぇ。有償のセミナーでもセキュリティ関係では悪用しません的な書類にサインを求められることがありますが、急に誓約書にサインしろとか言われると驚くかもしれませんね。
こんな風にすれば悪用できちゃうとかをBlogとかに書くのはアレなわけですが、勉強会であればそのシナリオに対してはここがダメとかこうすれば的なディスカッションがなされると思いますので、単に攻撃的なお話だけでなくいかに防ぐかとか限界を知るとかの意味でも色々と面白い気がします。少なくとも自分はひっかからないように注意しようという気になるかも（笑）
ただ、それを参加レポートとかで書くときっと「もっとこうすればより効率的に攻撃が可能になると○○さんが発言」とかになるんですかね？（嘘）
