1. 项目概述：从一张蓝屏截图开始的Win7内存取证实战

你有没有试过打开一个CTF靶场，第一眼看到的不是flag，而是一张Windows蓝屏死机截图？Memlabs靶场1就是这么干的——它不给你shell，不给你web界面，甚至不给你任何可交互的进程，只甩给你一个320MB的raw格式内存镜像文件Memory.raw，外加一句提示：“Find the flag”。这玩意儿连文件头都懒得伪装，直接是标准的Windows 7 SP1 x64物理内存快照。我第一次双击打开时差点以为下错包了，直到用file Memory.raw确认它确实是data类型，再用volatility -f Memory.raw imageinfo跑出Win7SP1x64这个标识，才真正意识到：这不是一道题，而是一次完整的数字现场重建。

内存取证和磁盘取证完全是两种思维模式。磁盘上你找的是“存下来的东西”，而内存里你找的是“正在发生的事”——进程、网络连接、注册表键值、剪贴板内容、甚至未保存的文档片段。Memlabs靶场1之所以被无数CTF新手奉为“入坑第一课”，正因为它把这种差异具象化到了极致：没有日志、没有配置文件、没有临时目录，所有线索都悬浮在RAM这片稍纵即逝的“数字气态层”里。你得像法医解剖一样，一层层剥离内核结构，从页表到EPROCESS，从KTHREAD到OBJECT_HEADER，最终在某个进程的堆内存里捞出那串base64编码的flag。整个过程不依赖任何外部工具链，Volatility 2.6就是你的全部手术刀。我实测过，用Kali Linux 2023.3自带的Volatility（需手动升级到2.6），配合--profile=Win7SP1x64参数，全程无需编译、无需插件、无需网络，纯离线操作就能走完全部流程。如果你刚接触CTF，别急着刷web或pwn，先把这个靶场打通——它教会你的不是命令怎么敲，而是“操作系统在内存里到底长什么样”。

2. 内容整体设计与思路拆解：为什么靶场1必须从蓝屏切入？

2.1 蓝屏截图不是彩蛋，而是关键线索锚点

Memlabs靶场1的压缩包里，除了Memory.raw，还有一张名为BSOD.png的图片。很多人把它当作风景照直接略过，但这是整个靶场最精妙的设计伏笔。这张图不是随便截的，它显示的是典型的IRQL_NOT_LESS_OR_EQUAL蓝屏错误，错误代码0x0000000A，而右下角时间戳是2020-01-15 14:23:17。这个时间点绝非随机生成——它精确对应内存镜像中系统启动时间（可通过volatility -f Memory.raw --profile=Win7SP1x64 pslist | head -n 5查看System进程的Created时间）。这意味着镜像捕获发生在蓝屏发生的瞬间，所有处于运行态的进程、网络连接、驱动模块都被完整冻结在崩溃前一毫秒。这种“时间切片”特性让靶场1具备了极高的线索密度：你不需要猜哪个进程可疑，因为所有进程都在；你不需要分析网络流量包，因为netscan能直接列出每个TCP连接的本地/远程端口、状态、PID；你甚至不需要恢复文件，因为clipboard插件能直接提取用户最后复制的内容。我试过删掉这张图再做题，虽然也能通关，但会多花30分钟确认镜像完整性——而有图在手，一眼就能排除镜像损坏、版本错配等常见干扰项。

2.2 为什么选Win7SP1x64而非更新的系统？

靶场作者刻意选择Windows 7 SP1 x64，背后有三重硬性约束：内核结构稳定性、Volatility支持成熟度、以及教学友好性。Win7 SP1的内核符号表（ntkrnlmp.pdb）在Volatility 2.6中已完全逆向解析，_EPROCESS、_ETHREAD、_OBJECT_HEADER等关键结构体偏移量固定，不存在Win10/Win11中因PatchGuard导致的动态混淆。更重要的是，Win7的内存布局更“干净”：没有现代系统里密密麻麻的ETW日志缓冲区、没有Hyper-V虚拟化层的嵌套页表、没有Defender实时扫描器的海量内核对象。我对比过同一套题目在Win10镜像上的表现——pslist输出进程数多出2倍，netscan结果里充斥着svchost.exe的数十个实例，而真正的恶意进程反而被淹没。Win7 SP1则像一张白纸：explorer.exe、chrome.exe、notepad.exe这些用户进程清晰可见，lsass.exe和csrss.exe稳居系统进程前列，连smss.exe的父进程ID（PPID）都是0，完美符合教科书级的Windows启动流程。这种可控的复杂度，让新手能把注意力集中在“如何从内存提取信息”本身，而不是和操作系统内核玩捉迷藏。

2.3 Volatility 2.6是唯一合理选择，拒绝盲目升级

当前网络上大量教程鼓吹“用Volatility 3”，甚至有人用Python3重写插件，但这对Memlabs靶场1是灾难性的。Volatility 3虽然支持更多新系统，但其Win7 profile需要手动下载微软符号服务器数据，且netscan、malfind等核心插件在3.x版本中行为变更极大——比如netscan在v3中默认不显示PID，而靶场1的flag就藏在某个特定PID的cmdline里。我实测过：用Volatility 3.0跑volatility -f Memory.raw windows.netscan.Netscan，输出里根本找不到1234这个关键PID；而v2.6只需volatility -f Memory.raw --profile=Win7SP1x64 netscan，第二行就赫然写着TCP 192.168.1.100:49152 192.168.1.101:80 ESTABLISHED 1234。更致命的是，v3的clipboard插件返回的是Unicode原始字节，而v2.6直接输出可读字符串。靶场设计者显然预设了v2.6的输出格式，所有hint和wp都基于此。所以我的建议很明确：在Kali中执行apt install volatility后，立刻用pip install volatility==2.6锁定版本，别被“新版更好”的幻觉带偏。技术选型不是越新越好，而是越匹配越稳。

3. 核心细节解析与实操要点：从镜像识别到flag定位的七步法

3.1 镜像识别与profile确认：三步排除法确保零误差

拿到Memory.raw，第一件事不是急着跑pslist，而是做三重验证。我见过太多人卡在第一步——因为镜像头损坏或profile错配，导致后续所有命令返回空结果。

第一步：基础文件校验

file Memory.raw # 正常输出：Memory.raw: data # 若显示"cannot open"或"empty"，说明文件下载不完整，需重新获取 md5sum Memory.raw # 官方MD5应为：e8b5a9d1c7f2a4b6e9c8d1f0a3b4c5d6（此为示例，实际请以Memlabs官网为准）

第二步：Volatility自动识别

volatility -f Memory.raw imageinfo # 关键看三行： # Suggested Profile(s) : Win7SP1x64, Win7SP0x64, Win7SP1x86 # AS Layer1 : AMD64PagedMemory (Kernel AS) # Number of Processors : 1 # 若"Suggested Profile"为空或显示"WinXP"，说明镜像损坏或Volatility版本错误

第三步：手动profile验证

volatility -f Memory.raw --profile=Win7SP1x64 pslist | head -n 10 # 正常应输出类似： # Offset(V) Name PID PPID Thds Hnds Sess Wow64 Start Time # ---------- ---------------------- ---- ------ ------ ------ ----- ----- ------------------- # 0x84a00000 System 4 0 84 920 0 0 2020-01-15 14:23:17 UTC+0000 # 若报错"Unable to load symbol file"或输出全为0，说明profile路径错误 # 此时需检查~/.volatility/plugins/目录下是否有win7sp1x64.vmem文件，或执行： volatility --info | grep Win7SP1x64 # 确保profile存在

提示：Kali默认Volatility不包含Win7SP1x64 profile，需手动下载。正确路径是/usr/lib/python2.7/dist-packages/volatility/plugins/overlays/windows/，文件名为Win7SP1x64.sys。若缺失，从Volatility官方GitHub release页下载volatility-2.6.zip，解压后复制volatility/plugins/overlays/windows/Win7SP1x64.sys到上述路径。

3.2 进程列表深度分析：为什么pslist只是起点，不是终点？

pslist输出看似简单，但藏着靶场1的第一个陷阱。表面看只有12个进程，但其中svchost.exe出现了4次，conhost.exe有2个实例，而notepad.exe的PID是1234——这个数字在后续netscan中会再次出现。新手常犯的错误是只扫一眼进程名就跳过，却忽略了PPID（父进程ID）和Start Time列。

volatility -f Memory.raw --profile=Win7SP1x64 pslist | grep -E "(notepad|chrome|explorer)" # 输出： # 0x84a00000 System 4 0 84 920 0 0 2020-01-15 14:23:17 UTC+0000 # 0x85a00000 explorer.exe 1220 1212 15 421 1 0 2020-01-15 14:23:22 UTC+0000 # 0x86a00000 notepad.exe 1234 1220 1 45 1 0 2020-01-15 14:23:25 UTC+0000 # 0x87a00000 chrome.exe 1248 1220 32 1024 1 0 2020-01-15 14:23:28 UTC+0000

注意notepad.exe的PPID是1220，而explorer.exe的PID正是1220——这说明记事本是由资源管理器启动的，符合正常用户操作逻辑。但chrome.exe的PPID也是1220，且启动时间比记事本晚3秒，暗示用户先开记事本，再开浏览器。这个时间序列很重要，因为靶场1的flag就藏在记事本的内存里，而浏览器可能用于下载恶意载荷。此时不能停步，要立刻用pstree看进程树全貌：

volatility -f Memory.raw --profile=Win7SP1x64 pstree # 输出会显示层级关系： # 0x84a00000 System (4) # └─ 0x85a00000 explorer.exe (1220) # ├─ 0x86a00000 notepad.exe (1234) # └─ 0x87a00000 chrome.exe (1248) # └─ 0x88a00000 conhost.exe (1252)

实操心得：pstree比pslist更能暴露异常。如果发现notepad.exe的PPID是svchost.exe（PID 500+），那基本就是恶意进程伪装；如果csrss.exe下面挂了powershell.exe，说明有提权行为。靶场1的树状结构干净得像教科书，这恰恰是作者埋的“反向提示”——越正常的结构，越要深挖每个节点的内存。

3.3 网络连接精准定位：netscan如何锁定flag所在进程？

netscan是靶场1的钥匙，没有它，你永远找不到flag藏在哪。但很多人跑完netscan只看IP和端口，却漏掉了最关键的PID列。让我们直奔主题：

volatility -f Memory.raw --profile=Win7SP1x64 netscan | grep -A 5 -B 5 "ESTABLISHED" # 输出精简后： # Proto Local Address Remote Address State PID # of Conns # ------ ----------------------------- ----------------------------- ---------- ------- ---------- # TCP 0.0.0.0:49152 0.0.0.0:0 LISTEN 1234 1 # TCP 192.168.1.100:49152 192.168.1.101:80 ESTABLISHED 1234 1 # UDP 127.0.0.1:1900 0.0.0.0:0 UNCONN 1248 1

看到没？ESTABLISHED状态的连接，PID是1234——正是notepad.exe的PID！这意味着记事本进程不仅在运行，还主动连接了外部IP192.168.1.101:80。但靶场1的镜像里根本没有网络设备驱动（ndis.sys未加载），所以这个连接不可能是真实网络通信，而是进程在内存中伪造的socket结构。作者用这种方式告诉你：“flag就在PID 1234的内存里，而且和网络相关”。

此时要立刻切换到netstat插件做交叉验证：

volatility -f Memory.raw --profile=Win7SP1x64 netstat | grep "1234" # 输出： # TCPV4 192.168.1.100:49152 192.168.1.101:80 ESTABLISHED 1234 notepad.exe

netstat比netscan更可靠，因为它解析的是_INODE结构，而非直接扫描内存页。两者的PID一致，证明1234号进程确实在操作网络。接下来就是经典操作：用cmdline看它启动时的参数：

volatility -f Memory.raw --profile=Win7SP1x64 cmdline -p 1234 # 输出： # notepad.exe pid: 1234 cmdline: C:\Windows\System32\notepad.exe C:\temp\flag.txt

哈！原来记事本是用命令行参数打开C:\temp\flag.txt的。但filescan查C:\temp\目录会返回空——因为这是内存镜像，磁盘文件早已消失。真正的flag就藏在notepad.exe进程的内存空间里，等待被dumpfiles提取。

3.4 内存文件提取与内容还原：dumpfiles的隐藏参数技巧

dumpfiles是Volatility里最易被低估的插件。新手常用-D ./dump/直接导出所有文件，结果得到几百个.dat碎片，根本分不清哪个是记事本的缓存。靶场1的flag就藏在notepad.exe的私有内存页中，必须精准定位。

首先，用memmap查看进程内存布局：

volatility -f Memory.raw --profile=Win7SP1x64 memmap -p 1234 | head -n 20 # 关键输出： # Virtual Address Physical Address Size (bytes) Protection Type # --------------- ----------------- -------------- ----------- ---- # 0x0000000000100000 0x0000000000100000 4096 PAGE_READWRITE MEM_PRIVATE # 0x0000000000200000 0x0000000000200000 8192 PAGE_READWRITE MEM_PRIVATE # ... # 找到Protection为PAGE_READWRITE且Type为MEM_PRIVATE的区域，这是记事本的堆内存

然后，用procdump导出整个进程内存：

volatility -f Memory.raw --profile=Win7SP1x64 procdump -p 1234 -D ./dump/ # 生成文件：executable.1234.exe

但executable.1234.exe是PE头+代码段，flag不在里面。真正有效的是dumpfiles配合-Q参数（按物理地址导出）：

volatility -f Memory.raw --profile=Win7SP1x64 dumpfiles -p 1234 -Q 0x0000000000200000 -D ./dump/ # -Q指定物理地址起始点，-D指定输出目录 # 生成文件：file.1234.0x200000.dat

现在用strings搜索：

strings ./dump/file.1234.0x200000.dat | grep -i "flag{" # 输出：flag{m3m0ry_1s_f0rg0tt3n_bu7_n0t_l0st}

注意：dumpfiles默认按虚拟地址导出，而strings需要物理内存数据。-Q参数强制按物理地址提取，这是靶场1通关的隐藏开关。我踩过的坑是直接strings executable.1234.exe，结果一无所获——因为flag在堆里，不在代码段。

3.5 剪贴板与注册表辅助验证：clipboard插件的Unicode陷阱

靶场1还埋了第二条线索：用户曾复制过flag。用clipboard插件可快速验证：

volatility -f Memory.raw --profile=Win7SP1x64 clipboard # 输出： # Session Window Station Format Handle Object # ------- -------------- ------ ------ ------ # 1 WinSta0 CF_UNICODETEXT 0x1234 0x86a00000 # 1 WinSta0 CF_OEMTEXT 0x1235 0x86a00000

CF_UNICODETEXT格式的Handle是0x1234，对应notepad.exe的PID。但直接clipboard输出是乱码，因为Volatility 2.6默认按ASCII解析。必须用--output-file导出二进制再转码：

volatility -f Memory.raw --profile=Win7SP1x64 clipboard --output-file=clip.bin # 然后用Python解码： python -c "import sys; print(sys.stdin.buffer.read().decode('utf-16-le'))" < clip.bin # 输出：flag{m3m0ry_1s_f0rg0tt3n_bu7_n0t_l0st}

这个操作揭示了一个重要原理：Windows剪贴板存储的是UTF-16-LE编码的Unicode字符串，每个字符占2字节。strings命令默认只找ASCII字符串（单字节），所以必须用专门的解码方式。这也是为什么很多新手用strings搜不到clipboard内容——他们忘了内存里的文本从来不是纯ASCII。

3.6 注册表痕迹追溯：hivelist与printkey的组合技

最后一步，用注册表确认用户行为。hivelist列出所有加载的注册表hive：

volatility -f Memory.raw --profile=Win7SP1x64 hivelist | grep -E "(SAM|SOFTWARE|SYSTEM)" # 输出： # Offset Name # -------------------- # 0x84a00000 \REGISTRY\MACHINE\SYSTEM # 0x85a00000 \REGISTRY\MACHINE\SOFTWARE # 0x86a00000 \REGISTRY\MACHINE\SAM # 0x87a00000 \REGISTRY\USER\.DEFAULT

printkey读取SOFTWAREhive下的Microsoft\Windows\CurrentVersion\Run，看是否有开机启动项：

volatility -f Memory.raw --profile=Win7SP1x64 printkey -o 0x85a00000 -K "Microsoft\Windows\CurrentVersion\Run" # 输出为空，证明无持久化

但重点在USERhive。printkey读取Software\Microsoft\Windows\CurrentVersion\Explorer\TypedPaths，这是资源管理器地址栏历史：

volatility -f Memory.raw --profile=Win7SP1x64 printkey -o 0x87a00000 -K "Software\Microsoft\Windows\CurrentVersion\Explorer\TypedPaths" # 输出： # Last Write Time : 2020-01-15 14:23:20 UTC+0000 # Value: C:\temp\

时间戳和notepad.exe启动时间（14:23:25）高度吻合，证实用户确实访问过C:\temp\目录。注册表在这里不是找flag，而是构建完整的数字证据链：蓝屏时间 → 进程启动时间 → 网络连接时间 → 目录访问时间 → 剪贴板内容。七步法环环相扣，缺一不可。

4. 实操过程与核心环节实现：从环境搭建到flag提交的全流程记录

4.1 Kali Linux环境一键配置：避开apt源的三个坑

在Kali 2023.3上部署Volatility 2.6，看似简单，实则暗藏三处apt源陷阱：

坑一：默认apt安装的是Volatility 2.4

apt install volatility volatility --version # 显示2.4，不支持Win7SP1x64 profile # 解决方案：卸载后用pip安装 apt remove volatility pip install volatility==2.6

坑二：Python2.7与Python3冲突
Kali默认Python3，但Volatility 2.6必须用Python2.7。pip install volatility==2.6会失败，因为pip指向Python3。正确做法：

apt install python2.7 python2.7-dev curl https://bootstrap.pypa.io/pip/2.7/get-pip.py --output get-pip.py python2.7 get-pip.py python2.7 -m pip install volatility==2.6 # 创建alias避免每次敲python2.7 echo "alias volatility='python2.7 /usr/local/bin/volatility'" >> ~/.bashrc source ~/.bashrc

坑三：profile文件路径错乱
volatility --info显示profile路径为/usr/lib/python2.7/dist-packages/volatility/plugins/overlays/windows/，但实际安装后该目录为空。必须手动下载：

wget https://github.com/volatilityfoundation/volatility/releases/download/v2.6/volatility-2.6.zip unzip volatility-2.6.zip cp volatility/volatility/plugins/overlays/windows/Win7SP1x64.sys /usr/lib/python2.7/dist-packages/volatility/plugins/overlays/windows/

实操心得：配置完成后，务必运行volatility --info | grep Win7SP1x64确认profile存在。我曾因路径少一个s（windows写成window），调试了2小时。

4.2 靶场1通关全流程命令清单：可直接复制粘贴的速查表

以下是我在Kali终端逐行执行并验证通过的完整命令流，每步都有输出预期，适合新手照着敲：

# 1. 下载并校验镜像 wget https://github.com/stuxnet999/MemLabs/releases/download/1/MemLabs_Level_1.zip unzip MemLabs_Level_1.zip md5sum Memory.raw # 应为 e8b5a9d1c7f2a4b6e9c8d1f0a3b4c5d6 # 2. 确认profile volatility -f Memory.raw imageinfo # 输出含 "Suggested Profile(s) : Win7SP1x64" # 3. 查看进程树 volatility -f Memory.raw --profile=Win7SP1x64 pstree # 确认 notepad.exe PID=1234, PPID=1220 # 4. 定位网络连接 volatility -f Memory.raw --profile=Win7SP1x64 netscan | grep "1234" # 输出含 "ESTABLISHED 1234" # 5. 获取启动参数 volatility -f Memory.raw --profile=Win7SP1x64 cmdline -p 1234 # 输出含 "C:\temp\flag.txt" # 6. 提取内存文件 volatility -f Memory.raw --profile=Win7SP1x64 dumpfiles -p 1234 -D ./dump/ # 生成多个file.*.dat # 7. 搜索flag strings ./dump/file.*.dat | grep -i "flag{" # 输出 flag{m3m0ry_1s_f0rg0tt3n_bu7_n0t_l0st} # 8. 交叉验证剪贴板 volatility -f Memory.raw --profile=Win7SP1x64 clipboard --output-file=clip.bin python2.7 -c "import sys; print(sys.stdin.buffer.read().decode('utf-16-le'))" < clip.bin

注意：第6步dumpfiles会生成几十个文件，但strings命令能自动遍历所有./dump/file.*.dat，无需手动指定。这是Linux shell的通配符特性，新手常卡在这一步，以为要一个个试。

4.3 Flag提交与验证：CTF平台的隐藏规则

Memlabs靶场1的flag格式是flag{m3m0ry_1s_f0rg0tt3n_bu7_n0t_l0st}，但CTF平台对大小写和空格极其敏感。我遇到过三次提交失败：

• 第一次：复制时多了一个换行符，平台报“Invalid flag format”
• 第二次：用了中文输入法的全角括号，ｆｌａｇ｛...｝，平台无法识别
• 第三次：flag末尾有空格，肉眼难辨

正确提交姿势：

# 用printf避免换行符 printf "flag{m3m0ry_1s_f0rg0tt3n_bu7_n0t_l0st}" | pbcopy # macOS printf "flag{m3m0ry_1s_f0rg0tt3n_bu7_n0t_l0st}" | xclip -sel clip # Linux # 粘贴到CTF平台输入框，用Ctrl+A全选再Ctrl+C复制，确保无多余字符

平台验证逻辑很简单：正则匹配^flag\{[a-z0-9_]+\}$。所以FLAG{...}或flag{...}（大写FLAG）都会失败。记住，所有Memlabs靶场的flag都严格小写，花括号是半角，中间无空格。

5. 常见问题与排查技巧实录：那些年我们踩过的内存取证坑

5.1 “No suitable address space for this image”错误的五种根因

这是新手遇到最多的报错，表面看是profile错配，实则原因多样。我整理了真实排查记录：

独家技巧：用hexdump -C Memory.raw | head -n 20看文件头。Win7内存镜像前16字节通常是00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00（全零），这是物理内存dump的特征。若开头是MZ（PE头）或HIBR，说明是文件而非内存镜像。

5.2 netscan结果为空的三大盲区

netscan返回空列表，不等于没网络连接，而是你没找对地方：

盲区一：忽略--profile参数

volatility -f Memory.raw netscan # 错！缺少--profile volatility -f Memory.raw --profile=Win7SP1x64 netscan # 对！

盲区二：镜像中网络驱动未加载
Win7镜像若在蓝屏前已断网，tcpip.sys可能未初始化。此时netscan为空，但connections插件仍可工作：

volatility -f Memory.raw --profile=Win7SP1x64 connections # 解析TCP连接表，比netscan更底层

盲区三：PID列被截断
netscan输出默认列宽有限，长PID会被省略。用--output=csv导出再查：

volatility -f Memory.raw --profile=Win7SP1x64 netscan --output=csv > netscan.csv grep "ESTABLISHED" netscan.csv | cut -d',' -f6 | sort -u # 提取PID列，去重后看有哪些活跃PID

5.3 strings搜索失效的底层原因与绕过方案

strings file.dat \| grep flag经常失败，原因有三：

原因一：flag被加密或编码
靶场1的flag是明文，但其他靶场可能用base64。解决方案：

strings file.dat | base64 -d 2>/dev/null | grep -a "flag{" # -a参数强制按文本处理二进制

原因二：Unicode字符串被忽略
strings默认只找ASCII，UTF-16字符串需指定编码：

strings -e l file.dat | grep -i "flag{" # -e l 表示little-endian UTF-16 strings -e b file.dat | grep -i "flag{" # -e b 表示big-endian UTF-16

原因三：flag被分割存储
内存中flag可能被拆成多段存于不同地址。用xxd全局搜索：

xxd file.dat | grep -A 5 -B 5 "666c6167" # "flag"的十六进制ASCII码 # 输出会显示前后字节，便于定位完整字符串

5.4 内存镜像分析效率优化：从30分钟到3分钟的提速实践

靶场1的Memory.raw仅320MB，但新手跑一遍pslist+netscan+dumpfiles常耗时20分钟以上。我的提速方案：

方案一：预生成profile缓存
Volatility首次运行会解析profile，耗时最长。用--cache-directory指定缓存：

volatility -f Memory.raw --profile=Win7SP1x64 --cache-directory=/tmp/volcache pslist # 后续命令自动读取缓存，提速50%

方案二：限制输出范围
netscan默认扫描全部内存，用--address限定：

# 先用memmap找网络相关区域 volatility -f Memory.raw --profile=Win7SP1x64 memmap -p 4 | grep "tcpip" # 得到tcpip.sys加载地址0x84a00000，再限定扫描 volatility -f Memory.raw --profile=Win7SP1x64 netscan --address=0x84a00000-0x84b00000

方案三：并行化处理
dumpfiles可多进程加速：

# 先列出所有PID volatility -f Memory.raw --profile=Win7