reverse-skills-max: initial public release (restored, redacted, hardened)
This commit is contained in:
baradok609hecl1pq6qi
140
vendor-new/rev-skills/.claude/skills/re-memdump/SKILL.md
Normal file
140
vendor-new/rev-skills/.claude/skills/re-memdump/SKILL.md
Normal file
@@ -0,0 +1,140 @@
|
||||
---
|
||||
name: re-memdump
|
||||
description: >
|
||||
内存转储与提取：默认转储优先(gcore)，直读特例。
|
||||
触发词：内存转储、dump内存、找密钥、DEX提取
|
||||
capabilities: [memory-dump]
|
||||
---
|
||||
|
||||
# 内存转储与提取
|
||||
|
||||
## 何时使用 / 何时不用
|
||||
|
||||
- 用：任何需要读进程内存的任务（找密钥/解密数据、脱壳后提取干净样本、DEX 提取）；进程已死后的 core 分析；attach 被禁时的兜底
|
||||
- 不用：实时交互调试（那是 [[re-gdb]] / [[re-lldb]] / [[re-x64dbg]] 的活）
|
||||
- 不用：静态可得的字符串/结构（静态优先）
|
||||
|
||||
## 工具准备
|
||||
|
||||
参考 [[re-analyze/platform-tips]]「直读 vs 转储」决策表与 Linux 内存转储极端段——**默认转储优先**，直读仅特例。
|
||||
|
||||
### gdb / gcore（转储主力）
|
||||
|
||||
- Linux: `apt install gdb` / `dnf install gdb` / `pacman -S gdb`（gcore 随附）
|
||||
- WSL: Linux 包
|
||||
- 验证: `gcore --help` / `gdb --version`
|
||||
|
||||
### gdb core 分析工具
|
||||
|
||||
- gdb（`gdb ./target core`）、elfutils `eu-stack`（`apt install elfutils`）、`file core`
|
||||
- 验证: `eu-stack --version`
|
||||
|
||||
### volatility（内存取证分析）
|
||||
|
||||
- 全平台: `pip install volatility3`（命令 `vol`）——Volatility 3 是当前唯一维护主线；Volatility 2 已于 2025-05-16 被 upstream 归档（只读），仅用于旧 V2-only 插件/profile 的历史镜像或结果复现，需置于隔离的 Python 2 环境，现代镜像勿作常规 fallback
|
||||
- 验证: `vol -h`；`vol -f core windows.info` 能识别镜像
|
||||
|
||||
### proc / psmisc（进程状态）
|
||||
|
||||
- Linux: `apt install procps psmisc` / `dnf install procps-ng psmisc` / `pacman -S procps-ng psmisc`（多数自带）
|
||||
- 验证: `ps aux`、`pkill` 可用
|
||||
|
||||
### Windows 转储（procdump / DumpIt，补充分支）
|
||||
|
||||
- procdump（Sysinternals 官方下载，或 `choco install sysinternals`）：`procdump -accepteula -ma <pid> out.dmp` 全进程内存转储（含托管堆）——x64dbg/windbg 可加载分析
|
||||
- DumpIt（Comae 官网）：整机物理内存转储（.raw），管理员运行——供 [[re-mem-forensics]] 整机取证
|
||||
- 验证: `procdump -accepteula -?` 输出 usage；转储产物用 `file` 确认（dmp/raw 头）
|
||||
|
||||
## 操作步骤
|
||||
|
||||
1. **默认转储：`gcore -o out <pid>`（按明文/代码 materialization 定时机）**：
|
||||
```sh
|
||||
gcore -o out <pid>
|
||||
# 或调试器内
|
||||
gdb -q -p <pid> -ex 'gcore out' -ex detach -ex quit
|
||||
```
|
||||
- 转储含完整内存 + 寄存器/线程状态（ELF notes），可直接导入 [[re-ghidra]] / [[re-ida]]
|
||||
- **时机**：转储时机由目标明文/代码的 materialization 决定——经典单层壳在真实 OEP 附近转储通常合适，但 OEP 不是通用完成判据；多阶段 loader、按需/逐页解密、虚拟化保护、反射加载、进程注入与 fake OEP 应按「写→执行转移 + 内存保护变化 + payload 头/导入恢复」定 dump 点，必要时多时点快照（见坑 2；多阶段/fake OEP 的判定正例见 [[re-unpack-simple]] 步骤 3「第一次执行即 OEP 不成立」）
|
||||
- 一次转储满足后续所有定向提取需求——不重复多次 dump
|
||||
|
||||
2. **转储前按 maps 过滤 vsyscall/vdso**：
|
||||
```sh
|
||||
cat /proc/<pid>/maps > maps.txt
|
||||
grep -E 'vsyscall|vdso|vvar' maps.txt # 这些段必须剔除
|
||||
# 只保留 r--p / rw-p 可读映射区域作为提取范围
|
||||
```
|
||||
按 [[re-analyze/platform-tips]] Linux 内存转储极端段: `[vsyscall]`（0xffffffffff600000）、`[vdso]`/`[vvar]` 读取失败正常，dump 进 core 也只是垃圾页——转储后提取时跳过，或用 maps 白名单方式直读（步骤 5）。
|
||||
|
||||
3. **导入 Ghidra/IDA 分析（core 复盘）**：
|
||||
```sh
|
||||
gdb -q ./target out # core 复盘: bt / info registers / x/gx $rsp
|
||||
eu-stack -e out | head -30 # 快速栈回溯
|
||||
```
|
||||
Ghidra: `File > Import File` 选 core（Ghidra 支持 ELF core 导入），符号/堆栈线索可用。
|
||||
- gcore 产物是单进程 ELF core，不是整机物理内存镜像——Volatility 的 `linux.pslist` 等插件只适用于整机镜像（采集方式如 LiME/`dd if=/dev/mem`），gcore 上按 [[re-mem-forensics]] 流程跑会失败；进程级枚举用 gdb/`eu-stack`/ELF core 解析与定向提取即可
|
||||
|
||||
4. **定向提取：密钥/DEX/字符串（magic 扫描）**：
|
||||
```sh
|
||||
# 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'
|
||||
```
|
||||
```python
|
||||
# 扫描指定地址范围找特定模式
|
||||
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)
|
||||
```
|
||||
密钥提取注意: 密钥可能在堆/栈上碎片化——先定位加密上下文再取（配合 [[re-ghidra]] 看调用点）。
|
||||
|
||||
5. **特例直读：maps 定址 → SIGSTOP → pread**：
|
||||
```sh
|
||||
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>
|
||||
```
|
||||
```python
|
||||
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()
|
||||
```
|
||||
- 适用: 进程必须保持运行 / 只取极小特定区段（[[re-analyze/platform-tips]] 特例①/②）
|
||||
- `/proc/<pid>/mem` 偏移是**虚拟地址**，不是文件偏移——直接 open+read 从 0 开始读必报错（见坑 3）
|
||||
|
||||
6. **Windows 侧转储（分支补齐）**：
|
||||
```sh
|
||||
procdump -accepteula -ma <pid> out.dmp # 全进程内存（含堆），windbg/x64dbg 加载
|
||||
# 整机物理内存: DumpIt 管理员运行产出 .raw → [[re-mem-forensics]]
|
||||
```
|
||||
- procdump 产物是进程级 minidump，与 gcore 同级——不是整机镜像，Volatility 不适用（[[re-mem-forensics]] 只吃整机镜像）
|
||||
- 分析入口：[[re-windbg]]（minidump 加载）/ [[re-x64dbg]]（`minidump` 命令）
|
||||
|
||||
## 跨域联合
|
||||
|
||||
- [[re-binary-core]]：工作流第 6 步（内存环节，默认转储优先）
|
||||
- [[re-sample-acquire]]：**还没确定要 dump 哪个进程/哪块内存**（只有现象、样本不落盘）时先走那边——它负责扫描异常执行区与执行上下文归属，再把目标交回本技能执行转储
|
||||
- [[re-malware]]：恶意样本内存产物提取（脱壳后样本）
|
||||
- [[re-mobile]]：App 内存中 DEX/so 提取
|
||||
- [[re-anti-analysis]]：脱壳后提取干净镜像的标准动作
|
||||
- [[re-crypto-keys]]：内存中密钥提取的方法论配合（先定位加密上下文再取，见步骤 4）
|
||||
- [[re-format-elf]]：core 是 ELF 格式，节区/notes 结构解析可对照
|
||||
- 与 [[re-gdb]] / [[re-x64dbg]] / [[re-windbg]] 互补（attach 失败→转储；需要交互→调试器；Windows 进程 dump→windbg）
|
||||
|
||||
## 常见坑与陷阱
|
||||
|
||||
- **vsyscall/vdso 读取失败正常**：`[vsyscall]` 只可执行、`[vdso]` 部分页不可读，gdb/pread 访问报错是预期行为——按 maps 过滤后提取，别当 bug 排查
|
||||
- **转储时机过早 = 壳的初始状态**：在明文/代码尚未 materialize 时 dump 拿到的是压缩/加密数据——经典单层壳在真实 OEP 附近合适，但 OEP 不是通用完成判据；多阶段 loader / 按需解密 / 虚拟化保护 / 反射加载 / 进程注入 / fake OEP 应按「写→执行转移 + 内存保护变化 + payload 头/导入恢复」定 dump 点，必要时多时点快照（见 [[re-analyze/platform-tips]] 关键经验）
|
||||
- **/proc/pid/mem 无脑 open 必报错**：直接 `open('/proc/pid/mem').read()` 会失败（偏移非法/权限）——必须 maps 定址 + SIGSTOP + chunked pread
|
||||
- core 文件可达数 GB——先 `file out` 确认是 ELF core，再按需定向提取，别整文件导入工具
|
||||
- **从转储重建进程时 vDSO 不可移植**：现象——重建/复现进程镜像后程序仍跳回原 vDSO 地址，或 `call *%gs:0x10` 间接调用断掉；原因——vDSO 地址记录在进程栈 auxv 的 `AT_SYSINFO`/`AT_SYSINFO_EHDR`，且 glibc 有缓存，修补 auxv 也不一定能重定位；对策——重建镜像时把 vDSO 相关调用视为必然失效（该页直接跳过），分析以其余映射为准
|
||||
- **gcore 取证分辨率有限**：现象——core 里查共享库注入/函数指针重定向困难，堆栈信息残缺；原因——传统 core 是内核按段快照，无每进程 profile 与符号重建；对策——普通逆向 gcore 够用；深度取证（定位注入点/hook）改用 ECFS 类内核级转储（core_pattern 挂钩重建 `.symtab`/`.dynsym`）或配合 `/proc/<pid>/maps` 手工重建
|
||||
- **看到解密数据 → 立刻保存**：现象——动态调试/转储中刚在内存里见到明文（解密字符串/密钥/第二层代码），切换工具或继续运行后该地址已被覆盖或清空，再也拿不回；原因——解密数据是阶段性的：解壳完成清理、自清除、用后即焚密钥、缓冲区复用都会立刻抹掉（注意与"转储时机过早"相反，这里是晚了就没了）；对策——动态里一确认解密产物立即 `gcore` / 定向提取（见步骤 1/4，默认转储优先），"先保存再继续"；需要再现时回到解密循环调用点重新观察（见 [[re-binary-core]] 分析方法论 R19）
|
||||
- **gcore/直读被 ptrace 权限拦**：现象——`gcore` 报 `ptrace: Operation not permitted`，`/proc/<pid>/mem` 打开即失败；原因——`kernel.yama.ptrace_scope=1/2` 限制跨进程族 attach（非 root 且目标不是自己子进程时）；对策——root 运行转储，或临时 `sysctl kernel.yama.ptrace_scope=0`（用后恢复），或经调试器（[[re-gdb]]）以允许身份执行
|
||||
@@ -0,0 +1,105 @@
|
||||
# 内存转储与提取命令速查与操作序列
|
||||
|
||||
工具族按「默认转储优先」组织：gcore/gdb（转储主力）、maps 与 /proc 文件系统（定址/直读）、grep/strings/python（定向提取）、gdb/eu-stack（core 复盘）、procdump/DumpIt（Windows 分支）。命令与参数以官方文档为准（gdb 手册、linux proc(5) 手册、Sysinternals 文档）。
|
||||
|
||||
## 命令族速查
|
||||
|
||||
### 转储（gcore / gdb）
|
||||
|
||||
- `gcore -o <前缀> <pid>` 按 pid 转储（产物 `<前缀>.<pid>`）；`gcore -a -o <前缀> <pid>` 含所有映射段
|
||||
- `gdb -q -p <pid> -ex 'gcore out' -ex detach -ex quit` 调试器内转储（attach 后可见状态再 dump）
|
||||
- `gcore --help` 验证；产物是单进程 ELF core（含线程/寄存器 notes）
|
||||
- 时机：按明文/代码 materialization 定——单层壳在真实 OEP 附近通常合适，但 OEP 不是通用完成判据（多阶段 loader/按需解密/虚拟化/反射加载/注入/fake OEP 另判，见 SKILL.md 坑「转储时机过早」）
|
||||
|
||||
### maps 定址（/proc）
|
||||
|
||||
- `cat /proc/<pid>/maps > maps.txt` 记录全部映射（地址区间/权限/路径）
|
||||
- `grep -E 'vsyscall|vdso|vvar' maps.txt` 剔除不可读极端段（见 [[re-analyze/platform-tips]] Linux 内存转储极端段）
|
||||
- `awk '$1 ~ /r/ {print $1}' maps.txt` 只保留含读权限的映射区间（提取范围白名单）
|
||||
|
||||
### 定向提取（core 内搜索）
|
||||
|
||||
- `grep -abo $'dex\n035' out` 找 DEX 魔数位置（`-b` 输出字节偏移）
|
||||
- `grep -abo '-----BEGIN' out` 找 PEM 私钥头；`grep -abo $'\x89PNG' out` 找 PNG
|
||||
- `strings -n 8 out | grep -iE 'key|secret|flag|BEGIN'` 通用字符串过滤
|
||||
- `dd if=out of=seg.bin bs=4096 skip=<偏移/4096> count=<页数>` 按块导出区间（对齐页性能好）
|
||||
- python 一次性扫描：`data.find(b'\x89PNG')` 循环取全部命中（见 SKILL.md 步骤 4 示例）
|
||||
|
||||
### 直读（/proc/<pid>/mem 特例）
|
||||
|
||||
- `kill -STOP <pid>` 先停住进程防竞态；`dd if=/proc/<pid>/mem bs=1 skip=<虚拟地址> count=<长度> of=seg.bin 2>/dev/null`（bs=1 慢，小段可用；大段用 python pread 分块）
|
||||
- python: `os.lseek(f.fileno(), <虚拟地址>, os.SEEK_SET)` + `f.read(n)`（见 SKILL.md 步骤 5 示例）；完成后 `kill -CONT <pid>`
|
||||
- 偏移是虚拟地址不是文件偏移；maps 白名单（读权限段）之外的地址读必报错——按 maps 定址再读
|
||||
|
||||
### core 复盘
|
||||
|
||||
- `file out` 确认是 ELF core（`ELF 64-bit LSB core file ...`）
|
||||
- `gdb -q ./target out` → `bt` / `info registers` / `x/gx $rsp` / `info threads`
|
||||
- `eu-stack -e out | head -30` 快速栈回溯（elfutils）
|
||||
- Ghidra: `File > Import File` 导入 core，符号/堆栈线索可用；ELF 结构细节对照 [[re-format-elf]]
|
||||
|
||||
### Windows 分支
|
||||
|
||||
- `procdump -accepteula -ma <pid> out.dmp` 全进程内存 minidump（含托管堆）
|
||||
- DumpIt（Comae，管理员）整机物理内存 .raw → [[re-mem-forensics]]
|
||||
- 分析：[[re-windbg]] 打开 .dmp；[[re-x64dbg]] 命令 `minidump <文件>` 加载
|
||||
|
||||
## 常用操作序列（组合套路）
|
||||
|
||||
### 1. 标准转储流（maps 记录 → 时机确认 → gcore → 验证 → 定向提取）
|
||||
|
||||
```
|
||||
cat /proc/<pid>/maps > maps.txt # 定址基线
|
||||
# 脱壳样本：按明文/代码 materialization 定 dump 点（单层壳常在 OEP 附近，非通用判据）
|
||||
gcore -o out <pid>
|
||||
file out # 确认 ELF core
|
||||
grep -abo $'dex\n035' out | head # 定向提取（密钥/DEX/字符串）
|
||||
strings -n 8 out | grep -iE 'key|secret|flag'
|
||||
# 一次转储满足后续所有定向提取，不重复多次 dump
|
||||
```
|
||||
|
||||
### 2. 直读特例（进程必须保持运行 / 极小区段）
|
||||
|
||||
```
|
||||
kill -STOP <pid>
|
||||
# 从 maps.txt 取目标段起始虚拟地址
|
||||
python3 - <<'EOF'
|
||||
import os
|
||||
f = open(f"/proc/{pid}/mem", "rb")
|
||||
os.lseek(f.fileno(), 0x7f0000000000, os.SEEK_SET)
|
||||
data = f.read(4096); f.close()
|
||||
EOF
|
||||
kill -CONT <pid>
|
||||
```
|
||||
|
||||
### 3. 解密数据即时捕获（动态里的「先保存再继续」）
|
||||
|
||||
```
|
||||
# 在解密循环/校验比较点命中时（调试器内）
|
||||
gdb -q -p <pid> -ex 'gcore out' -ex detach -ex quit # 立即转储
|
||||
grep -abo '-----BEGIN' out # 或直接定向提取明文区段
|
||||
# 确认产物可用后再继续运行——解密数据阶段性的，晚了就没了（见 SKILL.md 坑）
|
||||
```
|
||||
|
||||
### 4. core 复盘（进程已死 / 事后分析）
|
||||
|
||||
```
|
||||
file out
|
||||
gdb -q ./target out # bt / info registers
|
||||
eu-stack -e out | head -30 # 快速栈回溯
|
||||
# Ghidra 导入 core 看反编译与符号；ELF 结构对照 [[re-format-elf]]
|
||||
```
|
||||
|
||||
## 实现教训（内化）
|
||||
|
||||
- 转储前先存 maps：直读/提取的所有地址都以 maps.txt 为基准，别凭记忆写偏移
|
||||
- vsyscall/vdso/vvar 是垃圾页不是 bug：读失败正常，转储后提取跳过，白名单方式直读
|
||||
- 密钥/明文碎片化：先定位加密上下文（[[re-ghidra]] 看调用点）再取数据，纯扫描可能只拿到半个密钥
|
||||
- `gcore` 与 `procdump` 都是进程级镜像，整机取证（[[re-mem-forensics]]）需要 DumpIt/LiME 类整机转储——按目标选层级
|
||||
- ptrace_scope 权限拦是环境问题不是命令问题：root/降级 sysctl 前先确认目标进程归属
|
||||
|
||||
## 使用注意
|
||||
|
||||
- 动态运行样本在沙箱内执行（[[re-analyze/platform-tips]] 最高原则）；转储产物 sha256 存档（[[re-triage]]）
|
||||
- 大 core（数 GB）先 `file` 确认再按需定向提取，别整文件导入工具
|
||||
- 结论与证据（转储时间戳/地址/明文片段）写 [[re-analyze/analysis-contract]]
|
||||
@@ -0,0 +1,40 @@
|
||||
# 内存转储与提取工具特有坑与边界
|
||||
|
||||
## /proc/<pid>/mem 直读坑组
|
||||
|
||||
- **偏移是虚拟地址不是文件偏移**：直接 `open('/proc/<pid>/mem').read()` 从 0 读必报错（偏移非法）——必须按 maps 定址 + SIGSTOP + chunked pread（SKILL.md 坑 3）
|
||||
- **越界读返回 EIO**：读到的地址不在进程映射内（或只读段写）报 `Input/output error`——按 maps 白名单（含 `r` 权限区间）规划读取范围，命中 EIO 先回查 maps
|
||||
- **权限门槛**：非 root 且 `kernel.yama.ptrace_scope=1/2` 时 `/proc/<pid>/mem` 打开即失败（`Permission denied`）——root 或临时 `sysctl kernel.yama.ptrace_scope=0`（用后恢复）
|
||||
- **竞态窗口**：SIGSTOP 前/后进程可能正切换线程、回收页——先 STOP 再读，读完 CONT；多线程目标 STOP 是全进程冻结，读完后及时 CONT 避免影响行为分析
|
||||
|
||||
## core 文件坑组
|
||||
|
||||
- **gcore 是单进程 ELF core，不是整机镜像**：Volatility 的 linux.pslist 等只适用整机镜像（LiME/`dd if=/dev/mem` 类）——gcore 上跑 [[re-mem-forensics]] 流程会失败，进程级枚举用 gdb/eu-stack（SKILL.md 步骤 3 已述）
|
||||
- **vDSO 不可移植**：重建/复现进程镜像时程序跳回原 vDSO 地址或 `call *%gs:0x10` 断掉——vDSO 地址在栈 auxv 的 `AT_SYSINFO`/`AT_SYSINFO_EHDR`，修补 auxv 也不一定能重定位；重建时把 vDSO 相关调用视为必然失效（SKILL.md 坑「vDSO 不可移植」）
|
||||
- **vsyscall/vdso/vvar 读失败是预期**：`[vsyscall]` 只可执行、`[vdso]` 部分页不可读——按 maps 过滤后提取，别当 bug 排查（SKILL.md 坑 1）
|
||||
- **core 可达数 GB**：先 `file` 确认是 ELF core，再按需定向提取；整文件导入 Ghidra 前先评估体积
|
||||
- **gcore 取证分辨率有限**：共享库注入/函数指针重定向难查——深度取证改 ECFS 类内核级转储（core_pattern 挂钩重建 `.symtab`/`.dynsym`）或配合 maps 手工重建（SKILL.md 坑「gcore 取证分辨率」）
|
||||
|
||||
## 时机坑组（过早 / 过晚）
|
||||
|
||||
- **转储过早 = 壳的初始状态**：明文/代码尚未 materialize 时 dump 拿到的是压缩/加密数据——经典单层壳在真实 OEP 附近合适，但 OEP 不是通用完成判据；多阶段 loader / 按需解密 / 虚拟化保护 / 反射加载 / 进程注入 / fake OEP 按「写→执行转移 + 内存保护变化 + payload 头/导入恢复」定 dump 点，必要时多时点快照（SKILL.md 坑 2；[[re-analyze/platform-tips]] 关键经验）
|
||||
- **解密数据见后即弃**：明文是阶段性的——解壳清理、自清除、用后即焚密钥、缓冲区复用都会立刻抹掉；一确认产物立即保存，"先保存再继续"（SKILL.md 坑「看到解密数据」；需要再现回到解密循环调用点，[[re-binary-core]] 方法论 R19）
|
||||
- **转储进程生命周期**：attach 型转储要选对时机点（解密完成、校验比较点命中、C2 握手后）——同一目标不同时机 dump 内容差异巨大，取证记录时间戳
|
||||
|
||||
## 平台坑组
|
||||
|
||||
- **Windows**：procdump 进程级 minidump 与 gcore 同级——Volatility 不适用；整机镜像用 DumpIt/其他内核转储；分析入口 [[re-windbg]] / [[re-x64dbg]]（`minidump` 命令）
|
||||
- **macOS**：无 /proc 与 Linux 式 gcore——进程内存读取用 task_for_pid 类接口（lldb/自定义工具），转储用 [[re-lldb]] 的 `process save-core`（产物为 Mach-O core，`file` 确认格式）
|
||||
- **容器内**：`/proc/<pid>/maps` 看到的是容器 namespace 视角（容器内 pid ≠ 宿主机 pid）——转储先 `ps` 确认 pid 归属（宿主 pid 用 `nsenter` 或宿主机 ps 查）
|
||||
|
||||
## 版本差异
|
||||
|
||||
- **gdb/gcore**：gcore 随 gdb 发布，`-o` 前缀参数长期稳定；gdb 12+ 对 core 的 notes 处理更完整（含 x86_64 AVX 寄存器区）；老 gdb 导出的 core 在新工具链里符号解析可能偏少——核心用新版本，跨版本解析差异以实测为准
|
||||
- **elfutils（eu-stack）**：0.196 实测 `--version` 可用；eu-stack 对 core 内符号化依赖 `.symtab` 保留情况，剥离符号的 core 输出裸地址
|
||||
- **内核 core_pattern**：`core_pattern` 决定崩溃转储是传统 core 还是管道给外部工具（systemd-coredump 等）——分析崩溃转储前先确认来源格式（`coredumpctl info` 可查）
|
||||
|
||||
## 使用注意
|
||||
|
||||
- 动态运行样本在沙箱内执行（[[re-analyze/platform-tips]] 最高原则）
|
||||
- 转储产物与时间戳 sha256 存档（[[re-triage]]）；结论写 [[re-analyze/analysis-contract]]
|
||||
- 版本相关行为（gdb core 格式、/proc 语义）以目标版本实际表现为准
|
||||
Reference in New Issue
Block a user