售前问题

拿到STM32固件后，很多人第一步就想直接看伪代码，但真正容易出错的往往不是反编译按钮，而是装载方式、处理器类型、入口点和地址映射没有先对齐。Hex-Rays官方文档已经把基础路径写得很清楚，IDA先根据输入文件匹配loader，再让你确认处理器；而Cortex-M的启动方式又决定了向量表、初始栈顶和复位入口本来就是最重要的起手线索。对STM32来说，先把固件装对、入口找对、段布局理顺，再去判断芯片系列，通常会比一上来死盯某个函数更稳。

很多人把ARM程序丢进IDA Pro以后，第一反应就是直接点函数、看伪代码、找关键字符串，结果越看越乱。更稳的顺序通常不是先钻某一段逻辑，而是先确认当前代码到底被当成ARM还是Thumb，再把反汇编、交叉引用和伪代码放到一条线里看。Hex-Rays官方文档已经明确，IDA在ARM处理器模块里用虚拟段寄存器T区分ARM与Thumb，反汇编和伪代码又可以来回切换，所以看ARM代码时，先判模式，再看逻辑，效率通常会高很多。

很多人拿到bin文件以后，第一反应就是直接想看伪代码，但raw binary和PE、ELF这类带文件头的格式不一样，IDA读不出处理器类型、装载地址和段布局，所以如果前面的加载动作没做对，后面反汇编和反编译通常都会跟着偏。Hex-Rays官方资料也明确说明，bin文件更适合通过binary loader手动装入，处理器和装载位置需要用户自己确认，载入后还要把真正的代码区域手动转成代码。

很多人第一次分析so文件，最容易走偏的地方不是不会点F5，而是把so当成独立可执行文件来处理。Hex-Rays官方文档说明，IDA的反编译核心入口是伪代码窗口，既可以在反汇编和伪代码之间来回切换，也可以把选中的函数或整个应用生成C风格输出；同时，IDA里的函数窗口、导出符号窗口和入口点列表，本来就是配合定位代码结构一起用的。也就是说，分析so文件时，真正稳的顺序通常不是“先找main”，而是先让函数、导出和入口信息都浮出来，再决定从哪一层往里走。

在IDA里调DLL，最容易走偏的一点，是把“打开DLL文件”和“调试DLL”当成一回事。按Hex-Rays官方文档的口径，IDA支持调试Windows应用和DLL，也支持附加到已经在运行的进程；调试前还需要在【Debugger】里的【Process options...】配置Application、Directory和Input file这几个路径。与此同时，调试期里还有专门的【Module list】窗口，用来显示当前进程已经加载的所有模块。也就是说，调DLL的核心不是单独把DLL跑起来，而是先找到会加载它的宿主进程，再让IDA把“当前IDB对应的模块”和“运行中的模块实例”对上。

很多人用IDA Pro动态调试时，表面上看问题是“连不上”，真正根子往往有两层。一层是调试链路根本没配通，比如远程调试服务器没启动、主机地址没填、路径写成了本机路径、端口或防火墙没放行；另一层是调试器类型一开始就选错了，比如明明是gdbserver目标，却还在用本地Windows或Linux调试器。Hex-Rays官方文档把这件事分得很清楚，IDA需要先在【Debugger】【Select debugger】里选对调试器，再到【Debugger options】或【Process options】里补齐连接细节。