detoursが復元なしで元関数を呼び出す仕組み - やや温め納豆
以前、単純なJMP方式のフックとして紹介したやり方は、元関数を呼び出すために一時アンフックするという実装だった。 図解するとこう。 1.初期状態 2.ExitProcessフック実施後。関数の先頭5バイトがNewExitProcessへのJMPに改竄される。 3.ExitProcessが呼び出された。即座にNewExitProcessにJMPする。 4.NewExitProcessでフックを解除する。これによりExitProcessの先頭5バイトは復元される。 5.NewExitProcessでExitProcessを呼び出す。ExitProcessは実行を完了しNewExitProcessに制御を返す*1 6.NewExitProcessでフックを実施する。 でも問題があって、アンフックしている最中に別スレッドがExitProcessを呼び出すと、当然ながらNewExitProcessを
APIフックメモのまとめ #2 - やや温め納豆
Win32 | 18:00 | #1の続き。 単純なJMP関数の先頭5バイトを JMP NN NN NN NN という命令に書き換え、JMP先に代替関数を用意する方法。TRAMPOLINE（トランポリン）と呼ばれているらしい。最近知った。日本語では、過去に香り屋というサイトで紹介されていたが今はページが見当たらない。技法としては特徴的なものではないためか、あまり注目されていないような印象がある。IAT方式と比較して、実装上の複雑さが少ない。フックはモジュール単位ではなくプロセス単位で有効なのでLoadLibrary系をフックする必要は無く、GetProcAddressでも本来の関数アドレスをそのまま返してしまって問題が無い（そのアドレスの先頭5バイトが既に改竄済みであるため）。フックに失敗することが殆どなく、フック処理そのものは信頼性がある。一方で、IATにはない課題もいくつか。5Byte
Finding the Linux System Call table in 2.6 series kernels - Charles Hooper
I have been modifying Sebek to get it to work in more recent 2.6 series (~2.6.18) kernels and ran into some snags. Most notably, I could not intercept/redirect/wrap any system calls. As it turns out, Sebek couldn't find the system call table. The code Sebek was using to find the system call table is 100% identical to the code found in this article on KernelTrap. Unfortunately, that code is outdate
linux のシステムコールをフックする : DSAS開発者の部屋
最近、とあるクローズドソースなデバイス管理ツールの挙動が気になり、その動作について解析してみることにしました。 プログラムをデバッグしたり解析したい時、どんなシステムコールが呼ばれ、どのような引数が渡されているかを、調べることができる strace は非常に有用です。 しかし、strace では ioctl で渡される複雑なデータ構造を表示することはできないため、システムコールをフックして引数を表示するという手段を取ることにしました。 そんな訳で linux でシステムコールをフックする方法について調べて見たところ、意外といろいろな方法が有ることを知りましたので、試してみた方法を幾つか紹介したいと思います。 注)今回の実験に使用した linux kernel のバージョンは 2.6.25.11 です。異なるバージョンではこの実験通りにはならない場合があります。 LD_PRELOAD を使っ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
