Question

下面就来分析一下如何解决上面的问题。其实解决这个问题现有的方法太多了。

第一种方法：修改 smali 源码。

把上面的那个 Java Script 对象名称改成自己想要的，比如 jiangwei，然后在自己编写的页面中直接调用 jiangwei.showToast 方法即可。不过这里需要修改 smali 源码，使用 smali 工具回编译成 dex 文件，再返回到 apk 中运行。方法是可行的，但是感觉太复杂，这里不采用。

第二种方法：利用 WebView 的漏洞。

直接使用如下 Java Script 代码即可。

这里根本不需要任何 JavaScript 对象的名称，只需要方法名就可以完成调用。可以看到这个漏洞还是很危险的。

第三种方法：调用加密方法。

看到了那个加密方法，自己写一个程序，来调用这个方法，既然上面已经得到正确的 JavaScript 对象名称，这里就采用这种方式。因为这个方式有一个新的技能，所以这里就讲解一下了。

如果用第三种方法的话，就需要再去分析那个加密方法逻辑了：

android.support.v4.widget.ListViewAutoScrollHelpern 在这个类中，再去查找这个 smali 源码：

这个类加载了 libtranslate.so 库，而且加密方法是 native 层的，那么用 IDA 查看 libtranslate.so 库，如图 23-17 所示。

图 23-17　native 函数

搜一下 Java 开头的函数，发现并没有和 decrypt_native 方法对应的 native 函数，说明这里做了 native 方法的注册混淆，直接看 JNI_OnLoad 函数，如下所示：

这里果然是自己注册了 native 函数，但是分析到这里，就不往下分析了，为什么呢？因为其实没必要搞清楚 native 层的函数功能，知道了 Java 层的 native 方法定义，那么可以自己定义一个 native 方法来调用 libtranslate.so 中的加密函数功能，如图 23-18 所示。

图 23-18　Demo 工程

新建一个 Demo 工程，仿造一个 ListViewAutoScrollHelpern 类，内部再定义一个 native 方法。

然后在 MainActivity 中加载 libtranslate.so：

然后调用那个 native 方法，打印结果如下：

这里的方法参数可以查看 smali 源码中的那个方法参数：

点击运行，发现有崩溃的，查看 log 信息，如下所示：

是由于 libtranslate.so 中有一个 PagerTitleStripIcsn 类找不到，这个类应该也有一个 native 方法，再构造这个类：

再次运行，还是报错，原因差不多，还需要再构造一个类 TaskStackBuilderJellybeann：

好了，再次点击运行：

成功了，从这个 log 信息可以看出来，解密之后的 Java Script 对象名称是：SmokeyBear，那么下面就简单了，再构造一个 URL 页面，直接调用 SmokeyBear.showToast 即可。

注意：这里如果知道了 Java 层的 native 方法的定义，那么就可以调用这个 native 方法来获取 native 层的函数功能，这还是很不安全的。如何防止自己的 so 被别人调用呢？在前面章节中已经讲解了安全防护的知识，可以在 so 中的 native 函数做一个应用的签名校验，只有属于自己的签名应用才能调用，否则直接退出。