这一章来说说Janus签名漏洞，网上关于这个漏洞的介绍很详细，其中的原理均为其它地方进行摘录，那么我主要做的就是POC测试，在文章末尾也会给出相应的样本，当然样本就是自己做的，用真实的上线项目来做这个也不合适，想找真实的项目来练练手的话推荐找2017年12月之前的项目（学习可以，但不要在网上发布不当的东西）
一、漏洞原理 基本概述Google在2017年12月份披露了一个名为“Janus”的安全漏洞（漏洞编号：CVE-2017-13156），该漏洞可以让攻击者绕过安卓的签名校验机制（signature scheme V1签名机制），进而可以对应用进行篡改（apk代码篡改）。安卓的部分安全机制是建立在签名和校验的基础上的，故这个漏洞会给搭载安卓系统的设备造成很大的危害
这个漏洞可以在篡改apk内容的情况下，保持apk的签名不发生变化，那么这就会使得用户在下载到安装这个过程中，设备中的安全软件发现不了它是一个被篡改的恶意盗版应用。
影响范围安卓5.0到8.0系统以及基于V1签名机制的app均Janus漏洞影响；基于V2签名的App则不受影响。从安卓7.0开始系统就已经支持了V2签名，那么7.0的安卓系统安装了含有V2签名的app不会受到此漏洞的影响
原理文章来源：https://zhuanlan.zhihu.com/p/31972541
二、POC攻击原理解读：
安卓应用程序代码逻辑主要是以DEX文件格式存放。DEX格式标准文档链接：链接
此DEX格式文件以文件名classes.dex,classes2.dex等与其他应用程序所需文件一起压缩存放于APK格式的文件里。APK格式文档链接：链接
APK格式文件就是大众熟知的安卓应用程序安装包，有它就可以安装一款应用软件到手机。问题也就出在安卓操作系统安装应用程序的流程上。
蚂蚁金服安全部门的巴斯光年实验室成员吴潍浠(@wish_wu)表示，Android操作系统在安装一个应用软件时，会将DEX文件转化成OAT文件，负责转化任务的程序叫dex2oat 。安卓操作系统会将APK文件直接给dex2oat程序。
而dex2oat有这样一套逻辑：
如果给它的是APK文件，它会把classes.dex文件从APK文件里取出再转化成OAT文件。如果给它的是DEX文件，它直接把DEX文件转化成OAT文件。
如果一个既是APK格式文件又是DEX格式文件的文件，给dex2oat程序会怎样呢？
以下是程序判断逻辑：
dex2oat通过IsZipMagic函数和IsDexMagic函数来决定这是什么格式的文件。
再来看看IsZipMagic函数和IsDexMagic函数的实现：
所以dex2oat程序是依据前文件的前4个字节决定这是什么格式文件。然而根据APK格式，前两个字节可以不是‘P’和‘K’，也就是说这里对APK格式的判断并不严谨。事实上一个既满足APK格式要求又满足DEX格式要求的文件是可以构造出来的。
借用漏洞个发现者发布的图片所示：
这里我们暂且把这个DEX格式文件与APK格式文件合体之后产生的文件叫做DEXAPK文件。
当DEXAPK文件在被安卓操作系统安装时，包管理器的代码会把它当作APK格式文件，而dex2oat会把它当作DEX格式文件。安卓应用程序的签名验证是包管理器做的，程序运行加载的OAT文件是由dex2oat根据输入的DEX格式文件生成的。
攻击者可以利用Janus漏洞，将一个恶意DEX与源APK进行拼接，构造一个DEXAPK文件，从而既可以通过安装程序时系统对APK文件的签名认证，又包含攻击者想要运行的程序逻辑。Android系统运行时会将当前的APK文件看作是之前应用的合法升级版并允许安装，最终通过
“升级”植入用户设备执行恶意DEX代码。
这里主要做"Janus"漏洞的POC测试，在实际的操作过程种遇到的一些问题
测试环境工具 （1）AndroidStudio自带模拟器Android 6.0
（2）dex和apk合并工具
（1）在原dex的基础之上进行修改
（2）生成一个新dex替换原dex
具体测试 1、在原dex的基础之上进行修改 1.1、使用Android Studio生成含有单dex文件的apk（只使用V1签名机制进行签名），并查看apk的签名信息
1.2、模拟真实环境（不知道apk源码的情况下），使用AndroidKiller对apk文件代码（dex）进行修改，将文本修改成"盗版软件"，并且进行重打包
1.3、将重打包生成的apk文件提取出classes.dex文件，将提取出的dex文件和原apk文件（样本）进行合并（使用工具进行合并）
1.4、将合并完成的apk文件安装至模拟器，可以发现apk的内容已经修改，成功复现在原dex的基础之上进行修改情况下的Janus漏洞
2.1、使用Android Studio生成一个含有Application、Activity、ContentProvider的apk文件
2.2、模拟真实环境（不知道apk源码的情况下），将apk进行反编译查看清单文件中的所有组件
2.3.创建一个新的Android项目，根据清单文件创建出所有已存在的组件(主Activity、ContentProvider)，若是有Application也要进行创建
2.4、把新Android项目生成的apk文件提取出classes.dex文件，将提取出的dex文件和原apk文件（样本）进行合并（使用工具进行合并）
2.5.将合并完成的apk文件安装至模拟器，可以发现apk的内容已经修改，成功复现Janus漏洞
1、在第二种情况（生成一个新dex替换原dex）中，若未实现Application，则会发生崩溃情况
2、在第二种情况（生成一个新dex替换原dex）中，若未实现ContentProvider，则会发生崩溃情况
3、合并apk之后无法进行安装的问题。出现这种问题可能是当前手机系统已经修复了此漏洞，换模拟器或者其它手机即可（系统版本在5.0-8.0）
4、单dex和多dex的情况不同，单dex的情况下可以在原apk的基础上直接进行修改，而不对功能的使用造成影响，而多dex的情况下处理比较麻烦，分dex表示dex的方法数超过了65535，若想保留原软件的功能，而使用一个dex来替换多dex文件，这是不太现实的，那么对于多dex并想保留原功能可以考虑使用动态加载和Classloader替换的方式来实现
三、修复建议（1）建议开发者使用V2签名机制对应用进行签名
四、样本稍后附上
asjhan for Android reverse