2008-11-23

第1回ローレイヤー勉強会いってきた

NTKRNL

Windows カーネルハックというネタでしゃべってきたのでその資料をアップ（llbenkyo1_win.cab）。よく知っている人には「それはどうなのよ」というところがあると思うので、その辺は突っ込んでもらえるとうれしいです。

以下にデモごとの主要な動作・コンセプト等を列記します。このデモは実行すると青画面になる可能性が高いので悪しからず。

loader00    CreateService + StartServiceによるドライバのロード/アンロードツール
loader01    NtSetSystemInformation(SystemLoadAndCallImage, ...)　によるロードツール
loader02    一見sysファイルがない状態から、内蔵のカーネルモジュールを密かに展開してロードする
            （読み込まれたカーネルモジュールによりこのプロセスは隠蔽される）
            レジストリでカーネルモジュールに必要な値を渡したり、
            カーネルモジュールのロードが完了したらディスク上から削除するなどしている
example00   DbgPrintを使用してDebugViewにデバッグ出力
example01   特権命令（ここではrdmsr）を使用する
example02   writemsrでsysenterフック
            ただしDriverEntryが実行されたプロセッサのものだけフックしているので、
            アンロード関数がDriverEntryとは別のプロセッサで実行されると死ぬ
example03   すべてのプロセッサでのsysenterフック版
            カーネルデバッガを接続しているとなぜか死ぬ。たぶん出力データが多すぎる。
example04   KeServiceDescriptorTable（システムサービスへのアドレスの配列）を列挙
example05   KeServiceDescriptorTableのアドレスを交換して任意の関数に置き換える
            ここではプロセスの生成・終了に関する関数をフックする
example06   関数の先頭2byte+とその後方5byteを書き換えて任意のコードを実行させる（detourフック）
            ここではNTFSアクセスチェックの実装である SeAccessCheck と
            ファイル名のマッチング処理の実装である FsRtlIsNameInExpression が対象
            本来はすべてのプロセッサの一時ロックのうえでフックするのが安全（gain exclusivity）
example07   関数が参照するデータ構造体を直接書き換えることで、関数の結果にも影響を与える（DKOM）
            EPROCESSとMODULE_ENTRYのリンクリストを操作してプロセスとカーネルモジュールを隠蔽
            これも本来はすべてのプロセッサの一時ロックを必要とする
brute_force
            プロセスIDやスレッドIDをインクリメントしながらopenすることで
            隠蔽されたプロセスを検出する（結果の差異による検出例）
            特に面白いこともないので、ここでは検出までは実装していない
HookDetector
            ポインタの変更によるフックの検出
            HookDetector.sys を読み込ませてから -std -stds などの引数を渡してチェックする
              >loader00 HookDetector.sys
              >HookDetector.exe -std      <- フックされてない
              >loader00 example05.sys
              >HookDetector.exe -std      <- フックされてる
            途中で放棄したソースの再利用なので完全に魔窟
xp_080526.txt
xp_080527.txt
            とあるセキュリティツールをインストールする前後のKeServiceDescriptorTableの状態

Windowsの仕組みやAPIを理解するにあたっては以下の書籍がおすすめです。

APIで学ぶWindows徹底理解（「価格に比して」内容が良い）
Advanced Windows
インサイド Windows
Rootkits: Subverting the Windows Kernel

インサイド Windowsの上巻はこの中でも特にオススメです。1月にVista対応の新版(英語）が出るはずなのでそれ待ちもあり。

また、話のネタは2005年ぐらいまでにすべてまとめられていたりしていて、特に目新しいものではないです。きっちり勉強したい方は上記Rootkits: Subverting the Windows Kernelを買うと良いです。

2008-11-23

Vistaの起動を最適化してみた

Microsoft

せっかくVista搭載の実機を買ったのだし、Windows Performance Analyzerを使って起動を最適化してみた。細かい手順は以前の記事のとおり。速くなったんじゃないかな、たぶん。

以下の画像は最適化前後のディスク使用率。記録時間全体から見て特徴的なのは、140sec-200secの間のディスクIOが激減していること。

この期間のIOの内訳を見ると、svchost.exeのIOが減少していて、readが2/3、writeが1/3の時間で完了していた。$Mftに対するread時間が1/5（これだけで実に７秒減！）になるなど、最適化前に時間のかかっていた上位4項目（$Mft / \Windows\Prefetch\NTOSBOOT-~~~.pf / \Windows\Prefetch\ReadyBoost\Trace1.fx / \Windows\System32\DriverStore\FileRepository　へのアクセス）が根こそぎ短縮、ないしは無くなる（！）などの変化があった。
これはファイルの断片化云々ではなくて、そもそも読み込むべきファイルが減っている（Prefetch系がなくなった）ので、断片化の影響を受けにくいSSDでも短縮効果がある最適化なんじゃないかと思う。

あと、数値として判るように、エクスプローラの開始等ユーザーログオンに関する処理を行うuserinit.exeの開始と終了の時間を比較した。単位は秒で、OS起動からの経過時間で書いている。

項目	開始	終了	期間
before	51.3	86.1	34.8
after	47.4	64.5	17.1

開始も速くなっているが活動時間そのものが圧倒的に短い。これはuserinit.exeの処理が最適化されたわけではなくて、最適化前は他のプロセスの活動とかぶっていて、ディスクビジーの時間帯に完璧に含まれてしまっていたことが理由のようだ。上の画像を参照しつつ、活動時間を照らし合わせると判る。

やっぱりボトルネックがIOなわけで、このあたりからがっつり分析しようかなと思ったが、来週（てか明日から）仕事で同じようなことをしないといけないのでやめた。