面对鸿蒙 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 出结果，避免丧失思考能力。

结果：修复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。未来，我们将持续深化与鸿蒙生态的技术合作与生态协同，同时针对金融、医疗、教育、政务等特定行业需求，聚焦行业核心场景打造差异化安全优势，输出并落地更完善的鸿蒙应用解决方案，为数智经济创新发展注入安全动能。

合作单位