先了解一下什么是SuperWebview,然后进入主题。简介较多，可以往下滑直接进入解密主题

​ SuperWebview 是APICloud 官方推出的另一项重量级API生态产品，以SDK方式提供，致力于提升和改善移动设备Webview体验差的整套解决方案，APP通过嵌入SuperWebview替代系统Webview，即可在Html5中使用APICloud平台现有的所有端API，以及包括增量更新、版本管理、数据云、推送云、统计分析、积木式模块化开发、所有已经聚合的开方平台服务等在内的云服务能力，增强用户体验，解决移动设备Webview使用过程中出现的兼容能力弱、加载速度慢、功能缺陷等任何问题，帮助开发者解决使用Webview过程中的所有痛点。

​ SuperWebview继承APICloud终端引擎的包括跨平台能力，模块扩展机制，生命周期管理，窗口系统，事件模型，APP级别的用户体验等在内的所有优秀能力，并且全面打通Html5与Android和iOS之间的交互，同步提供APICloud平台最新的API技术能力和服务，APICloud团队将保持对SuperWebview的持续更新和优化，兼容Html5的新特性，持续推出优质服务。

总结来说有三点：

安卓原生Webview的扩展

结合native app 和 web app

APICloud实现安卓框架，自己开发web

SuperWebview的安全措施-- 全包加密

网页全包加密：对网页中全包的html,css,javascript代码进行加密，加密后的代码都是不可读的，并且不能通过常用的格式化工具恢复。代码在运行前都是加密的，在运行时进行动态解密。

一键加密、运行时解密 在开发过程中无需对代码做任何特殊处理，在云编译时选择代码加密即可。

零修改、零影响 加密后不改变代码的大小，不影响运行效率。

安全盒子 定义了一个安全盒子，在盒子内的代码按照加密和解密进行处理，其他代码不受影响。

以上内容摘自看雪论坛https://bbs.pediy.com/thread-218656.htm

在我们抓包分析时，很多参数都需要通过分析app代码获取，比如 token 、sign，还有很多接口，在抓包时是获取不到的，又不能将全部功能点一个一个点一遍就需要反编译apk ，直接获取。

这次的样本使用SuperWebview对安卓app进行加密，核心代码也有可能会存放在本地web文件中

当然，在直接上手之前 还是要分析一下整个apk的结构和流程

我在刚开始拿到apk的时候还不了解SuperWebview ，先当作普通的加固app分析的，见招拆招

在真机上安装apk 打开闪退，那可能是有代理或vpn检测、xposed检测、root检测。

这里推荐mumu模拟器，很多模拟器检测遇到mumu就没有用武之地，照样正常打开使用。

我们看一下apk的文件结构，这种将web资源保存在本地，很明显是webService架构

使用jadx反编译classes.dex，在com下的app关键代码只有资源文件的调用吗，关键代码不在dex里，那就是app做了加固了，我刚开始误区以为是厂商自己做的加固

)

用pkid 查壳后也没有任何发现

通过解压软件打开apk ，查看一下资源文件里的html和lib下的so文件

)

在assets文件下，存在js、css、html资源， 这种将网页的资源文件存储在本地的方式，可以确定这是个WebService的框架，网页转app

Web Service是一个平台独立的，低耦合的，自包含的、基于可编程的web的应用程序，可使用开放的XML（标准通用标记语言下的一个子集）标准来描述、发布、发现、协调和配置这些应用程序，用于开发分布式的交互操作的应用程序。

)

随便打开一个文件查看，发现都是加密状态，这个和之前遇到的lua 比较像， 资源文件都是加密的

)

之后查看了其他的一些文件，都是加密的

分析so文件，apk 只有一个so libsec.so

)

使用ida 打开后libsec.so文件， 查看一下流程和段结构

)

)

so文件段结构正常，流程简单清晰明了，可以发现没有做任何安全防护，那so层就很容易分析了。

快捷键shift+F12 搜索字符串

科普一下：我们知道 JNI 分为 动态调试和动态调试，静态注册，每次调用native方法，都要去寻找，方法都是以Java+包名+类名+方法名这种结构，根据函数名建立起java方法与JNI函数的对应关系，这种方式简单明了，但是必须遵守注册规则，效率低，基本很少在app中遇到，而动态注册，是通过Registernatives方法手动完成native方法和so方法的绑定，通过函数映射表查找函数，因此运行效率要比静态注册高。方法一般可以通过分析Jni_onload 得到

先搜索 java_ 没有返回，那就没有使用JNI静态注册

)

然后在查看 jni_onload

)

跟进去，发现字符串也没加密，arm汇编也很清晰

)

先修改一下参数类型，ida 自己识别不出来，需要我们手工改一下，修改为正确的类型，JNI_onload 参数是JavaVM*

)

重新识别一下，得到了GetEnv

)

在修改一下GetEnv 的第一个参数，为JNIEnv * ,改完后就可以得到清晰的逻辑了

)

识别一下

)

识别后的结果和跳转地址都有了，根据刚才的介绍，我们知道函数的映射关系都在RegisterNatives， 通过off_8804 跳转

)

找到注册函数后，可以看到 JNI 的所有方法都在这块，分为三部分： 参数类型，方法地址和函数名

)

方法很清晰

)

接下来 就很容易了，找到so加载的地方，查看调用native的函数，frida hook 即可

参考： APICloud解密本地资源到逆向APP算法到通用资源解密

先思考APP对资源的加载流程

可能为:

1)WEBVIEW - > 加载页面 -> 拦截/查找本地文件 有 -> 解密/写回数据

2)WEBVIEW - > 加载页面 -> 拦截/查找本地文件 无 -> 请求网络文件

这里有个共同的点都是需要 拦截,而 WebView 只有一个实现这个功能的接口: WebViewClient.shouldInterceptRequest

参考： APICloud解密本地资源到逆向APP算法到通用资源解密

搜索 关键词 shouldinterceptResquest

)

跟进第一个，分析函数逻辑

)

在跟b.d(url) 进去查看

)

调用另一个方法，继续跟进去

-20210420110621781.png)

然后根据函数名称可以猜出他是从url获取文件扩展名

返回shouldInterceptRequest 继续往下跟

)

对得到的后缀扩展名进行判断

)

这里的a 记录的是扩展名列表

)

继续往下跟

)

跟进去

)

获取文件路径，

)

到这里 发现已经开始做解密工作了

)

继续往下
)

基本到这里就分析出来了，下面就被SDK接管
)

从上一步 分析 下图位置，拿到结果 就可以dump出source了

)

这里用的构造函数，在frida hook 时 要用$init

)

编写hook 脚本

)

查看dump结果

)

通过adb pull 到本地
)

在和之前的对比
)

解密就结束了，下来就是愉快的抓包 找api 捡漏洞了 。

参考：

https://bbs.pediy.com/thread-218656.htm

https://docs.apicloud.com/Dev-Guide/SuperWebview-guide-for-android

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！