无论是 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 二进制，而这个难度远远高于逆向字节码。
3：mPaaS 移动安全加固重磅上线
结合着阿里内部移动应用安全加固能力的升级，我们在 mPaaS 中对外正式上线移动应用安全加固能力。
针对市面上移动应用普遍存在的破解、篡改、盗版、钓鱼欺诈、内存调试、数据窃取等各类安全风险，mPaaS移动安全加固为 App 提供稳定、简单、有效的安全防护，提升 App 整体安全水平，力保 App 不被破解和攻击。
在应对 Android 常见的攻击手段，比如 反编译、二次打包、动态调试等的同时，我们也注重性能和兼容性。
- 加固能力经历了淘宝、菜鸟等上亿业务的实践，在安全性上有保障；
- 在兼容性上，我们支持 4.2 到 Android Q 的 版本；
- 能够支持 arm、x86、x64 的系统架构，在复杂的环境下稳定运行，奔溃率低；
- 另外，通过对于类的混淆保护，增加攻击者逆向 App 的难度，让攻击无从下手。
产品核心价值
通过前面的介绍，相信大家对于 mPaaS 移动应用加固有了一个初步的认识，下面总结下 mPaaS 移动应用安全加固的优势。
- 操作简单，在控制台上上传加固包即可，开箱即用。开发同学、项目经理等都可以使用；
- 高稳定性和高兼容性，崩溃率极低；
- 经过淘宝等阿里系App的验证，在安全性上有保障；
- 同时支持 Android 4.2 到 Android Q 的系统以及 arm、x86、x64的系统架构；
- 另外，支持 Javabytecode 级别的混淆保护，增加攻击者逆向 App 的成本，最大限度的保障 App 的安全性。
移动安全加固能力清单
我们从反编译保护、防篡改保护、防调试保护等多个维度上做了安全性保障，针对 dex文件、so文件以及各种 hook框架都做了相应的安全策略，能力清单如下：
与此同时，mPaaS移动安全加固还完美兼容 mPaaS 的热修复能力，通过热修复能力，可以快速修复线上版本问题，不需要发版，保障业务的连续性，大家可以到 mPaaS 控制台体验热修复的能力。
性能表现
本文为阿里云原创内容，未经允许不得转载。
