项目的研究背景
近年来，随着移动互联网时代的来临，手机作为信息流入流出的终端，新时代下承载信息的重要载体，遍布全球的庞大开发团队和用户网络。无处不在的智能手机，以及它们非常广泛的功能和使用，使得这些设备的安全性非常重要，而由于Android系统2017年度市场占有率在全球范围内高达85.9%，在国内市场占比83%，加之相继曝出的安全问题有增无减，“Android安全”受到越来越广泛的重视。
安全已经成为决定任何平台、任何事件或任何新特征的成功与否的中心和关键方面。随着功能的提高，整体安全性决定了平台的强度。Android系统是基于Linux内核的，通常使用java语言编程。Android拥有一些安全特性来保护用户数据和资源。其中一些包括通过Linux内核的强大安全性、权限模型、应用程序签名以及所有应用程序的沙箱方法。这些特征当然是必要的，但不足以保证Android平台的安全。
同时，移动APP数量呈现爆炸式的增长，黑产也从原来的PC端转移到了移动端，源码被盗，APP被山寨，破解APP后注入病毒或广告，用户数据泄漏，甚至盗取用户账号、密码的现象屡见不鲜，这对Android系统现有安全机制发起了冲击，使得Android手机安全形势更加复杂严峻，APP的安全受到了前所未有的高度关注。
2018年1月30日，谷歌宣布2017年全年，谷歌商店被下架的违规APP超过70万个，2017下架的应用程序数量比2016年增加了70%，其中多达25万的违规APP是其它正规APP的山寨品，故安卓平台的应用体系面临着严峻的安全威胁。如何保护应用的源码、检测应用本身存在的高危漏洞，防止应用被破解、反编译、调试、二次打包，是所有移动APP开发人员共同的难题。
腾讯移动安全实验室发布了“2017年第一季度移动安全报告”，并表示2017年第一季度，Android增加的新病毒包数量增加了465万，同比增长21.42％，是2014年第一季度的33倍。手机病毒感染用户数为6047万。智能手机的覆盖率日益提高，其用户群体愈加广泛，加之Android应用的分发渠道多样，缺乏行之有效的安全筛查标准，导致基于Android平台开发的恶意程序层出不穷。如何扫描出尽可能多的安全威胁，如何健壮手机的安全体系，提供更安全的应用，是用户群体急需的服务。
正是由于Android系统本身的安全保护机制不足以保证Android平台的安全，以及当今Android的APP数量呈爆炸式增长，使得应用安全的需求被无限放大，推动了Android应用软件保护技术的产生和发展，APP加固技术逐渐涌现。
传统的软件保护技术根据所使用的方法，主要分为两类：第一类是基于硬件的保护技术，而第二类是基于软件的保护技术。前一种加密技术需要考虑到硬件设备等底层设备的运行原理，其开发难度大、成本高，但其破解难度大。Android系统硬件保护技术主要由Google和厂家设计，而大部分文献涉及的Android保护机制主要基于是软件保护技术来涉及的，主要包括注册验证，代码混淆，防篡改，加壳技术等，较为灵活，成本较低，同时安全性有限。
APP加固技术不仅以传统软件保护技术为基础，它是与安全扫描的结合体，单纯的使用软件保护技术具有一定的局限性，本项目将APP所处的Android操作系统的环境作为安全扫描的一部分，作为应用加固的一个重要的参考部分。
对开发人员而言，APP加固技术更关注应用本身的漏洞和代码完整性，开发的封闭性与开源性；对用户而言，APP加固技术更关注用户个人信息的保护，这些都与移动APP的安全息息相关。
Android系统概述
Android系统是一个基于Linux的、开源的、用于移动智能终端的操作系统，由Google公司领导和开发。Android系统不仅有庞大的开发者社群，而且有Google和开放手机联盟等诸多公司的技术支持，更新迭代的速度非常之快。Android采用层次化系统架构，Google官方公布的标准架构如图所示，自顶而下划分为5个主要功能层，分别是：
- 系统应用层（System Apps）
- 应用程序框架层（Java API Framework）
- 系统运行时库层（Native C/C++ Libraries和Android Runtime）
- 硬件抽象层（HAL）
- Linux内核层（Linux Kernel）
Linux内核层
Android以Linux操作系统内核为基础开发的，如图1.1所示，可以看到Android系统在Linux内核层实现了声音、进程间的通信、显示、键盘、蓝牙、内存、电源等的管理。值得一提的是，Android系统还针对移动智能终端的需求，对Linux内核一些部分进行的增强。
硬件抽象层
原生库与运行时及以上的部分属于软件层，它与Linux内核内核之间还存在所谓的硬件抽象层（Hardware Abstract Layer, HAL），它是对硬件设备的具体实现加以抽象。HAL位于Android官方系统架构中的Linux内核层的上方，如图简化地标出了硬件抽象层在Android系统中的位置。
因为考虑到厂商为了保护商业技术，很大可能上不愿意公开硬件的技术，但是更好地利于Android系统的各类应用的开发，在Linux内核层与原生库与运行时层之间增加一个硬件抽象层，应用的开发者无需考虑硬件细节，即可通过该层预留的接口进行低层的操作。这使得Android系统的开发更友好，效率也更高。
本地库与运行时层
本地库与运行时层包括本地C/C++层和Android运行时，位于Android架构图中自上而下的第三层。在Android系统架构中，位于硬件抽象层的上面，为Java API框架层提供支持，这是对硬件的再一次抽象，是对硬件抽象层的接口的封装。
系统应用层与Java API框架层
在Android系统架构中常把系统应用层（System Apps）和Java API框架层（Java API Framework）视为一体。Java API框架层包括Android系统的四大组件——Activity、Service、Provider和Receiver，还有视窗系统、位置、包、通知等等，开发者在开发APP时最主要的就是和这一层进行交互，通过该层提供的接口调用相应的组件实现程序的功能，有必要的话，可以调用低一层的本地库（Native C/C++ Libraries）；而系统应用层则是提供给应用的使用者，相机、发邮件、日历、拨号、闹钟、浏览器等都属于该层的范畴，我们平常使用智能手机接触最多的就是这一层。
Android系统的安全机制
应用程序框架安全机制
主要有应用程序的权限控制机制和数字签名机制。应用程序必须在权限内运行，程序安装时系统会对相关文件进行安全检查，通过后授予相应权限。从Android 6.0 (API 23)开始后采用运行时权限策略，普通权限在安装时一次授权完毕，而危险权限在应用运行时由应用自行申请、用户授权同意。
在Android 6.0及更高的版本( API >= 23 )是系统采用运行时权限模式，应用在安装时不会通知用户应用的权限，但是在应用需要使用危险的权限时，会提示用户手动进行授权，而普通权限在安装时一次授权完毕；而在Android 5.1.1级更低的 ( API <=22 )版本，用户需要在应用安装时授权所有的权限，才能正常安装，否则无法安装该应用程序。
应用申请的所有的权限都写在AndroidManifest的
1 | <manifest |
Android的权限体系，一般是分为四种保护等级：正常、危险、签名和签名|特权，但是根据实际情况，往往有许多应用会申请一些不在这四种保护等级范围的权限，所以另外附加两种情况：不允许被第三方应用使用、已弃用。
权限的四个基本保护等级
- 正常（normal[N]）权限的默认值。风险较低的权限，授权时会自动同意，无需用户手动同意。
- 危险（dangerous[D]）一种风险较高的权限，可以使请求的应用程序访问私有用户数据或控制可能对用户产生负面影响的设备。
- 签名（signature[S]）应用A有一个声明了signature等级的权限，则应用B必须具备应用A的相同的签名才行。若证书匹配，系统会自动授权，无需用户操作。
- 签名/特权（signature/privileged[S/P]）API > 23后使用signatureOrSystem表示。一是放置在Android系统上专用文件夹中的应用程序才能获得授权；二是另外一个应用B需要有和有标记为signature的权限的应用A相同的签名。
权限保护等级的两种附加情况
- 不允许被第三方应用使用（Not for Use by third-party applications[NU]）
- 已弃用（out[O]）
这里有必要提及一下第三方应用的概念，Android系统自带的应用以外的，也就是我们开发者开发的Android应用，比如QQ、微博、微信、今日头条、抖音和王者荣耀等等，都是第三方应用，这些应用都是不能拥有NU标注的权限的。
对于带有已弃用标注的权限，有以下三种情况
- 从API级别高于某一值废弃。低于这个数值申请该权限属于正常，但是高于这个数值，再申请肯定是错误的，因为此权限被弃用。我们使用O-xxx来表示从API级别xxx以后废弃该权限。比如O-23表示从API Level为23以后弃用该权限。
- 该权限被某一权限替代。比如BIND_CARRIER_MESSAGING_SERVICE被BIND_CARRIER_SERVICES取代。
- 该权限被永久废弃。我们用O-all来表示。
除了权限的概念外之外，Android系统中还有对权限的分组。权限分组为与设备功能或功能相关的组。在此系统下，权限请求会以组的形式进行提醒。例如，CONTACTS组（与此设备上的联系人和配置文件相关的权限），包括READ_CONTACTS、WRITE_CONTACTS和GET_ACCOUNT，当用户授权了READ_CONTACTS，则Android会自动授权另外两个权限，具体的权限是针对开发者，而对于用户而言是以组的形式展现。
内核安全机制
从技术架构角度来看，Android安全模型基于强健的Linux操作系统内核安全性，故Android的内核安全机制继承自Linux内核的安全机制。进程沙箱机制可以隔离隔离进程资源，限制资源间的自由度；低内存管理技术与新标准Binder IPC通信机制，适应嵌入式移动终端处理器的性能与内存容量的限制。还有完整的权限控制、管理和授权机制，加上签名的引入，能够对Android应用程序的行为进行规范化的管理，对应用之间的关系也进行了定义，包括信任关系和资源共享的授权。
运行环境安全机制
Android 4.4采用Dalvik虚拟机，每个应用都运行在独立的Dalvik虚拟机上，但虚拟机不作为隔离代码的安全边界，所以，在系统Android主要采用强制安全类型来进行加固。在Android 4.4以后Google引入了ART虚拟机，到5.5已经成为默认模式。Android 7.0 向 ART 中添加了一个 just-in-time（JIT）编译器，这样就可以在应用运行时持续的提高其性能。
Android程序结构
Android Studio的APP项目结构
1 | Project |
AndroidManifest.xml是Android项目的配置文件，程序中定义的四大组件都需要在这个文件里面注册，另外还可以在这个文件中给应用程序添加权限声明。proguard-rules.pro该文件用于指定项目代码的混淆规则，这是Android开发工具集里自带的代码混淆工具，当开发者完成开发打成安装包文件，如果不希望被别人破解，通常会将代码进行混淆，从而让破解者难以阅读。
res文件夹中都是用来放置应用的资源文件，比如layout用来放设计的界面布局文件，drawable用来放图片，mipmap用来放图标，values用来放字符串、样式、颜色等配置。
而不同于Eclipse，Android Studio是采用Gradle来构建项目的。Gradle是一个非常先进的项目构建工具，它使用一种基于Groovy的领域特定语言（DSL）来声明项目设置，摒弃了传统基于XML（如Ant和Maven）的各种繁琐配置。项目中的build.gradle一般有两个，一个在最外层的目录下，另一个在app目录下，这两个文件对构建Android Studio项目都起到了至关重要的作用。