Dumping a process's memory in Linux is a common task for debugging, forensics, or reverse engineering. There are multiple ways to achieve this, including using tools like `gcore` or directly accessing `/proc/[PID]/mem`. Below, we'll explore both methods with practical examples.
The simplest way to dump a process's memory is by using the `gcore` utility, which is part of the GDB (GNU Debugger) package. It creates a core dump file containing the process's memory.
# Install gdb if not already installed
sudo apt-get install gdb
# Dump memory of a process by PID
gcore -o /tmp/dump [PID]
This will generate a core dump file (e.g., `/tmp/dump.[PID]`) containing the process's memory. You can analyze it later with tools like `gdb` or `objdump`.
For more granular control, you can read the process's memory directly from `/proc/[PID]/mem`. However, this requires careful handling due to permissions and memory mapping.
#include
#include
#include
#include
int main(int argc, char *argv[]) {
if (argc != 3) {
fprintf(stderr, "Usage: %s [PID] [output_file]\n", argv[0]);
return 1;
}
char mem_path[256];
snprintf(mem_path, sizeof(mem_path), "/proc/%s/mem", argv[1]);
int mem_fd = open(mem_path, O_RDONLY);
if (mem_fd == -1) {
perror("open");
return 1;
}
FILE *maps = fopen("/proc/[PID]/maps", "r");
if (!maps) {
perror("fopen");
close(mem_fd);
return 1;
}
// Parse memory regions and dump them to the output file
// (Example code for parsing /proc/[PID]/maps omitted for brevity)
close(mem_fd);
fclose(maps);
return 0;
}
- You need root privileges or the same user as the target process to access `/proc/[PID]/mem`.
- Memory pages may not be readable if they are swapped out or protected.
- For security reasons, some processes (e.g., those with `ptrace` restrictions) may block memory access.
Other tools like `pmap`, `dd`, or specialized forensic tools (e.g., Volatility) can also be used for memory dumping, depending on your use case.
Every running process in Linux has its virtual memory space mapped to physical memory through the kernel's memory management system. The /proc/[PID]/
filesystem provides a window into this memory space, with several key files:
/proc/[PID]/maps
- Shows memory mappings and permissions/proc/[PID]/mem
- The actual process memory (requires ptrace attachment)/proc/[PID]/smaps
- Extended memory information
Before attempting to dump process memory:
- You need root privileges or CAP_SYS_PTRACE capability
- The process must be in a dumpable state (check
/proc/[PID]/status
) - ASLR (Address Space Layout Randomization) may affect memory addresses
Here's a Python script that dumps all readable memory regions of a process:
#!/usr/bin/env python3
import os
import sys
def dump_process_memory(pid, output_file):
maps_file = f"/proc/{pid}/maps"
mem_file = f"/proc/{pid}/mem"
output_path = f"{output_file}_{pid}.dump"
with open(maps_file, 'r') as maps, open(mem_file, 'rb', 0) as mem, open(output_path, 'wb') as out:
for line in maps.readlines():
if 'r' not in line.split()[1]: # Skip non-readable regions
continue
addr_range = line.split()[0]
start, end = [int(addr, 16) for addr in addr_range.split('-')]
mem.seek(start)
chunk = mem.read(end - start)
out.write(chunk)
if __name__ == "__main__":
if len(sys.argv) != 3:
print(f"Usage: {sys.argv[0]} PID OUTPUT_FILE")
sys.exit(1)
dump_process_memory(int(sys.argv[1]), sys.argv[2])
For more controlled dumping, consider these approaches:
1. Using gcore (GNU Debugger)
gcore -o dumpfile PID
2. Direct /proc Access with dd
dd if=/proc/PID/mem of=process.dump bs=4096 skip=$((0xSTART_ADDR/4096)) count=$((SIZE/4096))
3. Using pmap for Specific Regions
pmap -x PID > memory_layout.txt
- Memory dumping may violate process isolation security policies
- Some memory regions may contain sensitive information
- Modern systems may have additional protections (YAMA ptrace scope, etc.)
- Consider using
memfd_create
for secure temporary storage
After obtaining the memory dump, you can analyze it with:
- hexdump/xxd for basic inspection
- radare2/Cutter for reverse engineering
- Volatility Framework for forensic analysis
- GDB for live debugging