阿里云栖大会 app加固小记

主要讲阿里巴巴对Android加固的基础介绍，以及在开发这个产品过程中遇到的一些问题和一些复杂场景的适配过程。

第一代: 本身这个加固方案对于安卓本身的可执行文件，也就是Dex文件的保护，相当于是在打包的时候，就是生成整个安卓安装应用包的时候会对Dex进行加密。加密算法各种各样，可以用AES，也可以用其它的。在运行的时候通过一个自定义的类加载器进行解密，真正在运行的时候是完整的原来应用开发者编译出来的Dex文件。这种加固的特点一目了然，你拿到文件的时候，既不知道密钥，也不知道加密算法，看不出来文件的整个逻辑，这个时候一定程度上能够防住，通过一些开源的工具逆向分析这个Dex文件。缺点也很明显，因为它简单，因为运行时用一个自定义的类加载器在加载的时候解密，把这点拦掉，就把这个壳脱了。

第二代:类级别的Dex保护 其实Dex文件的格式是公开的，公开就意味着这里面的某些类、某些函数保护的code在哪一个位置，都能够知道。第二代的保护方案，相当于把Dex里面要保护的核心函数抽离出来生成另外一个文件，利用一个虚拟机类加载机制。本身虚拟机有一个特点，它必然会调到这个类里面的一个方法，我们已经在打包的时候，将这些核心函数保留在已知的位置，通过这个函数调用我们的修复函数，然后将所有的业务逻辑进行修复。这样的一个方案，其实主要的原理还是利用虚拟机类加载机制的特点来达到一定保护的效果。当然这种保护有一个特点，我们如果简单来说，即便是我把它抽离了，最后运行的指令是谷歌支持的Dex标准指令

第三代:跟前面两代完全不同，因为谷歌的Dex指令是开源的，不管第一代第二代，内存中运行的都是谷歌的标准指令，所以从原理上一定有办法将这个指令完全逆向出来，然后把它反编译出来。但是第三代就有一个质的区别了。其实第一步和第二代是一样的，也是在编译打包的时候将Dex的核心函数抽离的，抽离后，翻译成一种自己定义的指令，用自己的一种编译指令进行翻译，把这个指令变一个种，变成其他的指令，这个时候运行的时候通过自己的解释器来解释执行，是自己定义的相关指令，这是跟第二代有质的区别的。我在内存中运行的指令，在某些保护的函数里面就一定不是谷歌的标准指令了，这点能够很有效的防止内存直接拷贝等破解方案。

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

第三代和第四代的缺点:到了第三代的自定义解释器的时候，这个时候由于要hook系统的一些接口，普通的应用开发者要遇到很多碎片化的问题，对于加固要调用大量的系统私有api的安全服务来说，可能遇到的问题更显突兀，所以基本上在第三代的自定义解释器的保护方案，可能遇到碎片化的东西比较多，到第四代其实反倒碎片化比较小，为什么大家比较推崇java2C的保护方案，是因为把java代码翻译成C代码再编译成SO，是完全符合很多虚拟机的开发规范的，这样的兼容性问题最小。当然这两个场景也有一个问题，它编译出来的函数可能会体积变大，可能执行效率变低

加固在复杂业务场景下的挑战:安卓从几年前大家也不是特别看好的一个智能操作系统到现在成为全球第一大的智能操作系统来说，自身的操作系统是有一个不断的迭代，包括今年最新发布的android O，我们能看到它的进步。在安卓上面开发各种业务其实现在已经变得很复杂了，就以我们阿里巴巴公司比较旗舰类型的应用，比如手机淘宝和支付宝的应用，应用开发的流程和开发使用的黑科技的各种技术，已经是不亚于传统上面的一些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还是本身加固工具链的方式，获取一个端上唯一的标识，我们称为一个设备指纹。像下单这种行为会加入这种设备指纹的请求，然后服务器通过这个指纹识别进行风险控制，比如我们认为是恶意者操控的设备，可以加入黑名单，不会让这个应用崩溃。比如你抢红包抢不到，你买东西买不成功，给用户一个反馈，这种其实保护效果是相当好的。

以上是阿里对加固的一些小总结,mark..

更多相关文章

随机推荐