The Linux proc(5)
man page tells me that /proc/$pid/mem
“can be used to access the pages of a process's memory”. But a straightforward attempt to use it only gives me
$ cat /proc/$$/mem /proc/self/mem
cat: /proc/3065/mem: No such process
cat: /proc/self/mem: Input/output error
Why isn't cat
able to print its own memory (/proc/self/mem
)? And what is this strange “no such process” error when I try to print the shell's memory (/proc/$$/mem
, obviously the process exists)? How can I read from /proc/$pid/mem
, then?
Best Answer
/proc/$pid/maps
/proc/$pid/mem
shows the contents of $pid's memory mapped the same way as in the process, i.e., the byte at offset x in the pseudo-file is the same as the byte at address x in the process. If an address is unmapped in the process, reading from the corresponding offset in the file returnsEIO
(Input/output error). For example, since the first page in a process is never mapped (so that dereferencing aNULL
pointer fails cleanly rather than unintendedly accessing actual memory), reading the first byte of/proc/$pid/mem
always yield an I/O error.The way to find out what parts of the process memory are mapped is to read
/proc/$pid/maps
. This file contains one line per mapped region, looking like this:The first two numbers are the boundaries of the region (addresses of the first byte and the byte after last, in hexa). The next column contain the permissions, then there's some information about the file (offset, device, inode and name) if this is a file mapping. See the
proc(5)
man page or Understanding Linux /proc/id/maps for more information.Here's a proof-of-concept script that dumps the contents of its own memory.
/proc/$pid/mem
[The following is for historical interest. It does not apply to current kernels.]
Since version 3.3 of the kernel, you can access
/proc/$pid/mem
normally as long as you access only access it at mapped offsets and you have permission to trace it (same permissions asptrace
for read-only access). But in older kernels, there were some additional complications.If you try to read from the
mem
pseudo-file of another process, it doesn't work: you get anESRCH
(No such process) error.The permissions on
/proc/$pid/mem
(r--------
) are more liberal than what should be the case. For example, you shouldn't be able to read a setuid process's memory. Furthermore, trying to read a process's memory while the process is modifying it could give the reader an inconsistent view of the memory, and worse, there were race conditions that could trace older versions of the Linux kernel (according to this lkml thread, though I don't know the details). So additional checks are needed:/proc/$pid/mem
must attach to the process usingptrace
with thePTRACE_ATTACH
flag. This is what debuggers do when they start debugging a process; it's also whatstrace
does to a process's system calls. Once the reader has finished reading from/proc/$pid/mem
, it should detach by callingptrace
with thePTRACE_DETACH
flag.ptrace(PTRACE_ATTACH, …)
will stop the target process (it sends aSTOP
signal), but there is a race condition (signal delivery is asynchronous), so the tracer should callwait
(as documented inptrace(2)
).A process running as root can read any process's memory, without needing to call
ptrace
, but the observed process must be stopped, or the read will still returnESRCH
.In the Linux kernel source, the code providing per-process entries in
/proc
is infs/proc/base.c
, and the function to read from/proc/$pid/mem
ismem_read
. The additional check is performed bycheck_mem_permission
.Here's some sample C code to attach to a process and read a chunk its of
mem
file (error checking omitted):I've already posted a proof-of-concept script for dumping
/proc/$pid/mem
on another thread.