64位機器/proc/kcore的結構及與物理記憶體的關係

讓我先說我已經找到了很多與我的問題類似但針對 32 位機器的問題的答案。但是，我找不到 64 位機器的任何東西。請不要回答關於 32 位機器的問題。

根據 Stack Exchange 上的許多來源，/proc/kcore可以從字面上轉儲（例如，使用dd）到文件中以獲得物理記憶體的副本……但這顯然不適用於 64 位機器，其中/proc/kcore128TB 在尺寸。

順便說一句，我注意到可以通過/dev/mem. 這是出於安全原因。解決這個問題涉及重新編譯核心，我不想這樣做……我也不能為了我的目的而這樣做（我必須使用正在執行的核心）。

好的…所以，/proc/kcore這是物理記憶體的 ELF 核心文件轉儲，可以使用gdb. 例如，使用：

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

這是我能做到的……但是，這不是我想做的。我想將物理記憶體導出到文件以進行離線分析。但我遇到了問題。

一方面，我不能只轉儲/proc/kcore到一個文件，因為它是 128TB。我想轉儲所有物理記憶體，但我不知道它在哪裡/proc/kcore。在字節 3600 之前，我只看到非零數據，然後就我所看到的（大約 40GB）而言，它都是零。我認為這可能與記憶體的映射方式有關/proc/kcore，但我不了解結構，需要一些指導。

我想我知道的更多內容：我知道只有 48 位用於定址，而不是 64 位。這意味著應該有 2 48 =256TB 的可用記憶體……但/proc/kcore只有 128TB，我認為這是因為定址進一步分為從 0x0000000000000000 到 0x00007fffffffffff （128TB）的塊和從 0xffff800000000000 到 0xffffffffffffff 的塊（128TB） . 所以，不知何故，這使得/proc/kcore128TB ……但這是因為這些塊中的一個被映射到/proc/kcore而另一個不是嗎？還是其他什麼原因？

所以，作為一個例子，我可以gdb用來分析/proc/kcore和查找，例如，sys_call_table 的位置（？）：

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

這是否意味著從 0xffff8000000000000 到 0xffffffffffffffff 的記憶體塊是什麼/proc/kcore？如果是這樣，它是如何映射到的/proc/kcore？例如使用

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

僅顯示零（2128982200 稍早於 0xffffffffffffffff-0xffffffff811a4f20）…

此外，我知道如何使用gcore轉儲給定程序的記憶體進行分析。而且我也知道我可以查看程序記憶體的樣子……但是我仍然不知道如何轉儲整個物理記憶體……這讓我發瘋了。請幫助我避免發瘋… ;)/proc/*PID*/maps

經過更多的搜尋，我想我已經說服自己，沒有簡單的方法可以得到我想要的東西。

那麼，我最終做了什麼？我從 github ( https://github.com/504ensicsLabs/LiME )安裝了 LiME

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

上面的命令創建了lime.ko 核心模組。然後執行以下命令可以獲得完整的記憶體轉儲：

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

它只是插入核心模組，字元串是指定輸出文件位置和格式的參數……它工作了！耶。

引用自：https://unix.stackexchange.com/questions/185841