問題タブ [rootkit]

KASLR のため、このモジュールがシステム コール テーブル アドレスを使用できないことは理解しています。/boot/System.map-$(uname -r)で起動するとnokaslr、モジュールが機能しました。それが解決されたので、実際にkill関数をフックすることに進みましたが、できませんでした。insmodモジュールのロード時に再び「Kill​​ed」を返しますdmesgが、強調された行で発生する書き込みアクセス許可エラーをログに記録するようになりました。

コントロールレジスタのライトプロテクトビットを解除する目的は「ライトプロテクトを解除する」ためだと思いました。それ（または私のコード）以外に、カーネルモジュールがシステムコールテーブルを上書きするのを妨げているものはありますか?

コード

dmesg

エディターが監視しているファイルを把握しようとしています。inotify fds の数を数えることが可能であることを知りました/proc/${PID}/fd。私の質問は、監視されている i ノードのリストを 1 つのプロセスでダンプすることは可能ですか?

更新: 1 つの実用的なソリューションを更新しました。ここで役立つ参照をありがとうございます。

更新 2: 最近、kallsyms_lookup_name(およびその他のシンボル) がエクスポートされていないことがわかりましLinux Kernel v5.7た。

このトピックに関する以前の質問でKASLR オフセット シフトを導出するための提案された解決策を試した後、のランタイム アドレスは、KASLR が有効かどうかsystem_wqによって異なることに気付きました (ただし、KASLR が無効になっていても同じままです)。/boot/System.map-$(uname -r)反対のケースでは明らかに発生しません)。

次のスニペットはsys_call_table、 のランタイムsystem_wqアドレスと両方の System.map アドレスを使用してアドレスを計算する必要がsystem_wqありますsys_call_table(対応する System.map アドレスが含まれていると仮定sysmap_*します)。dmesg出力はスニペットの下にあります。

KASLR が有効

ブート 1 :

ブート 2 :

KASLR 無効

ブート 1 :

ブート 2 :

質問

1 . sys_call_tableKASLR が無効になっているのに System.mapの実行時アドレスが一致しないのに、(システム コールが正常にフックされたのでわかっている) の実行時アドレスが一致するのはなぜsystem_wqですか?

2 . sys_call_tableKASLR が有効かどうかのランタイム アドレスをスニペットが計算できないのはなぜですか?

3 . とにかくのランタイムアドレスがsystem_wqSystem.map のアドレスと異なる場合、他のエクスポートされたシンボルを使用して派生させることができますsys_call_tableか?

Windows が起動する前に、単純な種類のルートキットから ACPI テーブルを変更したかったのです。

->いいえ、BIOS コードを変更できません

-> Clover がその仕事をすることができることは知っていますが、私はレガシー モードで起動していて、レガシー デバイスにインストールすることができませんでした。

しかし今、私はRSDPポインターから始めました：

->int 15h E820 は、そのメモリ領域を「Type 2: Reserved - unusable 」と報告します

そして、私はそれを書くことができないので、それは真実であるようです. BIOSにハードコードされているのではなく、起動時に書き込まれていると思うので、DRAMコントローラーをプログラムする必要があるという結論に達しました...

INTEL32 や AMD64 などのすべてのプラットフォームで、これらの領域で書き込みアクセスを取得するように DRAM コントローラーをプログラムする一般的な方法はありますか?

またはACPIテーブルで書き込みアクセスを取得する他の方法はありますか?

編集 1: EBDA は PAM レジスタによって書き込み保護されており、TSEG は ACPI テーブルなどのより高い領域への書き込みを防止します。AMD64 プラットフォームでこれらと同等のものは何ですか?