去年秋天，进制某汽车零部件供应商的漏洞产线突然停了四个小时。原因不是扫描机械故障，而是工具一个藏在ECU固件里的栈溢出漏洞被攻击者利用，篡改了PLC的进制调度指令。事后复盘时，漏洞安全团队发现他们用了三年的扫描二进制扫描工具根本没覆盖这个指令集架构——工具只支持x86，而那个控制器跑的工具是PowerPC。

这种事在工业控制、进制物联网和嵌入式领域太常见了。漏洞二进制漏洞扫描工具，扫描说白了就是工具给那些没有源代码、或者源代码不可信的进制二进制程序做“体检”。它不像源码扫描那样能直接看懂逻辑，漏洞而是扫描得把机器码反汇编成汇编指令，再从中找危险的模式。比如函数调用时有没有检查栈边界，内存拷贝的长度是不是来自外部输入，格式化字符串的参数有没有被污染。

我见过一个挺典型的例子。某款国产路由器固件里，httpd 处理 Cookie 头时调用了 strcpy，目标缓冲区只有64字节，而HTTP头最大能到8KB。静态扫描工具通过识别 strcpy 的调用点、回溯参数来源，发现源指针直接指向了socket读取的缓冲区。这种漏洞在源码扫描里一眼就能看出来，但二进制里你得先识别出 strcpy 的PLT表项，再分析调用约定，还得处理MIPS架构下延迟槽带来的控制流干扰。

工具的实现路线分两拨。一拨是纯静态的，用IDA Pro的插件或者自己写反汇编器，提取控制流图、数据流切片，然后匹配漏洞模式。好处是快，能扫整个固件；坏处是误报高，因为二进制里很多间接跳转和虚函数调用根本解析不出来。另一拨是动态的，用QEMU或者硬件调试器跑起来，插桩记录内存访问和系统调用。这能抓到真正的执行路径，但覆盖率取决于输入样本的质量——你喂的测试用例不够刁钻，漏洞就永远触发不了。

现在比较务实的做法是动静结合。先用静态扫描把可疑函数标出来，比如所有调用了 memcpy 且长度参数来自网络包的地方。然后针对这些点做符号执行，用 angr 或者 Triton 这类框架去求解触发漏洞的具体输入。我试过对一个ARM路由器固件做这种分析，静态扫出17个候选点，符号执行跑了六个小时，最终确认了3个可远程利用的堆溢出。剩下的14个要么是误报，要么需要物理接触才能触发。

但工具再强也绕不开一个现实：二进制里没有类型信息。你看到一块内存被写入，但不知道它是结构体、数组还是函数指针。攻击者可以利用这种模糊性构造数据导向的攻击，而扫描工具只能靠启发式规则去猜。比如检测到某个地址既被当作整数比较，又被当作指针解引用，就标记为可疑。这种规则误报率不低，但在缺乏调试符号的固件里，有总比没有强。

另一个坑是混淆。商业固件经常加壳，或者用OLLVM把控制流打散成状态机。这时候反汇编出来的代码全是 while(1) switch(state) 的鬼样子，数据流分析直接崩掉。得先做去混淆，把状态变量和分发器识别出来，恢复原始跳转。这个过程半自动，经常需要人工写脚本辅助。我认识一个做固件漏洞挖掘的团队，他们养了三个工程师专门写IDA脚本处理各种变种混淆，剩下的才做漏洞分析。

成本也得算。一个能覆盖x86、ARM、MIPS、PowerPC，支持静态反汇编、动态插桩、符号执行，还能处理常见混淆的二进制扫描平台，自研的话至少投五个人年。买商业工具呢？某知名二进制分析平台按固件大小收费，一个200MB的固件扫一次报价两万美金。小厂根本玩不起，只能靠开源工具拼拼凑凑，漏报率自然下不来。

所以现实就是：二进制漏洞扫描不是买个工具就能解决的问题。它需要你懂目标架构的指令集特性，理解编译器优化带来的副作用，还得有耐心去调误报和漏报的平衡。那些指望一键扫描就能找出所有漏洞的想法，跟指望杀毒软件能防住所有APT一样不切实际。工具只是杠杆，支点还是人的判断。