Question

按照逆向惯例，用一个案例来分析讲解，这次依然采用的是阿里的 CTF 比赛的第三题，如图 23-1 所示。

图 23-1　破解应用界面

题目是：要求输入一个网页的 URL，然后跳转到这个页面，但是必须要求弹出指定内容的 Toast 提示，这个内容是：祥龙！

了解到题目，就来简单分析一下。这里大致的逻辑应该是，输入的 URL 会传递给一个 WebView 控件，进行展示网页。如果按照题目的逻辑的话，应该是网页中的 JavaScript 会调用本地的一个 Java 方法，然后弹出相应的提示。那么下面就开始操作。

按照之前的破解步骤：

第一步：先用解压软件解压出它的 classes.dex 文件，然后使用 dex2jar+jd–gui 查看 Java 代码，如图 23-2 所示。

这里只有一个 Application 类，这个 apk 可能被加固了，为什么这么说呢？因为一个 apk 加固，外面肯定得套一个壳，这个壳必须是自定义的 Application 类，它需要做一些初始化操作，那么一般现在加固的 apk 壳的 Application 类都喜欢叫 StubApplication。这里可以看到，除了一个 Application 类，没有其他任何类了，包括入口 Activity 类都没有了，那么这时候会发现，无处下手了。

图 23-2　应用的 classes.dex 文件

第二步：会使用 Apktool 工具进行 apk 的反编译，得到 apk 的 AndroidManifest.xml 和资源内容，如下所示：

反编译之后，看到程序会有一个入口的 Activity，就是 MainActivity 类，记住一点，不管最后的 apk 如何加固，即使看不到代码中的四大组件的定义，也肯定会在 AndroidManifest.xml 中声明，因为如果不声明的话，运行是会报错的。这里还是没发现入口 Activity 类，而且知道它肯定是放在本地的一个地方，因为需要解密动态加载，所以不可能是放在网上的，肯定是本地。

这里的技巧如下：当发现 apk 中主要的类都没有了，肯定是 apk 被加固了，加固的源程序肯定是在本地，一般会有这么几个地方需要注意的：

·应用程序的 assets 目录，知道这个目录是不参与 apk 的资源编译过程的，所以很多加固的应用喜欢把加密之后的源 apk 放到这里。

·把源 apk 加密放到壳的 dex 文件的尾部，这个方式肯定不是本文的案例，但是也有这样的加固方式，遇到这种加固方式会导致用 dex2jar 工具解析 dex 失败，这时候就知道了，肯定对 dex 做了手脚。

·把源 apk 加密放到 so 文件中，这就比较难了，一般都是把源 apk 进行拆分，存到 so 文件中，分析难度会加大的。

一般都是这三个地方。记住一点，不管源 apk 被拆分，被加密了，被放到哪了，只要是在本地，都有办法得到它。

按照这上面的三个思路来分析一下，这个 apk 中加固的源 apk 放在哪了？通过刚刚的 dex 文件分析，发现第二种方式肯定不可能，那么会放在 assets 目录中吗？查看 assets 目录，如图 23-3 所示。

图 23-3　应用的 assets 目录

assets 目录中的确有两个 jar 文件，而且第一反应是使用 jd-gui 来查看 jar，可惜的是打开失败，所以猜想这个 jar 是经过处理了，应该是加密，这里很有可能是存放源 apk 的地方。但是上面也说了还有第三种方式，去看看 libs 目录中的 so 文件，如图 23-4 所示。

图 23-4　应用的 libs 目录

这里有三个 so 文件，而上面的 Application 中加载的只有一个 so 文件：libmobisec.so，那么其他的两个 so 文件很有可能是拆分 apk 文件的藏身之处。

通过上面的分析之后，大致知道了两个地方很有可能是源 apk 的藏身之处，一个是 assets 目录，一个是 libs 目录。那么分析完了之后发现现在面临两个问题：

·assets 目录中的 jar 文件被处理了，打不开，也不知道处理逻辑。

·libs 目录中的三个 so 文件，唯一加载了 libmobisec.so 文件了。

这里现在的唯一入口就是这个 libmobisec.so 文件，因为上层的代码没有，没法分析，下面来看一下 so 文件，如图 23-5 所示。

图 23-5　so 中的函数列表

这里没有特殊的方法，比如 Java_开头的方法，所以猜测这里应该是自己注册了 native 方法，混淆了 native 方法名称。那么到这里，会发现遇到的问题用现阶段的技术是没法解决了。