移动安全加固助力 App 实现全面、有效的安全防护

关注

发布于: 2020 年 11 月 09 日

无论是 Android app 还是 Jar 应用，代码一旦分发出去，都会以某种形式处于不可信环境中，难免被有心人分析破解。隐藏在代码中的秘密，无论是私有算法，或是私有协议，或者是加解密秘钥，都可能被攻击者破解出来，然后侵犯原作者的商业利益或知识产权。所以应用被逆向破解是商业风险源头之一。

#1：移动应用安全现状分析

根据工信部的数据显示，截止 2019 年，中国移动应用数量已经达到 450 万个，其中游戏类、生活服务类、电子商务类 App 排名前三。

细分市场，我们再看下金融行业，根据信通院的数据，在 2019 年，针对国内 22777 款金融行业 App 进行观测发现，仅 17.08% 金融行业 App 完成加固，而超过 80% 金融行业 App 在应用市场“裸奔”，未进行任何安全加固。通过金融行业这一个细分行业来看全行业，其他行业也有类似的问题。

我们再看监管政策：

对于金融行业——中国人民银行下发的了移动金融客户端应用软件安全管理规范，明确规范了移动 App 的安全加固要求。

对于教育行业——教育部下发的《关于引导规范教育移动互联网应用有序健康发展的意见》以及《高等院校管理服务类教育移动互联网应用专项治理行动方案》，发文明确提出教育 App 应当经过安全评估后方可上线，并及时通过安全加固修复安全隐患。

通过金融、教育行业的监管要求以及国家对于移动互联网的越来越重视大的背景，后续其他行业也会可能会陆续出台相关的安全政策要求。

#2：全新移动应用安全防护策略

下面介绍下阿里内部移动安全防护策略升级迭代的过程。

在一代和二代的加固方案上，主要针对 APK 的加壳保护，对 dex 做隐藏，同时加密 dex，在运行时动态加载加密的 dex 并做解壳操作。加壳加固的优势是不会增加应用的体积，同时 dex 被隐藏，可以对抗 dex 的静态分析。

随着攻击手段的不断升级，阿里移动安全加固进行了全新能力的升级。目前已发展到了第三代加固：Java 字节码转换为 Native 二进制码。

阿里内部加固的原则和目标秉承着既要充分提高自身安全能力，增加对手的破解难度和攻击成本，也要尽量降低业务方的接入成本，还要兼顾运行效率与体积。

应对的主要风险点：

Java/Smali 字节码被工具反编译为 Java 源码
Java/Smali 字节码被直接阅读
native 汇编码被工具反编译为 C 源码

Java 字节码因为格式和指令限制，安全保护能力是有上限的。但是，native 二进制码相对于 Java 字节码破解难度大大提高。于是我们将字节码转换为 native 二进制码，代码逻辑转移到 so 里面，原来是 Java 函数调用，现在变成了 JNI 调用。攻击者的 Java 逆向相关技能直接失效，被逼去逆向 native 二进制，而这个难度远远高于逆向字节码。