一、移动应用安全简介

移动应用安全一直是一个各方面需要重视的问题，从早期的二次打包批量插广告，伪造应用开始,安卓的安全性就开始受到各个安全厂商的重视。

早期，安卓应用的安全性是受到自身系统的拖累，不得不重视。相反在iOS上，虽然也会有一定的安全问题，但是没有安卓上那么的严重。

早期的安卓分发渠道真的是群魔乱舞，现而今受到各方面的监管，情况已经有所改善。但是也存在小白用户莫名其妙扫码下载、论坛下载一些乱七八糟的应用，最后导致自己中招了还不明白怎么回事的情况。

二、移动应用安全的发展历程

2010年，随着智能手机兴起，安卓应用市场野蛮式生长，各种黑产满天飞。二次打包插入广告，修改官方应用种木马等现象数不胜数。

2012年，厂商开始推出安卓加固服务，在当时能够抵挡很大一部分黑产的攻击。但随着产业的逐渐成熟，各路黑产大神的进场，安全对抗不断升级。

2014年，随着gdb xposed 等调试注入工具的进入，安全防护不再局限于代码层面，防调试、验签名等安全措施的出现，逐渐补齐了立体防护的短板。同时动态加载机制被广泛使用，其原理也被大家悉知，随之而来的是各种dump整理加密的工具出现。

2015年，对于代码层面的保护，一直是重中之重，从dump工具的出现，逐渐出现了指令抽取方案、二代指令抽取方案等等，皆是为了与各种黑客工具的对抗。

2018年，相比于x86环境，vmp的保护方案也出现在android上。虽然有些大神耗费大量时间能够获取到部分指令映射表，但是如果的去还原一个函数，投入也非常之大。

到2021年的现在，各大移动应用安全厂商的安全技术保护面基本相似。

三、移动应用保护方案

1、整体加密

此项保护方案是早期安卓应用防护的必备项目，原理是将apk包中代码的dex文件进行一次加密，然后使用动态加载的方式，在应用application中再去动态的解密加载整体代码到内存当中。

2、指令抽取

受限于安卓的动态加载技术，最后加载运行的必然是解密后的代码体，而通过hook技术也能很方便地把内存中的dex块dump出来写到文件当中。因此诞生了指令抽取的技术方案，将具体的Java函数体当中的指令提取出来，整体封装加密。原有的函数体进行一些垃圾代码或空指令的填充，在整体dump dex体的时候代码并没有实际还原，无法查看到具体逻辑。而在实时运行的过程当中，当类被加载时，再将该类中被抽取的指令进行回填，此技术的弊端在虽然函数抽取的细粒度时方法，但是回填的细粒度却是类。

3、第二代指令抽取

黑产工具的不断迭代，指令抽取技术也会被循环遍历类的方式全部加载并回填，最后再进行dump。为了防止此工具第二代指令抽取也就诞生了，真正能够做到函数运行时再进行代码回填。

4、VMP保护

VMP protect并不是一个新鲜的技术，早期的x86时代已经被老牌安全厂商玩得很熟练了。即自定义一个Java虚拟机，将原始的指令转化为自定义的指令，运行时将该函数放到自己的虚拟机中运行，从而整体逻辑无法被跟踪与逆向。

当然，VMP技术各大厂商也有多个版本迭代，但是各种变化也脱离不了自身的虚拟机运行。同时，安卓的环境目前也没有很好的跟踪vmp指令的工具，所以目前来看vmp对安卓java代码的保护还是挺不错的。

5、java2c保护

该技术同样也是对java代码的保护方案，将原有的java代码编写的逻辑全部转换为c代码的逻辑，普通计算使用原生c代码，函数调用使用反射方式进行，但是c代码的逻辑编写本身就会比java复杂，最后会导致的必然是运行效率的降低与代码大量膨胀的结果。

6、native层保护

针对于native层防护各个安全厂商就开始有一定分歧了；

a.常见的就是类似upx的加壳了，对原始elf文件进行代码段的加密压缩，init运行时进行释放；

b.符号的变换，利用hook dloen dlsym 等方式进行还原；

c.自定义linker ，使用自己的linker对加壳后的elf文件进行加载；

d.vmp,同java vmp，使用自定义虚拟机运行指令，目前市面上尚无基于arm elf文件的vmp，大部分还是基于源码在IR层的转换。

e.其他

7、其他基础安全防护

a.apk安装包的完整性保护，防止删除/添加/替换安装包中的文件；

b.签名验证，即在保护时将原始包的签名打入加密的壳中，运行时再进行校验；

c.防调试，常见的有ptrace占位、各种状态的检查等

d.其他安全措施，数据/资源加密、防截屏录屏，防界面劫持、安全加密(白盒)等等

四、纵深的安全防护

1、割裂的安全防护

从接触到的很多应用厂商来看，公司/企业越大，安全防护割裂这个问题就越严重。业务团队、开发团队、安全团队各自为政。开发团队向业务部门负责，实现需要的功能就行，安全团队会进行各种安全检测，向开发团队提出各种要求，开发就是最终的背锅侠。这种部门之间的割裂，必然会导致信息的隔离，开发人员不懂安全防护，而安全团队无权限阅读代码，无法做到更深层次的评估，业务漏洞或代码漏洞比比皆是。最终安全团队想找一家安全厂商来搞定一切安全问题极为不现实。

2、安全防护应该从立项开始

从一个项目开始安全团队就应该积极介入，从业务漏洞的评估，到代码的安全审查，再到最后的整体防护。通过各个部门之间的联动来提升整体的安全强度，而不是把安全交给最后一棒。

3、贴合实际的防护

从第二点可以看到安全厂商能够提供的保护项目非常之多，各种策略的配置也眼花缭乱，不在这个圈子里每天加深印象，真不懂你这个保护方案到底是怎样的，能起到什么作用，导致的结果就是“你有的，我都要”、“出问题，安全厂商的问题”。

应用开发厂商需要根据自身的切实需求积极和安全厂商进行沟通，调整保护方案。同时针对自身的安全关注点，向安全厂商提出自己的其他诉求。

抛开“人”的问题，厂商之间的合作应该是一种亲密无间的关系，而不应该是防家贼似的。毕竟做安全的最高境界就是“你中有我，我中有你”。

五、该怎么做安全

1、秉持“适合自己的，才是最好的”的安全策略；

2、明白安全与业务/兼容性是此消彼长的关系；

3、在复合监管的基础上使自己的利益最大化。

具体落实到不同行业，应该寻找好自己的安全定位，以下列举几个不同行业的细分，谈谈我对安全的理解。

说明：

1.金融行业，因为涉及到“钱”的问题，再高的安全防护都不为过。不能因为自身的安全缺陷导致用户的实际“利益”受到损失。

2.互联网行业，需要的是用户数、日活等各种数据指标，所以兼容性与运行效率应该放在第一位。但是核心的业务逻辑也不能被随意破解，因此VMP的保护范围可以集中在自己的关键逻辑上，而其他的业务安全的增多，必然导致性能降低，崩溃率的提高，最终导致用户的流失，所以重点可以放在威胁情报的收集，对危险行为收集证据，事后进行追溯。

3.运营商行业，运营商更关注的是投诉率，由工信部严格监管，但是同样也涉及到客户的切身利益“话费”的问题，暗扣的花样越来越多，已经不是靠最后一棒的防护能够完全解决的。打铁自身硬，业务的安全是运营商的重中之重。

4.政企行业，政府应用当然需要做到最高的兼容率与最高的运行效率，为了保证全国所有的智能机，包括一些陈旧的垃圾手机都能运行，太多的安全防护而导致一些“老年人”无法使用，就不应该了。同事黑客在这个方面还是有一定操守，毕竟产出太小，还容易吃牢饭。企业自身的应用同样因为受众面小，不会大规模外发，不需要太考虑一些危害不大的安全漏洞。

5.能源/交通/教育/医疗行业，基础设施的建设，涉及到使用的人会非常多，同样需要考虑兼容性与性能，但是也不能太差。重点应该放在后端，例如，如果发现有刷XX的行为，完全不需要在客户端防护，后面直接把帐号禁用3个月，这个威慑力也会比较有作用。

6.整体来说，基础的安全措施必须包含：Java代码的整体防护、核心业务的vmp保护、自研的so文件加壳/混淆，附加安全功能基本的有完整性的保护、签名的验证、防调试、资源/数据加密。

六、任重道远的安全

写到最后的总结，只想说做好安全，任重道远。只要哪里有“利益”，哪里就必须有安全。安全有可能会迟到，但是永远不会缺席!