☰

64ビットシステムの/proc/kcore構造と物理メモリとの関係

tag-icon • tag-icon linux memory 64bit gdb
64ビットシステムの/proc/kcore構造と物理メモリとの関係

私と似ていますが、32ビットコンピュータに関する質問に多くの答えを見つけたことから始めましょう。ただし、64ビットコンピュータでは何も見つかりません。 32ビットシステムに関する質問には答えないでください。

Stack Exchangeの多くのソースによれば、/proc/kcoreそのままダンプすることが可能です（例dd：/proc/kcore

ところで、メモリは最初のMBを介してのみアクセスできることがわかりました/dev/mem。これはセキュリティ上の理由です。この問題を解決するにはカーネルを再コンパイルする必要がありますが、私はそうしたくありません。私の目的ではそうすることはできません（実行中のカーネルを使用する必要があります）。

[ OK].../proc/kcoreここで使用できる物理メモリのELFコアファイルダンプがありますgdb。

gdb /usr/[blah]/vmlinux /proc/kcore

そのためにできるしてください...しかしこれはいいえ私がしたいこと。オフライン分析のために物理メモリをファイルにエクスポートしたいと思います。ところで問題が生じました。

まず、/proc/kcore128TBなのでファイルに直接ダンプできません。すべての物理メモリをダンプしたいのですが、わかりません。どこそれは/proc/kcore3600バイトまでゼロ以外のデータのみを見ることができ、それから（約40GB）すべてのデータはゼロです。これはメモリがどのようにマッピングされるかに関連している可能性があると思います/proc/kcoreが、構造を理解しておらず、指示が必要です。

もっと知っているようです。アドレス指定には64ビットではなく48ビットのみが使用されることがわかります。つまり、2 48 = 256TBのメモリを使用できますが、... /proc/kcore128TBしか使用できません。私の考えではアドレス指定が 0x0000000000000000 から 0x00007ffffffffff(128TB) までのブロックと 0xffff800000000000 から 0xffffffffffffffff(128TB) までのブロックに分かれるためです。すると何とか/proc/kcore128TBになります。しかし、そのブロックの1つはマッピングされ、もう/proc/kcore1つはマッピングされていないためですか？それとも別の理由がありますか？

たとえば、sys_call_tableの場所（？）をgdb解析して検索するために実行できる操作は次のとおりです。/proc/kcore

(gdb) p (unsigned long*) sys_call_table
$1 = (unsigned long *) 0xffffffff811a4f20 <sys_read>

これは、0xffff8000000000000から0xffffffffffffffffffまでのメモリブロックがの内容であることを意味しますか/proc/kcore？では、どのようにマッピングされますか/proc/kcore？例えば

dd if=/proc/kcore bs=1 skip=2128982200 count=100 | xxd

0 のみ表示されます (0xffffffffffffffffff-0xffffffffff811a4f20 より少し前の 2128982200)...

gcoreまた、分析に特定のプロセスのメモリダンプを使用する方法も知っています。プロセスメモリがどのように見えるかを見ることができることも知っていますが.../proc/PID/mapsそれにもかかわらず私はまだ物理メモリ全体を捨てる方法を知りません...それが私を狂わせます。私が狂わないように助けてください... ;)

答え1

多くの検索の最後に、私が欲しいものを手に入れる簡単な方法はないと自信を持っているようです。

それで結局私は何をしましたか？私はgithubにLiMEをインストールしました（https://github.com/504ensicsLabs/LiME)

git clone https://github.com/504ensicsLabs/LiMe
cd /LiME/src
make -C /lib/modules/`uname -r`/build M=$PWD modules

上記のコマンドはlim.koカーネルモジュールを生成します。次に、次のコマンドを実行してメモリー・ダンプ全体を取得します。

insmod ./lime.ko "path=/root/temp/outputDump.bin format=raw dio=0"

カーネルモジュールを挿入したばかりで、文字列は出力ファイルの場所と形式を指定するパラメータでした。そして働いた！途方もない。

答え2

このコマンドの出力を見てくださいsudo readelf -e -g -t /proc/kcore。各仮想アドレス空間のオフセットを取得し、lseek（）とread（）を介してダンプできます。

これを発見するにはたくさんのお金がかかりました。最初は、仮想アドレスマッピングが読み取り専用であることがわかりました。 / dev / kmemに似ていますが、書き込み権限がありません...私が読んだとき、それはRAMアクセスを持つ疑似ELFファイルであり、ELFバイナリユーティリティを使用してアクセスでき、readelfを試みました。

大丈夫です。

関連情報