你可能还不知道的apk签名绕过方法【修改APK却保留原签名】
本帖最后由 imsnail 于 2018-6-9 21:23 编辑近期更新Android应用可要注意了，不要随意点个链接就升级，你的正宗应用可能升级成山寨应用哦。 Google在12月发布的安全公告中提到的“Janus”漏洞，可使攻击者在不改变原应用签名的情况上，注入恶意代码。
Android应用的包名和签名是唯一确定一个应用的基础。
伪造包名可以说没有任何成本，但是签名确是唯一的；正版应用如果被修改，其签名也随之被破坏，需要重新签名，因此山寨应用不能再安装在有正版应用的Android手机上；各种应用商店和管家类应用，往往通过包名和签名来判断一个应用是否山寨。
此次Google公布的“Janus”漏洞，可使攻击者将Dex附加到原有的apk之上，绕过签名认证；在执行时优先执行附加的dex文件。
该漏洞直接影响Android 5.0--8.0上所有基于 signature scheme V1签名的apk。
先通过一个简单的Demo来验证下如何利用该漏洞
1.准备
(1)Android5.0到8.0系统版本的手机
最好是android 7.0以下，这样就不用考虑当前的apk签名方案是v1，还是v2混合的。
(2)apk文件
最好是自己的应用，这样测试避免通过反编译重打包的方式来修改。下面也将以自己应用方式演示
2.具体使用过程
(1)生成apk文件并安装
自己的应用，在Android7.0以下手机测试时，直接生成apk即可，不需额外操作。7.0以上手机时，通过Android studio生成，关闭v2签名。我的是升级到了3.0.1后可选的,如下图所示：
https://img-blog.csdn.net/20171218103015054?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvdzc4NDk1MTYyMzA=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast
(注意，当gradle plugin在2.2及以上时，自动采用了v1+v2的混合方式。可以通过配置v2SigningEnabled关闭
signingConfigs { debug { v2SigningEnabled false } }或者升级到新版本，支持在Build->Generate Signed APK中选择配置。 在apk文件的META-INF文件夹.sf文件中开头有X-Android-APK-Signed: 2，表明是使用了v1+v2签名，没有则是v1签名。连.sf文件都没有那是仅采用了v2签名)
将生成的apk文件安装到手机上。
(2)修改apk文件
自己的应用，直接修改代码，从新生成的apk中解压得到dex文件
通过参考4的链接下载Python脚本，将dex文件附加到apk文件之上得到新apk文件out.apk文件
janus.py class.dex demo.apk out.apk
将out.apk文件直接安装到手机上即可，不需要重新签名，发现可以升级覆盖安装。
解压此apk，可以看到解压出的文件中没有刚才添加的dex文件(部分压缩软件可能提示无法解压)
原理简单分析：
Android 7.0之前的apk签名为v1方案（Jar Signature），apk也是一个zip文件，其中包含的目录、文件及应用开发者的签名信息都存储在META-INF文件夹中。
（1）manifest.mf清单文件，列出对jar中除meta-inf文件夹外所有文件的sha1后进行base64编码
例如
Name: res/layout/xxx.xml
SHA1-Digest: NCdFnJxgi644KYg8m8OvtnEdHWw=
cat -e 显示文件的回车换行符（linxu \n，windows \r\n , mac \r），查看.mf文件中的内容
可以看到每行的后面是（\r\n），最后相当于有两个(\r\n)
openssl dgst -sha1 -binary res/layout/xxx.xml | openssl base64可以计算一个文件的hash值，写入.mf文件中
（2）.sf
开头的摘要值是对.mf文件的摘要，后续每行是对.mf文件对一个文件的描述的三行做一个摘要产生，方法同上
（3）.rsa
包含应用开发者的证书信息，以及对.sf文件摘要的签名。具体可以看看参考文章
apk的验证过程是依赖于zip文件格式，同时需要解压文件后依次校验，从.rsa的证书，到.sf文件的验证，再依次校验各个文件。
从上面几个文件间接可以理解apk的签名验证机制，它是如何保护文件不被篡改的。meta-inf中的文件添加是不会破坏签名信息。
该漏洞可以绕过签名校验的两个条件：
（1）应用apk（v1签名）安装时的签名校验，是解压apk，执行文件和目录的校验；未在zip目录中的数据不做处理
（2）应用执行时，虚拟机可直接执行Dex文件和apk文件
看Python脚本，非常简单，就是将dex文件添加到apk文件的头部，然后依次修改zip目录中各个信息块的偏移地址，加上了dex文件的大小。再修改dex文件的大小和校验值。
修复建议:
注意使用v1和v2混合签名。单纯的v2的签名在Android7.0以下是不支持的。
(如果android7.0以下的系统没有升级安全补丁，那么即使采用v1+v2的混合签名也是没有意义的。)
apk签名v2方案是Android 7.0时推出的，和v1方案的区别主要是不再需要解压apk，而是直接校验apk文件，除了签名信息块外，所有对apk文件的修改都会被检测出来，此时该漏洞添加dex文件的方式不再有效。
详细的v2签名方案可以查看参考链接3
转载请注明出处：http://blog.csdn.net/w7849516230，欢迎关注微信公众号“编程阳光”
https://img-blog.csdn.net/20160519222822234
参考文章
1.CVE-2017-13156 Janus安卓签名漏洞预警分析
https://mp.weixin.qq.com/s/VuHasIKQdWbQ8rBOQX6vqw
2.ZIP文件格式分析
http://blog.csdn.net/a200710716/article/details/51644421
3.APK 签名方案 v2
https://source.android.google.cn/security/apksigning/v2?hl=zh-cn
4.漏洞POC的python脚本下载
https://github.com/V-E-O/PoC/blob/master/CVE-2017-13156/janus.py
fairytale110 发表于 2018-6-11 11:01
现在studio打包基本都是v1 v2混合签名方式了，很少有人只用v1.
如果你要禁用V1或者V2签名，可以在build.gradle 的signingConfig部分设置：
v1SigningEnabled false
v2SigningEnabled false
在Android Gradle Plugin 2.2上，默认两种签名都开启，优先使用V2。 fairytale110 发表于 2018-6-11 11:01
现在studio打包基本都是v1 v2混合签名方式了，很少有人只用v1.
如果你要禁用V1或者V2签名，可以在build.gradle 的signingConfig部分设置：
v1SigningEnabled false
v2SigningEnabled false
在Android Gradle Plugin 2.2上，默认两种签名都开启，优先使用V2。
学习了，谢谢 谢谢你的资料 学习了 进来看看。 我说我的市场版QQ怎么在APKPURE里升级成国内毒瘤版了{:301_998:} 膜拜大佬之中 谢谢你的资料，学习了 牛逼。所以就是要使用v2方式签名 我感觉我的贴吧就是这样才被封号了 进来学习一下