5

Let me preface this question by saying that I've found a lot of answers for questions similar to my question but for 32-bit machines. However, I can't find anything for 64-bit machines. Please no answers with respect to 32-bit machines.

According to many sources on Stack Exchange, /proc/kcore can be literally dumped (e.g., with dd) to a file in order to get a copy of physical memory... But this clearly does not work for a 64-bit machine, for which /proc/kcore is 128TB in size.

As an aside, I note that it is possible to access only the first MB of memory through /dev/mem. This is for security reasons. Getting around this involves recompiling the kernel, which I don't want to do... nor can I do for my purposes (I have to work with the running kernel).

Ok... so, /proc/kcore is an ELF-core file dump of the physical memory and it can be viewed using gdb. For example, with:

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

This I can do... but, this is not what I want to do. I would like to export the physical memory to a file for offline analysis. But I'm running into issues.

For one thing, I can't just dump /proc/kcore to a file since it's 128TB. I want to dump all of physical memory, but I don't know where it is in /proc/kcore. I only see non-zero data up until byte 3600 and then it's all zeros for as far as I have looked (about 40GB). I think this may have to do with how the memory is mapped to /proc/kcore, but I don't understand the structure and need some guidance.

More stuff I think I know: I know that only 48 bits are used for addressing, not 64 bits. This implies that there should be 248=256TB of memory available... but /proc/kcore is only 128TB, which is I think because addressing is further divided into a chunk from 0x0000000000000000 to 0x00007fffffffffff (128TB) and a chunk from 0xffff800000000000 to 0xffffffffffffffff (128TB). So, somehow this makes /proc/kcore 128TB... but is this because one of these chunks is mapped to /proc/kcore and one isn't? Or some other reason?

So, as an example, I can use gdb to analyze /proc/kcore and find, e.g., the location (?) of the sys_call_table:

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

Does this mean that the chunk of memory from 0xffff8000000000000 to 0xffffffffffffffff is what is in /proc/kcore? And if so, how is this mapped to /proc/kcore? For example using

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

shows only zeros (2128982200 is a little before 0xffffffffffffffff-0xffffffff811a4f20)...

Furthermore, I know how to use gcore to dump the memory of a given process for analysis. And I also know that I can look in /proc/PID/maps to see what process memory looks like... but nevertheless I still have no idea how to dump the whole physical memory... and it's kind of driving me nuts. Please help me avoid going crazy... ;)

2 Answers 2

4

After a lot more searching I think I have convinced myself that there is no simple way to get what I want.

So, what did I end up doing? I installed LiME from github (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

The above commands create the lime.ko kernel module. A full dump of memory can be obtained by then running:

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

which just inserts the kernel module and the string are the parameters specifying the output file location and format... AND IT WORKED! YAY.

2
  • Now I can run that command on your computer and see all your passwords or secret unicorns or whatever. Maybe a security risk for production machines ?
    – cat
    Jun 14, 2016 at 20:50
  • This may also be helpful: unix.stackexchange.com/questions/119762/… Jun 24, 2016 at 1:54
3

You should have a look to the output of this command sudo readelf -e -g -t /proc/kcore. You can have the offset for every virtual address space, and then dump it by lseek() and read().

It cost to me a lot to discover this. First I thought it was virtual address mapping read-only. Like /dev/kmem but without write permissions... and when I read it's a pseudo ELF file with the RAM access, which can be accessed with ELF binary utils, I tried readelf.

So, fine.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .