测试目标apk是否能被反编译
目前绝大多数的Android软件都是由java编写，由于java的本质属于解释型语言（即java编译之后需要依赖JVM虚拟机执行，类似于C#编译之后会生成IL），故java代码编译之后，从理论上来讲是可以还原的。若源代码未混淆，源代码反编译之后就可以看到源代码，对Android应用程序来讲，是极大的隐患。
将apk反编译通常是安全测试的第一步，目前有很多工具可以实现apk的反编译。其中大多数依赖于apktool，所以首先以Apktool为例，介绍一下Apktool的配置和使用

windows平台下有许多apk反编译工具，例举几个常用的如下：
apktool
JEB
Android killer
ApkToolBox
dex2jar
....

apktool官方下载地址：39eK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6A6j5X3!0@1M7r3g2S2j5$3S2W2M7#2)9J5k6h3N6A6N6r3S2#2j5W2)9J5k6h3W2G2i4K6u0r3b7i4m8C8N6r3!0G2L8q4)9J5c8X3W2F1M7%4c8S2L8r3I4Q4x3V1j5`.
apktool提供了三个平台的下载以及安装教程

apktool使用方法：

或者在地址栏直接输入cmd或者powershell，然后回车运行，即可在当前目录打开powershell/cmd

如下所示：

成功执行后，会在当前目录生成一个和apk同名的文件夹，里面即包含了apk解包后的数据

一个简单的apk，解包后的文件夹结构如下：

其中

反编译是否成功，可以通过查看反编译之后的AndroidManifest.xml 来判断。
AndroidManifest.xml文件中存放了APK的大量配置信息，比如软件的名称、包名、图标、组件配置等。
如果反编译之后的AndroidManifest.xml 以明文显示则说明反编译成功，比如在本例子中该文件如下：

我们可以从Application标签的Activity标签的Android:name字段中知道，该apk在开发的时候，程序入口点在com.example.myapplication.MainActivity。
一般来说，AndroidManifest文件被反编译成功即说明apk未做反编译保护，我们也可以接着对res目录下的资源文件以及smali目录下的smali文件进行查看，如果明文显示则说明反编译成功。如下所示

由于Apktool依赖于命令行，有些参数和操作不太方便，所以后面有了许多带UI界面的反编译工具，但其实基本上都是依赖于Apktool。以ApktoolBox为例。ApktoolBox界面如图所示，是一个工具集：

通过查看ApktoolBox的路径可以得知，反编译所使用的工具还是Apktool.jar

可以看到，这里的Apktool.jar是17年的，比较老，我们直接替换为刚从官网下载的最新版。（其他工具的替换方式同理，直接下载新版本替换即可）

现在直接用ApktoolBox打开我们想要反编译的apk，然后选择<反编译apk>即可

这里的<是否需要忽略res资源文件>需要选<取消>，如果选择了<确定>则会在反编译的时候不对AndroidManifest以及资源文件进行反编译，没有AndroidManifest，我们将不能直观的了解到程序的入口Activity在哪里。
反编译完成之后，则会在指定目录下释放生成对应的文件夹，和Apktool d 包名 的方式的结果一样。

可以针对AndroidManifest做简单的处理，起到入门级的反编译作用。
首先介绍一下AndroidManifest的相关知识。Android studio在编译APK的时候会把AndroidManifest.xml处理为一个二进制文件。我们必须对APK反编译之后，才能看到原本的AndroidManifest.xml内容，否则只能看到一个全是乱码的文件，这种文件格式称为"AXML"
根据之前大佬们发现的AXML解析漏洞，我们可以直接尝试修改AXML文件，使得反编译工具无法正常识别该文件，从而起到防反编译的作用。
我们通过ApktoolBox打开目标apk，然后选择<反编译apk>，在反编译的时候会弹出选项<是否需要忽略res资源文件> 选择<确定>，忽略了资源文件之后，将只会反编译smali文件，不会反编译AndroidManifest以及res目录下的各种资源文件。

然后打开AndroidManifest，此时的AndroidManifest是一个AXML文件格式的二进制数据流。

根据AndroidManifest的解析漏洞，我们可以使用一个简单的方法起到反编译的作用，即更改编译之后的AndroidManifest文件头，然后直接重新打包，签名。这样可以在一定程度上防止程序被直接反编译。
所以我们把的AndroidManifest的文件头 03 00 08 00 更改为00 00 08 00
然后将后面的数据跟改一下再保存。

再重新打开该文件，可以看到010edit已经没有正常识别该文件为AndroidManifest

此时我们直接使用ApktoolBox打开我们修改过后的文件夹，选择<回编译apk>。

回编译成功之后将会在当前文件夹下生成指定的apk，我们将<demo1_Mod.apk> 安装到手机上是可以正常运行的。

但是此时的<demo1_Mod.apk>已经不能正常反编译了。
我们通过Apktool d 包名的方式对<demo1_Mod.apk>会得到如下结果，反编译之后的文件夹中只有一个空的AndroidManifest文件。

使用ApktoolBox在反编译资源文件的情况下也是同样的结果

这是因为我们更改了AndroidManifest文件，导致Apktool在反编译的时候不认识这个文件了，从而解析失败。
要想绕过这样的"保护"也很简单，使用Apktool的 -no -res 参数即可，这样Apktool在反编译的时候就不会尝试解析资源文件和AndroidManifest文件。

就可以正常反编译出smali文件

第二个解决方案也是一样，就是在是使用ApktoolBox反编译的时候，<是否需要忽略res资源文件>选择确定，这样也会跳过资源文件去反编译class文件。
但是如果想要看到原本的AndroidManifest文件，我们就需要尝试修复一下被更改的文件头。
我们可以找几个正常的apk，查看AndroidManifest的二进制文件，通过对比的方法将被更改的AndroidManifest文件改成正常的格式，然后重复上面的步骤，打包之后再反编译，应该就可以正常反编译出AndroidManifest文件了。

测试目标apk是否能对签名有验证。
Android的签名机制是一种比较邮件的身份标识，若开发人员没有对Android的签名，那么攻击者可以对apk反编译之后，插入恶意代码再二次打包运行。
关于如何在编写Android程序的时候自定义签名，网上有很多教程，这里就不赘述。

还是使用ApktoolBox进行测试，我们将有签名的APK反编译，然后直接使用ApktoolBox进行重签名，如果重前面之后还可以正常运行，则说明程序没有做签名验证。
首先我们可以查看一下APK的签名信息，随便找一个APK的安装包，我们可以直接解压该APK或者反编译。如果是直接解压，签名的文件存放在META-INF文件夹下

如果是反编译，签名的文件在original的META-INF文件夹下

在本例中签名文件为CERT.RSA

我们可以直接通过keytool对该签名文件进行解析
解析语法为：
keytool -printcert -file CERT.RSA

我们可以在这里看到签名的所有者 Henry
签名的序列号，有效日期，证书的指纹等信息。
我们使用apktoolbox直接对反编译出来的文件夹进行重打包
回编译完成之后，会自动重新签名并在当前目录下生成一个原始文件名_Mod.apk的文件

我们再查看Naver Mail_Mod.apk的签名信息
此时的签名文件已经变成了我们自定义的签名文件NETEASE.RSA

具体信息如下：

然后我们安装自己签名的Naver Mail_Mod.apk 依旧可以正常运行，说明该APK并没有进行签名验证。

我们可以先确定好我们所使用的签名文件，然后通过keytool计算出该文件的MD5值，然后在代码中写一个验证，获取当前apk前面的MD5和预定义的MD5进行对比，如果不相同，则说明签名文件不是我们所指定的，说明文件被重新签名，这个时候可以终止运行。
为了测试方便，新建一个Android studio项目，然后通过代码获取当前的包名和签名文件的MD5，获取到的信息如下。我们可以看到，如果使用Android studio 默认的签名MD5为:90f2ba57841b2e30d56581f8d5c47c33

于是我们将这个MD5硬编码到代码中进行比较。

然后我们将生成的apk拿去反编译，然后再重新打包和签名。

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课