最近根据别人的博客看了下如何对应用进行二次打包。之前没有真正实践过，今天就来自己动手实现一下。声明，本篇博客内容也是根据别人的博客进行学习，然后我自己总结写出的，目的就是好记性不如烂指头，还是敲一遍记得深，我的学习链接：http://www.jianshu.com/p/7e5ad780f8ab/comments/3607759#comment-3607759 在此也向作者表示感谢.
一、二次打包的概念
所谓的二次打包的概念，即对已经编译发布的apk文件，即已经使用签名文件进行正式签名的应用文件进行自己的修改之后，再次签名打包发布的过程称为二次打包。
二、二次打包能干什么
我们知道，最终我们发布到应用市场供用户下载的是一个.apk形式的文件，apk文件其实就是一种特殊的文件格式，其实就是资源文件，布局文件，主配置文件，dex文件以及签名验证文件等的文件集合。我们把.apk文件的后缀名修改为.zip包，然后进行解压缩进行查看，就能看到上面说的一些文件目录及文件的罗列，在此不在贴图。具体说到二次打包能干什么，其实就是我们可以对原来的apk文件中的源码进行修改，然后重新编译，进行二次打包，重新发布测试，从而达到我们修改别人的apk文件的目的。
三、二次打包需要的准备
- adb shell dumpsys activity activities 命令, 该命令会列出当前连接设备运行的Activity栈的情况，其中就可以看到应用包名，类的全路径名等详细信息。这有助于我们定为分析界面的相关信息。
- apktool, dex2jar, jd-gui三个反编译工具的准备。apktool工具下载是建议安装最新的，有的版本比较老在反编译的时候可能会报错。dex2jar工具是将dex文件转变成jar文件的工具;jd-gui工具是我们查看生成的jar文件的图形化工具；关于如何准备三个工具以及使用说明，比较简单，就不在此叙述了。
- apk反编译命令
apktool d demo.apk
- 生成keystore文件
keytool -genkey -alias androidauto.keystore -keyalg RSA -validity 20000 -keystore android.keystore
- apk文件进行签名
jarsigner -keystore demo.keystore -storepass password -signedjar demo.apk demo_signed.apk demo.keystore
如上命令就是使用demo.keystore签名文件对apk文件进行签名。另外，在执行如上签名命令时，有的jdk如果是1.7版本时，可能会签名失败，提示警告，信息如下：
No -tsa or -tsacert is provided and this jar is not timestamped. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (2019-08-16) or after any future revocation date.
此时，需要修改如上的签名命令，修改后如下:
jarsigner -digestalg SHA1 -sigalg MD5withRSA -keystore demo.keystore -storepass password -signedjar demo.apk demo_signed.apk demo.keystore
- 卸载安装命令
//先卸载 package为应用包名
adb uninstall package
//然后进行重新安装
adb install package
不出意外，安装就能成功。如果要验证的话，自己可以到应用市场下载官方的apk文件，然后试图安装替换，会提示失败，因为签名不一致。
准备工作就是这么多，接下来就是具体的二次打包的步骤
四、如何进行二次打包
首先说一下本次实践的终极目标，修改某个应用中一个界面的点击事件，使其不能产生页面跳转事件，如下图：
我们的目的就是让右上角的意见反馈按钮事件失效，无法完成跳转，以完成我们修改的目的。依旧，Talk is cheap, show me the code.下面将二次打包的主要步骤分步骤叙述如下,为了方便说明，以某个应用为例进行说明：
-
1.修改文件查看目录结构。修改.apk文件为.zip后缀名并进行解压, 查看得到的目录文件
应用的zip包解压后的目录结构 -
2.查找代码入口，寻找关键信息。移动设备安装官方apk应用，并将要修改的设置界面打开到当前显示界面，然后执行前面说过的栈分析命令进行查看，如下：
Activity栈信息截图
通过上面的栈信息，我们可以清晰的看到，包名，相关类名及其全路径，这对我们后面找代码至关重要。这里我们就看到我们要修改的类为BaseSettingActivity，全路径名也要记住。
-
3.因为此应用有三个dex文件，理论上来说我们并不能确定BaseSettingActivity在哪个dex文件中，所以只能一个一个来进行测试。首先将classes.dex拷贝出来使用dexjar工具进行反编译，得到classes-dex2jar.jar文件,如下图：
dex文件转jar文件 -
4.使用jd-gui图形化工具查看相关代码，查找线索。
在反编译的代码中找到程序的关键位置
混淆后的代码aQ变量就是反馈控件变量，同时还可以看到设置了监听事件。
-
5.在Smali文件中找到对应代码进行修改
图中红框内的代码为关键代码
将上图中的设置监听事件的关键代码删除，也就是我们本次修改的目的，使点击事件失效。
6.将修改后的smali代码重新编译成jar然后编译成dex文件，再次进行签名，最后安装试验。关于如何进行二次签名以及流程，请查看：http://www.jianshu.com/p/3322d873af53
五、二次打包的意义
整个反编译，分析，修改，重新打包签名这一整个过程下来，可以发现，其实中间涉及的流程和内容挺多的，同时还涉及到很多平时不容易涉及的原理知识点等内容。所以，掌握二次打包这整个过程，有助于我们更好的理解整个Android项目的内在结构，编译过程，发布流程甚至安全防护等方面的知识。
六、延伸及拓展
通过上面的反编译过程我们看到，通过反编译工具，我们可以拿到别人项目的混淆后的代码。虽然混淆代码是将变量及类名做了处理，但是其实还是不够安全，如果被别人盯上，分析出业务逻辑理论上只是时间问题。所以在安全防护这方面，敌追我赶，又出现了应用加固这种说法，增加别人破解的难度，不让别人反编译，提高门槛。当然，有矛自然有盾，对应的肯定就是脱壳技术，可以将加固的文件进行脱壳，然后反编译。打算下一目标学习学习脱壳，看能否研究个皮毛。
