简介：x32dbg 与 x64dbg 是 Windows 平台广受欢迎的调试器工具，本资源即为两者的整合包，面向逆向工程初学者、安全研究人员及需要分析 32 位与 64 位程序的开发者，帮助解决调试环境搭建繁琐、组件缺失的问题。压缩包共收录 151 个文件，约 25.75MB，以 56 个 dll 动态库、40 个 png 界面图标、36 个 qm 多语言翻译文件为主，另含 5 个 exe 主程序、4 个 txt 说明与 4 个 ini 配置文件，以及 chm 帮助文档、css 样式表、json 配置等辅助内容，覆盖运行、界面与本地化所需的核心组件。目前已有 398 人学习下载，说明该工具组合在调试与逆向场景中具备一定认可度。解压后可直接获得可运行的调试器目录结构，便于快速开展断点调试、反汇编查看与插件扩展，适合作为日常逆向分析的基础工具集使用。
1. 为什么调试器还要分 32 位和 64 位：一次崩溃排查引出的选型问题
很多人第一次接触 x32dbg 和 x64dbg，是在一个很具体的场景里：某个 Windows 程序双击没反应，或者跑着跑着就崩了，日志里什么都没有，这时候静态反汇编看着头疼，就想找个能单步、能看寄存器、能下断点的动态调试器。x32dbg 和 x64dbg 就是干这个的，它们是同一套开源调试器工程的两个构建版本，界面、快捷键、插件体系几乎一模一样，唯一的硬性区别是：x32dbg 只能调试 32 位进程，x64dbg 只能调试 64 位进程。这个限制不是设计偷懒，而是 Windows 的调试 API 本身就按位数分家，32 位调试器没法直接接管 64 位进程的线程上下文。
我见过太多人在这上面翻车：拿 x64dbg 去附加一个 32 位的老程序，附加不上，然后开始怀疑是不是权限问题、是不是杀软拦截，折腾半天。其实第一步就该确认目标进程的位数。这篇文章面向的是需要做 Windows 本地程序动态分析、崩溃定位、行为验证的从业者，从位数判断讲到附加、断点、脚本、插件，把 x32dbg 和 x64dbg 这套工具链怎么落地讲清楚，新手能照着跑通，熟手能看到参数边界和踩坑点。
2. 先搞清楚目标进程位数：判断方法与调试器选择
2.1 用任务管理器和 dumpbin 确认位数
选错调试器的根源是没确认目标位数。最直接的办法是打开任务管理器，在「详细信息」标签页里看进程列表，32 位进程在部分系统版本上会带「(32 位)」标注，但这个方法不稳定，不同系统版本显示不一样。更可靠的是看文件本身。Windows 自带的dumpbin可以读 PE 头，或者用 PowerShell 直接读文件头字段。
# 方法一：用 dumpbin 查看 PE 头（需要装 Visual Studio 构建工具） dumpbin /headers target.exe | findstr "machine" # 输出 x86 表示 32 位，输出 x64 表示 64 位 # machine (x86) -> 用 x32dbg # machine (x64) -> 用 x64dbg# 方法二：纯 PowerShell 读 PE 头，不依赖任何工具 $path = "C:\sample\target.exe" $fs = [System.IO.File]::OpenRead($path) $br = New-Object System.IO.BinaryReader($fs) $fs.Seek(0x3C, 'Begin') | Out-Null # 读 e_lfanew，PE 头偏移 $peOffset = $br.ReadInt32() $fs.Seek($peOffset + 4, 'Begin') | Out-Null # 跳过 "PE\0\0" $machine = $br.ReadUInt16() $br.Close(); $fs.Close() switch ($machine) { 0x014c { "32 位 (x86)，用 x32dbg" } 0x8664 { "64 位 (x64)，用 x64dbg" } default { "未知架构: 0x{0:X}" -f $machine } }逻辑说明：PE 文件偏移 0x3C 处存的是 PE 头起始位置，PE 头前 4 字节是签名，紧接着 2 字节就是 Machine 字段。0x014c 是 x86，0x8664 是 x64。这个方法不需要任何额外工具，适合在客户机器上快速判断。参数上唯一要注意的是路径必须存在且可读，如果文件被占用只读打开一般没问题，但如果是正在运行的进程镜像，建议直接对磁盘文件读，不要对进程内存读。
2.2 位数不匹配时的典型报错与应对
当你用错调试器时，x64dbg 附加 32 位进程通常会提示无法附加或附加后线程列表为空，x32dbg 附加 64 位进程则可能直接拒绝。这里有个容易忽略的点：有些程序是 32 位主进程加 64 位子进程，或者反过来，比如某些安装器、浏览器多进程架构。你附加了主进程，发现断点不触发，因为真正干活的逻辑在另一个位数的子进程里。
常见做法是先用进程树工具看清楚父子关系，再逐个确认位数。我一般会写一个批处理，把目标目录下所有 exe 的位数扫一遍，避免来回切调试器。
@echo off REM 扫描目录下所有 exe 的位数，输出建议使用的调试器 setlocal enabledelayedexpansion for %%f in (*.exe) do ( for /f "tokens=2" %%m in ('dumpbin /headers "%%f" ^| findstr /i "machine"') do ( if "%%m"=="(x86)" echo %%f -^> x32dbg if "%%m"=="(x64)" echo %%f -^> x64dbg ) ) endlocal这个脚本依赖 dumpbin 在 PATH 里。如果没有构建工具，就退回上面的 PowerShell 方案，把路径换成循环即可。参数上没什么可调的，重点是别把 dll 混进来，dll 的位数可能和主程序不同，调试时如果断点下在 dll 里，要确认那个 dll 是被哪个位数的进程加载的。
2.3 什么时候两个都要开
实际排查中经常出现混合场景：一个 32 位程序通过 IPC 或共享内存和一个 64 位服务通信，崩溃发生在交界处。这时候你没法用一个调试器看全，只能两边都开，各自附加，靠日志或共享内存内容对齐时间线。我的习惯是先在 64 位服务侧下断点确认收到的数据，再切到 32 位客户端侧看发送前的数据，中间用文件或命名管道做标记。这种做法比较笨，但比猜要靠谱。需要注意的是，两个调试器同时附加不同进程时，系统资源占用会上升，如果机器配置一般，建议关掉不必要的插件和符号加载，只保留核心功能。
3. 附加与启动：x32dbg/x64dbg 的两种接入方式和参数
3.1 启动调试和附加调试的区别
x64dbg 和 x32dbg 都支持两种接入方式：一种是「文件 → 打开」直接启动目标程序，调试器作为父进程创建它；另一种是「文件 → 附加」挂到已经在跑的进程上。这两者在行为上有实质区别。启动调试时，调试器从进程创建的第一条指令就能接管，能抓到 TLS 回调、入口点之前的初始化代码，适合分析启动阶段就崩溃或做反调试的程序。附加调试则只能从附加那一刻开始接管，之前发生的事情看不到，适合分析运行一段时间后才出问题的场景。
选择依据很简单：如果问题是「一启动就崩」，用启动调试；如果问题是「跑了几分钟才崩」，用附加调试。但有个坑：有些程序检测父进程，发现父进程是调试器就改变行为或直接退出。这时候启动调试会失败，得改用附加，或者用调试器的「隐藏调试器」相关选项，但这类对抗手段效果有限，不建议在这上面花太多时间。
3.2 命令行参数与工作目录设置
x64dbg 支持命令行启动并带参数，这在自动化或批量调试时有用。基本格式是x64dbg.exe <目标路径> [目标参数]，但工作目录默认是调试器所在目录，不是目标所在目录。如果目标程序依赖同目录下的配置文件或 dll，工作目录不对就会加载失败。
# 启动 x64dbg 并调试目标，同时指定工作目录 # 注意：x64dbg 本身没有直接的工作目录参数，需要在界面里设置 # 常见做法是先 cd 到目标目录，再用绝对路径启动调试器 cd /d C:\sample\target_dir "C:\tools\x64dbg\x64dbg.exe" "C:\sample\target_dir\app.exe" --arg1 value1逻辑说明：cd /d先切换当前目录，这样调试器继承的工作目录就是目标目录。后面的--arg1 value1是传给目标程序的参数，不是调试器的。参数说明：如果目标程序需要特定环境变量，也得在启动调试器之前设好，因为调试器会把当前环境传给子进程。我一般会写一个启动脚本，把工作目录、环境变量、参数都固定下来，避免每次手动设。
3.3 附加时的权限与进程列表过滤
附加调试最常见的失败原因是权限不足。如果目标进程以管理员权限运行，而调试器不是管理员，附加会失败。解决办法是以管理员身份运行调试器。另一个问题是进程列表太长，找目标费劲。x64dbg 的附加对话框支持按名称过滤，直接输入进程名关键字即可。
还有一个细节：系统关键进程和受保护进程无法附加，这是 Windows 的保护机制，不是调试器的问题。遇到附加不上且确认位数和权限都没问题的情况，先查一下目标是不是受保护进程。我踩过的坑是花半小时折腾一个系统进程，最后发现它根本不允许附加，血泪经验就是先确认目标是否可调试，再动手。
4. 断点、脚本与插件：把重复排查变成可复现流程
4.1 软件断点、硬件断点和内存断点的选择
x64dbg 支持多种断点类型，用错了要么不触发，要么拖慢整个系统。软件断点（INT3）最常用，把目标地址的第一个字节改成 0xCC，命中时调试器接管。优点是数量不限，缺点是会修改内存，如果程序校验自身代码完整性就会暴露。硬件断点用 CPU 的调试寄存器，最多 4 个，不修改内存，适合下在只读代码段或对抗校验的场景。内存断点监控某块内存的读写执行，适合追踪数据被谁修改，但性能开销大，范围要尽量小。
选择逻辑：普通逻辑断点用软件断点；如果程序有自校验或断点下在关键校验函数上，用硬件断点；如果要知道某个全局变量被谁改写，用内存断点并限定在变量所在页。参数上，硬件断点要指定长度（1、2、4、8 字节）和触发条件（执行、写入、读写），设错了不会触发。
4.2 用脚本批量下断点和自动记录
x64dbg 内置脚本引擎，可以批量下断点、条件断点、自动记录命中信息。这在分析循环调用或批量 API 时特别有用。下面是一个脚本示例，对多个 API 下断点并记录调用参数。
// x64dbg 脚本：对常用文件操作 API 下断点并记录路径参数 // 保存为 .txt 后在调试器里用 "脚本 -> 加载" 执行 var addr var count = 0 // 对 CreateFileW 下断点，记录第二个参数（文件路径） addr = api.CreateFileW bp addr bpcond addr, 1 // 命中时的回调逻辑（简化示意，实际用条件日志） // 在断点属性里设置日志表达式： // "CreateFileW path: {utf16@[rsp+0x10]}" // 对 WriteFile 下断点，记录写入长度 addr = api.WriteFile bp addr // 批量对注册表 API 下断点 addr = api.RegOpenKeyExW bp addr addr = api.RegSetValueExW bp addr log "断点设置完成，共设置 4 个 API 断点"逻辑说明：api.CreateFileW是调试器解析出的 API 地址，bp下断点，bpcond设条件。日志表达式里的utf16@[rsp+0x10]是按调用约定取第二个参数（x64 下前四个参数在 rcx、rdx、r8、r9，但这里用栈偏移是简化示意，实际 x64 要用寄存器）。参数说明：x64 调用约定和 x86 不同，x86 参数在栈上，x64 前四个在寄存器，写日志表达式时要区分，否则取到的是垃圾值。这个脚本的价值在于把「手动一个个下断点」变成一次执行，排查同类问题时直接复用。
4.3 插件生态与常用插件类型
x64dbg 的插件体系是它比很多商业调试器更灵活的地方。插件可以扩展反汇编视图、增加自动化分析、对接外部工具。常见的插件类型包括：反混淆插件、字符串解密插件、API 监控插件、脚本增强插件。安装方式一般是把 dll 放到调试器目录的plugins文件夹下，重启调试器即可。
选插件的原则是：只装当前任务需要的，装多了启动慢且可能冲突。我一般保持一个干净的基础环境，遇到特定需求再临时加。需要注意的是，插件和调试器位数必须匹配，32 位插件只能给 x32dbg 用，64 位插件只能给 x64dbg 用，混放会导致加载失败。这个坑很隐蔽，因为插件加载失败不一定报错，可能只是功能没出现，让人以为是插件本身的问题。
5. 避坑与排查：x32dbg/x64dbg 使用中的五个高频问题
5.1 附加成功但断点不触发
现象：调试器显示已附加，线程列表也有，但下的断点一直不命中。原因通常有三种：一是断点下在了错误的模块实例上，比如目标加载了两个同名 dll，你下在了没被调用的那个；二是断点地址在附加前就已经执行过了，比如入口点附近的代码；三是程序有反调试，检测到断点后走了另一条分支。解决：先在模块列表里确认目标模块的基址，再下断点；如果是启动阶段代码，改用启动调试；如果怀疑反调试，用硬件断点替换软件断点试试。
5.2 中文路径或空格路径导致启动失败
现象：用调试器启动目标程序，提示找不到文件或直接闪退。原因：路径里有中文或空格，调试器传参时没正确处理。解决：把目标移到纯英文无空格路径下，或者用引号把路径包起来。我一般会在项目目录里专门建一个debug_workspace纯英文目录，把要调试的样本复制进去，避免路径问题干扰。
5.3 符号加载慢或加载失败
现象：调试时函数名显示为地址，没有符号，或者加载符号时卡住。原因：符号服务器连接慢或不可达，或者没配置符号路径。解决：在「符号」设置里配置本地符号缓存目录，只加载需要的模块符号，不要全量加载。对于系统 dll，如果不需要看内部实现，直接跳过符号加载，用导出函数名就够了。参数上，符号缓存路径建议设在 SSD 上，机械硬盘加载大符号文件会很慢。
5.4 调试 64 位程序时寄存器显示异常
现象：用 x64dbg 看寄存器，发现值不对或和预期不符。原因：x64 下寄存器是 64 位的，但很多指令只操作低 32 位或低 16 位，调试器显示的是完整寄存器值，需要自己看子寄存器。解决：熟悉 rax/eax/ax/al 的对应关系，在寄存器窗口里展开看子寄存器。另一个原因是调用约定不同，x64 前四个参数在寄存器，不是栈，看参数要去寄存器里找，不能照搬 x86 的经验。
5.5 脚本执行报错但提示不明确
现象：加载脚本后执行，报错信息很模糊，不知道哪一行出问题。原因：脚本引擎对语法错误和运行时错误的提示不够细。解决：分段执行，先注释掉后半部分，确认前半部分能跑；用log输出中间变量值；确认 API 名称拼写和大小写正确。我一般会先在脚本里加一行log "start"，确认脚本被加载了，再逐步放开后续逻辑，这样能快速定位是加载问题还是执行问题。
6. 进阶技巧：用条件断点和日志表达式做无侵入追踪
当你已经能熟练附加、下断点之后，真正提升效率的是条件断点和日志表达式。这两个功能让你不用反复手动继续，就能自动筛选出关心的调用。比如一个函数被调用几千次，你只关心参数等于某个值的那次，条件断点就是干这个的。
在 x64dbg 里，右键断点 → 编辑条件，可以写表达式。x64 下第一个参数在 rcx，第二个在 rdx，第三个在 r8，第四个在 r9。假设你要在CreateFileW被调用且路径包含特定字符串时断下，条件可以写成对 rdx 指向的宽字符串做匹配。日志表达式则更进一步，不中断执行，只记录。在断点属性里勾选「日志」，填入表达式，比如记录每次调用的参数，程序继续跑，你在日志窗口看结果。
// 条件断点示例：只在第二个参数（rdx）指向的字符串以 "config" 开头时断下 // 在断点条件里填入： // strstr(utf16@rdx, "config") != 0 // 日志表达式示例：记录每次 CreateFileW 的路径，不中断 // 在断点日志里填入： // "CreateFileW: {utf16@rdx}" // 组合用法：对某个循环内的函数，只记录第 100 次之后的调用 // 需要配合脚本维护计数器，条件里判断计数器值逻辑说明：utf16@rdx表示把 rdx 当作指向 UTF-16 字符串的指针读取内容，strstr做子串匹配。参数说明：x64 下字符串指针通常在 rcx 或 rdx，具体看 API 签名；如果字符串是 ANSI 的，用ascii@而不是utf16@。日志表达式的优势是不打断程序执行，适合分析高频调用，但日志量大了会拖慢速度，建议配合条件过滤，只记录关心的部分。
另一个实用技巧是结合内存断点追踪数据流。比如你发现某个全局变量在某个时刻被改成了错误值，但不知道是谁改的。对这个变量所在的内存页下内存写入断点，程序一写就断下，调用栈直接告诉你是谁改的。这个方法的代价是性能，内存断点会让每次访问都触发异常，所以范围要尽量小，只覆盖目标变量所在的页，不要整个模块。
我自己的习惯是：先用日志表达式做一轮无侵入记录，拿到调用模式和参数分布，再针对可疑的那几次调用下条件断点，最后如果需要看数据流，才上内存断点。这个顺序能把性能开销控制在可接受范围，也避免一上来就下重断点导致程序卡死。调试器是工具，核心还是你对目标程序行为的假设和验证，工具只是帮你把假设变成可观测的事实。希望帮到你。
本文还有配套的精品资源，点击获取
语法分析器实现)
