计划执行与检查节点
executing-plans
按既定实施计划完成工作,保持过程检查和反馈。
re-gdb【效率与协作】GDB/pwndbg/gef 调试:attach、断点、内存读写。 触发词:gdb、调试、pwndbg、attach
独立 GitHub 快照 · 自动分类 · 以原作者文档为准
参考 [[re-analyze/platform-tips]]:动态执行默认沙箱;Linux 分支的 Wine 进程 attach 经验;直读 vs 转储 决策——attach 失败即转 [[re-memdump]]。
apt install gdb / dnf install gdb / pacman -S gdbbrew install gdb(需自签证书,一般直接用 lldb 更顺)gdb --versioncurl --proto '=https' --tlsv1.2 -LsSf 'https://install.pwndbg.re' | sh -s -- -t pwndbg-gdb
LLDB 版把 -t 换成 pwndbg-lldb;另有 Homebrew(brew install pwndbg/tap/pwndbg-gdb)、Nix 与发行版包可选。仓内 git clone + ./setup.sh 属 legacy/开发用(内部调 sudo 需 root),不再是主路径curl -L https://github.com/hugsy/gef/raw/master/gef.py -o ~/.gdbinit
~/.gdbinit,与 gef 的 ~/.gdbinit 注入方式不同;版本滚动较快,功能差异以各自官方 README 为准(详见 [[gotchas]])checksec 命令(装好 pwndbg 即用)pip install pwntools → pwn checksec --file ./targetgdb -q -ex 'checksec' -ex quit ./target 输出 NX/Canary/RELRO/PIEattach 前查 ptrace 权限:
cat /proc/sys/kernel/yama/ptrace_scope
# 1 = 仅父进程可 attach(默认);0 = 任意同属主;容器内常被强制禁止
sudo sysctl -w kernel.yama.ptrace_scope=0 # 临时放宽(重启还原)
gdb -q -p <pid> # 同属主或 root;失败(Operation not permitted)→ 见坑 1
沙箱容器内 attach 常被 seccomp 拦 → 直接走 [[re-memdump]] 转储。
断点/单步/条件断点:
(gdb) file ./target
(gdb) b *0x401000 # 地址断点
(gdb) b sym.check if argc == 2 # 条件断点
(gdb) r arg1 arg2 # 运行并传参
(gdb) ni / si # 单步(跳过/进入调用)
(gdb) c # 继续
(gdb) info b # 列出断点
带参数动态分析命令: gdb -q -ex 'b main' -ex 'r' -ex 'x/10i $rip' ./target
watch *(int*)0x601000(写触发)/ rwatch(读触发)——查密钥写入时刻/解密落点catch syscall openat——理清文件/网络行为,配合 commands ... end 自动打印参数后继续(gdb) b check
(gdb) commands
silent
printf "arg=%s\n", $rdi
continue
end
查看/修改内存与寄存器:
(gdb) x/20wx $rsp # 栈上 20 个 word
(gdb) x/s 0x601000 # 字符串
(gdb) p $rax # 寄存器
(gdb) set $rax = 0 # 改寄存器
(gdb) set {int}0x601000 = 0x90909090 # 写内存(绕过校验)
(gdb) find 0x400000, 0x410000, "flag{" # 内存搜索字符串
反调试绕过:
(gdb) p $eflags
(gdb) set $eflags = $eflags | 0x100 # 置 TF 位
ptrace(PTRACE_TRACEME) 返回值被检查 → 断在调用点直接 set $eax = 0(x86)续跑p $rax 记两次调用差值,超阈值即退出——断到比较点 patch 比较寄存器gcore 转储(默认转储优先):
(gdb) gcore out
或外部命令: gcore -o out <pid>(gdb 包附带,含寄存器/线程 ELF notes)
按 [[re-analyze/platform-tips]]「直读 vs 转储」: 默认转储优先;脱壳须等 OEP 解密后再 dump;core 直接 gdb ./target core 复盘(bt 看崩溃栈、info proc mappings 看映射)。
脚本化批处理(-x / python):
gdb -q -batch -x script.gdb ./target # 非交互跑完整脚本
script.gdb 里可含 commands ... end、define 自定义命令、python 内嵌 Python(gdb 内置 Python 解释器,pwndbg/gef 即基于此)——重复性分析(批量打印调用参数、跑通一条路径)固化成脚本复用;交互式分析结论用 gdb -q -ex ... -ex quit 一行式落档。
[[re-address-space]]:基址换算(info proc mappings 与链接地址对齐)
[[re-binary-core]]:工作流第 6 步(Linux 调试器)
[[re-anti-analysis]]:脱壳验证(断 OEP)与反调试绕过
[[re-ctf]]:pwn 调试
[[re-malware]]:Linux 恶意样本动态观察
与 [[re-memdump]] 互补(attach 失败→转储)
ptrace(PTRACE_TRACEME) 自检或 rdtsc 时间差检测调试器——先静态定位检查点再断点 patch/proc/<pid>/maps 定位 PE 镜像段)unset env LD_PRELOAD 类方式清理后 attachx/i 看断点处是否仍为 int3(自修改)、查 /proc/<pid>/maps 比对映射变化(重映射)、在异常上下文里找真实跳转目标(异常机制)、静态先找 0xCC 扫描与段校验点(反调试),再决定换断点位置 / 下内存断点 / patch 检查点(见 [[re-binary-core]] 分析方法论 R17)si 单步时触发未预期的 SIGTRAP/#DB,或单步后样本行为跳变(时间差类见"时钟对抗分三类"坑);原因——陷阱旗检测(样本读 TF 位 / 利用单步异常自身做文章)与异常处理机制反调试(int3 由样本自身 handler 接管、SEH 链承担流程跳转、异常即控制流);对策——先排除时间检测,再静态定位 pushf/lahf 后查 TF 的检查点与 int3 写入点,断 handler 入口看真实流向,patch 检查点或改用硬件断点(见 [[re-binary-core]] 分析方法论 R18)