アプリケーションに依存しないAPIフック
まず参考文献から
Detours – Microsoft Research
http://research.microsoft.com/en-us/projects/detours/#overview
http://research.microsoft.com/pubs/68568/huntusenixnt99.pdf
Windows XP SP1、およびWindows Server 2003 SP1から、ホットパッチという再起動しなくてもセキュリティ上問題のある部分を修正を適応可能とする機構が導入されました。
OS起動中はロックされてしまい修正不可能なファイルに対して、メモリ上でパッチをして一時的に適応。再起動時にファイルを置き換えるというものです。
ROの場合は、描画とマウス入力へ処理をもぐりこませるために、DirectInputCreateAとDirectDrawCreateExが実行されCOMオブジェクトが生成される際にラップする必要があるのでこれをパッチングします。
ddraw.dllとdinput.dllのそれぞれのファンクションのメモリイメージの抜粋が以下の通り。
赤く線でマーキングした部分がホットパッチのために用意された部分で、コードの流れ上無意味であるmov edi,ediとう２バイトの命令をマジックキーに見立てて、前方の５バイトと合わせてトランポリンコードに置き換えるために用意されています。
実際にコードを置き換えると以下の通り
ファンクションの先頭にあったmov edi,ediの命令を5バイト前方のアドレスへジャンプさせるショートジャンプ命令を書き、そのアドレスへパッチコードへのジャンプ命令を書き込んでおき、パッチ用のファンクションを実行させます。
パッチ用のファンクションはマジックキーの次のアドレス（L702ebc8）を呼び出すことで、オリジナルファンクションを呼び出すことが可能です。
mov edi,edi命令がすでにショートジャンプコード(0xeb 0xf9)だった場合は、すでに他者がパッチしている状態なので前方５バイトがジャンプコードかを確かめてジャンプコードを自分のファンクションのアドレスへ、オリジナルファンクションとしての呼び出しは他者のパッチコードが呼ばれるようにすると多重パッチが成立します。
ゲームなどの場合であればexeが圧縮等に悩まされずパッチコードを挿入させることができますが、問題点が無いわけではなく、nProtectのようなガードプログラムにより凶悪なものの場合、この領域がオリジナルコードへ上書きされ、さらにセキュリティロックを掛けられてしまうという問題があります。
ただし、DirectX関連のパッチは初期化さえ通過出来れば内部コードとして存在し続けられるので、その後オリジナルコードへ書き直されてロックされても問題はありません。
このオリジナルコードへの修復は善意のセキュリティパッチすら無効にするので、nProtectのゲームを実行するときは再起動してからにしましょう。
協調性のないセキュリティプログラムは死滅すべきだと思うんですがね・・・。