タグ

WinDbgに関するodawaraのブックマーク (9)

  • 第13回 カーネル・モードで動くマルウエアを自動解析 --- FFR GreenKiller

    フォティーンフォティ技術研究所 先端技術研究部長 村上 純一 2009年11月4日から6日にかけて,京都でAVAR(Association of anti-Virus Researchers)国際会議2009が開催された。AVAR国際会議は,名称の通りウイルス対策ソフト・ベンダーが中心となり,最新のマルウエア技術,犯罪事例などについて意見交換することを目的としたカンファレンスである。 幸運なことに,このカンファレンスで研究成果の一部を発表する機会を得た。今回は,発表内容である「FFR GreenKiller - Automatic kernel-mode malware analysis system」について紹介したい(発表スライドはフォティーンフォティ技術研究所のWebサイトで公開している)。 カーネル・モードで動作するマルウエア 連載で紹介してきたように,近年はルートキットを含め,

    第13回 カーネル・モードで動くマルウエアを自動解析 --- FFR GreenKiller
  • Rootkitのようなデバイスドライバファイルを回収するツール - やや温め納豆

    デバイスドライバがカーネルにロードされたタイミングで、そのファイルをバックアップコピーするデバイスドライバを書いてみました(drvcopy.cab)。よければどうぞー。 マルウェアは、往々にしてデバイスドライバを使ってきます。デバイスドライバを動的に生成し、カーネル空間にロードさせます。有名なことですが、一度ロードされたドライバは、ディスク上から削除することができます。そして、デバイスドライバを使うマルウェアは、痕跡を消すためにかなりの割合で、自身が生成したデバイスドライバをディスク上から削除してしまいます。 削除されたドライバはProcess Explorerなどで確認すると一見してわかります。 デバイスドライバのファイルが削除される前に回収するには、デバッガで生成元にアタッチし、CreateServiceをブレークすることでディスク上にある状態で停止させることができます。 ただし、この

    Rootkitのようなデバイスドライバファイルを回収するツール - やや温め納豆
  • NT_ASSERTマクロ - やや温め納豆

    ドライバ開発の際には従来広くASSERTマクロが使われているが、最近のWDKではASSERT定義周辺に、NT_ASSERTというマクロが追加されている。このマクロは現時点では文書化されていないものの、ASSERT Yourself - The New NT_ASSERT Macro in the WDKにおいて、詳細に独自研究されている。 ここでは以下にこの文書の要約を示す。 ASSERTと同じ点 DBGが定義されていなければ(つまりFree Buildであるならば)完全に消去される。 渡した条件式がFALSEになるとカーネルデバッガにトラップされる。 その状況でカーネルデバッガが接続されていないとBSODになる。 ASSERTと異なる点 __annotation組み込み命令を使い、条件式中の文字列をPDB側に埋め込む(バイナリには埋め込まない)。 Vista以降でしかトラップ(ブレーク)

    NT_ASSERTマクロ - やや温め納豆
  • WinDbgでコードパッチを簡単に検出する - やや温め納豆

    !chkimgコマンドを使うと、コードパッチを簡単に検出することができる。以下の実行例では、ntカーネル(ntoskrnl.exe)に10byteの改ざんがあること、それらが5byteの改ざん2つ(そして関数フック)であることを確認している。 C:\>livekd ... 0: kd> .exepath c:\windows\system32 Executable image search path is: c:\windows\system32 Expanded Executable image search path is: c:\windows\system32 0: kd> !chkimg nt 10 errors : nt (8332b2d0-8332b349) 0: kd> !chkimg -d nt 8332b2d0-8332b2d4 5 bytes - nt!InbvSol

    WinDbgでコードパッチを簡単に検出する - やや温め納豆
  • 細かいWinデバッグテクニックのメモ - やや温め納豆

    (12/05)追記したら記事の方向性がわかりやすくなったのでタイトルも変えた(笑 UserDebuggerHotKey GUIアプリケーションに対してデバッガがアタッチしているとき、このレジストリキーで設定されたキーを押すと、ブレークが発生しデバッグすることができようになる。環境によってはできないこともあるみたい? .ocommand (WinDbg) WinDbg上でプロセスにアタッチする .ocommand メタコマンドを実行する 以後 OutputDebugString のプレフィックスに がついているものは 以降がWinDbgコマンドとして解釈される 残念ながら、カーネルランドでは利用できない。 指定したプロセスの起動を置き換える(MSDN) HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution

    細かいWinデバッグテクニックのメモ - やや温め納豆
  • main が呼ばれる前に実行されるコードのコールスタック - やや温め納豆

    プログラムのエントリーポイントは、main関数ではなく、PE内に定義されたアドレスであることはよく知られているが、それより以前にコード実行できるTLS Callbacksという仕組みはあまり知られていない。 TLS CallbacksはPE内に適切にセクションとディレクトリテーブルを作り、そのテーブルにコールバック関数のアドレスを設定しておくと、イメージローダー(ntdll.dll)によるプロセス初期化処理中に、その関数が実行されるという仕組みである。 この関数の呼び出しをブレークするのは、PEを解析して手動でブレークを置いたり、対応しているデバッガ(OllyDbg 2.0)でブレークをかけたりなどの方法があるが、呼び出しのシーケンスを把握しておいた方が、いざというとき小回りが利くので調べてみた。 調査には、このコードを使用した。このソースには以下の関数呼び出しが含まれている。 C++グロ

    main が呼ばれる前に実行されるコードのコールスタック - やや温め納豆
  • wdk 7.0 windbg over network - Google 検索

  • ieee1394 expresscard windbg - Google 検索

  • WinDbgを再起動する - やや温め納豆

    目的としてはVMwareの仮想シリアルポートでも書かれているように「WinDbgの再起動が面倒くさいよね、なんとかしたいね」というところ。 再起動させるスクリプトでも書いてしまえば良さそうなのだけれど、例のごとくDLLで実装して、メッセージフックでシステムワイドに配信するようにしてみた。フックによりDLLをロードしたプロセスはウィンドウメニューが拡張され、再起動コマンドが利用できるようになる、というもの。 ……が、この欲張りさんな実装が失敗のもとらしい。アプローチとしては以下のスクリプトを生成し、第一引数にイメージパスや引数を与えて起動させる。 WScript.Sleep(100) WScript.CreateObject("WScript.Shell").Exec(WScript.Arguments.Item(0)) WScript.CreateObject("Scripting.Fil

    WinDbgを再起動する - やや温め納豆
  • 1