面对鸿蒙 NEXT 应用加固过程中出现的深层崩溃问题,三六零天御团队依托 AI Agent,完成了一次从异常现象到根因闭环的高强度技术攻坚。此次问题横跨 ABC 文件结构解析、反编译工具链、二进制偏移校验与业务处理逻辑多个底层环节,排查链路长、技术门槛高、人工定位难度极大,传统方式往往需要投入大量时间反复验证与交叉比对。AI Agent 深度参与问题研判后,快速锁定 GetProtoIndex 关键调用链,辅助生成排查日志代码,持续解析异常输出与十六进制数据,并进一步识别出 proto_idx 异常、method 偏移错位、010editor abc12.bt 模板对 SOURCE_FILE(tag=7) 的解析缺陷,以及加固业务代码遗漏 tag=7 处理等核心问题,最终推动模板 BUG 与业务 BUG 双重修复。这不仅体现了天御团队在鸿蒙安全底层攻防上的深厚能力,也充分展现了 AI Agent 在复杂安全研发场景中“加速定位、辅助决策、放大专家能力”的实战价值。
“多用 Agent 做事,少直接用 AI 出结果,避免丧失思考能力。”
本文工具列表: opencode + GPT 5.4 + 鸿蒙系统源码 Ubuntu 20.0 +鸿蒙系统源码 010editor + abc12.bt(ABC文件解析模板) |
结果:修复010editor abc12.bt模板BUG;修复业务BUG;
三六零天御鸿蒙应用自动化加固方案是行业内唯一一键加固方案。该系统对ABC文件进行自动化保护,并集成RASP应用内运行时自保护能力,通过整合签名校验(防重打包篡改)、VPN环境检测(防网络抓包)、字符串加密(隐藏敏感信息)、日志防泄漏(防止调试日志、敏感信息外泄)等安全机制,结合反调试、模拟器检测、Hook检测、Root检测等高级防护功能,构建多层次、全链路的安全防护体系,确保发布前应用安全。
三六零天御团队正加速迈向安全研发全面智能体化,以前沿智能技术深度赋能安全攻防实战,持续深入黑灰产对抗核心场景,聚焦底层攻击路径、关键攻防细节与风险演化趋势,打造更敏捷、更精准、更具前瞻性的智能安全防护能力。通过构建覆盖监测、研判、响应与加固的全链路安全体系,加固保正以更强大的技术实力守护业务安全、品牌信誉与用户信任。
背景:客户在使用鸿蒙应用一键加固时,反馈加固后运行崩溃。拿到该应用的modules.abc(应用运行时核心文件),加固后果真被重构为畸形文件。

使用ark_disasm对加固后modules.abc反编译失败,错误提示如图所示。看到此提示的时候可能会陷入茫然。没关系,现在是AI时代。让AI来解决一下吧。把错误直接贴给Agent。

最直观感受:似对非对,找不到根本原因。
360技术专家换了种思路。为何不基于源码先摸清GetProteIndex的调用逻辑。这点如果用人来分析的话,就会慢很多。看AI是如何进行分析的。
提示词:分析GetProtoIndex调用链和所在文件。 |

只是找到调用源头还没有用,需要在代码中插入一些日志,重新编译ark_disasm才好排查。接下来就让Agent来智能插一些日志协助我们排查问题。
提示词:我需要打印一下日志来判断是哪个method出的问题,帮我确认一下应该在哪儿插日志,并打印所在的类和method |

生成代码如下:

最终通过AI的两次优化,生成了可以编译的代码。前后2分钟。进入Ubuntu系统,编译源码,生成新的ark_disasm。

重新运行ark_disasm后,提示F/pandafile: Invalid file offset, from method: GetSpanFromId。很明显,新插入的代码在解析ABC文件时提前中断,导致方法名或类名无法打印。因为重新构造的ABC文件在某处偏移错了。故去掉方法名和类名打印,只打印偏移(methodID),重新编译ark_disasm。

继续将命令行输出内容传给Agent。
提示词:method_id=0x84a9f7, class_id=0x0, proto_idx=6727, is_external=0 |

经过一系列追问,最终给出了最有价值的结论。proto_idx正常情况应该是0xFFFF,但是给出的却是6727。让我们打开010editor去看看。

method_id=0x84a9f7处是当前方法的起始地址。我们先把这个类的十六进制传给Agent。

提示词:45 4C 26 40 63 66 63 61 2F 63 66 63 61 2D 6C 6F 63 61 6C 68 6B 65 2F 49 6E 64 65 78 26 38 2E 36 2E 37 3B 00 00 00 00 00 01 06 01 02 02 07 00 7E 02 01 00 8A 66 1D 00 00 01 00 00 7E 02 01 00 CB B8 1E 00 00 01 00 00 7E 02 01 00 F3 ED 19 00 00 01 00 00 7E 02 01 00 A7 FA 18 00 00 01 00 00 7E 02 02 00 02 AA 25 00 00 02 F7 0B 3A 00 00 7E 02 02 00 38 AD 19 00 00 02 B7 0B 49 00 00 7E 02 FF FF 20 47 1A 00 |

AI可以正确分析这段十六进制值。而且解析出了proto_idx为0xFFFF。但是现实情况并不是这样。因为没有告诉它offset是什么。
提示词:0x84a9f7对应在了十六进制的0xFF 0x20 0x47 0x1A处了 |


所以,现在最关键的问题是,为什么在解析这个method的时候,偏移错位了?
重构的ABC文件在哪个地方出错了。
当用010editor提供的默认abc12.bt解析原始modules.abc文件时,在第634个类出现了中断。排查过程中,触达了知识盲区。带着疑问咨询Agent。


提示词:class_data中tag_value有0x38和0x2C,代码中怎么体现的 |

所以class_data的tag根本不存在0x38和0x2C。也就是说当tag等于7的时候,后面的偏移解析错误了。问题很有可能出现在下图中的绿色框中。此时需要确认一下,SOURCE_FILE是占几位。

提示词:如果是0x07对应的SOURCE_FILE 占几位 |

010editor模板解析错误导致在第634个类中断。

BUG修复:上图蓝框中,uchar改为uint,重新运行模板后解析正常。
重新使用修复后模板加载加固后modules.abc,定位到tag等于7的时候,对应的value没有写进去。最终排查加固业务代码,发现没有处理tag等于7的情况。
提示词:问题已经解决,谢谢。原因是没有处理tag = 7的情况 |

三六零天御鸿蒙应用安全保护方案通过持续的技术革新与深度优化,提供安全合规检测和安全加固服务,覆盖鸿蒙应用开发、测试、发布、运营全生命周期,通过构建从源头设计到持续运维的端到端防护机制,形成鸿蒙生态纵深安全防护体系。
三六零天御鸿蒙应用安全加固平台架构

如有需要欢迎通过官网(tianyu.360.cn)留资或邮件发送至360jiagubao@360.cn。未来,我们将持续深化与鸿蒙生态的技术合作与生态协同,同时针对金融、医疗、教育、政务等特定行业需求,聚焦行业核心场景打造差异化安全优势,输出并落地更完善的鸿蒙应用解决方案,为数智经济创新发展注入安全动能。