3

カーネル モジュールを作成していて、いくつかの sys 呼び出しをハイジャック/ラップする必要があります。私は sys_call_table アドレスを総当たり攻撃しており、cr0 を使用してページ保護を無効/有効にしています。これまでのところとても良いです（完了したらコード全体を公開するので、誰かが望むならこの質問を更新できます）。

とにかく、ハイジャック__NR_sys_readすると、カーネル モジュールをアンロードするときにカーネル oops が発生し、すべてのコンソール (KDE) がクラッシュすることに気付きました。__NR_sys_openこれはorでは起こらないことに注意してください__NR_sys_write。

なぜこれが起こっているのだろうと思います。何か案は？

PS: KProbes の方法を使用しないでください。私は既にそれについて知っており、カーネル全体を再コンパイルすることなく最終製品を使用できるようにする必要があるため、使用することはできません。

編集：（情報を追加）

荷降ろし前の本来の機能を復元します。また、2 つのテスト ケースを作成しました。1 つは_writeonly で、もう 1 つは_readです。アンロードのあるものは_write問題ありませんが、_readアンロードしたものはカーネルをクラッシュさせます)。

編集：（ソースコード）

現在家にいるので、ソースコードをすぐに投稿することはできませんが、誰かが望む場合は、仕事に着き次第、サンプルコードを投稿できます. (~5時間)

4

1 に答える 1

5

これは、カーネル スレッドが現在内部にあることが原因である可能性がありreadます。read-hook を呼び出してもモジュールがロックされない場合、安全にアンロードできません。

readこれは、おそらく現在システムコールを実行してデータを待っているため、「コンソール」(?) がクラッシュしていることを説明しています。それらが実際のシステムコールから戻ると、関数があった場所にジャンプして問題を引き起こします。

アンロードは面倒ですが、最初にフックを削除し、すべての呼び出し元がフック関数を終了するのを待ってから、モジュールをアンロードする必要があります。

私は最近、Linux syscall フックで遊んでいますが、私は決してカーネルの第一人者ではありません。

PS: この手法は、sys_call_table をブルート フォーシングするよりも信頼性が高いと証明される可能性があります。私が見た力ずくの手法は、sys_close既にフックされている場合、カーネル パニックを起こす傾向があります。

于 2013-04-08T13:58:34.473 に答える