某app实现反弹shell

app加壳了，脱壳后在 com.xxx.xxx.web.WebProxy 类的 initWeb() 方法中，发现对 WebView 进行了以下配置：
1、启用 JavaScript 支持：setJavaScriptEnabled(true)；
2、通过 addJavascriptInterface 将名为 BridgeInterface 的 Java 对象暴露给 JavaScript 上下文，映射名为 "Android"。

跟踪BridgeInterface，是com.xxx.xxx.web.WebProxy的内部类，方法xxxCallNative()
该方法没有任何白名单校验，直接接收用户输入的functionName为方法名，params为参数名，利用反射机制，调用WebProxy.this.object的方法

现在要跟踪WebProxy.this.object，查看WebProxy的构造函数，object为第三个参数

全局搜索new WebProxy查找new了WebProxy的类
其中有com.xxx.xxx.web.xxxxxxRefreshWebView，第三个参数是this，意味着可以调用他的任意public方法，如读写app文件等，所以当这个组件启动时，WebProxy调用xxxCallNative()方法时，被反射的WebProxy.this.object指向这个类，可以调用他里边的public方法，om.xxx.xxx.web.IndexRefreshWebView中存在SaveFile方法

然后继续跟踪webViewStorageManager，目录创建函数getDirFile(String dirName) 

除了写文件，还可以读文件删文件，由于只用到写文件，此处只展示写文件
在测试中，手动查看目录，发现__UNI__特有的 AppID 目录格式，app内还嵌套了小程序，这是使用了DCloud (UniApp) 框架 ，该框架DCloud 框架有一个特性叫 Native.js。它允许 JavaScript 代码通过 plus.android.importClass直接调用原生 Java 类。那么就能调用java.lang.Runtime。
前期写文件失败了，是因为没有对应的目录，后来app内点击小程序，app自动创建__UNI__xxx目录

通过SaveFile方法目录翻越写恶意文件覆盖掉原来的文件，然后SDK 重新加载这个小程序。依然去那个路径读取文件。读到了恶意代码，并把它当做正版代码加载到了特权环境中。因为是 SDK 加载的，所以代码自动拥有了 plus 对象（Native.js）的权限，从而可以调用Runtime.exec 执行系统命令。（正常 WebView 里的 JS 是无法执行系统命令的。但 UniApp 容器为了方便开发者，提供了一个强大的特性：Native.js。它允许 JS 代码通过 plus.android.importClass 直接在前端实例化 Java 类。）

最初执行了Runtime.exec("id")，进程确实启动了，但当我尝试用JS去读取 时，不仅拿不到回显，还报错了这是 JSBridge 的底层映射缺陷。DCloud 的反射机制在处理静态数据时没问题，但在处理 InputStream 这种持续的、阻塞式的内存 I/O 流时，桥接层往往会崩溃或找不到对应的方法映射。 解决方法是写读文件，利用上边写文件的方法将执行命令的结果写到临时目录的文件里，再读出来，再删掉

电脑上放两个文件exploit.html和server.py（代码就不看了哈）
app可以和任意用户包括和商家聊天，并且自动转换为网址，调用内部 WebView 打开该链接
创建两个账号，使用其中一个账号向另一个账号发送网址

在另一个账号上点击，电脑拿到shell

此shell是持续化的，每次打开app都会自动加载小程序文件，也就是咱们的弹shell的文件