最近一直处于忙碌的状态，花了很长一段时间，抽出碎片时间才将这篇帖子写完，本文结合上文的动态加载文章一起学习，本文主要讲述Android中存在的插件化漏洞、签名机制漏洞、解压缩漏洞等，并对一些经典的漏洞进行了复现，本文的相关实验文件由于太多，后面都会上传到知识星球

本文第二节主要讲述Dex文件结构、Zip文件结构、Android签名机制

本文第三节主要讲述插件化漏洞和解压缩漏洞的安全场景

本文第四节主要对插件化漏洞进行讲述

本文第五节主要对解压缩漏洞进行讲述

本文第六节主要对Janus漏洞原理进行讲述

dex文件是anroid虚拟机Dalik运行的一种文件，包含应用程序的全部操作指令以及运行时数据，下面我们看下.class文件和.dex文件的区别：

我们可以发现dex文件将原来每个文件都有的共有信息合成一体，从而减少了class的冗余

下面我们进一步详细看dex文件结构

我们可以发现dex文件主要由3大部分组成，分别是：文件头、索引区、数据区。其中索引区主要包括字符串、类型、方法、域、方法的索引。数据区主要包括类的定义、数据区、链路数据区

上面我们可以看出Dex文件由许多部分组成，其中Dex Header最为重要，因为Dex的其他组成部分，都需要通过Dex Header中的索引才能找到

dex文件头一般固定为0x70个字节大小，包括标志、版本号、校验码、sha-1签名以及其他一些方法、类的数量和偏移地址等信息。如图所示：

结合上面的两张图进行对照，下面我们进一步详细的描述dex文件的结构

dex文件索引区主要是对一些字符串、类型、方法、域、方法的索引，方法可以查找到对应的数据位置

数据区一般包括类的定义区、数据区、链接数据区。类的定义区一般存放dex文件中一些类对象的声明，数据区则存放代码原数据，链接数据区一般提供从索引区到数据区的链接映射关系

zip文件是比较常见的压缩文件，我们先来看一下zip文件的基本结构图：

通过图中我们可以看出，zip文件一般分为三个部分：源文件数据存储区、中心目录区、中心目录结束标识

记录着压缩的所有文件的内容信息，其数据组织结构是每个文件都由local file header、file data、data descriptor三部分组成

用于标识文件的开始，文件结构如下：

主要存放相应的压缩文件的源数据

一般用于标识该文件压缩结束，该结构只有在相应的header中通用标记字段的第３位设为１时才会出现，紧接在压缩文件源数据后。这个数据描述符只用在不能对输出的 ZIP 文件进行检索时使用。例如：在一个不能检索的驱动器（如：磁带机上）上的 ZIP 文件中。如果是磁盘上的ZIP文件一般没有这个数据描述符。

对于待压缩的目录而言，每一个子目录对应一个压缩目录源数据，记录该目录的描述信息。压缩包中所有目录源数据连续存储在整个归档包的最后，这样便于向包中追加新的文件。头部的结构如下：

目录结束标识存在于整个归档包的结尾，用于标记压缩的目录数据的结束，结构如下：

应用签名主要是避免外部恶意解压、破解或者反编译修改内容，签名的本质是：

截止到Android12，Android支持三种应用签名方案：

为了提高兼容性，必须按照v1,v2,v3的先后顺序采用签名方案，低版本平台会忽略高版本的签名方案在APK中添加额外数据，具体流程图如下：

最基本的签名方案，是基于Jar的签名

v1签名后会增加META-INF文件夹，其中会有如下三个文件：

v1签名流程：

验证流程：

主要包括验证签名、校验完整性两个步骤：

步骤1：验证签名步骤

步骤2：验证完整性

上面任何一个步骤验证失败，则整个APK验证失败

问题：

Android7.0 中开始引入了APK签名方案v2，一种全文件签名方案，该方案能够发现对APK的受保护部分进行所有更改，相比v1来说校验速度更快，覆盖的范围也更广。但是考虑到版本兼容的问题，所以一般常见了v1+v2的混合签名模式

我们由上文知道Zip文件主体分为：源文件数据存储区、中心目录区、中心目录结束标识。EoCD中记录了中央目录的起始位置，在源文件数据存储区和中心目录区插入其他数据不会影响Zip的解压

因此v2签名后会在源文件数据存储区和中心目录区插入APK 签名分块（APK Signing Block）

如下图所示。从左到右边，我们定义为区块 1~4

v2签名块（APK Signing Block）本身又主要分成三部分:

签名流程：

​ 相比v1签名方案，v2签名方案不再以文件为单位计算摘要，而是以1MB为单位将文件拆分为多个连续的快（chunk），每个分区的最后一个快可能会小于1MB。v2签名流程如下：

验证流程：

因为v2签名机制是在Android 7.0上版本才支持，因此对于Android 7.0以及以上版本，在安装过程中，如果v2 签名块，则必须走 v2 签名机制，不能绕过。否则降级走 v1 签名机制

v1 和 v2 签名机制是可以同时存在的，其中对于 v1 和 v2 版本同时存在的时候，v1 版本的 META_INF 的 .SF 文件属性当中有一个 X-Android-APK-Signed 属性：

v2签名本身的验证过程：

Android 9.0中引入了新的签名方式v3，v3签名在v2的基础上，仍然采用检查整个压缩包的校验方式。不同的是在签名部分增可以添加新的证书（Attr块）。在这个新块中，会记录我们之前的签名信息以及新的签名信息， 支持密钥轮换，即以密钥转轮的方案，来做签名的替换和升级。这意味着，只要旧签名证书在手，应用能够在 APK 更新过程中更改其签名密钥。

v3 签名新增的新块（attr）存储了所有的签名信息，由更小的 Level 块，以链表的形式存储。

签名流程：

v3版本签名块也分成同样的三部分，与v2不同的是在SignerData部分，v3新增了attr块，其中是由更小的level块组成。每个level块中可以存储一个证书信息。前一个level块证书验证下一个level证书，以此类推。最后一个level块的证书，要符合SignerData中本身的证书，即用来签名整个APK的公钥所属于的证书。从v2到v3的过渡：

签名校验：

Android 的签名方案的升级都需要确保向下兼容。因此，在引入 v3 方案后会根据 APK 签名方案，v3 -> v2 -> v1 依次尝试验证 APK。而较旧的平台会忽略 v3 签名并尝试 v2 签名，最后才去验证 v1 签名。如下图所示：

注意：对于覆盖安装的情况，签名校验只支持升级而不支持降级。即一个使用 V1 签名的 Apk，可以使用 V2 签名的 Apk 进行覆盖安装，反之则不允许

v3签名自身的校验：

v2、v3的比较如下图所示：

验证签名的时机主要要了解Android安装应用的方式：

但是其实无论通过哪种方式安装都要通过PackageManagerService来完成安装的主要工作，最终在PMS中会去验证签名信息，如v3验证方式一样

Android动态加载总会涉及到插件化、热部署、热修复等，这里我在网上查阅资料后，给大家总结了下动态加载的场景使用和分类：

动态加载，就是程序运行时，可以加载外部的可执行文件并运行，这样使得我们可以不用安装apk就可以更新应用，针对一些SDK项目，可以加快app新版本的覆盖率、快速修复线上bug。这里运行时是指应用冷启动并开始工作后，外部可以是SD卡，可以是data目录，也可以是jniLib目录，这些可执行文件是没有随着应用一起编译的的

动态加载的特点：

Android动态加载按照工作机制不同，可以分为虚拟机层动态加载和Native层动态加载两大类

这里由于本文主要讲解动态加载方面漏洞，所以对热更新、热修复等原理就不深究了，大家感兴趣可以下去查阅相关资料，动态加载原理详细可以参考我上一篇帖子：Android加壳脱壳学习（1）——动态加载和类加载机制详解

前文我们知道了Android的动态加载机制和签名机制，Android插件化机制具有模块解耦性，可以动态升级按序加载，而且当下很多APP都使用了热部署、热修复、插件化等技术都采用了动态加载技术，这样可以实现APP的快速更新，但是也带来一定的安全隐患，使得很多恶意软件能熬过安全检测，来动态加载代码。而执行加载绕过执行漏洞一般与Android 的签名机制密不可分，所以上文我们也很详细的讲解了Android的签名机制。

很多APP通过动态加载一些dex或so文件，但是考虑到存在动态加载的安全性问题，往往会对加载的文件进行签名校验机制，因此我们可以将插件化漏洞分为两类：动态加载漏洞和签名校验绕过漏洞

Android中经常会涉及到解压缩问题，比如动态加载机制，可能下载了apk/zip文件，然后在本地做解压工作，还有就是一些资源在本地占用apk包的太大，就也打包成zip放到服务端，使用的时候再下发。Android在解压zip文件，使用的是ZipInputStream和ZipEntry类，代码比较简单，但是ZipEntry.getName的方法存在的漏洞就是返回的是文件名，并没有对特殊字符处理，linux中../可以命令文件但是这个可以进行穿越上层目录，就会带来一定的安全隐患

我们这里列举两个典型的漏洞：如下所示：

Android系统提供类加载器DexClassLoader，可以在运行时动态加载执行包含的JAR或APK文件内的DEX文件，这样可能导致所加载的Dex文件被恶意应用替换或代码注入，如果不对Dex文件进行签名校验，就可能导致加载的是恶意代码，这样就会进一步造成严重危害

案例准备：

我们先编写一个测试类文件,然后生成dex文件，这里我们在dex文件中只加入字符串信息，我们源apk并未加入签名校验机制

我们先将dex文件放到模拟器的sdcard/下

我们新建一个程序，然后编写主程序的代码，并授权sd读取权限

然后我们编写类加载器代码

效果显示：

这里说明加载成功了，如果我们这里写的是一段恶意代码，这样就会进行攻击，造成破坏

我们上文的动态加载漏洞，是因为源APK并未对加载的dex文件进行签名校验，从而导致容易导入恶意代码，当然从Android 4.4后加入了对JAR/DEX存放目录文件的user_id 和动态加载JAR/DEX的进程的user_id是否一致的判断，如果不一致将抛出异常导致加载失败，这样就很好的可以防范替换加载的dex文件，进行恶意注入

解决方案：

我们知道一般对APK的验证，主要使用的是签名校验或者MD5校验，使用校验的方式较多。而签名校验一般是处理APK中动态加载或防止二次重打包的问题。

我们可以将APK中的签名检验机制进一步进行分类：

这一部分完整性保护大家可以详细的参考看雪陌殇大佬的帖子Android应用完整性保护总结

案例：书旗小说.apk

我们发现书旗小说在进行重新签名后，再次安装会报错，首先我们AndroidKiller解析APP：

然后我们开始进行定位，这里我们使用常见的定位点：signature、killProcess、PageManager

我们这里搜索signature或killProcess，我们找到了签名三兄弟：

分析签名的逻辑，修改后回编译，再安装显示成功

因为so层和java层签名绕过原理相近，只是so层是分析汇编代码，java层分析Smali源码，这里我们参考一个博主的案例，我列举一下

首先我们根据NDK注册定位到so层的入口点，去查找JNI_Onload函数，然后开始去查找上面的三兄弟

这里我们就很好的定位到了代码段，后续就是分析逻辑，修改对应的校验点即可

最后就会发现签名成功的绕过

在线签名校验主要是抓取校验部分的数据包，然后去查找cookie中的public_key，或者签名Signature值，通过分析数据包后再定位到相应的代码段将值回传到相应的代码段即可

这里有一个案例大家可以参考Android APP漏洞之战（6）——HTTP/HTTPs通信漏洞详解 中酷狗直播的漏洞实现，这里就是通过在线修改了MD5值，然后使得程序在升级过程中绕过了升级校验，从而成功的注入了恶意病毒

因为Linux系统中../代表向上级目录跳转，攻击者可以通过构造相应的Zip文件，利用多个'../'从而改变zip包中某个文件的存放位置，费用该替换掉应用原有的文件，完成目录穿越。这样严重可能会导致任意代码执行漏洞，危害应用用户的设备安全和信息安全

Java 代码在解压 zip 文件时，会使用到 ZipEntry 类的 getName() 方法，如果 zip 文件中包含 ../ 的字符串，该方法返回值会原样返回。如果没有过滤掉 getName() 返回值中的 ../ 字符串，继续解压缩操作，就会在其他目录中创建解压的文件

样本：

我们打开海豚浏览器，并用Fiddler去监控海豚浏览器，Fiddler的配置大家可以参考我之前博客

这里我们可以通过抓包去发现主题下载的申请链接，然后我们将主题下载下来，然后解包查看结构，这里我们重命名为zip文件

我们可以发现下载下来的三个资源文件，这也说明海豚浏览器的主题本质是一个zip包

那么我们如何实现zip目录穿越了，我们是不是可以尝试去构建一个这样的zip包，去替换浏览器的下载包，并重命令去文件名，使得替换浏览器中的关键文件，这里我们就尝试去替换浏览器中的libdolphin.so文件。我们先查看该文件的位置：

此时我们知道了libdolphin.so文件的存放位置，目录为：/data/data/com.dolphin.browser.express.web/files，这样我们只需要将我们制作的libdolphin.so去替换原文件即可

我们编写一个libdolphin.so文件

然后我们将生成的so文件重新命名libdolphin.so文件，接下来我们再使用我们的Poc代码更改名称：

此时我们就成功的构造了我们的攻击文件attack.zip

然后我们只需要对海豚浏览器下载主题的包进行劫持替换即可

然后我们再次点击手机下载相应主题，发现主题是成功的下载，但是并没有替换成功

经过验证，我们发现首先正常命名的so文件是可以正常的和主题一起下载成功的

然后我们验证，Android中直接重命令文件../../libdolphin.so是可以直接回到上级目录的

所以综上是因为我测试的Android6.0 已经打了补丁，在进行解压的时候对../这种情况进行了过滤，这样就导致不能进行成功的穿越

当然这里我们主要是理解zip穿越的原理，这样就可以在很多地方利用这个原理存在的漏洞了

Google的修复意见：

我们上面已经介绍了签名相关的漏洞、和Zip相关的漏洞，下面我们拿2017年的典型漏洞Janus漏洞进行说明，这个漏洞结合了签名和Zip、dex的原理

相信Janus漏洞原理大家已经十分熟悉了，作为2017年比较重大的Android漏洞，已经有不少的人对其进行了研究和复现，本节只是初步记录下Janus漏洞的学习过程和复现思路（Janus只针对v1签名，v2签名就无效了）

Android ART虚拟机在加载并执行一个文件时，会首先判断这个文件的类型。如果这个文件是一个Dex文件，则按Dex的格式加载执行，如果是一个APK文件，则先抽取APK中的dex文件，然后再执行。而判断的依据是通过文件的头部魔术字（Magic Code）来判断。如果文件的头部魔术字是“dex”则判定该文件为Dex文件，如果文件头部的魔术字是“PK”则判定该文件为Apk文件

然而Android在安装一个APK时会对APK进行签名校验，但却直接默认该APK就是一个Zip文件（并不检查文件头的魔术字），而ZIP格式的文件一般都是从尾部先读取，因此只要ZIP文件尾部的数据结构没有被破坏，并且在读取过程中只要没有碰到非正常的数据，那么整个读取就不会有任何问题

因此，Android在加载执行代码时，只认文件头，而安装签名时只认文件尾

这样我们构造一个APK，从其头部看是一个Dex文件，从其尾部看，是一个APK文件，就可以实施攻击。因此Janus漏洞便是将原APK中的classes.dex抽取出来，改造或替换成攻击者想要执行的dex，并将这个dex和原APK文件拼起来，合成一个文件

当然我们在构造apk时，还需要修改dex文件的字段和zip文件的字段：

漏洞攻击步骤：

实验样本：

首先，我们通过Android Studio编写apk文件，并通过v1签名生成

我们在Bulid--->Generate Signed APK中选择通过v1签名来生成apk文件

我们便得到了app-release.apk文件，我们再通过AndroidKiller去修改源文件的代码，然后重新打包

然后我们提取出生成的apk文件中的classes.dex文件

我们是使用Janus.py python2版本 和java版本，这里我们使用Python版本

我们就得到拼接的out.apk，我们只需要将这个apk去覆盖原始的apk即可

问题：

在尝试了几台Android 6.0的机子后，并未成功复现漏洞，最后推断很大程度是Android 系统打了补丁，所以要复现成功可能只能在未打补丁的系统上才行，不过整体来说是一次很好的学习经历

本文对插件化和解压缩漏洞进行了详细的讲解和漏洞复现，在漏洞复现的过程中，我们发现一个漏洞复现的环境十分重要，因为很多时候曾经的一些典型漏洞都被打了补丁，很难在当下情况复现，当然我们应该更加注重漏洞的原理，从而进行学习，本文可能还存在一些不足之处就请各位大佬指教了。

本文的相关实验文件存放在知识星球中，本系列的实验文件后面也会逐一上传到知识星球。
github首页：github

dex文件结构：

zip文件结构：

Android APK签名机制：

插件化漏洞原理：

Janus漏洞原理：

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！