re-sample-acquire

Live sample acquisition (from phenomenon to usable sample)

Task classifier (intent → path)

User intent	Path
Only a description of the phenomenon ("some program doesn't touch disk" "abnormal behavior"), no sample file	→ Step 1 (abnormal execution region scan) → 2 (execution context attribution) → 4 (dump the entire region)
Known process, but no sample file on disk (injection/memory residency)	→ Step 2 → 4
Server-side resident payload (Web middleware/Java etc., request-triggered)	→ the "server-side" section of the platform branch (memory shell)
Payload suspected to be a driver/kernel-mode (memory-reading/writing cheats/rootkit)	→ [[platform-windows]] kernel side
Embedded/microkernel target (seL4 system)	→ [[platform-sel4]] (capability provenance route)
Has callback/download behavior, want to obtain the original sample	→ Step 7 (network and disk side)

Entry decision (Decision Gate) —— platform × form

现场采集
├─ 已有样本文件（磁盘上有）→ 不需要本技能，直接 [[re-triage]] 初勘
├─ Windows 目标 → [[platform-windows]]（VAD/region + 线程 + 模块链 + ETW/Sysmon）
├─ Linux 目标   → [[platform-linux]]（VMA + mmap/mprotect 追踪 + process_vm_readv）
├─ macOS 目标   → [[platform-macos]]（Mach task VM + Endpoint Security）
├─ seL4 目标    → [[platform-sel4]]（capability/VSpace 审计，不是"扫描进程"）
└─ 不知平台/跨平台 → 先按步骤 1 的平台无关判据走，再进对应分支

The platform observation models differ, methods cannot be mechanically translated(the table below is the division of labor for each branch, not synonymous substitution):

Platform	Observation object	Event source (trigger)	Read (ground truth)	Privilege model
Windows	Process VAD/region + thread + module chain	Sysmon 8/10/25, ETW (including Threat-Intelligence), kernel callbacks	VirtualQueryEx / ReadProcessMemory / PE-sieve	Administrator + debug privilege
Linux	Process VMA (/proc/<pid>/maps）	tracepoint/kprobe、BPF LSM（file_mprotect etc. hooks)	process_vm_readv() / ptrace / gcore	ptrace access check (including Yama)
macOS	Mach task + VM region	Endpoint Security（MMAP/MPROTECT/REMOTE_THREAD_CREATE/GET_TASK）	mach_vm_read / mach_vm_read_overwrite(requires task port)	SIP / Hardened Runtime / task port authorization
seL4	capability（VSpace / frame / TCB）	fault endpoint + system construction-time record	No capability means no access right	capability system (there is no "root reads everything" model)

When to use / when not to use

• Use: analysis targetthere is no analyzable file——only a phenomenon (no disk writes, memory residency, parasitizing another process), it needs to first be turned into an "analyzable sample"
• Use: the payload exists only in memory and the window is very short (one-time decryption, self-clearing after use, buffer reuse)
• Applicable scenarios (not limited to cheats): fileless malware / reflective loading payloads / memory shells (server-side) / APT memory residency / the pre-loading stage of ransomware and data theft / game cheats (user-mode and driver) / unauthorized executable pages on microkernel and embedded systems
• Do not use: there is already a sample file ([[re-triage]]); whole-machine image forensics ([[re-mem-forensics]], offline image malfind-style investigation belongs there); device backup parsing ([[re-mobile-forensics]]); "given a PID, how to dump" ([[re-memdump]])
• Authorization boundary (red line): only forown or written authorization obtaineddevice/system collection (RE_AUTH = owned / research). The collection actions themselves (enumeration, hooking, reading memory, dumping, loading monitoring components) leave obvious traces and will trigger anti-cheat / EDR / business monitoring; executing them in a production environment or on someone else's device is unauthorized access, so first confirm authorization and stop conditions
• Boundary: this skill only doescollection, and does not do concealment from the target detection system (concealment belongs to the [[re-evasion]] domain, and is limited to authorized scenarios only)

Tool preparation

Windows

• PE-sieve / HollowsHunter(reference implementation of this skill: detects injected/replaced PE, shellcode, inline hooks, patches by memory artifact, supports thread call stack scanning) — GitHub releases (hasherezade/pe-sieve、hasherezade/hollows_hunter), verify the sha256 on the release page; verify pe-sieve.exe /help
• System Informer(formerly Process Hacker) / Process Explorer: full process region/thread/handle view
• procdump（Sysinternals）：procdump -ma <pid> out.dmp; verify procdump -?
• Sysmon(Event 8/10/25, see the behavior monitoring section of [[re-behavior]]);frida([[re-frida]], script template [[re-frida/frida-scripts]])
• See [[platform-windows]] for details

Linux

• /proc parsing (python3, [[re-python]]),gdb/gcore（[[re-memdump]]）、bpftrace/perf/BPF LSM（[[re-ebpf]]）、frida
• Verification: cat /proc/<pid>/maps | head can see the VMA's address/permissions/backing pathname
• See [[platform-linux]] for details

macOS

• lldb / vmmap / otool（[[re-lldb]]、[[re-format-macho]]）；Mach VM API（mach_vm_region* / mach_vm_read*, requires task port); Endpoint Security client (requires entitlement and user authorization)
• Note:under SIP + Hardened Runtime, root alone is not enough to read—see the permission boundary in [[platform-macos]]
• See [[platform-macos]] for details

seL4 / microkernel

• No general off-the-shelf tool: provenance must be recorded by the security monitor at system construction time (capability route); for the method and checklist see [[platform-sel4]]

Operating steps (platform-independent trunk)

For the platform-specific implementation of each step, see the corresponding platform branch; here onlywhat to do and the criteria are listed。

1. Scan anomalous executable regions(don't guess the PID, scan first):
   • Enumerate the target's executable memory units and filter for "executable": Windows = VAD/region (VirtualQueryEx/NtQueryVirtualMemory）；Linux = VMA（/proc/<pid>/maps, available in 6.11+ PROCMAP_QUERY ioctl for efficient filtering); macOS = VM region (vm_region_recurse_64/mach_vm_region*); seL4 = VSpace mapping audit (see branch)
   • Priority characteristics:no backing (anonymous/private) and executable；protection attribute transitions(W→X, RW→RWX→RX—the instant of transition is the best capture opportunity); high entropy / executable format characteristics (PE/Mach-O/ELF); no known JIT/runtime origin
   • Don't only check "private/no backing": file-backed memory can be exploited just as well (Windows MEM_IMAGE + module stomping/DLL hollowing, COW pages still report MEM_IMAGE; Linux file-backed mappings are rewritten; macOS file-backed regions are patched)
   • Cross-check mapping origin vs structural records: on Windows use VirtualQueryEx+NtQueryVirtualMemory to get the mapping path and compare it with the PEB module chain ("there is a mapping but no module entry" = unlinked and hidden); on Linux compare the maps' pathname/inode with the ELF on-disk copy; on macOS compare dyld records with VM regions
2. Execution context attribution(the thread is the second-strongest signal, and you must look at the stack, not just the entry):
   • Get each thread's execution location: starting point (Windows NtQueryInformationThread + ThreadQuerySetWin32StartAddress; macOS thread backtrace) → attributed to the execution region; Linux uses /proc/<pid>/task/ to enumerate threads,stat 's wchan/state as auxiliary clues, PC and return addresses rely onstack backtrace（eu-stack/gdb) to obtain
   • A normal starting point may also be a trampoline: starting from a legitimate module and then jumping into an unbacked executable region bypasses "start-point-only" detection
   • Supplement with three layers of evidence:current PC/RIP、call stack return address、region ownership— any level falling into an anomalous region raises the score
3. Runtime correlation (division of labor between trigger and ground truth)：
   • Event sources serve only as triggers for "when to dump": memory allocation/write/protection transition + suspicious thread creation + anomalous module load—combined judgment, no single-point alerting
   • Memory scanning is the ground truth for "what to dump": paths such as direct syscalls, shared section mapping, and overwriting existing executable regions can all bypass user-mode hooks
   • Platform event sources: Windows = Sysmon 8/10/25 and ETW; Linux = tracepoint/kprobe/BPF LSM; macOS = Endpoint Security; seL4 = fault endpoint
   • Also capture the injector/constructor: the source of the execution injection or mapping (process/driver/construction path) is often more analytically valuable than the parasitized payload
4. Snapshot / Dump (do not just look for MZ/PE headers)：
   • Save the entire suspicious region: the payload may have no executable format header to begin with, orthe header is deliberately erased(classic: after injection, erase the PE header, then relocate by region and reconstruct)
   • Content classification (determines the subsequent analysis path): full PE/Mach-O/ELF / manually mapped image / raw shellcode / JIT code / decrypted code blob
   • Record for each region: base address / size / protection attributes andchange history / type / mapping source / collection time
   • Differences between memory copy and disk copy: compare the disk file and memory contents of the same-named image (to detect stomping, patching, header erasure, code replacement)
5. Reconstruction / false-positive assessment / reporting：
   • Reconstruction: manually mapped images are reconstructed according to the section table; header-erased payloads are recovered from region contents (annotated "reconstructed from memory, not the original file")
   • False-positive whitelist and downweighting(mandatory): JIT (.NET/V8/JVM/Mono), browsers, Wine/Proton, QEMU TCG,security software's own hooks and patches, profilers, overlays, shim/hotpatch — they likewise produce unbacked executable memory
   • Scoring rather than binary judgment: unbacked executable + thread/PC/stack hits + recent W→X + high entropy/format characteristics + no known runtime source → high confidence; a single feature is insufficient to characterize it
   • Report according to the [[re-analyze/analysis-contract]] core fields (target_id / sha256 / evidence)—the collection method itself is also evidence("the region was RWX at time T", "the thread's starting point is not within any mapping source")

Platform branches (references)

• [[platform-windows]] —— VAD/region scanning, thread and call stack attribution, Sysmon/ETW/kernel callbacks, PE-sieve and PE reconstruction, kernel and driver carriers
• [[platform-linux]] —— VMA enumeration (/proc/<pid>/maps、PROCMAP_QUERY), mmap/mprotect tracing (tracepoint/kprobe/BPF LSM),process_vm_readv and ptrace dump, ELF memory-disk diff, memfd and deleted mappings, JIT false positives
• [[platform-macos]] —— Mach task and VM region,mach_vm_read, Endpoint Security (MMAP/MPROTECT/REMOTE_THREAD_CREATE/GET_TASK), Mach-O/dyld provenance, task port and SIP/Hardened Runtime boundaries
• [[platform-sel4]] —— capability provenance, VSpace mapping audit, executable page policy, TCB debug and fault endpoint——provenance is retained at design time, which is a different route from the "post-hoc reconstruction" of the previous three

Cross-domain federation

• [[re-memdump]]: dump execution for a given PID (this skill is responsible for "which to scan, what to dump")
• [[re-mem-forensics]]: investigation of offline full-disk images (this skill is the online/live side); [[re-fileless]] / [[re-loader]]: analysis of collected artifacts
• [[re-frida]]: cross-platform execution layer; [[re-java]]: server-side memory shells; [[re-kernel]] / [[re-ebpf]]: kernel and kernel-mode observation
• [[re-evasion]]: sample-side anti-detection (the collection side needs to know it will be seen); [[re-malware]]: artifact analysis gateway; [[re-triage]]: artifact initial survey entry point
• [[re-rtos]] / [[re-tee]] / [[re-firmware]]: related analysis of embedded and trusted execution targets (the system construction perspective of the seL4 branch complements them)

Common pitfalls and traps (cross-platform commonalities)

• Hooking only user-mode APIs and thinking coverage is complete: direct system calls, shared sections, and overwriting existing executable regions can all bypass it——treat event sources only as triggers, and memory scanning as ground truth
• Treating "executable with no backing" directly as malicious: JIT, browsers, Wine/Proton, QEMU TCG, and security software's own hooks all produce similar regions——is a signal, not a verdict, requiring provenance + execution history + scoring
• Checking only "private/unbacked" memory: file-backed memory can also be exploited (Windows MEM_IMAGE+COW, Linux/macOS file-backed mappings being rewritten)
• Finding payloads only by executable format headers: payloads may be headerless ordeliberately header-wiped——save the entire region before classification and reconstruct when necessary
• Looking only at thread entry points：trampoline、SetThreadContext, borrowing in-module jump instructions, etc., can bypass it——look at PC and call stack together
• Misjudging the platform permission model: on macOS, being root does not mean you can read (SIP/Hardened Runtime/task port); seL4 has no such thing as "root reads everything" at all——design the collection scheme according to the platform-specific permission boundaries
• Collecting too late: one-time decryption/self-clearing after use——dump at theinstant the trigger point is hit, do not "record the address first and read later"
• The collection action itself is exposed: enumeration/hooking/reading memory will be discovered by anti-cheat, anti-debugging, and monitoring ([[re-game]] / [[re-evasion]])——operate within the authorized scope, prepare in an isolated environment first, and complete dynamic collection in one pass
• Trace-free hooks make the memory view untrustworthy: Shadow pages/hardware breakpoints implement a traceless hook that separates the "read view" from the "execution view"—multi-view intersection,the view discrepancy itself is evidence
• Clearing precedes forensics(frequently occurring on the server side): restarting/killing the process will also lose the evidence—dump for forensics first, then block the implantation path and clear it