移动终端安全期末论文

Android应用程序安全加固保护研究

课程移动终端安全

姓名

学院

专业

班级

学号

年月

摘要

随着Android操作系统的广泛使用和移动互联网时代的到来，Android系统的安全问题也不断出现，给用户和开发者造成了许多困扰。Android应用程序面临着知识产权被侵犯、被二次打包、应用程序遭逆向等安全问题。如何加强Android 平台上的应用程序的安全性就成了一个非常重要的问题。Android中的Apk反编译可能是每个开发都会经历的事，但是在反编译的过程中，对于源程序的开发者来说那是不公平的，那么Apk加固也是应运而生，

基于上述背景，本文首先简单的介绍了一下android的安全机制，和目前状况下android面临的一些问题。然后梳理了android应用程序目前的加固保护手段的最常用的几种方式，并给出了实现的基本思路和方法。然后基于对以上加固保护手段的分析，我们完成了其中一种加固手段：android中dex的加壳实验。针对普通应用程序，完成了加壳实验后，无法得到源应用程序的源码。最后分析调研了目前比较成熟的android应用程序安全加固保护的第三方解决方案，并给出了分析和总结。

关键词:Android；Android安全；Android应用程序加固；逆向；安全加固

目录

1 绪论 (3)

1.1 背景 (3)

1.2 Android安全机制 (4)

1.3 Android应用问题： (5)

2 Android 应用程序加固保护手段： (6)

2.1 Android 应用程序加密保护核心概念 (6)

2.2 android 加固常用技术 (8)

2.2.1 对dex加密来实现加固 (8)

2.2.2 对native层进行加密 (8)

2.2.3 直接对目标函数进行加密 (9)

2.2.4 反逆向 (11)

2.2.5 反调试 (12)

2.2.6 代码混淆 (13)

3． Android中DEX加壳的原理与实验： (14)

3.1 Android 应用程序 DEX加壳的基本原理： (14)

3.2 APK加壳实验 (14)

3.2.1 Dex文件的头部信息： (14)

3.2.2 Android动态加载： (18)

3.2.3 android apk加壳实验基本介绍： (19)

3.2.4 运行实验程序 (21)

4 目前Android 应用程序成熟的第三方解决方案 (23)

4.1. 娜迦 (23)

4.2. 爱加密 (23)

4.3. 梆梆加固 (25)

4.4. 360加固保 (25)

4.5 上述产品分析及总结 (26)

5 总结 (26)

1绪论

1.1背景

Android系统是基于Linux的智能操作系统，2007年11月，Google与84家硬件制造商、软件开发商及电信运营商组建开发手机联盟，共同研发改良Android系统。随后Google以Apache开源许可证的授权方式，发布了Android 的源代码。也就是说Android系统是完整公开并且免费的，Android系统的快速发展，也与它的公开免费不无关系。

随着Android系统的迅猛发展，它已经成为全球范围内具有广泛影响力的操作系统。Android系统已经不仅仅是一款手机的操作系统，它越来越广泛的被应用于平板电脑、可佩戴设备、电视、数码相机等设备上。

Android操作系统以其基于Linux内核、开放源码等特性，迅速得到广大开发人员以及许多厂商的支持。与此同时，基于Android平台的应用程序数目飞速增长。2010年10月，Android团队宣布Android应用程序数量达到10万。2013年7月，Google公司宣布Go091e P1av商店的应用程序数量已经超过100万个，成为全球最大的应用商店。目前，全球的Android开发人员已经为广大用户开发出海量的应用程序，这给用户带来方便的同时也带来了巨大的安全隐患。据360互联网安全中心所发布的《2013年中国手机安全状况报告》瞄显示，Android 平台新增恶意程序样本67．1万个，较2012年增长4．4倍；用户感染恶意程序9747万人次，较2012年增长了88．3％，平均每天恶意程

序感染量接近30万人次Android平台在登陆市场几年间，发展迅速，占据了大量的移动终端市场，已经逐渐成为了移动终端的最普及的操作系统，同时基于其中的软件应用数目也相当惊人，然而与之并生的安全问题却始终没有得到良好的解决，安全威胁越来越多，且威胁程度也在逐步加深，无论对开发者还是用户都带来了不良的影响。

由于Android应用程序使用Java语言编写，其本身容易被逆向，进而攻击者可以轻松地获得Android应用程序的源代码。因此，目前Android系统在安全方面所面临的主要问题就是盗版应用和恶意软件。盗版应用的盛行极大损害了广大开发者的利益和积极性，而恶意代码的植入使得Android用户面临隐私泄漏和财产损失的风险。

为此，国内外研究者在Android应用程序保护方面开展了许多工作，包括防盗版、防篡改、数据保护以及核心代码的防逆向等。近年来，Android恶意代码的数量不断攀升，盗版和恶意软件层出不穷。只有通过加固Android应用程序逆，才能从源头上有效遏制这些问题。

1.2 Android安全机制

Android将安全设计贯穿系统架构的各个层面，覆盖系统内核、虚拟机、应用程序框架层以及应用层各个环节，力求在开放的同时，也恰当保护用户的数据、应用程序和设备的安全。Android安全模型主要提供以下几种安全机制：

（1）进程沙箱隔离机制

进程沙箱隔离机制，使得Android应用程序在安装时被赋予独特的用户标识（UID），并永久保持。应用程序及其运行的Dalvik虚拟机运行在独立的Linux 进程空间，与其它应用程序完全隔离。

（2）应用程序签名机制

应用程序签名机制，规定APK文件必须被开发者进行数字签名，以便标识应用程序作者和在应用程序之间的信任关系。在安装应用程序APK时，系统安装程序首先检查APK是否被签名，有签名才能安装。当应用程序升级时，需要检查新版应用的数字签名与已安装的应用程序的签名是否相同，否则，会被当做一个新的应用程序。Android开发者有可能把安装包命名为相同的名字，通过不同的签名可以把他们区分开来，也保证签名不同的包不被替换，同时防止恶意软件替换安装的应用。

（3）权限声明机制

权限声明机制，要想获得在对象上进行操作，就需要把权限和此对象的操作进行绑定。不同级别要求应用程序行使权限的认证方式也不一样，Normal级申请就可以使用，Dangerous级需要安装时由用户确认，Signature和Signatureorsystem级则必须是系统用户才可用。

（4）访问控制机制

访问控制机制，确保系统文件和用户数据不受非法访问。

（5）进程通信机制

进程通信机制，基于共享内存的Binder实现，提供轻量级的远程进程调用（RPC）。通过接口描述语言（AIDL）定义接口与交换数据的类型，确保进程间通信的数据不会溢出越界。

（6）内存管理机制

内存管理机制，基于Linux的低内存管理机制，设计实现了独特的LMK，将进程重要性分级、分组，当内存不足时，自动清理级别进程所占用的内存空间。同时，引入的Ashmem内存机制，使得Android具备清理不再使用共享内存区域的能力。

1.3 Android应用问题：

Android应用会遇到各种各样的安全性问题，如何从宏观上了解各种安全隐患，积极采取适当的防御措施便变得尤为重要。那么，Android应用面临哪些安全问题呢？

（1）病毒

Android病毒就是手机木马，主要是一些恶意的应用程序。比如央视曾经曝光的一款名为“银行悍匪”的手机银行木马，模仿真正的手机银行软件，通过钓鱼方式获取用户输入的手机号、身份证号、银行账号、密码等信息，并把这些信息上传到黑客指定服务器。盗取银行账号密码后，立即将用户账户里的资金转走。手机木马有的独立存在，有的则伪装成图片文件的方式附在正版App上，隐蔽性极强，部分病毒还会出现变种，并且一代比一代更强大。

（2）静态破解：

通过工具apktool、dex2jar、jd-gui、DDMS、签名工具，可以对任何一个未加密应用进行静态破解，窃取源码。

（3）二次打包

通过静态破解获取源码，嵌入恶意病毒、广告等行为再利用工具打包、签名，形成二次打包应用。

（4）本地储存数据窃取

通过获取root权限，对手机中应用储存的数据进行窃取、编辑、转存等恶

意行为，直接威胁用户隐私。

（5）界面截取

通过adb shell命令或第三方软件获取root权限，在手机界面截取用户填

写的隐私信息，随后进行恶意行为。

（6）输入法攻击

通过对系统输入法攻击，从而对用户填写的隐私信息进行截获、转存等恶意操作，窃取敏感信息。

（7）协议抓取

通过设置代理或使用第三方抓包工具，对应用发送与接收的数据包进行截获、重发、编辑、转存等恶意操作。

（8）关键信息泄露

Android的几大组件的创建方式是依赖注入的方式，因此不能被混淆。通过目前常用的一些反编译工具比如apktool等能够毫不费劲地还原Java里的明文信息，native里的库信息也可以通过objdump或IDA获取。因此一旦Java或native代码里存在明文敏感信息，基本上就是毫无安全而言的

（9）进程被劫持

进程被劫持一般通过进程注入或者调试进程的方式来hook进程，改变程序运行的逻辑和顺序，从而获取程序运行的内存信息。hook需要获取root权限或者跟被hook进程相同的权限。如果手机没被root，被劫持的可能性还是较小。

（10）数据在传输过程遭劫持

数据在传输过程遭劫持，一般来说是由于数据明文传输或没使用HTTPS。Webview漏洞一般由于JS注入。

（11） Webview漏洞

由于现在hybrid app的盛行，Webview在app的使用也是越来越多，Android 系统Webview存在一些漏洞，造成js提权。最为著名的就是传说中js注入漏洞和webkit xss漏洞。

2Android 应用程序加固保护手段：

2.1Android 应用程序加密保护核心概念

（1）防内存窃取

防止通过gdb、gcore，从内存中截取dex文件，获取代码片段，从而反编译还原APK进行不法操作。

（2）防动态跟踪

防止通过ptrace调试进程，跟踪、拦截、修改正在运行的应用，进行动态注入，保护程序运行安全。

（3）防逆向分析

防止通过APKTool、IDA Pro等反编译工具破解DEX文件，从而获取APK源代码，保护代码层安全。

（4）防恶意篡改

校验APK完整性，自动终止运行被篡改的APK，二次打包后应用都无法使用，杜绝盗版应用的出现。

（5）存储数据加密保护

更底层，跨文件格式的数据加密，防止应用数据被窃取。

（6）对抗反编译

对抗反编译是指apk文件无法通过反编译工具（例如ApkTool，BakSmali，dex2jar等）对其进行反编译，或者反编译后无法得到软件正确的反汇编代码。基本思路是寻找反编译工具在处理apk或者dex文件时的缺陷，然后在自己的代码中加以利用，让反编译工具在处理我们apk文件的时候抛出异常或者反编译失败，有两种方法可以找到反编译工具的缺陷：

●阅读反编译工具的源码

●压力测试

（7）对抗静态分析

反编译工具一直在改进，因此即使你在版本2.1发现它的缺陷并加以利用，使反编译你的apk失败，但很可能在版本2.2就把这个缺陷解决了，因此，不要指望反编译工具永远无法反编译你的apk，我们还需要使用其他方法来防止apk 被破解：

（8）代码混淆技术

ProGuard提供了压缩，混淆，优化Java代码和（Shrinking），混淆（Obfuscation），优化（Optimition）Java代码和反混淆栈跟踪（ReTrace）

的功能。

（9）NDK保护

逆向NDK程序的汇编代码比逆向Java代码枯燥和困难很多，同时使用C++

也可以对敏感字符串和代码进行加密。

（10）外壳保护

针对NDK编写的Native代码。

（11）对抗动态调试

检测调试器：动态调试使用调试器来挂钩apk，获取apk运行时的数据，因此，我们可以在apk中加入检测调试器的代码，当检测到apk被调试器连接时，终止apk的运行。

（12）检测模拟器

apk发布后，如果发现其运行在模拟器中，很有可能是有人试图破解或者分析它，因此这时我们也要终止apk的运行。

（13） Android 开发设置

Android 系统在 android.os.Debug 类中提供了 isDebuggerConnected()

方法，用于检测是否有调试器连接。可以在 Application 类中调用isDebuggerConnected()方法，判断是否有调试器连接，如果有，直接退出程序。除了 isDebuggerConnected 方法，还可以通过在 AndroidManifest 文件的application 节点中加入android:debuggable=”false”使得程序不可被调试，这样如果希望调试代码，则需要修改该值为 true，因此可以在代码中检查这个属性的值，判断程序是否被修改过，代码如下：

（14）防止重编译

●检查APK的签名

●校验APK的完整性

●校验classes.dex文件的完整性

2.2 android加固常用技术

2.2.1对dex加密来实现加固

我们把需要加固的apk，外部包装一层壳，而这个壳的作用是为了解密源apk 的，比如现在360加固都是采用这种思想。360加固给需要加壳的apk添加一层Application。这样启动加壳之后的apk，其实是先启动这个Application，然后这个Application就开始解密apk操作，然后动态加载apk运行源程序。

2.2.2对native层进行加密

Android的消息机制中，不仅提供了供Application 开发使用的Java的消息循环。其实java的机制最终还是靠native来实现的。在native不仅提供一套消息传递和处理的机制，还提供了自定义文件描述符的I/O时间的监听机制。Native层最重要的就是so文件，so文件中有很多section,我们可以将我们的目标函数存到指定的section中，然后对section进行加密即可。找到一个section的base和size就可以对这段section进行加密了

加密流程：

1) 从so文件头读取section偏移shoff、shnum和shstrtab

2) 读取shstrtab中的字符串，存放在str空间中

3) 从shoff位置开始读取section header, 存放在shdr

4) 通过shdr -> sh_name 在str字符串中索引，与.mytext进行字符串比较，如果不匹配，继续读取

5) 通过shdr -> sh_offset 和 shdr -> sh_size字段，将.mytext内容读取并保存在content中。

6) 为了便于理解，不使用复杂的加密算法。这里，只将content的所有内容取反，即 *content = ~(*content);

7) 将content内容写回so文件中

8) 为了验证第二节中关于section 字段可以任意修改的结论，这里，将shdr -> addr 写入ELF头e_shoff，将shdr -> sh_size 和 addr 所在内存块写入

e_entry中，即ehdr.e_entry = (length << 16) + nsize。当然，这样同时也简化了解密流程，还有一个好处是：如果将so文件头修正放回去，程序是不能运行的。

解密时，需要保证解密函数在so加载时被调用，那函数声明为：init_getString

__attribute__((constructor))。(也可以使用c++构造器实现，其本质也是用attribute实现)

解密流程：

1) 动态链接器通过call_array调用init_getString

2) Init_getString首先调用getLibAddr方法，得到so文件在内存中的起始地址

3) 读取前52字节，即ELF头。通过e_shoff获得.mytext内存加载地址，ehdr.e_entry获取.mytext大小和所在内存块

4) 修改.mytext所在内存块的读写权限

5) 将[e_shoff, e_shoff + size]内存区域数据解密，即取反操作：*content = ~(*content);

6) 修改回内存区域的读写权限，这里是对代码段的数据进行解密，需要写权限。如果对数据段的数据解密，是不需要更改权限直接操作的

2.2.3直接对目标函数进行加密

在so文件中，每个函数的结构描述是存放在.dynsym段中的。每个函数的名称保存在.dynstr段中的，类似于每个section的名称都保存在.shstrtab段中，所以在上面的方法中中我们找到指定段的时候，就是通过每个段的sh_name字段到.shstrtab中寻找名字即可，而且我们知道.shstrtab这个段在头文件中是有一个index的，就是在所有段列表中的索引值，所以很好定位.shstrtab.

so中函数的表现形式：

在so文件中，每个函数的结构描述是存放在.dynsym段中的。每个函数的名称保存在.dynstr段中的，.shstrtab值存储段的名称，.dynstr是存储so中的所有符号名称。

Elf文件中有一个.hash段，在上图中我们也可以看到的：

由于Elf32_Word 对象组成的哈希表支持符号表访问。用目标函数名在用hash 函数得到一个hash值，然后再做一些计算就可以得到这个函数在.dynsym段中这个函数对应的条目了。关于这个hash函数，是公用的，我们在Android中的bonic/linker.c源码中也是可以找到的：

1.unsigned long elf_hash (const unsigned char *name) {

2.unsigned long h = 0, g; while (*name)

3.{

4. h=(h<<4)+*name++; if (g = h & 0xf0000000)

5. h^=g>>24; h&=-g;

6.}

7.return h; }

我们只要得到.hash段即可.程序头信息是最后so被加载到内存中的映像描述，这里我们看到有一个.dynamic段。我们再看看so文件的装载视图和链接视图：

在so被加载到内存之后，就没有section了，对应的是segment了，也就是程序头中描述的结构，而且一个segment可以包含多个section,相同的section 可以被包含到不同的segment中。.dynamic段一般用于动态链接的，所以.dynsym 和.dynstr，.hash包含在这里解析了程序头信息之后，通过type获取到.dynamic 程序头信息，然后获取到这个segment的偏移地址和大小，在进行解析成

elf32_dyn结构。下面两种图就是程序头的type类型和dyn结构描述，可以在elf.h中找到：

这里的三个字段很好理解：

d_tag：标示，标示这个dyn是什么类型的，是.dynsym还是.dynstr等

d_val：这个section的大小

d_ptr：这个section的偏移地址

细心的同学可能会发现一个问题，就是在这里寻找.dynamic也是通过类型的，然后再找到

具体步骤;

编写native程序，只是native直接返回字符串给UI。需要做的是对

Java_com_example_shelldemo2_MainActivity_getString函数进行加密。加密和解密都是基于装载视图实现。需要注意的是，被加密函数如果用static声明，那么函数是不会出现在.dynsym中，是无法在装载视图中通过函数名找到进行解

密的。当然，也可以采用取巧方式，类似上节，把地址和长度信息写入so头中实现。Java_com_example_shelldemo2_MainActivity_getString需要被调用，那么一定是能在.dynsym找到的。

加密流程：

1) 读取文件头，获取e_phoff、e_phentsize和e_phnum信息

2) 通过Elf32_Phdr中的p_type字段，找到DYNAMIC。从下图可以看出，其实DYNAMIC就是.dynamic section。从p_offset和p_filesz字段得到文件中的起始位置和长度

3) 遍历.dynamic，找到.dynsym、.dynstr、.hash section文件中的偏移

和.dynstr的大小。在我的测试环境下，fedora 14和windows7 Cygwin x64中elf.h定义.hash的d_tag标示是：DT_GNU_HASH;而安卓源码中的是：DT_HASH。

4) 根据函数名称，计算hash值

5) 根据hash值，找到下标hash % nbuckets的bucket；根据bucket中的值，读取.dynsym中的对应索引的Elf32_Sym符号；从符号的st_name所以找到

在.dynstr中对应的字符串与函数名进行比较。若不等，则根据chain[hash % nbuckets]找下一个Elf32_Sym符号，直到找到或者chain终止为止

6) 找到函数对应的Elf32_Sym符号后，即可根据st_value和st_size字段找到函数的位置和大小

7) 后面的步骤就和上节相同了，这里就不赘述

解密流程为加密逆过程，大体相同，只有一些细微的区别，具体如下：

1) 找到so文件在内存中的起始地址

2) 也是通过so文件头找到Phdr；从Phdr找到PT_DYNAMIC后，需取p_vaddr 和p_filesz字段，并非p_offset，这里需要注意。

3) 后续操作就加密类似，就不赘述。对内存区域数据的解密，也需要注意读写权限问题。

2.2.4 反逆向

反逆向是应用程序安全保护的第一重要步骤，良好的反逆向措施可以起到举足轻重的作用。为了增强反逆向能力，起初仅仅是通过修改apk（也就是Zip包）的头部的一位信息，将压缩头部中的一位（Central Directory Encrypted Flag）从0修改为1。这样用压缩软件解压时会提醒该软件已经被加密，但该apk仍然可以正常安装运行（Android系统不会判断该apk是否被加密），从而给逆向分析人员在PC端分析apk时增加难度。但是这种手段基本上并没有多大改变。第二种就是通过破坏apk的文件结构，尽可能的防止apk被加压缩，但是该apk仍能在Android系统正常运行和安装，而且也能兼容到所有系统。Android系统对通过线性解析apk，恢复Dex具体的结构来具体实现加载。采用修改编码并打包好的apk文件，在apk文件后面追加512个字节。通过FileInputStream读入apk 文件，新建一个文件，用ByteArrayOutputStream将apk写入进去，之后再往文件里面增加若干字节的“垃圾数据”即可。

“垃圾字节码”的插入也在x86体系中非常流行。它的作用主要是用来混淆反编译工具，让反编译工具不能正常解析代码，产生错误的或者阅读不良好的反编译代码，以增加逆向人员的分析难度。在程序字节码文件中，由于“垃圾字节码”插入，反汇编工具本来期待的正常指令被“垃圾字节码”代替，从而解析错误。“垃圾字节码”需要选定好插入的位置，这个位置不能够影响程序的正常运行，并且应该最大可能的“迷惑”反编译工具。因此，“垃圾字节码”的插入必须是永远不会被程序执行的位置。可以从两个方面入手插入的“垃圾字节码”，一个是插入不会被执行的字节码，该字节码不会被执行，但是可以欺骗过反编译工具；另一个是字节码有条件转跳的字节码，在转跳字节码与正常的字节码之间插入垃圾字节码。程序在运行时会跳过垃圾字节码，不会受到影响，但由于反编译工具的线性扫描算法，垃圾字节码同样可以使得反编译工具无效。在代码中编写一行无实际意义的代码。

2.2.5 反调试

结合逆向工程中的知识我们知道，逆向应用程序的另一个有效办法是动态分析法。为了抵抗对应用程序的动态分析，可以从以下几个方面来作反调试保护工作：

1、模拟器检测，IMEI在每个设备上是独一无二的，且Android模拟器的IMEI 是15连续的0 。应用程序通过获取当前运行环境的IMEI信息可以判断当前是

否处于模拟器环境中，如果是则退出运行。除了检查设备的IMEI外，还可以通过系统全局属性来判断当前运行环境是否为模拟器，即通过Build.MODEL.equals （"sdk"）或（Build.MODEL.equals（"Google_sdk"）可以判断当前是否处于模拟器运行环境。此外，Android的各个操作系统版本都有“code name”，在模拟器中，系统全局属性BRAND和DEVICE的值都是“generic”，通过Build.BRAND.equals （“generic”）或Build.DEVICE.equals（“generic”）是否为真也可以判断当前运行环境是否为模拟器。模拟器检测代码如下文所示。

TelephonyManager tm = (TelephonyManager)

2、由于模拟器是虚拟设备，其还存在特殊文件或目录，如

/system/bin/qemu-props文件，该文件是专门用于在模拟器中设置系统属性的，如文件/system/lib/libc_malloc_debug_qemu.so和/sys/qemu_trace目录等，它们也是

存在于模拟器中的。通过验证这些文件或目录是否存在，同样可以判断当前运行环境是否为模拟器。

3、Linux系统中，调试一个程序需要调用Ptrace函数，且同一个进程无法被Ptrace两次。可以考虑在应用程序中生成额外的守护进程，该进程与主进程相互Ptrace，这样其他进程就无法Ptrace到主进程中，即无法调试应用程序。此外，Android系统也提供了Android.os.Debug类，该类的isDebuggerConnected方法可以用来检测是否有调试器链接存在。此外，在AndroidManifest.xml的application 节点中加入Android:debuggable="false"也可以设置应用程序不可调式。

DVM实现调试的机制为设置断点、单步执行、Java对象检测，最后给出序列图。在利用JDWP调试时，DVM里额外的调试进程会被生成，调试着直接与应用程

序通信（通过DVM），且在应用程序初始化阶段（context对象生成），调试环境就已经设定好了。直接在Native层防止被调试，需要与DVM直接通信。要想防止这类调试器调试应用程序，可以在Native层做调试检测。

2.2.6代码混淆

混淆是一种常用的保护软件以及算法的技术。该技术用来增大逆向工程的难度，增加时间、人力、物力的成本，使破解难度加大。混淆技术不能改变程序的逻辑行为，也不能改变程序的其他行为，混淆仅仅用来增加逆向工程的难度，使用混淆技术有可能增加程序运行的效率。混淆还可以和指令乱序结合起来使用，正常情况下，编译好的指令是按照业务逻辑编程时确定下来的，这样逆向分析人员容易采取单步向下的阅读方法来阅读分析。如果采取某种指令乱序手段，打破了常规的指令顺序，则可以进一步增加分析的难度。

程序的正常执行流程应该是先执行指令1，继而执行指令2，最后执行指令3，并且三个指令按顺序出现。通过指令乱序方法三个指令的顺序发生了变化，指令3出现在第一个，继而是指令2，最后是指令1 。虽然指令的出现顺序发生了变化，但是指令的执行过程却不变，任然是指令1->指令2->指令3 。当大量的指令乱序后，产生的结果更加复杂，势必会增加逆向分析人员的难度。Android系统中有如下成熟的混淆工具：ProGard、Allatoria、DexGuard，

2.2.7 数据保护

1、数据完整性校验

每个应用程序都有自己的签名和包名，在程序启动时，可以通过获取apk本身的签名，并和已有的签名做对比来判断应用程序是否被二次打包。这里有两种方式，一种是apk本身的签名已经保存在某处，程序运行时重新计算该签名并与已保存的签名进行验证；另一种是应用程序计算自己的签名，并上传到服务器作验证，由服务器判断apk是否为正版。

2、数据存储安全

对于存储在SD卡上的储数据，应该尽可能避免隐私数据泄露。可以从三个方面来入手，一个是将数据从外部存储卡转存到内部存储，二是对外部存储的数据进行加密处理，三是尽可能的不存储隐私的数据。将数据加密存储可以较好的保护数据的安全性，重点在于选择高效率的加密算法。对于存储在系统内部的数据，权限和加密则必不可少。Android中操作数据库有两种方式，分别是使用SQLiteOpenHelper 或使用ContentProvider。数据库存放在data/data//databases/目录，对于root用户，这个目录可以随意访问。因此，私密数据也要做到加密存储。使用这两个时，需要在主配置文件AndroidManifest.xml来注册，为了数据库数据安全就要对访问进行控制，在AndroidManifest.xml注册Provider时设置

Android:exported="false"，则外部应用程序无法对该Provider进行访问。如果想让外部可以访问到本Provider，如果需要外部操作有读权限，则设置

android:readPermission为“true”。为了具有写操作权限，则需要设置

android:writePermission为“true”。此外，任何数据库都需要防范SQL注入，Android

数据库也不例外。对SharePreference来说，存储的敏感键值对也要加密处理，避免明文存储密码等数据。

3Android中DEX加壳的原理与实验：

3.1 Android应用程序DEX加壳的基本原理：

需要加密的Apk和自己的壳程序Apk，然后用加密算法对源Apk进行加密在将壳Apk进行合并得到新的dex文件，最后替换壳程序中的dex文件即可，得到新的Apk,那么这个新的Apk我们也叫作脱壳程序Apk.他已经不是一个完整意义上的Apk程序了，他的主要工作是：负责解密源Apk.然后加载Apk,让其正常运行起来。

主要流程图如下图所示：

我们在加固的过程中需要三个对象：

1、需要加密的Apk(源Apk)

2、脱壳程序Apk(负责解密Apk工作)

3、加密工具(将源Apk进行加密和壳Dex合并成新的Dex)

3.2APK加壳实验

3.2.1 Dex文件的头部信息：

Dex文件和Class文件的都是有固定的格式，我们知道现在的反编译的一些工具:

1、jd-gui：可以查看jar中的类，其实他就是解析class文件，只要了解class 文件的格式就可以

2、dex2jar：将dex文件转化成jar，原理也是一样的，只要知道Dex文件的格式，能够解析出dex文件中的类信息就可以了

当然我们在分析这个文件的时候，最重要的还是头部信息，应该他是一个文件的开始部分，也是索引部分，内部信息很重要。

Dex文件头主要包括校验和以及其他结构的偏移地址和长度信息。

那么接下来我们就可以来介绍dex的文件结构了，首先还是来看一张大体的结构图：

基本的格式如下：

修改文件校验码(checksum).因为他是检查文件是否有错误。那么signature也是一样，也是唯一识别文件的算法。还有就是需要修改dex文件的大小。

所以我们需要做的就是：修改Dex的三个文件头，将源Apk的大小追加到壳dex 的末尾。

这里需要用到的字段的解释：

1) checksum

文件校验码，使用alder32 算法校验文件除去 maigc ，checksum 外余下的所有文件区域，用于检查文件错误。

2) signature

使用 SHA-1 算法 hash 除去 magic ,checksum 和 signature 外余下的所有文件区域，用于唯一识别本文件。

3) file_size

Dex 文件的大小。

我们修改之后得到新的Dex文件样式如下：

那么我们知道原理了，下面就是代码实现了。所以这里有三个工程：

1、源程序项目(需要加密的Apk)

2、脱壳项目(解密源Apk和加载Apk)

3、对源Apk进行加密和脱壳项目的Dex的合并

3.2.2 Android动态加载：

Android应用类似于Java程序，只不过虚拟机换成了Dalvik/ART，而Jar

换成了Dex。在Android APP运行的时候，动态调用外部的Dex文件。在APK

文件中往往有一个或者多个Dex文件，我们写的每一句代码都会被编译到这些文件里面，Android应用运行的时候就是通过执行这些Dex文件完成应用的功能的。虽然一个APK一旦构建出来，我们是无法更换里面的Dex文件的，但是我们可以通过加载外部的Dex文件来实现动态加载，这个外部文件可以放在外部存储，或者从网络下载

Android项目中，动态加载按技术实现上的区别大致可以分为两种：

●动态加载.so库

●动态加载.dex/jar/apk（现在动态加载普遍说的是这种）

其一，Android中NDK中其实就使用了动态加载，动态加载.so库并通过JNI 调用其封装好的方法。后者一般是由C++编译而成，运行在Native层，效率会

比执行在虚拟机的Java代码高很多，所以Android中经常通过动态加载.so库

来完成一些对性能比较有需求的工作。由于.so库是由C++编译而来的，只能被反编译成汇编代码，相比Smali更难被破解，因此.so库也可以被用于安全领域

其二，“基于ClassLoader的动态加载.dex/jar/apk”就是我们上面提到的“在Android中动态加载由Java代码编译而来的Dex包并执行其中的代码逻辑”，这是常规Android开发比较少用到的一种技术，目前网络上大多文章说到的动态

加载指的就是这种。Android项目中，所有Java代码都会被编译成Dex包，Android应用运行时，就是通过执行Dex包里的业务代码逻辑来工作的。使用动态加载技术可以在Android应用运行时加载外部的Dex包，而通过网络下载新的Dex包并替换原有的Dex包就可以达到不安装新APK文件就升级应用的目的。后续实验就是这种加载方式。

Java中.class 文件类似于我们的windows 的DLL或者Linux下的.SO 文件，在Winodows 下我们使用DLL的服务，我们必须使用使用LoadLibaray函数加载它。同理在java中我们要使用.class中的的类，我们必须使用类加载器加载后，才能使用。在android中我们如果提供一个DexClassLoader(继承ClassLoader), 这个DexClassLoader 可以用来加载.jar, .apk, .class 文件。

基本的步骤如下：

1)反射调用这个函数ActivityThread.currentActivityThread 拿到一个

当前ActivityThread对象

2)反射获取ActivityThread对象的final HashMap

WeakReference> mPackages 成员

3)从mPackages获取已在加载的LoadedApk 对象

4)反射获取LoadedApk 对象的LoadedApk.mClassLoader成员

5)用新的ClassLoaded 替换原来的mClassLoader

3.2.3androidapk加壳实验基本介绍：

我们的实验主要包含以下三个项目：

1、需要加密的源程序Apk项目：ForceApkObj

这个apk中有三个java文件

第一个展示界面为打开app显示的Activity。第二个为application在onCreat 方法用log.i打印一下，用来后续观察结果。第三个包含一个activity，以及用lod记录一下。