最近用GPT-5.6 Sol分析了几份SO，感觉它处理二进制文件比以前实用了不少。上传文件后，ChatGPT可以调用工具读取ELF结构、符号、字符串和重定位信息，再把零散结果整理出来，省去了不少手动筛查时间。
这次我准备了两款手游中的安全模块，想看看在相同分析口径下，FairGuard和腾讯ACE各自会留下多少静态信息。测试流程与结果整理如下，感兴趣的朋友可以做下复现：
测试对象
| 游戏 | 版本号 | 加固产品 | 测试文件 |
|---|---|---|---|
| 《闪烁之光》 | 4.4.8 | FairGuard | libFairGuard.so |
| 《火影忍者》 | 1.79.79.9 | 腾讯ACE | libtersafe.so |
解压游戏包后，在lib/arm64-v8a目录中找到对应的安全模块。将两个SO上传至ChatGPT，模型选择GPT-5.6 Sol，推理强度开到“极高”，输入指令：
分析两个SO文件的加固强度并进行量化对比。
ChatGPT完成分析后，我又对ELF结构、符号、字符串、重定位和函数展开信息进行了复核。以下为GPT-5.6 Sol给出的测试结果，数据和判断保留原文，最后会附上完整的分析截图。
测试结果
从两个SO的静态信息隐藏和分析阻力来看，FairGuard明显强于腾讯ACE。差距并非来自文件体积或单一熵值，而是同时体现在ELF结构、符号表、字符串、重定位和函数边界信息上。
一、样本信息
| 项目 | FairGuard | 腾讯ACE |
|---|---|---|
| 文件 | libFairGuard.so |
libtersafe.so |
| SHA-256 | e34dd793cb58f360fc235e0375486a9a116154d664724ce5e688a46c611bf4fe |
517f1e3891e7a7c5dd8254bedcb09a5fe1d2acb0147cec757efb3a06ec5b2a10 |
| 架构 | AArch64 | AArch64 |
| 文件大小 | 5.16 MiB | 5.52 MiB |
| ELF类型 | 64位共享库 | 64位共享库 |
| Strip | 是 | 是 |
| ELF入口 | 0xfe00 |
0x0 |
两个文件架构相同、体积接近，具备较好的静态对比基础。
二、ELF结构隐藏
| 指标 | FairGuard | 腾讯ACE |
|---|---|---|
| 节区数量 | 21 | 28 |
| 程序段数量 | 6 | 9 |
| 节区表覆盖文件比例 | 6.94% | 99.96% |
| 最大无节区描述区域 | 4,805,144字节 | 1,799字节 |
| 最大无节区区域占比 | 88.80% | 0.03% |
| 声明的.text大小 | 16字节 | 3,590,944字节 |
| .text零字节比例 | 100% | 10.10% |
| RX段中可执行节区覆盖率 | 0.0039% | 65.74% |
FairGuard的.text只有16字节，而且全部为零，显然不是实际代码主体。其入口0xfe00位于节区表没有描述的区域，文件中还有一段占比88.8%的大型无节区区域。
常规分析工具打开FairGuard模块后，无法直接依赖节区表建立代码地图。腾讯ACE保持了较为标准的布局，.text、.rodata、.eh_frame、重定位表和版本表都能正常定位，节区表几乎覆盖整个文件。
三、动态符号与接口暴露
| 指标 | FairGuard | 腾讯ACE |
|---|---|---|
| 动态符号总数 | 1,028 | 288 |
| 空名称符号 | 1,002（97.47%） | 1（0.35%） |
| 可读符号比例 | 2.24% | 99.65% |
| 可读导出接口 | 0 | 71 |
| 唯一导入函数名 | 4 | 216 |
| 4字节伪函数条目 | 999 | 2 |
| 不落在声明节区的符号 | 1,007 | 0 |
| readelf一致性警告 | 10条 | 0 |
FairGuard虽然放入了1,028个动态符号，但其中1,002个没有名称，999个所谓函数的长度固定为4字节，1,007个符号地址与其声明节区对不上。
另外还有3个非空导出名称，但内容是不可读字节序列，因此可读导出接口为0。readelf同时报告10条本地符号顺序异常。
腾讯ACE的符号表结构正常，能直接看到71个导出接口，例如：
JNI_OnLoadtss_sdk_inittss_sdk_encryptpackettss_sdk_decryptpackettss_sdk_ischeatpackettss_recv_sec_signature
这些名称中有一部分属于公开SDK接口，但分析者也可以把它们当作路标，快速找到初始化、数据收发和加解密相关位置。
四、字符串信息暴露
为了避免高熵数据随机产生大量短字符串，本次主要观察8字节以上的连续可打印ASCII内容。
| 指标 | FairGuard | 腾讯ACE |
|---|---|---|
| 长度≥8的字符串 | 427 | 4,224 |
| 长度≥16的字符串 | 27 | 1,624 |
| 长度≥32的字符串 | 12 | 370 |
| .rodata可打印字符串 | 6 | 10,880 |
| 源码路径 | 0 | 6 |
| 明文JNI_OnLoad | 未发现 | 可见 |
腾讯ACE中长度达到16字符的字符串约为FairGuard的60倍，还能看到NDK版本、Build ID及部分编译路径，例如指向.cpp和LLVM源码的路径。
FairGuard主要能看到依赖库名称和GCC 4.9编译痕迹，没有提取到可直接指向反调试、Hook、签名校验等功能的明文关键词。通过静态字符串很难确认它的内部功能路径。
五、重定位、初始化与函数边界
| 指标 | FairGuard | 腾讯ACE |
|---|---|---|
| 重定位总数 | 93 | 25,380 |
| INIT/FINI目标 | 4 | 66 |
| 位于标准.text的INIT/FINI目标 | 0 | 66 |
| 位于无节区区域的INIT/FINI目标 | 4 | 0 |
| 可恢复FDE记录 | 0 | 16,286 |
| .eh_frame零字节比例 | 100% | 32.51% |
| .gcc_except_table零字节比例 | 100% | 38.33% |
FairGuard的4个构造与析构目标全部指向无节区描述区域。它的.eh_frame和.gcc_except_table虽然存在，但内容全部为零，readelf只能解析出一个终止符，无法恢复有效FDE记录。
腾讯ACE可以恢复出16,286条FDE记录。这些记录没有函数名称，但可以帮助分析工具识别大量函数边界和栈展开关系。
重定位数量会受代码规模和编译方式影响，不能单独用于判断强弱。不过结合符号表、节区结构及FDE结果，可以看出腾讯ACE保留了更多标准化交叉引用信息。
六、熵与数据分布
| 指标 | FairGuard | 腾讯ACE |
|---|---|---|
| 整体信息熵 | 4.626 | 6.456 |
| 文件零字节占比 | 54.43% | 21.89% |
| RX段中熵≥7.8的64KiB块 | 35/83，42.17% | 4/84，4.76% |
| RX段中熵＜1的64KiB块 | 42/83，50.60% | 0/84 |
FairGuard的整体熵低于腾讯ACE，主要是因为文件中存在大量零填充区域。单独比较整体熵值，容易得出错误结论。
从局部分布看，FairGuard的RX段中同时存在大量高熵块和低熵零块。结合88.8%的无节区区域，这类分布更接近隐藏载荷、加密数据或自定义布局的特征。
腾讯ACE的整体数据分布相对连续，只有少量64KiB数据块达到7.8以上。
七、基础安全属性
| 属性 | FairGuard | 腾讯ACE |
|---|---|---|
| NX Stack | 通过 | 通过 |
| GNU RELRO | 通过 | 通过 |
| BIND_NOW | 通过 | 通过 |
| Full RELRO | 通过 | 通过 |
| TEXTREL | 无 | 无 |
| RWX加载段 | 无 | 无 |
这一项双方基本持平，都采用了较完整的基础ELF安全配置。
八、量化评分
业内没有统一的SO加固百分制。下面采用本次专用的“静态抗分析强度”评分，原始数据优先于总分。
| 评分维度 | 权重 | FairGuard | 腾讯ACE |
|---|---|---|---|
| ELF结构与节区隐藏 | 25 | 23 | 8 |
| 符号与接口信息隐藏 | 20 | 18 | 11 |
| 字符串与构建信息保护 | 15 | 14 | 8 |
| 初始化、重定位及FDE隐藏 | 15 | 14 | 7 |
| 数据不透明度与局部熵特征 | 15 | 13 | 9 |
| 基础ELF安全属性 | 10 | 10 | 10 |
| 总分 | 100 | 92 | 53 |
libFairGuard.so更接近经过整体隐藏处理的安全模块。实际内容没有通过常规节区完整呈现，符号表带有大量干扰项，字符串、重定位和函数展开信息也很少。分析者很难依靠常规工具快速建立结构。
libtersafe.so同样完成了Strip，并具备Full RELRO、NX等基础保护，但整体仍保留标准ELF布局。符号、接口、字符串、重定位和FDE信息都能被常规工具较完整地提取，分析者更容易先建立模块结构，再沿着公开接口继续定位。
本轮静态结果可以概括为：FairGuard在文件结构隐藏和静态信息收敛方面表现更强，常规ELF工具难以直接恢复有效代码地图；腾讯ACE更偏向标准化共享库结构，接口和分析辅助信息保留较多。
小结
这次测试让我感受比较明显的一点，是GPT-5.6 Sol已经能承担不少SO静态分析中的重复工作。过去需要逐条跑命令、整理输出的数据，现在可以先交给AI批量统计，再由人检查异常项。像节区覆盖率、符号表异常、长字符串数量和FDE记录这类指标，整理速度会快很多。
回到这两个样本，双方的基础ELF安全属性差距不大，拉开距离的是静态信息暴露。FairGuard把代码主体、符号和函数边界藏得更深，腾讯ACE这边则保留了更多标准结构和可读接口。对准备采购或验证游戏加固方案的技术团队来说，检查SO时可以重点看这些位置，而不只是确认文件有没有经过Strip。
