re-memdump

Memory Dumping and Extraction

When to Use / When Not to Use

Use: any task that needs to read process memory (finding keys/decrypting data, extracting clean samples after unpacking, DEX extraction); core analysis after the process has died; fallback when attach is disabled
Don't use: live interactive debugging (that is the job of [[re-gdb]] / [[re-lldb]] / [[re-x64dbg]])
Don't use: strings/structures obtainable statically (static first)

Tool Preparation

Refer to [[re-analyze/platform-tips]] "direct read vs dump" decision table and the Linux memory dump extreme section——dump-first by default, direct read only as an exception.

gdb / gcore (main dumping tool)

Linux: apt install gdb / dnf install gdb / pacman -S gdb(bundled with gcore)
WSL: Linux package
Verification: gcore --help / gdb --version

gdb core analysis tools

gdb（gdb ./target core）、elfutils eu-stack（apt install elfutils）、file core
Verification: eu-stack --version

volatility (memory forensics analysis)

All platforms: pip install volatility3(command vol)——Volatility 3 is currently the only maintained mainline; Volatility 2 was archived by upstream on 2025-05-16 (read-only), used only for historical images or result reproduction of old V2-only plugins/profiles, needs to be placed in an isolated Python 2 environment, do not use as a regular fallback for modern images
Verification: vol -h；vol -f core windows.info can identify the image

proc / psmisc (process status)

Linux: apt install procps psmisc / dnf install procps-ng psmisc / pacman -S procps-ng psmisc(mostly built-in)
Verification: ps aux、pkill available

Windows dumping (procdump / DumpIt, supplementary branch)

procdump (official Sysinternals download, or choco install sysinternals）：procdump -accepteula -ma <pid> out.dmp full-process memory dump (including managed heap)——loadable and analyzable by x64dbg/windbg
DumpIt (Comae official site): whole-machine physical memory dump (.raw), run as administrator——for [[re-mem-forensics]] whole-machine forensics
Verification: procdump -accepteula -? outputs usage; for dump artifacts use file to confirm (dmp/raw header)

Operation Steps

Default dump:gcore -o out <pid>(timing determined by plaintext/code materialization)：
```
gcore -o out <pid>
# 或调试器内
gdb -q -p <pid> -ex 'gcore out' -ex detach -ex quit
```
- The dump contains complete memory + register/thread state (ELF notes), can be directly imported into [[re-ghidra]] / [[re-ida]]
- Timing: the dump timing is determined by the materialization of the target plaintext/code——for a classic single-layer packer, dumping near the real OEP is usually appropriate, but OEP is not a universal completion criterion; multi-stage loaders, on-demand/per-page decryption, virtualization-based protection, reflective loading, process injection and fake OEP should determine the dump point based on "write→execute transition + memory protection changes + payload header/import recovery", with multi-point snapshots when necessary (see Pitfall 2; for a positive example of multi-stage/fake OEP determination see [[re-unpack-simple]] Step 3 "first execution is not necessarily OEP")
- A single dump satisfies all subsequent targeted extraction needs——do not dump multiple times
Before dumping, filter out vsyscall/vdso by maps：
```
cat /proc/<pid>/maps > maps.txt
grep -E 'vsyscall|vdso|vvar' maps.txt     # 这些段必须剔除
# 只保留 r--p / rw-p 可读映射区域作为提取范围
```
According to [[re-analyze/platform-tips]] Linux memory dump extreme section: [vsyscall]（0xffffffffff600000）、[vdso]/[vvar] read failure is normal, dumping into core is just garbage pages——skip them when extracting after dumping, or direct-read using the maps whitelist method (Step 5).
Import into Ghidra/IDA for analysis (core review)：
```
gdb -q ./target out         # core 复盘: bt / info registers / x/gx $rsp
eu-stack -e out | head -30  # 快速栈回溯
```
Ghidra: File > Import File select core (Ghidra supports ELF core import), symbol/stack clues are available.
- gcore output is a single-process ELF core, not a full-machine physical memory image—Volatility's linux.pslist and other plugins apply only to full-machine images (acquisition methods such as LiME/dd if=/dev/mem), and running the [[re-mem-forensics]] workflow on a gcore will fail; for process-level enumeration use gdb/eu-stack/ELF core parsing and targeted extraction are sufficient

Targeted extraction: keys/DEX/strings (magic scan)：

# DEX 魔数 "dex\n035\0"
grep -abo $'dex\n035' out | head
# PEM 私钥头
grep -abo '-----BEGIN' out | head
# 通用字符串
strings -n 8 out | grep -iE 'key|secret|flag|BEGIN'

# 扫描指定地址范围找特定模式
data = open('out','rb').read()
i = data.find(b'\x89PNG')          # PNG 魔数
while i != -1:
    print("found at", hex(i)); i = data.find(b'\x89PNG', i+1)

Key extraction note: keys may be fragmented on the heap/stack—locate the encryption context first, then extract (use [[re-ghidra]] to inspect the call site).

Special case direct read: maps addressing → SIGSTOP → pread：

kill -STOP <pid>    # 先停住进程防竞态
# 从 maps.txt 拿目标段地址偏移后:
dd if=/proc/<pid>/mem bs=1 skip=0x7f0000000000 count=4096 of=seg.bin 2>/dev/null
kill -CONT <pid>

import os
pid = 1234
f = open(f"/proc/{pid}/mem", "rb")
os.lseek(f.fileno(), 0x7f0000000000, os.SEEK_SET)   # maps 定址
data = f.read(4096)
f.close()

Applicable: process must remain running / only a very small specific region is needed ([[re-analyze/platform-tips]] special case ①/②)
/proc/<pid>/mem the offset isvirtual address, not a file offset—directly open+read starting from 0 will definitely error (see pitfall 3)

Windows-side dump (branch completion)：
```
procdump -accepteula -ma <pid> out.dmp   # 全进程内存（含堆），windbg/x64dbg 加载
# 整机物理内存: DumpIt 管理员运行产出 .raw → [[re-mem-forensics]]
```
- procdump output is a process-level minidump, same level as gcore—not a full-machine image, Volatility does not apply ([[re-mem-forensics]] only accepts full-machine images)
- Analysis entry points: [[re-windbg]] (minidump loading) / [[re-x64dbg]] (minidump commands)

Cross-domain combination

[[re-binary-core]]: workflow step 6 (memory stage, dump-first by default)
[[re-sample-acquire]]：when it is not yet determined which process/which memory to dump(only symptoms, no sample on disk), go there first—it handles scanning abnormal execution regions and attributing execution context, then hands the target back to this skill to perform the dump
[[re-malware]]: extraction of memory artifacts from malicious samples (unpacked samples)
[[re-mobile]]: DEX/so extraction from App memory
[[re-anti-analysis]]: standard actions for extracting a clean image after unpacking
[[re-crypto-keys]]: methodological coordination for key extraction from memory (locate the encryption context first, then extract; see step 4)
[[re-format-elf]]: the core is in ELF format; section/notes structure parsing can be cross-referenced
Complementary to [[re-gdb]] / [[re-x64dbg]] / [[re-windbg]] (attach fails → dump; need interaction → debugger; Windows process dump → windbg)

Common pitfalls and traps

vsyscall/vdso read failures are normal：[vsyscall] is execute-only,[vdso] some pages are unreadable, and errors from gdb/pread access are expected behavior—filter by maps before extracting, don't treat it as a bug to investigate
Dumping too early = the packer's initial state: dumping before plaintext/code has materialized yields compressed/encrypted data—the classic single-layer packer is fine near the real OEP, but OEP is not a universal completion criterion; for multi-stage loaders / on-demand decryption / virtualization protection / reflective loading / process injection / fake OEP, the dump point should be determined by "write→execute transition + memory protection changes + payload header/import recovery", with snapshots at multiple points in time if necessary (see [[re-analyze/platform-tips]] key experience)
Blindly open /proc/pid/mem and it will definitely error: directly open('/proc/pid/mem').read() will fail (illegal offset/permissions)—you must do maps addressing + SIGSTOP + chunked pread
Core files can reach several GB—first file out confirm it is an ELF core, then extract in a targeted way as needed; don't import the whole file into a tool
When rebuilding a process from a dump, vDSO is not portable: Symptom — after rebuilding/reproducing the process image, the program still jumps back to the original vDSO address, or call *%gs:0x10 indirect calls break; Cause — the vDSO address is recorded in the process stack's auxv AT_SYSINFO/AT_SYSINFO_EHDR, and glibc caches it, so patching auxv may not necessarily relocate it; Countermeasure — when rebuilding the image, treat vDSO-related calls as inevitably invalid (skip that page directly), and base the analysis on the remaining mappings
gcore forensics has limited resolution: Symptom — in the core it is difficult to investigate shared library injection/function pointer redirection, and stack information is incomplete; Cause — a traditional core is a segment snapshot taken by the kernel, with no per-process profile or symbol reconstruction; Countermeasure — ordinary reverse engineering with gcore is sufficient; for deep forensics (locating injection points/hooks), switch to an ECFS-style kernel-level dump (hooking core_pattern to rebuild .symtab/.dynsym) or combine with /proc/<pid>/maps for manual reconstruction
Seeing decrypted data → save immediately: Symptom — during dynamic debugging/dumping, plaintext (decrypted strings/keys/second-layer code) has just been seen in memory, but after switching tools or continuing execution, that address has already been overwritten or cleared, and it can never be recovered; Cause — decrypted data is transient: unpacking cleanup, self-clearing, burn-after-use keys, and buffer reuse all wipe it immediately (note this is the opposite of "dumping too early"; here, if you are late, it is gone); Countermeasure — in dynamic analysis, as soon as decrypted output is confirmed, immediately gcore / targeted extraction (see steps 1/4, dumping takes priority by default), "save first, then continue"; when reproduction is needed, return to the decryption loop call site to observe again (see [[re-binary-core]] analysis methodology R19)
gcore/direct read blocked by ptrace permissions: Symptom —gcore reports ptrace: Operation not permitted，/proc/<pid>/mem fails immediately on open; Cause —kernel.yama.ptrace_scope=1/2 restricts cross-process-family attach (when not root and the target is not one's own child process); Countermeasure — run the dump as root, or temporarily sysctl kernel.yama.ptrace_scope=0(restore afterward), or execute via a debugger ([[re-gdb]]) with an allowed identity