Question

破解的步骤比较多，下面来整理一下破解步骤。

1.破解的常规套路

按照破解惯例，首先解压出 classses.dex 文件，使用 dex2jar 工具查看 Java 代码，发现只有一个 Application 类，所以猜测 apk 被加壳（加固）了，然后用 apktool 来反编译 apk，得到它的资源文件和 AndroidManifest.xml 内容，找到了包名和入口的 Activity 类。

2.加固 apk 的源程序一般存放的位置

知道加固 apk 后，那么就分析这个加固的 apk 放在哪里，肯定是存放在本地的一个地方，一般是三个地方：

·应用的 asset 目录中。

·应用的 libs 中的 so 文件中。

·应用的 dex 文件的末尾。

分析了之后，发现 asset 目录中的确有两个 jar 文件，但是打不开，猜测是经过处理了，所以得分析处理逻辑，但是这时候也没有代码，怎么分析呢？这时候就需要借助于 dump 内存 dex 技术了：不管最后的源 apk 放在哪里，最后都是需要经历解密动态加载到内存中的，所以分析底层加载 dex 源码，知道有一个函数 dvmDexFileOpenPartial，这个函数有两个重要参数，一个是 dex 的地址，一个是 dex 的大小，而且知道这个函数是在 libdvm.so 中的。所以可以使用 IDA 进行动态调试获取信息。

3.双开 IDA 开始获取内存中的 dex 内容

双开 IDA，用之前的动态破解 so 方式，来给 dvmDexFileOpenPartial 函数下断点，获取两个参数的值，然后使用一段脚本，将内存中的 dex 数据保存到本地磁盘中。

4.分析获取到的 dex 内容

得到了内存中的 dex 之后，使用 dex2jar 工具去查看源码，但是发现无法保存，以为是 dump 出来的 dex 格式有问题，但是最后使用 baksmali 工具进行处理，得到 smali 源码是可以的，然后就开始分析 smali 源码。

5.分析源码了解破解思路

通过分析源码得知，在 WebViewActivity 页面中会加载一个页面，然后那个页面中的 JavaScript 会调用本地的 Java 对象中的一个方法来展示 toast 信息。但是这里遇到了个问题：JavaScript 的 Java 对象名称被混淆加密了，需要去分析那个加密函数，但是这个加密函数是 native 的，然后就是用 IDA 去静态分析了这个 native 函数，但是没有分析完成，因为不需要，其实很简单，只需要结果，不需要过程。现在解密的内容知道了，native 方法的定义也知道了，那么就去写一个简单的 demo 去调用这个 so 的 native 方法即可，结果成功了，得到了正确的 JavaScript 对象名称。

6.了解 WebView 的安全性

WebView 的早期版本的一个漏洞信息，在 Android 4.2 之前的版本 WebView 有一个漏洞，就是可以执行 Java 对象中所有的 public 方法，那么在 JavaScript 中就可以这么处理了，先获取 getClass 方法获取这个对象，然后调用这个对象中的一些特定方法即可，因为 Java 中所有的对象都有一个 getClass 方法，而这个方法是 public 的，同时能够返回当前对象。所以在 Android 4.2 之后有了一个注解 @JavascriptInterface，只有这个注解标识的方法才能在 JavaScript 中调用。

7.获取输入的新技能

验证结果的过程中发现了一个技巧，就是在输入很长的文本的时候比较烦琐，可以借助 adb shell input text 命令来实现。

提示：

·通过 dump 出内存中的 dex 数据，可以佛挡杀佛了，不管 apk 如何加固，最终都是需要加载到内存中的。

·了解 WebView 的安全性相关知识，比如在 WebView 中 JavaScript 对象名称做一次混淆还是有必要的，防止被恶意网站调用我们的本地隐私方法。

·可以尝试调用 so 中的 native 方法，在知道了这个方法的定义之后。

·用 adb shell input text 命令来辅助输入。