简介IDA Pro 7.2专业版是软件逆向工程领域的行业标准反汇编器面向安全研究员、恶意软件分析人员与二进制漏洞研究者支持Windows、Linux、macOS等多平台及ARM等多种架构的静态分析与动态调试。压缩包共1006个文件大小172.71MB包含核心DLL动态库、174个签名文件、106个Python脚本、88个配置文件、87个pyd扩展模块、60个til类型库以及idc、cpp、xml等辅助文件兼顾插件运行、分析脚本、处理器模块与调试支持。已有3472人下载学习适用于从入门到中高级的逆向工程实践。借助该压缩包读者可快速搭建IDA 7.2专业环境利用内置的android_server、armlinux_server等调试服务端开展移动端逆向并结合Python脚本与反编译插件提升分析效率支撑从静态反汇编到动态调试的完整工作流。1. IDA Pro 7.2 不是普通“ida 软件”先想清楚它解决什么问题拿到一个 ARM 架构的固件包或者在 Windows 上拆一个加了壳的样本我通常不会直接拖进调试器而是先让 IDA Pro 7.2 加载一次看它能不能把入口点、导入表和关键函数串起来。很多刚入门的开发者把 IDA 当成“能看汇编的工具”实际它是一个交互式反汇编工作台识别编译器特征、剥离导入导出表、建立交叉引用再靠插件和 IDAPython 把重复分析变成批处理。7.2 这个版本虽不算新但插件生态成熟对 ARM 和 Windows 两种目标支持稳定适合固件逆向、恶意样本拆解、协议分析三类场景。下面按我拆项目的顺序把加载参数、脚本化分析和排障细节挨个讲透。2. 加载 ARM 与 Windows 二进制加载参数、自动分析与第一眼确认2.1 文件识别这一步比点“OK”更重要把文件拖进 IDA 之前我习惯先用file和十六进制工具确认真实格式。很多人吃过这个亏明明是带自解压壳的 PE或者前面带了一段引导头的固件直接按 Binary 加载分析出来的函数窗口里全是DC.B。常见做法是先用固件拆解工具binwalk扫描内部特征找到真正的代码段偏移再把它单独抠出来。file firmware_dump.bin binwalk firmware_dump.bin | head -20逻辑说明file靠文件头里的 magic number 判断格式如果输出是data说明工具没识别出已知容器binwalk则按特征库扫描压缩流、文件系统头和可执行码段。head -20只是限制输出行数避免固件特征太多刷屏。如果你看到类似ELF 32-bit LSB ARM的输出那让 IDA 自己识别即可如果看到gzip compressed data或者uImage header就要先解包再加载。这里有个容易踩坑的判断裸二进制没有文件头加载时 IDA 无法自动选择处理器必须手动填。我一般先确定目标处理器是 ARMv7 还是 Cortex-M再确定是大端还是小端。很多物联网固件实际是 ARM Little-endian 启动但引导阶段会短暂切换成 Thumb 模式这种混合模式在加载对话框里不会自动体现只能等加载完成后手动验证。所以文件识别阶段多花两分钟后面能省两小时。2.2 加载器参数ARM 与 Windows 双视角下的选择先看 Windows 下的 PE 分析。打开一个 64 位样本时IDA 会自动选metapc处理器类型加载对话框里的 Kernel options 通常不用动。真正值得关注的是“Loading segment”和“Loading offset”两个字段如果样本是 dump 出来的内存镜像基址和文件偏移不对齐这两个参数直接决定导入表和重定位能否正确解析。ARM 场景要更细一点。用 dump 工具拿到的固件段加载方式是 Binary file必须在 Processor type 里手动选ARM Little-endian。如果是 32 位代码勾选 ROM 选项并填写装载基址。基址不一定要完全准确但会影响后续所有绝对地址引用。比如路由器固件常在0x08000000嵌入式控制器的 Bootloader 常在0x00000000或0x20000000不确定时可以先把基址设成 0看入口点是否落在合理区间。目标类型加载器选择处理器类型关键参数Windows x64 PEPE 自动识别metapc基址建议保持默认勾选 Load debug infoWindows x86 dumpBinary filemetapc手动填基址按内存镜像起始地址ARM 裸固件Binary fileARM Little-endian填装载基址确认 ROM 模式ARM Cortex-MBinary fileARM Little-endian入口点往往在向量表偏移 4 处加载完成后立刻保存 IDB 是必须动作。我的习惯是原始文件、加载参数说明、初始 IDB 放同一目录文件名带日期和处理器类型比如20250111_armle_router_module.i64。这样跑批处理或反复调整分析时不用回忆十分钟前选了哪些参数。2.3 自动分析完成后先看这四个窗口状态自动分析跑完我不急着翻反汇编而是依次看四个窗口。Functions 窗口是第一个判断点正常识别时应该有几十个甚至几百个函数如果只有十几个sub_xxxx说明代码段没被正确识别。Imports 窗口对 Windows 样本几乎是定性指标看到CreateProcess、VirtualAlloc、WinExec这类 API基本能判断这不是普通程序。Strings 窗口用ShiftF12打开过滤掉编译器的默认字符串剩下的常能直接定位到路径、命令参数和 IP 地址。最后是交叉引用点一个目标字符串右键选 Xrefs to看哪些函数引用过它。这套四窗口检查不只用于验收还能定位分析方向。如果函数窗口状态不对回到 2.1 重新检查文件识别和处理器类型如果导入表为空但函数窗口正常转向 4.4 的符号加载处理。我还会用一个最小 IDAPython 脚本快速统计函数和段信息把第一眼判断变成可重复检查。import idautils print(Total functions:, len(list(idautils.Functions()))) for seg in idautils.Segments(): print(Segment %08x % seg, size, idc.get_segm_end(seg) - seg)逻辑说明第一行统计 IDB 中已识别的函数总数第二行遍历所有段并打印基址和大小。如果函数总数小于 20而段大小超过几十 KB大概率是代码识别失败。参数说明idautils.Functions()返回所有函数起始地址的迭代器idc.get_segm_end()拿段结束地址二者都是 IDAPython 内置接口在 7.2 直接可用。3. 用 IDAPython 和插件把重复劳动脚本化最小批量分析流程3.1 插件体系不是越多越好先看版本边界7.2 匹配的是特定 SDK 接口。在 Windows 上安装目录里的plugins/文件夹决定启动时加载哪些插件。第三方插件如果是在 7.5 以上环境编译的直接丢进 7.2 会出现两种情况要么菜单不出现要么一启动就崩溃。所以我在 7.2 里维持一个最小插件集官方反编译器是基础额外只装一两个对 ARM 反汇编有实际帮助的插件其余重复功能尽量用脚本实现。判断插件值不值得装只看一条标准能不能缩短“从二进制到结论”的路径。比如自动识别 ARM 标准库、把浮点指令批量替换成可读性更好的伪指令这类收益是实在的而那种把一堆面板塞进界面的插件在 7.2 里反而拖慢启动。插件优先级我排在脚本之后因为脚本看得见、改得动插件一旦黑盒化出了问题很难排查。安装新插件后打开任意 IDB在 Output 窗口看一遍加载日志确认每个插件都打印了版本信息然后再投入批量任务。这个动作我用脚本固化下来放到后面 5.3 节。3.2 最小批量分析脚本收集目标函数并导出一个常见场景ARM 固件里有一批可疑函数需要把起始地址、大小、名称和引用关系全部导出。F5 伪代码一页页看太慢直接跑脚本最稳。import idautils import idc import idaapi # 收集所有函数按起始地址排序 def collect_functions(min_size: int 16): result [] for ea in idautils.Functions(): size idc.get_func_end(ea) - ea if size min_size: name idc.get_func_name(ea) # 统计该函数被多少处代码引用 xref_count len(list(idautils.XrefsTo(ea, 0))) result.append((ea, name, size, xref_count)) # 按引用数量降序排列优先看被大量引用的枢纽函数 result.sort(keylambda x: x[3], reverseTrue) return result if __name__ __main__: funcs collect_functions(min_size16) with open(rC:\work\output\func_report.txt, w) as fp: for ea, name, size, refs in funcs: fp.write(%08X\t%s\t%d\t%d\n % (ea, name, size, refs))逻辑说明idautils.Functions()返回当前 IDB 中所有函数起始地址的迭代器idc.get_func_end(ea)拿函数结束地址相减得到大小idautils.XrefsTo(ea, 0)统计引用该函数的交叉引用数量。最后按引用数降序排序让关键节点排在最前面。参数说明min_size默认 16 字节过滤掉短小的跳板代码如果想连 ARM 常见的 veneer 序列也看改成 1 即可。输出文件四列分别是起始地址、函数名、字节大小、引用次数制表符分隔可以直接导入表格工具。运行方式有三种菜单File Script file在 IDAPython 命令行里粘贴以及ida -S加载时自动执行。第三种方式在批量场景里最有用下一章会专门讲批处理参数。3.3 脚本参数怎么调地址范围、递归深度与超时批量脚本最容易翻车的不是语法而是范围失控。早期我写过一个递归遍历交叉引用的脚本从入口点往上追结果在 ARM 数据段上跑了几十层深把 IDB 拖到几个 GB。所以现在所有脚本都固定三个参数。第一个是max_depth递归深度。ARM 跳转表经常互相引用设置为 5 到 10 就足够超过这个值基本是数据被误判成代码导致的死循环。第二个是addr_start和addr_end限定只分析指定段。对固件来说代码段通常在.text或指定装载段不要直接拿整个地址空间去跑。第三个是timeout每个函数的处理超时。Windows 样本里的大函数反编译可能跑到分钟级设置 30 秒并跳过可以避免批处理卡死。拿上面 3.2 的脚本举例min_size已经承担了过滤作用。如果要把地址范围封进去在循环里加两个比较判断即可if ea addr_start or ea addr_end: continue。逻辑不算复杂但能把大批量任务从“跑完才知道有问题”变成“开始前就锁定边界”。4. 常见问题与避坑清单ARM 加载乱、分析卡死、插件崩溃怎么办4.1 ARM 固件加载后反汇编稀碎现象加载完一个裸 ARM 固件函数窗口里只有零散几个函数反汇编视图大部分是dc.b按 F5 无法生成伪代码。原因绝大多数是处理器类型或指令集模式选错。比如实际是 Thumb 代码按 ARM Little-endian 加载指令边界全部错位另一种情况是固件头部有一段 CPU 配置代码自动分析把配置数据当成了指令污染了后续分析。解决先把光标放到疑似代码段起始地址按C强制定义指令如果看到一串合理指令按P生成函数。然后进Options General Analysis把处理器选项里的 ARM/Thumb 模式切到 Thumb再重新跑一次自动分析。如果问题是数据被误判为指令选中那一段地址按U取消指令定义再用 Create Segment 把数据段单独划分出去。我会在加载前用拆分工具把引导头和真正代码段分开能省掉后面一大半排障。4.2 分析卡死在“Wait”现象、原因、解决现象打开文件后 IDA 状态栏一直显示 Analyzing进度条不动CPU 占用保持 100%Windows 上分析加壳样本时尤其明显。原因递归下降反汇编遇到数据区的随机字节产生大量不可达分支插件参与自动分析时可能把某些地址误标成代码并继续向下推广。解决先关闭自动分析再加载。加载时在对话框里取消勾选 Load resources 和 Load debug info同时进入Options General Analysis把 Auto-analysis 的花式选项全关掉。等手动清掉明显的数据区域再重新开启自动分析。另一个手段是把 Kernel analysis 的自动函数分析关掉改用手动创建函数的方式。如果仍然卡死就在命令行用ida -A以批处理模式加载它会跳过 GUI 刷新至少能把分析过程跑完。4.3 插件一启动就崩现象、原因、解决现象把下载的插件放进plugins/目录后IDA Pro 7.2 一启动就闪退或者打开任意文件后插件菜单点击无响应。原因典型原因是插件编译时用的 SDK 版本与 7.2 不匹配依赖了不存在的接口还有一部分插件需要 Python 3而 7.2 的 Windows 版绑定的是 2.7 运行环境或者反过来。解决不要急着删文件先把第三方插件全部移到一个备份目录确认 IDA 能正常打开。然后逐个放回每放一个启动一次。确认是某个插件导致后看插件文档里要求的 SDK 版本和 7.2 比对不匹配就放弃或者用 IDAPython 脚本重写该插件核心功能。IDAPython 出现 ImportError 时先在脚本里输出sys.version确认当前解释器版本和插件依赖一致。4.4 符号、重定位与签名素材三连坑现象Windows 样本的导入表窗口一片空白所有函数名都是sub_和loc_F5 伪代码里变量名全是v1、v2基本无意义。原因三类问题。一是 PE 导入表被加密或压缩加载时没解析出来二是 IDA 的签名库找不到匹配的标准库函数常见于用新版编译器生成的目标文件三是重定位符号没解析指针值直接按装载地址显示。解决先用Options Load file Load additional binary file把导入表重新解析再看 Output 窗口有没有签名加载的 warning。可以手动选择 Microsoft VC、ARM 编译器签名库来匹配。如果这些都不行用启发式方法把所有push加固定pc相对跳转的指令模式识别成函数边界。这个方法不完美但在没有符号的情况下比全手工快很多。5. 让 7.2 变成可重复的工具链批处理模式、签名固化与自检脚本5.1 批处理模式的标准姿势与参数边界如果每天要处理十多个样本手工打开 GUI 再一步步加载不现实。IDA 7.2 支持无头模式通过命令行直接加载目标文件并执行脚本输出日志。ida64 -A -LC:\work\logs\batch_case01.log -SC:\work\scripts\analyze_batch.py C:\work\samples\case01.bin逻辑说明-A让所有交互对话框自动选择默认值-L把 Output 窗口内容写入日志-S指定加载完成后执行的 IDAPython 脚本。日志会保留完整的签名加载记录和报错堆栈排障时先看日志再看脚本。参数说明ida64是 64 位版本如果目标是 32 位可以换idat32-S后的脚本路径建议用绝对路径因为工作目录在不同环境里变化很大。批处理有一个血泪经验脚本跑完没有显式退出时IDA 可能停留在某个对话框里挂住。所以脚本末尾一般要主动退出进程并把结果写到独立文件后再退出避免任务管理器里留一个僵尸进程。5.2 用 IDB 复用和 FLIRT 签名固化分析结果IDB 是一次性分析资产的载体。批处理后生成的.i64文件重新打开之前手工确认的函数、段边界、注释都在。处理完同一厂商的多台设备固件我会保留一个母版 IDB第二台设备直接复用母版的段划分再用脚本修正基址差异。这样能避免对每台设备重复做加载器诊断。签名固化是另一个方向。对重复出现的私有库先把一个已分析 IDB 中该库的全部函数导出为.pat文件再用签名工具生成私有签名文件放到签名目录。生成后重新加载同一固件函数窗口里很多sub_会恢复成函数名F5 可读性明显提升。注意签名库文件名要带厂商缩写避免覆盖官方签名。5.3 插件自检脚本一条命令验证整套环境插件装多了以后版本冲突很难靠肉眼排查。我写了一个自检脚本每次新样本开批之前先跑一遍。import ida_auto import ida_loader import idaapi import sys import os print([CHECK] IDA version:, idaapi.get_ida_version()) print([CHECK] Python:, sys.version.split()[0]) plugin_dir idaapi.get_plugin_path() for f in [arm_helper.py, report_batch.py]: path os.path.join(plugin_dir, f) print([CHECK], f, OK if os.path.exists(path) else MISSING)逻辑说明脚本在 IDA 内部运行输出运行时版本号并检查期望存在的插件文件。参数说明get_ida_version()返回运行时版本如果版本号和你以为的不一致说明安装目录可能被高版本残留污染get_plugin_path()返回插件目录之一如果插件安装在用户目录需要额外拼接两个路径再检查。这套检查三十秒内能定位八成插件加载问题。6. 收尾技巧用头文件和类型库把 ARM 代码还原度拉高6.1 加载类型库的时机与参数很多 ARM 固件虽然格式私有内部却调用了标准 C 库和厂商 SDK。手工识别结构体太慢正确做法是在反编译之前加载类型库。选File Load file Parse C header file把目标 SDK 的头文件解析成类型信息或者通过 Type Libraries 装载已有的.til。建议一次只加载一个头文件避免重复定义冲突。时机选择在自动分析完成后、开始人工注释前太早会让分析器多跑几轮太晚则反编译结果已经定型。出错时看错误类型名REDEFINE一般直接跳过UNKNOWN则要检查头文件路径是否完整。6.2 插件和脚本工作状态的快速验证清单按我的习惯换新样本后先花几分钟过一遍表格里的检查项能判断这个样本能不能深度分析。检查项目标状态如果不对怎么办Functions 窗口有几十个命名函数而不是十几个 sub_重新确认处理器类型和代码段边界ImportsWindows 样本能看清 API 名检查 PE 导入表或重载符号F5 可用主函数按 F5 出伪代码先强制创建函数再反编译插件菜单目标插件按钮可点看启动日志按版本匹配处理模拟项目X时我偷懒少跑了一次自检脚本直接拉了一整晚的批处理结果整批固件都因为 Thumb 模式没切换而输出了一堆不可读汇编。从那以后每次换新样本我都在-A跑批之前强制走一遍自检脚本确认日志里没有 processor mismatch 字样再开始批量任务。这条教训换来的习惯一直保留到现在。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/18 11:48:54 · 阅读 1.2k IDA Pro 7.2实战：ARM固件与Windows样本逆向分析
简介IDA Pro 7.2专业版是软件逆向工程领域的行业标准反汇编器面向安全研究员、恶意软件分析人员与二进制漏洞研究者支持Windows、Linux、macOS等多平台及ARM等多种架构的静态分析与动态调试。压缩包共1006个文件大小172.71MB包含核心DLL动态库、174个签名文件、106个Python脚本、88个配置文件、87个pyd扩展模块、60个til类型库以及idc、cpp、xml等辅助文件兼顾插件运行、分析脚本、处理器模块与调试支持。已有3472人下载学习适用于从入门到中高级的逆向工程实践。借助该压缩包读者可快速搭建IDA 7.2专业环境利用内置的android_server、armlinux_server等调试服务端开展移动端逆向并结合Python脚本与反编译插件提升分析效率支撑从静态反汇编到动态调试的完整工作流。1. IDA Pro 7.2 不是普通“ida 软件”先想清楚它解决什么问题拿到一个 ARM 架构的固件包或者在 Windows 上拆一个加了壳的样本我通常不会直接拖进调试器而是先让 IDA Pro 7.2 加载一次看它能不能把入口点、导入表和关键函数串起来。很多刚入门的开发者把 IDA 当成“能看汇编的工具”实际它是一个交互式反汇编工作台识别编译器特征、剥离导入导出表、建立交叉引用再靠插件和 IDAPython 把重复分析变成批处理。7.2 这个版本虽不算新但插件生态成熟对 ARM 和 Windows 两种目标支持稳定适合固件逆向、恶意样本拆解、协议分析三类场景。下面按我拆项目的顺序把加载参数、脚本化分析和排障细节挨个讲透。2. 加载 ARM 与 Windows 二进制加载参数、自动分析与第一眼确认2.1 文件识别这一步比点“OK”更重要把文件拖进 IDA 之前我习惯先用file和十六进制工具确认真实格式。很多人吃过这个亏明明是带自解压壳的 PE或者前面带了一段引导头的固件直接按 Binary 加载分析出来的函数窗口里全是DC.B。常见做法是先用固件拆解工具binwalk扫描内部特征找到真正的代码段偏移再把它单独抠出来。file firmware_dump.bin binwalk firmware_dump.bin | head -20逻辑说明file靠文件头里的 magic number 判断格式如果输出是data说明工具没识别出已知容器binwalk则按特征库扫描压缩流、文件系统头和可执行码段。head -20只是限制输出行数避免固件特征太多刷屏。如果你看到类似ELF 32-bit LSB ARM的输出那让 IDA 自己识别即可如果看到gzip compressed data或者uImage header就要先解包再加载。这里有个容易踩坑的判断裸二进制没有文件头加载时 IDA 无法自动选择处理器必须手动填。我一般先确定目标处理器是 ARMv7 还是 Cortex-M再确定是大端还是小端。很多物联网固件实际是 ARM Little-endian 启动但引导阶段会短暂切换成 Thumb 模式这种混合模式在加载对话框里不会自动体现只能等加载完成后手动验证。所以文件识别阶段多花两分钟后面能省两小时。2.2 加载器参数ARM 与 Windows 双视角下的选择先看 Windows 下的 PE 分析。打开一个 64 位样本时IDA 会自动选metapc处理器类型加载对话框里的 Kernel options 通常不用动。真正值得关注的是“Loading segment”和“Loading offset”两个字段如果样本是 dump 出来的内存镜像基址和文件偏移不对齐这两个参数直接决定导入表和重定位能否正确解析。ARM 场景要更细一点。用 dump 工具拿到的固件段加载方式是 Binary file必须在 Processor type 里手动选ARM Little-endian。如果是 32 位代码勾选 ROM 选项并填写装载基址。基址不一定要完全准确但会影响后续所有绝对地址引用。比如路由器固件常在0x08000000嵌入式控制器的 Bootloader 常在0x00000000或0x20000000不确定时可以先把基址设成 0看入口点是否落在合理区间。目标类型加载器选择处理器类型关键参数Windows x64 PEPE 自动识别metapc基址建议保持默认勾选 Load debug infoWindows x86 dumpBinary filemetapc手动填基址按内存镜像起始地址ARM 裸固件Binary fileARM Little-endian填装载基址确认 ROM 模式ARM Cortex-MBinary fileARM Little-endian入口点往往在向量表偏移 4 处加载完成后立刻保存 IDB 是必须动作。我的习惯是原始文件、加载参数说明、初始 IDB 放同一目录文件名带日期和处理器类型比如20250111_armle_router_module.i64。这样跑批处理或反复调整分析时不用回忆十分钟前选了哪些参数。2.3 自动分析完成后先看这四个窗口状态自动分析跑完我不急着翻反汇编而是依次看四个窗口。Functions 窗口是第一个判断点正常识别时应该有几十个甚至几百个函数如果只有十几个sub_xxxx说明代码段没被正确识别。Imports 窗口对 Windows 样本几乎是定性指标看到CreateProcess、VirtualAlloc、WinExec这类 API基本能判断这不是普通程序。Strings 窗口用ShiftF12打开过滤掉编译器的默认字符串剩下的常能直接定位到路径、命令参数和 IP 地址。最后是交叉引用点一个目标字符串右键选 Xrefs to看哪些函数引用过它。这套四窗口检查不只用于验收还能定位分析方向。如果函数窗口状态不对回到 2.1 重新检查文件识别和处理器类型如果导入表为空但函数窗口正常转向 4.4 的符号加载处理。我还会用一个最小 IDAPython 脚本快速统计函数和段信息把第一眼判断变成可重复检查。import idautils print(Total functions:, len(list(idautils.Functions()))) for seg in idautils.Segments(): print(Segment %08x % seg, size, idc.get_segm_end(seg) - seg)逻辑说明第一行统计 IDB 中已识别的函数总数第二行遍历所有段并打印基址和大小。如果函数总数小于 20而段大小超过几十 KB大概率是代码识别失败。参数说明idautils.Functions()返回所有函数起始地址的迭代器idc.get_segm_end()拿段结束地址二者都是 IDAPython 内置接口在 7.2 直接可用。3. 用 IDAPython 和插件把重复劳动脚本化最小批量分析流程3.1 插件体系不是越多越好先看版本边界7.2 匹配的是特定 SDK 接口。在 Windows 上安装目录里的plugins/文件夹决定启动时加载哪些插件。第三方插件如果是在 7.5 以上环境编译的直接丢进 7.2 会出现两种情况要么菜单不出现要么一启动就崩溃。所以我在 7.2 里维持一个最小插件集官方反编译器是基础额外只装一两个对 ARM 反汇编有实际帮助的插件其余重复功能尽量用脚本实现。判断插件值不值得装只看一条标准能不能缩短“从二进制到结论”的路径。比如自动识别 ARM 标准库、把浮点指令批量替换成可读性更好的伪指令这类收益是实在的而那种把一堆面板塞进界面的插件在 7.2 里反而拖慢启动。插件优先级我排在脚本之后因为脚本看得见、改得动插件一旦黑盒化出了问题很难排查。安装新插件后打开任意 IDB在 Output 窗口看一遍加载日志确认每个插件都打印了版本信息然后再投入批量任务。这个动作我用脚本固化下来放到后面 5.3 节。3.2 最小批量分析脚本收集目标函数并导出一个常见场景ARM 固件里有一批可疑函数需要把起始地址、大小、名称和引用关系全部导出。F5 伪代码一页页看太慢直接跑脚本最稳。import idautils import idc import idaapi # 收集所有函数按起始地址排序 def collect_functions(min_size: int 16): result [] for ea in idautils.Functions(): size idc.get_func_end(ea) - ea if size min_size: name idc.get_func_name(ea) # 统计该函数被多少处代码引用 xref_count len(list(idautils.XrefsTo(ea, 0))) result.append((ea, name, size, xref_count)) # 按引用数量降序排列优先看被大量引用的枢纽函数 result.sort(keylambda x: x[3], reverseTrue) return result if __name__ __main__: funcs collect_functions(min_size16) with open(rC:\work\output\func_report.txt, w) as fp: for ea, name, size, refs in funcs: fp.write(%08X\t%s\t%d\t%d\n % (ea, name, size, refs))逻辑说明idautils.Functions()返回当前 IDB 中所有函数起始地址的迭代器idc.get_func_end(ea)拿函数结束地址相减得到大小idautils.XrefsTo(ea, 0)统计引用该函数的交叉引用数量。最后按引用数降序排序让关键节点排在最前面。参数说明min_size默认 16 字节过滤掉短小的跳板代码如果想连 ARM 常见的 veneer 序列也看改成 1 即可。输出文件四列分别是起始地址、函数名、字节大小、引用次数制表符分隔可以直接导入表格工具。运行方式有三种菜单File Script file在 IDAPython 命令行里粘贴以及ida -S加载时自动执行。第三种方式在批量场景里最有用下一章会专门讲批处理参数。3.3 脚本参数怎么调地址范围、递归深度与超时批量脚本最容易翻车的不是语法而是范围失控。早期我写过一个递归遍历交叉引用的脚本从入口点往上追结果在 ARM 数据段上跑了几十层深把 IDB 拖到几个 GB。所以现在所有脚本都固定三个参数。第一个是max_depth递归深度。ARM 跳转表经常互相引用设置为 5 到 10 就足够超过这个值基本是数据被误判成代码导致的死循环。第二个是addr_start和addr_end限定只分析指定段。对固件来说代码段通常在.text或指定装载段不要直接拿整个地址空间去跑。第三个是timeout每个函数的处理超时。Windows 样本里的大函数反编译可能跑到分钟级设置 30 秒并跳过可以避免批处理卡死。拿上面 3.2 的脚本举例min_size已经承担了过滤作用。如果要把地址范围封进去在循环里加两个比较判断即可if ea addr_start or ea addr_end: continue。逻辑不算复杂但能把大批量任务从“跑完才知道有问题”变成“开始前就锁定边界”。4. 常见问题与避坑清单ARM 加载乱、分析卡死、插件崩溃怎么办4.1 ARM 固件加载后反汇编稀碎现象加载完一个裸 ARM 固件函数窗口里只有零散几个函数反汇编视图大部分是dc.b按 F5 无法生成伪代码。原因绝大多数是处理器类型或指令集模式选错。比如实际是 Thumb 代码按 ARM Little-endian 加载指令边界全部错位另一种情况是固件头部有一段 CPU 配置代码自动分析把配置数据当成了指令污染了后续分析。解决先把光标放到疑似代码段起始地址按C强制定义指令如果看到一串合理指令按P生成函数。然后进Options General Analysis把处理器选项里的 ARM/Thumb 模式切到 Thumb再重新跑一次自动分析。如果问题是数据被误判为指令选中那一段地址按U取消指令定义再用 Create Segment 把数据段单独划分出去。我会在加载前用拆分工具把引导头和真正代码段分开能省掉后面一大半排障。4.2 分析卡死在“Wait”现象、原因、解决现象打开文件后 IDA 状态栏一直显示 Analyzing进度条不动CPU 占用保持 100%Windows 上分析加壳样本时尤其明显。原因递归下降反汇编遇到数据区的随机字节产生大量不可达分支插件参与自动分析时可能把某些地址误标成代码并继续向下推广。解决先关闭自动分析再加载。加载时在对话框里取消勾选 Load resources 和 Load debug info同时进入Options General Analysis把 Auto-analysis 的花式选项全关掉。等手动清掉明显的数据区域再重新开启自动分析。另一个手段是把 Kernel analysis 的自动函数分析关掉改用手动创建函数的方式。如果仍然卡死就在命令行用ida -A以批处理模式加载它会跳过 GUI 刷新至少能把分析过程跑完。4.3 插件一启动就崩现象、原因、解决现象把下载的插件放进plugins/目录后IDA Pro 7.2 一启动就闪退或者打开任意文件后插件菜单点击无响应。原因典型原因是插件编译时用的 SDK 版本与 7.2 不匹配依赖了不存在的接口还有一部分插件需要 Python 3而 7.2 的 Windows 版绑定的是 2.7 运行环境或者反过来。解决不要急着删文件先把第三方插件全部移到一个备份目录确认 IDA 能正常打开。然后逐个放回每放一个启动一次。确认是某个插件导致后看插件文档里要求的 SDK 版本和 7.2 比对不匹配就放弃或者用 IDAPython 脚本重写该插件核心功能。IDAPython 出现 ImportError 时先在脚本里输出sys.version确认当前解释器版本和插件依赖一致。4.4 符号、重定位与签名素材三连坑现象Windows 样本的导入表窗口一片空白所有函数名都是sub_和loc_F5 伪代码里变量名全是v1、v2基本无意义。原因三类问题。一是 PE 导入表被加密或压缩加载时没解析出来二是 IDA 的签名库找不到匹配的标准库函数常见于用新版编译器生成的目标文件三是重定位符号没解析指针值直接按装载地址显示。解决先用Options Load file Load additional binary file把导入表重新解析再看 Output 窗口有没有签名加载的 warning。可以手动选择 Microsoft VC、ARM 编译器签名库来匹配。如果这些都不行用启发式方法把所有push加固定pc相对跳转的指令模式识别成函数边界。这个方法不完美但在没有符号的情况下比全手工快很多。5. 让 7.2 变成可重复的工具链批处理模式、签名固化与自检脚本5.1 批处理模式的标准姿势与参数边界如果每天要处理十多个样本手工打开 GUI 再一步步加载不现实。IDA 7.2 支持无头模式通过命令行直接加载目标文件并执行脚本输出日志。ida64 -A -LC:\work\logs\batch_case01.log -SC:\work\scripts\analyze_batch.py C:\work\samples\case01.bin逻辑说明-A让所有交互对话框自动选择默认值-L把 Output 窗口内容写入日志-S指定加载完成后执行的 IDAPython 脚本。日志会保留完整的签名加载记录和报错堆栈排障时先看日志再看脚本。参数说明ida64是 64 位版本如果目标是 32 位可以换idat32-S后的脚本路径建议用绝对路径因为工作目录在不同环境里变化很大。批处理有一个血泪经验脚本跑完没有显式退出时IDA 可能停留在某个对话框里挂住。所以脚本末尾一般要主动退出进程并把结果写到独立文件后再退出避免任务管理器里留一个僵尸进程。5.2 用 IDB 复用和 FLIRT 签名固化分析结果IDB 是一次性分析资产的载体。批处理后生成的.i64文件重新打开之前手工确认的函数、段边界、注释都在。处理完同一厂商的多台设备固件我会保留一个母版 IDB第二台设备直接复用母版的段划分再用脚本修正基址差异。这样能避免对每台设备重复做加载器诊断。签名固化是另一个方向。对重复出现的私有库先把一个已分析 IDB 中该库的全部函数导出为.pat文件再用签名工具生成私有签名文件放到签名目录。生成后重新加载同一固件函数窗口里很多sub_会恢复成函数名F5 可读性明显提升。注意签名库文件名要带厂商缩写避免覆盖官方签名。5.3 插件自检脚本一条命令验证整套环境插件装多了以后版本冲突很难靠肉眼排查。我写了一个自检脚本每次新样本开批之前先跑一遍。import ida_auto import ida_loader import idaapi import sys import os print([CHECK] IDA version:, idaapi.get_ida_version()) print([CHECK] Python:, sys.version.split()[0]) plugin_dir idaapi.get_plugin_path() for f in [arm_helper.py, report_batch.py]: path os.path.join(plugin_dir, f) print([CHECK], f, OK if os.path.exists(path) else MISSING)逻辑说明脚本在 IDA 内部运行输出运行时版本号并检查期望存在的插件文件。参数说明get_ida_version()返回运行时版本如果版本号和你以为的不一致说明安装目录可能被高版本残留污染get_plugin_path()返回插件目录之一如果插件安装在用户目录需要额外拼接两个路径再检查。这套检查三十秒内能定位八成插件加载问题。6. 收尾技巧用头文件和类型库把 ARM 代码还原度拉高6.1 加载类型库的时机与参数很多 ARM 固件虽然格式私有内部却调用了标准 C 库和厂商 SDK。手工识别结构体太慢正确做法是在反编译之前加载类型库。选File Load file Parse C header file把目标 SDK 的头文件解析成类型信息或者通过 Type Libraries 装载已有的.til。建议一次只加载一个头文件避免重复定义冲突。时机选择在自动分析完成后、开始人工注释前太早会让分析器多跑几轮太晚则反编译结果已经定型。出错时看错误类型名REDEFINE一般直接跳过UNKNOWN则要检查头文件路径是否完整。6.2 插件和脚本工作状态的快速验证清单按我的习惯换新样本后先花几分钟过一遍表格里的检查项能判断这个样本能不能深度分析。检查项目标状态如果不对怎么办Functions 窗口有几十个命名函数而不是十几个 sub_重新确认处理器类型和代码段边界ImportsWindows 样本能看清 API 名检查 PE 导入表或重载符号F5 可用主函数按 F5 出伪代码先强制创建函数再反编译插件菜单目标插件按钮可点看启动日志按版本匹配处理模拟项目X时我偷懒少跑了一次自检脚本直接拉了一整晚的批处理结果整批固件都因为 Thumb 模式没切换而输出了一堆不可读汇编。从那以后每次换新样本我都在-A跑批之前强制走一遍自检脚本确认日志里没有 processor mismatch 字样再开始批量任务。这条教训换来的习惯一直保留到现在。希望帮到你。本文还有配套的精品资源点击获取