鸿蒙NEXT应用一键加固——AI Agent助力安全开发

首页 阅读 安全资讯 安全知识 安全工具 活动 社区 学院 安全导航 内容精选 专栏 精选专题 安全KER季刊 360网络安全周报 鸿蒙NEXT应用一键加固——AI Agent助力安全开发 阅读量 1170909 发布时间 : 2026-04-10 16:25:22 x 译文声明 本文是翻译文章 译文仅供参考，具体内容表达以及含义原文为准。 面对鸿蒙 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的情况 三六零天御鸿蒙应用安全保护方案通过持续的技术革新与深度优化，提供安全合规检测和安全加固服务，覆盖鸿蒙应用开发、