某 Uni-App iOS App 逆向分析记录：从静态分析到 WebView 动态调试

最近分析了一个 iOS App，脱壳之后发现整个应用实际上是 uni-app 打包的。记录一下整个分析过程，以及其中涉及到的请求加解密流程。

判断 App 是否为 uni-app

首先对 App 进行脱壳，然后使用 Hopper / IDA 等工具进行静态分析。

分析过程中很快就能发现大量 DCUni*、plus.* 等相关字符串，同时资源目录也能够看到典型的 uni-app 结构，因此基本可以确认这是一个 uni-app 打包出来的应用。

确定技术栈之后，接下来主要目标就是分析网络请求的加解密流程。

经过分析，整个请求的加密逻辑如下。

请求加密流程

1. 生成随机 AES Key

首先生成一个随机字符串，作为本次请求的 AES Key。

randomskey()

后续请求体都会使用该方法重新生成 Key 进行 AES 加密。

2. 本地生成 RSA 密钥对

应用每次请求都会动态生成一对 RSA Key。

genKeyPair()

这里生成的是 512 位 RSA。

生成后：

• Public Key
• Private Key

都会保存在本地，用于本次请求。

3. AES 加密请求数据

真正的业务数据（即 data 参数）使用：

• AES
• ECB Mode

进行加密。

伪代码如下：

data = AES-ECB(key=randomskey, plaintext=requestBody)

4. RSA 加密 AES Key

随后，将下面两部分内容拼接：

AES_KEY + "@@@@" + timestamp

例如：

xxxx123456@@@@1750000000

然后使用服务端内置的 固定 RSA 公钥 进行加密。

得到请求参数：

a

5. Public Key 放入 Header

本地生成的 RSA Public Key 会去掉：

-----BEGIN PUBLIC KEY-----
-----END PUBLIC KEY-----

仅保留 Base64 内容。

随后放入 HTTP Header：

b: xxxxxxxxxxxxxxxxx

最终请求类似：

POST /api

Header
------
b: xxxxxxxxxxxxx

Body
----
{
    "a":"RSA(...)",
    "data":"AES(...)"
}

---

响应解密流程

响应流程则刚好相反。

1. RSA 解密参数 a

服务器返回：

{
    "a":"xxxxx",
    "data":"xxxxx"
}

首先使用本地刚刚生成的 RSA 私钥解密响应中的：

a

得到：

AES_KEY

2. AES 解密 data

随后使用得到的 AES Key：

AES-ECB

解密：

data

即可得到最终业务数据。

整体流程如下：

Response

      a ------------------------+
                                |
                                |
                     RSA Private Key
                                |
                                |
                         AES Key
                                |
                                |
      data ---------------------+
                                |
                           AES ECB
                                |
                                |
                      Plain Response

---

动态调试

由于目标是 uni-app，因此最方便的方法还是直接 Frida 调试 WebView。

frida -U webinspectord

使用 GitHub 项目：GlobalWebInspect

可以辅助开启 iOS WebView 的远程调试能力。之后即可通过 Safari DevTools 直接调试 WebView 内部的 JavaScript。

整个过程基本就是：

• Hook WebView
• 查看 JS
• 下断点
• 跟踪请求
• 分析接口

对于 uni-app 来说，这种方式比纯 Native Hook 的效率高很多。

总结

整个 App 的通信流程实际上并不复杂，可以概括为：

请求：

随机 AES Key
        │
        ▼
AES ECB 加密 data
        │
        ▼
RSA(固定公钥) 加密
AES_KEY + "@@@@" + timestamp
        │
        ▼
生成参数 a

本地生成 RSA Public Key
        │
        ▼
去掉 Header/Footer
        │
        ▼
放入 Header b

响应：

Response
        │
        ▼
RSA 私钥解密 a
        │
        ▼
得到 AES Key
        │
        ▼
AES ECB 解密 data
        │
        ▼
得到业务数据

整体来看，加密方案属于典型的 AES + RSA 混合加密。不过由于 RSA 密钥对是在客户端动态生成，而固定公钥内置于应用中，因此通过静态分析即可较容易还原完整通信流程，再配合 Frida 与 WebView 调试，对整个接口逻辑进行进一步分析。

测试环境

本文中的方法仅在以下环境验证通过：

• 越狱 iPhone
• macOS
• Frida
• Safari Web Inspector
• GlobalWebInspect

其他环境（如 Rootless、非越狱方案、Windows 等）请自行测试验证。