阿里巴巴移动安全应用加固能力养成记

近些年来，移动APP数量呈现爆炸式的增加，黑产也从原来的PC端转移到了移动端，伴随而来的逆向攻击手段也愈来愈高明。在解决加固产品容易被脱壳的方案中，代码混淆技术是对抗逆向攻击最有效的方式之一。但目前的移动端加固技术真能抵御黑客的攻击吗？  

本报告将分享阿里巴巴集团安所有应用加固能力养成记，重点介绍Android加固对于端上的业务风险控制是如何作到自动化部署和分析，更快捷的感知安全风险，以便快速作出响应，减小没必要要的业务损失。  

主讲人：阿里巴巴安全专家乱武。

今天讲的大的标题叫【APP加固新方向】，副标题主要讲阿里巴巴对Android加固的基础介绍，以及在开发这个产品过程当中遇到的一些问题和一些复杂场景的适配过程。因为大会给个人时间是25分钟到30分钟，整个安卓加固方面涉及的技术点还蛮多的，为了让此次的分享有一个比较聚焦的点，因此此次的分享主要是讲Androidjava代码方面的保护，也就是说编译成Android安装文件以后，Dex文件方面的一些基础保护点。  

我此次分享的主要有三个部分，第一部分主要是要介绍一下Androidjava代码保护的技术。第二部分介绍一下应用加固在复杂业务场景下的挑战以及遇到的一些问题。第三部分说一下将来对于Androidjava代码保护的一些思路，跟你们分享一下，也许你们未来会碰到，或者有相应的一些启发。  

第一部分主要讲Androidjava代码的技术保护，刚才主持人作了一个小的问卷调查，这里很多同窗不是开发，我大概介绍一下这个上下文。  

自己安卓手机你们不陌生，苹果和安卓，目前是业内主流的两大智能操做系统。安卓自己的开发环境是用java语言开发的，它有一个特色。因为java语言生成的文件是在虚拟机里面执行的，必然要保留大量的语义，虚拟机可以认识可执行文件的时候保留了不少的语义。这就带来一个问题，既然编译生成这种Dex格式，保留了大量的语义，而这种格式谷歌对外彻底公开的，恶意者经过反编译达到看到原来Java代码的这种目的。不论是阿里巴巴仍是其余安全加固的友商，对安卓java代码的一个保护，也就是安卓上面Dex文件的保护，从加固服务产生到如今一直是重点。  

我简单介绍一下Androidjava代码以及Dex代码保护迭代介绍，业内主要总结了四代的保护方案。  

第一代加固自己这种方案刚出来的时候，大概是2013到2014年之间，自己这个加固方案对于安卓自己的可执行文件，也就是Dex文件的保护，至关因而在打包的时候，就是生成整个安卓安装应用包的时候会对Dex进行加密。加密算法各类各样，能够用AES，也能够用其它的。在运行的时候经过一个自定义的类加载器进行解密，真正在运行的时候是完整的原来应用开发者编译出来的Dex文件。这种加固的特色一目了然，你拿到文件的时候，既不知道密钥，也不知道加密算法，看不出来文件的整个逻辑，这个时候必定程度上可以防住，经过一些开源的工具逆向分析这个Dex文件。  

缺点也很明显，由于它简单，由于运行时用一个自定义的类加载器在加载的时候解密，把这点拦掉，就把这个壳脱了。  

那经过一段时间的发展之后，又出现了第二代的保护方案，就是类级别的Dex保护。我前面介绍了其实Dex文件来讲，它的格式是公开的，公开就意味着这里面的某些类、某些函数保护的code在哪个位置，其实全部人都可以知道。因此第二代的保护方案，至关于把Dex里面要保护的核心函数抽离出来生成另一个文件，利用一个虚拟机类加载机制。自己虚拟机有一个特色，它必然会掉到这个类里面的一个方法，咱们已经在打包的时候，将这些核心函数保留在已知的位置，经过这个函数调用咱们的修复函数，而后将全部的业务逻辑进行修复。这样的一个方案，其实主要的原理仍是利用虚拟机类加载机制的特色来达到必定保护的效果。固然这种保护有一个特色，咱们若是简单来讲，即使是我把它抽离了，最后运行的指令是谷歌支持的Dex标准指令，这点你们要注意。  

第三代跟前面两代彻底不一样，由于谷歌的Dex指令是开源的，无论第一代第二代，内存中运行的都是谷歌的标准指令，因此从原理上必定有办法将这个指令彻底逆向出来，而后把它反编译出来。可是第三代就有一个质的区别了。其实第一步和第二代是同样的，也是在编译打包的时候将Dex的核心函数抽离的，抽离后，翻译成一种本身定义的指令，用本身的一种编译指令进行翻译，把这个指令变一个种，变成其余的指令，这个时候运行的时候经过本身的解释器来解释执行，是本身定义的相关指令，这是跟第二代有质的区别的。我在内存中运行的指令，在某些保护的函数里面就必定不是谷歌的标准指令了，这点可以颇有效的防止内存直接拷贝等破解方案。  

第四代，也是行业目前公认的方案，就是java2C的保护方案，这种更简单直接，它的原理很清晰，咱们若是做为一个开发者，在开发java代码的时候，不论是原来传统的PC上的java虚拟机仍是谷歌的虚拟机，java代码必定是能够翻译成用C代码来表示的。好比说写一个java代码的函数，从原理来讲其实只要不嫌麻烦，我必定可以利用虚拟机漏出的接口写成C代码，这种保护方案直接从根源上解决这个问题。你认为核心要保护的函数，咱们直接在编译打包的时候将这些函数翻译成C语言的代码，而后再用编译器编译成一个so的文件，也就是这个CPU支持的一个二进制code，这样达到了比较好的保护。  

这基本上就是我介绍目前安卓移动端对于java代码保护的四代技术。  

由于第一代和第二代技术相对比较简单，我介绍一下第三代和第四代技术整个的框架流程图。  

自定义解释器的Dex保护方法第一部分应用打包和普通的是没有什么区别的，最终生成的也是安卓系统可以认识的一个可执行的文件。可是到了第二步和第三步的时候就有点区别了，第二步要通过一个加固的工具链，由于也是一个安卓的可知性的文件，首先要找到一个Dex文件，抽取核心函数指令，而后埋点一些hook接口，接下来打包还回apk文件，签名后应用发布。蓝色的部分表示是在运行时，黄色的部分是没有安装到用户手上，蓝色的部分应用已经发布了，而后在用户的手机上执行的一个逻辑。由于第二步埋点了hook接口，就进入一个自定义的一个解释器，根据传译的二进制的code翻译成原来Dex文件想保护的java那个code的逻辑，完成了第三代的保护效果。真正在解释的时候解释执行的就是这种变种的指令，而后达到正常执行业务逻辑的效果，这是第三代的一个自定义解释器Dex保护方案的介绍。  

说一下第四代java2C保护方法的介绍，前两步也跟第三代是同样的，就是开发者本身编译好的一个安卓可安装程序。不一样的是，直接简单粗暴将须要保护的Dex核心函数直接翻译成C代码。好比一个编译好的Dex文件，直接把这个函数编译成C代码，能够自定义一个编译器翻译成一个C代码。C代码仍是很成熟的，能够用各类各样的编译器，包括谷歌以及第三方编译器，这样彻底去除了里面的核心指令，就变成看这个手机或者这个架构支持的Dex文件。这里面运行的时候又有不一样，由于这个时候是须要把SO给打进APP里面，由于这些代码其实已经编成SO，要加到apk里面，因此核心函数通常加一个native标签，调到自己的SO里面，后面的执行瓜熟蒂落了，就是本地指令的执行保护函数，可以达到彻底的正常执行的业务逻辑。  

第一部分大概介绍完了，包括目前比较流行的新的技术，就是第三代和第四代，可是其实我这边要说一下第三代和第四代的一些缺点。  

从刚才的介绍看起来比较美好，可是到了第三代的自定义解释器的时候，这个时候因为要hook系统的一些接口，普通的应用开发者要遇到不少碎片化的问题，对于加固要调用大量的系统私有api的安全服务来讲，可能遇到的问题更显突兀，因此基本上在第三代的自定义解释器的保护方案，不是说不强，但可能遇到碎片化的东西比较多，到第四代其实反倒碎片化比较小，为何你们比较推崇java2C的保护方案，是由于把java代码翻译成C代码再编译成SO，是彻底符合不少虚拟机的开发规范的，这样的兼容性问题最小。固然这两个场景也有一个问题，它编译出来的函数可能会体积变大，可能执行效率变低，可是这些都是一些具体的细节，今天的时间有限，就再也不详细赘述了。  

第二部分介绍一下加固在复杂业务场景下的挑战。  

安卓从几年前你们也不是特别看好的一个智能操做系统到如今成为全球第一大的智能操做系统来讲，自身的操做系统是有一个不断的迭代，包括今年最新发布的androidO，咱们能看到它的进步。在安卓上面开发各类业务其实如今已经变得很复杂了，就以咱们阿里巴巴公司比较旗舰类型的应用，好比手机淘宝和支付宝的应用，应用开发的流程和开发使用的黑科技的各类技术，已是不亚于传统上面的一些PC上面一些比较复杂的客户端开发的程度了，因此加固在服务于这些应用的时候，也面临着一些复杂业务场景的挑战，我作一些简单的介绍，举两个例子。  

Hotpatch应用场景，安卓应用若是是说在你的应用发布之后，到了用户的手机端上之后若是发现一些bug，按照传统的方案有一种解决方式，用户升级再更新一个版本、从新安装一遍把这个问题解决了。可是在对于不少复杂的应用来讲，好比说像手机淘宝或者天猫或者支付宝，它自己的一个安装包就已经70多兆了，好比里面有一个很小的bug，好比哪个页面显示不对，让用户彻底的升级一遍，从新下载包升级一下，用户体验不是很好，他们业务方开始研究一种技术，当我发现某一个地方某一段代码有问题了，这个时候我就只修改这一部分代码，而不须要用户安装整个发布包。咱们这个原始应用有三个类，分为A/B/C，当我有问题的时候，好比我发现的问题是某一个代码有bug了，假设B类有bug，我只须要把他弄成一个Dex文件，把这个下发下来，热部署之后把原始APP里面的Dex文件修改一下，让它变成只有A和C这两个类，而后再经过一些类加载器里面寻找Dex的顺序，达到首先执行个人热部署后的这个文件，当须要调用B的时候再执行B这个类，达到修复这个原有程序业务逻辑bug的目的，或者我想更新达到更新的效果，固然这种方案目前在安卓上面运行的仍是比较多的，包括阿里也有发布热补丁的。原来这种在苹果上面也会应用，但整个来讲苹果不让用了，谷歌想在明年P的版本可能会全面限制这种技术方案，可是目前来讲发布O的版本目前尚未这个限制。可是这种方案其实在加固来讲，从加固的原理来讲有一点冲突，热部署后的dex文件会出现一点问题，这是加固服务发展过程当中发现的一个比较复杂场景的举例。  

第二种场景你们更不陌生，因为业务发展愈来愈复杂，开发规模稍微大一点的应用，须要插件化的部署，好比手机淘宝集成了各类各样的服务，这时候要多个团队协做开发，这就无可避免要利用咱们所谓的插件化的思想，而后分步开发。这时候传统的加固面临一个问题，最初咱们主要是保护主Dex文件一些根目录下的Dex文件，插件会埋到lib下面很深的地方，致使加固刺出现盲点，做为一个通用化的一个加固方案很难作到将全部的Dex文件也保护，可是有些是比较核心的。刚才我提的这两个例子，不论是阿里巴巴仍是不少友商，这个问题都获得很好的解决，具体的细节我就不赘述了。  

最后一部分介绍一下业内认为将来对于安卓java代码一种保护手段的思路。  

第四代java2C保护方案是用编译器编译成一个标准的SO文件，其实标准的SO文件开发者都很清楚，这种elf格式也是透明的，至关于自己这种格式也是彻底有规范的，是透明的，也是能够逆向的。既然能够把DEX文件翻译成c代码，那么也能够用支持vmp虚壳的编译器在编译成内置于vmp虚壳的保护的so。  

风险设备的控制，咱们作安全来讲从原理来讲，若是不是特别计较成本的话，其实只要在端上运行的东西，特别谷歌开源运行的，其实原理上是可以破解的，只不过你花费的时间长短和破解成本的高低，因此在手机淘宝和电商的超级应用，保护思路愈来愈从端上防御倾向于端和云联合的防御。在端上在打包的时候会埋入不少点，不论是安全adk仍是自己加固工具链的方式，获取一个端上惟一的标识，咱们称为一个设备指纹。像下单这种行为会加入这种设备指纹的请求，而后服务器经过这个指纹识别进行风险控制，好比咱们认为是恶意者操控的设备，能够加入黑名单，不会让这个应用崩溃。好比你抢红包抢不到，你买东西买不成功，给用户一个反馈，这种其实保护效果是至关好的。