AI逆向(上):逆向能力增强给App安全带来的威胁

我关注的“橘AI”今天发了一段文字，强调了AI逆向能力增强给APP安全带来的威胁。〔1〕

对已经投入成本做过App加固的企业，“万能钥匙”这个比喻指向了一个具体的忧虑：AI大大降低了看懂和修改客户端的门槛，原有App防护还能抵挡多久？

（本篇主要讨论AI逆向的安全威胁，下篇将讨论AI是否应当对此进行对齐和安全围栏设置）

App安装到手机上时，用户拿到的通常是设备可以执行的程序，而不是开发者编写的源码。逆向分析就是从程序本身和运行时的表现出发，反过来理解它怎样工作：信息保存在哪里，请求怎样发给服务器，哪些条件会触发某个功能。分析者未必能完整还原源码，也不一定需要这样做，弄清其中一部分逻辑就可能满足特定的“研究”目的。

OpenAI发布的GPT-6 Astra能力与安全评估报告，提供了一组软件逆向能力的比较。报告采用的SRE-Bench评测，包含由19个私有开发程序衍生的262个二进制程序样本，涉及网络协议、文件格式、恶意软件修复和固件等任务。模型需要在拿不到原始源码的条件下，分析给定程序并完成任务要求。

按报告中四次独立试验取最高准确率的口径，Astra的成绩为99.2%，GPT-5.6 Sol为68.7%。这一结果显示，Astra在这组逆向任务上的表现明显提高。〔2〕

这种能力进步可能改变逆向分析所需的人力和时间。阅读陌生代码、查阅工具文档、整理线索、验证猜测，都需要分析者投入精力。AI如果能承担其中更多工作，有经验的人就能更快检验想法，原本缺少某项技术的人也可能借助工具跨越门槛、不断推进。企业过去依赖的部分护城河——让程序难以被理解，让分析者不得不花费大量时间——也就需要重新评估。

不过，从理解程序到拿到他人的数据、完成越权操作，中间仍有一段距离。看懂客户端怎样发出请求，并不意味着服务器就会接受其中的越权要求。AI逆向会带来多大的安全威胁，还要沿着这些请求继续往下分析。

以一个假设的购物App为例。用户点开订单详情，App向服务器发送查询请求，服务器找到相应订单并返回。逆向分析可能帮助人看懂请求中的字段、调用顺序和数据含义，但这份订单能不能被查看，仍应由服务器判断。

这里有两项不同的检查：请求者是否已经登录，以及他是否有权查看这份订单。登录验证通过，不代表可以查看其他人的订单。如果服务器没有检查订单归属，客户端暴露出来的请求逻辑就可能被用于访问其他用户的数据；如果归属检查有效，仅仅知道请求怎样发送，并不会自动获得这些数据。应用安全组织OWASP把这类授权缺陷称为“对象级授权失效”。〔3〕

对修改地址、删除资料或审批业务等操作，也存在同样的问题。App界面上没有某个操作入口，不代表服务器一定会拒绝相应请求。客户端可以限制用户在界面上怎样操作，服务器则需要核验请求者实际拥有什么权限。对于控制车辆或其他设备的应用，授权缺陷还可能影响现实中的设备操作。

付款涉及的判断更进一步：用户实际同意的是哪一笔交易。金额、收款对象等信息需要与这次授权对应，服务器也必须校验交易过程。假如它过度相信客户端提交的验证结果，修改客户端就可能影响实际执行的内容。反过来，即使有人跳过了手机上的验证画面，只要服务端的相应检查仍然有效，交易就不会因此自动获准。〔4〕

有些风险则来自App安装包里保存的访问凭证。例如，开发者把共享密钥或高权限服务凭证写进程序，再通过混淆、加密等方式让它们难以被发现。一旦这些材料被提取，损害范围取决于凭证实际拥有多大权限，以及是否被多个用户、设备或服务共同使用。

OAuth是一套常用的授权协议，对于安装在用户设备上的应用，OAuth的相关规范明确要求：如果共享密钥等秘密信息被写进App，并随安装包分发给多个用户，就不能再假定只有开发者掌握它们。服务器核验客户端身份时，也不能只看它是否持有这些信息。〔5〕这里说的是随安装包分发的共享秘密，与用户登录后取得的个人令牌、由硬件保护且不可直接导出的密钥，安全条件并不相同。

这些设计缺陷在AI出现之前就存在。AI辅助逆向可能让它们更快暴露，也可能降低利用它们所需的技术和时间成本。原本不容易被发现的问题，因而可能成为更现实的安全威胁。

App加固主要是在客户端增加观察和修改程序的难度。代码混淆会让名称和执行逻辑更难阅读；加壳、代码加密等措施会隐藏代码内容或改变程序的呈现方式；反调试、反注入等机制，则尝试阻止外部工具观察和干预正在运行的程序。

这些措施保护的环节并不相同。拿到安装包时看不懂代码，与程序运行后仍然难以被观察、修改，是两种不同的保护效果。OWASP将反逆向和反篡改视为纵深防御的一部分，也就是多道防护中的一层。应用在数据存储、身份验证、网络通信等方面需要的安全控制，仍然要分别妥善处理。〔6〕

移动应用保护厂商Promon在2026年3月公布过一项实验。研究者选取了200个用C语言编写的程序，每个包含15至70行代码，施加不同组合的代码混淆，再让10个模型尝试生成能够通过功能测试的代码。只有生成的代码能够编译，并在给定测试中得到与原程序一致的结果，才被记为成功。在手机常见的ARM架构上，叠加三种混淆后，表现最好的受测模型直接阅读底层汇编代码，成功率为24%；把输入换成反编译工具整理出的、较易阅读的伪代码，同一模型的成功率提高到了50%。〔7〕同样的保护条件，仅仅改变交给模型分析的材料，结果就有明显差异。评估AI逆向能力时，配套工具及其提供的材料也需要被考虑在内。

多层混淆仍然能够造成实质阻碍。Elastic Security Labs安全研究团队在2026年4月公布了另一项实验，研究者先用Tigress这款代码混淆工具，让程序更难被读懂，再让AI借助分析工具尝试理解程序的功能。实验主要采用静态分析，也就是检查程序的代码和结构，不直接运行目标程序来观察它的行为。多种混淆手段叠加后，分析变得更加困难，在实验设定的条件下，AI未能完成部分任务，分析所需的时间和计算费用也有所增加。〔8〕

这意味着，加固的实际效果需要连同模型、配套工具和投入预算一起评估。测试不仅要看程序最终有没有被理解或修改，也要记录分析者为此付出了多少成本，以及成功一次后能否反复复用结果。企业能否利用加固争取的时间发现异常、调整保护或限制损害，同样影响这笔投入的价值。（这也意味着Astra发布后，攻防局面可能又大不一样了）

一次“已加固”的验收，不能替代对这些变化的持续检验。

假设一个预约服务允许用户先占用名额，再决定是否使用。有人通过大量正常账户集中占位，即使每次请求都经过正版App提交、也符合单个账户的权限要求，仍可能挤占大量名额，让其他用户无法预约。

这种滥用不要求攻击者读懂整个App，甚至不一定需要修改客户端。OWASP将对敏感业务流程的过度自动化使用，列为一类独立的接口安全风险。〔9〕这里的问题是，每次操作单独看都可能符合要求，集中、反复执行却会损害业务。

逆向分析得到的流程信息，可以帮助人制作自动化工具；AI也可能帮助适配界面变化、处理异常，减少维护这些工具所需的重复劳动。如果这些工作变得更容易，原本需要持续投入人力的操作，就可能以更低成本反复执行。企业因此需要关注名额怎样被占用、操作以多大规模持续发生，而不能只检查单次请求是否有权限。

另一条风险路径是恶意改包：攻击者修改App安装包，在保留正常功能的同时，插入窃取信息或操纵行为的代码。用户使用修改版时，日常功能可能看起来仍然正常，程序执行的行为却已经发生变化。

反篡改和完整性验证可以增加这类攻击的难度，攻击者还需要设法让修改版进入目标用户的设备。因此，不要安装来源不明的App；让AI代为下载和安装时，也应核对安装包的实际来源。

Promon在另一篇讨论AI与App保护的文章中指出，加固不能修复后端授权错误、不当的加密设计和密钥管理问题，也不能独自识别通过正常业务流程完成的欺诈。〔10〕即使客户端已经做过加固，企业仍需要检查这些环节是否存在缺陷。

我的判断是，企业需要把两种测试放在一起观察。一种验证现有保护还能增加多少分析和修改成本；另一种则假设客户端的关键逻辑已经被理解、部分检查已经被绕过，验证服务器是否仍会错误地交出数据、接受越权操作，或允许业务被批量滥用。这样才能知道，加固为企业争取了什么，以及它一旦失效，后果会扩大到什么程度。

测试还应包括发现问题后的处置。共享凭证泄露后能否及时撤销，异常操作能否在服务端被限制，敏感数据能否减少返回，都影响企业控制损失的能力。如果所有补救都要等待用户升级App，发现问题与完成修复之间就会留下更长的时间。哪些措施可以立即生效，应当在出事之前就准备好。

同一种逆向能力，也可以用来帮助企业发现和修补漏洞。AI在协助这类工作时，怎样保留正常研究的价值，同时约束越权和攻击行为？这是下篇要讨论的对齐与安全围栏问题。

参考资料

〔1〕橘AI，关于AI逆向风险的文字。

https://mp.weixin.qq.com/s/RnEVRRiSe7Odbr28P62hRg

〔2〕OpenAI，GPT-6 Astra System Card，SRE-Bench。

https://deploymentsafety.openai.com/gpt-6-astra/sre-bench

〔3〕OWASP，API1:2023 Broken Object Level Authorization。

https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/

〔4〕OWASP，Transaction Authorization Cheat Sheet。

https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html

〔5〕IETF，RFC 8252，OAuth 2.0 for Native Apps，第8.5节。

https://www.rfc-editor.org/rfc/rfc8252.html#section-8.5

〔6〕OWASP，MASVS-RESILIENCE。

https://mas.owasp.org/MASVS/11-MASVS-RESILIENCE/

〔7〕Promon，App Threat Report 2026 Q1: The State of Code Obfuscation Against AI。

https://promon.io/security-news/app-threat-report-2026-q1-the-state-of-code-obfuscation-against-ai

〔8〕Elastic Security Labs，The Cost of Understanding: LLM-Driven Reverse Engineering vs Iterative LLM Obfuscation。

https://www.elastic.co/security-labs/threat-command/llm-reversing-vs-llm-obfuscation

〔9〕OWASP，API6:2023 Unrestricted Access to Sensitive Business Flows。

https://owasp.org/API-Security/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows/

〔10〕Promon，AI-powered mobile app attacks: What app shielding can and can’t stop。

https://promon.io/security-news/ai_powered-mobile-app-attacks-what-app-shielding-can-and-cant-stop