DEX加密及V2签名处理

最近得到了通信管理局的一份检测报告，提出了我负责的app的一些漏洞，其中提到了DEX文件未加密,未启用V2签名，导致apk容易被反编译导致源码泄漏。很久没关注这方面的内容了，决定整理一下，听着《The Planets, Op. 32: Jupiter, the Bringer of Jollity》。

1.自己打了一个包，可以确定的是V2签名肯定启用的，V2是默认勾选的：

2.反编译我的apk,工具使用的dex2jar-2.0和jd-gui
（1）先把apk文件的后缀名改为.zip,然后解压得到一个文件夹，在文件夹中找到classes.dex文件
（2）复制classes.dex文件到dex2jar-2.0的目录下，打开命令行工具 ，切换到dex2jar-2.0的目录下，通过执行d2j-dex2jar.bat classes.dex 会生成一个classes-dex2jar.jar的文件

（3）通过jd-gui打开刚才生成的classes.dex2jar.jar

仔细查看反编译后的目录，发现确实有没有加密的东西，正常情况下，应该内容都被 a,b,c,d替换了才对，不过这个是androidStudio直接打的包，线上的东西，是借助了腾讯乐固加固过的，按道理不应该出现未加密，那么再走一遍腾讯乐固打包的流程。
3.腾讯云加固，地址https://console.cloud.tencent.com/ms
把刚才打的包上传，进行加固得到加固包

但下载加固包，得到的是一个没有签名的包，需要我们再手动进行一次签名，这就提到了标题中的apksigner.jar的使用。这个内容其实是我们sdk的build-tools里的内容，例如：

这仅是我的sdk路径的一个例子，你们的可能不一样。
回到前面的问题，给我们加过过的apk进行签名。
(1)ZipAlign
zip对齐，因为APK包的本质是一个zip压缩文档，经过边界对齐方式优化能使包内未压缩的数据有序的排列，从而减少应用程序运行时的内存消耗 ，通过空间换时间的方式提高执行效率（zipalign后的apk包体积增大了100KB左右）。
打开cmd，把目录切换到SDK的build-tools目录下（例如 D:\androidSDK\Sdk\build-tools\29.0.3），执行：

.\zipalign.exe -v -p 4 Reinforced.apk align-reinforced.apk

得到了一个align-reinforced.apk
（2）apksigner
v2签名方式时在Android7.0后才推出的，所以只有版本>25的SDK\build-tools\中才能找到apksigner.jar。
打开cmd，把目录切到SDK\build-tools\版本号\lib下（例如D:\androidSDK\Sdk\build-tools\29.0.3\lib），执行：

java -jar apksigner.jar sign --ks D:\keyStore\aaa.keystore --ks-key-alias tutu --ks-pass pass:123456--key-pass pass:123--out output.apk  align-reinforced.apk

这里解释一下

java -jar apksigner.jar sign
--ks  签名文件的路径
--ks-key-alias 别名alias
 --ks-pass pass:  keyStorePassword
--key-pass pass:  keyPassword
--out   输出
align-reinforced.apk      要被签名的apk文件

生成之后，检查一下是否签名成功与否

到这里还是没有完的，我们再进行一次反编译，看看这次的情况。

看不到任何有价值的东西，剩下的交给测试。