上个月公司一个项目突然要找第三方进行安全漏洞的检测,于是打包了一个apk文件,发到第三方结构进行了安全检测,这项目我入职前就已经快完成的阶段,我后面基本是维护和小更新.比较坑的是之前的哥们连混淆都没有,更不要说加固了,最后扫出了30多个漏洞,看到检测报告都懵逼了.
自己对混淆和加固之前也只是知道皮毛没有深究,这次修复漏洞踩了不少坑,都是边上网搜资料边踩坑,总算搞定了,写出来防止后人踩坑,这里主要讲加固签名的坑,混淆这里不说了(自己对混淆还不熟)
混淆签名导出
Q: 进行混淆,怎么混淆?
A: 我也是不太熟简单说一下自己的做法,先google一下常用的第三方框架的混淆代码找到自己需用的,剩下不常用的就上项目引用的框架对应的github项目地址找对应的混淆代码.
Q: 导出的时候怎么选v1和v2?区别在哪?
A: 我自己是把v1和v2都勾上,区别是v1是7.0之前就存在的签名方式,v1相比v2安全系数要低,建议打包的时候v1和v2都勾上,只勾其中一个有可能会出现兼容问题,具体自己上网查
加固
Q: 怎么加固?
A: 网上很多加固方式 (360,爱加密,梆梆..)都是傻瓜式的操作,可以找自己合适的.
Q:加固有哪些坑?
A: apk进行加固之后签名信息都会丢失,加固完成之后要对apk重新进行签名,没有签名的apk是不能在手机上跑的
A: 我开始用的是某数字公司的加固,加固完重新签名就发给第三方机构检测了,报告说我没有进行v2签名,一直很懵逼,明明勾了v2的签名为什么一直说我没进行v2签名,最后发现原来有些公司的提供的签名工具不支持v2签名,你用了他的签名工具他会说你签名成功,但实际上他只进行了v1的签名,真的很蛋疼,也不说明一下.
自己进行签名检查和加固后重新对apk进行签名
检查是否签名成功:
方法1:利用android sdk自带的工具
用命令行进入本地的Android sdk目录(我用的是mac) 地址如下 cd /Users/用户名/sdk/build-tools/27.0.3/lib
- 27.0.3是你的自己的sdk版本,不一定和我一样
检查是否签名成功 java -jar apksigner.jar verify -v my.apk (my.apk为本地安装包的路径)
如果出现:mac 下终端访问文件出现“Permission Denied”解决方案的话:
一个文件有3种权限，读、写、可执行，你这个文件没有可执行权限，需要加上可执行权限。
终端下先cd到该文件的目录下,执行命令 chmod a+x ./apksigner.jar(文件名)
重新执行步骤2检查是否有签名,会出现下面类似的结果:
- Verifies
- Verified using v1 scheme (JAR signing): true //已进行v1签名
- Verified using v2 scheme (APK Signature Scheme v2): false //没有进行v2签名
很容易理解,ture是已签名,false是未签名,都为true的话说明v1,v2都成功签名了.
方法2:
用命令行进入GetApkInfo.jar文件目录 cd /Users/xxxx/GetApkInfo.jar
执行 java -jar GetApkInfo.jar my.apk检查是否有v2签名
如果出现:mac 下终端访问文件出现“Permission Denied”解决方案的话:
一个文件有3种权限，读、写、可执行，你这个文件没有可执行权限，需要加上可执行权限。
先cd到该文件的目录下,执行命令 chmod a+x ./apksigner.jar(文件名)
再次执行 java -jar GetApkInfo.jar my.apk
执行结果: 成功 应用信息: 包名: com.xxx.xx.xx 版本名: 2.0.1 版本号: 2 签名文件MD5: e093xxxb53xxxxxf5bxxxe17xxx7d V1签名验证通过: true 使用V2签名: true V2签名验证通过: true
如果你要确保自己没用错签名文件(虽然一般不会这么智障)这种方法比较适合你,能看到已签名的md5值
keytool -v -list -keystore /Users/xxxx/MyAPP/test.jks(路径是你的进行签名的秘钥路径)
有效期开始日期: Mon May 08 09:35:21 CST 2017, 截止日期: Fri May 02 09:35:21 CST 2042 证书指纹: MD5: E0:93:xx:xx:xx:22:xx:xx:xx:5F:xx:xx:xx:xx:15:7D SHA1: xx:xx:xx:xx:xx:xx:C0:A4:xx:33:6Exx02:80:xx:DA:xx:xx:5F:xx:C3 SHA256: 39:xx:3A:xx:xx:BA:xx:A8:6C:xx:D0:C6:xx:BC:xx:76:25:xx:xx:A3:86:xx:xx:A0:xx:E8:xx:xx:4F:xx:xx:9C 签名算法名称: SHA256withRSA 版本: 3
然后把两个md5的值进行比对,如果一致说明你的签名没用错秘钥 – -||
4.手动进行签名操作:
- 进入本地的sdk目录 cd /Users/xxxx/sdk/build-tools/27.0.3/lib
- 执行签名操作:
java -jar apksigner.jar sign –ks /Users/xxxx/Desktop/key.jks –ks-key-alias test –ks-pass pass:123456 –key-pass pass:123456 –out /Users/xxxx/Desktop/签名后的安装包.apk /Users/xxxx/Desktop/需要进行签名的安装包.apk
上面的命令会执行同时执行v1,v2签名
注意仔细看上的命令行:进了黑色加粗的文字需要替换成实际的信息
- 第一个加粗的是秘钥的路径
- 第二个是秘钥的别名
- 第三个是秘钥的密码
- 第四个是秘钥的密码
- 第五个是进行了签名的安装包保存的路径
- 第六个是需要进行签名的安装包路径
说个小插曲,我们的项目找的是一个规模很大的公司进行检测,开始用了网上的免费的加固工具加固拿去检测,别人拿去测试之后全部都脱壳了,说这种免费的加固安全没有保障,要用他们的加固服务可以解决,要收费..呵呵,因为项目比较特殊只能答应了,打包签名了apk,发到他们那边进行了加固后他们把apk发回来让我重新签名,签名后apk用不了,闪退….老板说别人大公司应该不会出现这种小问题,是我的问题.恩,自己也怀疑是我的错. 当天折腾到凌晨才下班,经历了上面的一顿折腾后发现v1,v2都签名了,并且md5值也没问题. 这时就有底气的去质问那家公司,最后发现是他们的加固出问题.
一般来说进行了上面的方法重新签名并且检查md5值没错,应该不会出问题了这时候可以去质疑一下加固方的问题.
先写这些记录一下,后面有需要再更新,有什么问题可以在下面留言讨论.
