某果app 加密校验算法逆向分析

0x0 前言

在对某 iOS App 进行安全分析时，发现其 HTTP 请求头中包含多个加密校验字段：Authorization、sign 以及 phoneName。只有解析出这些字段的生成逻辑，才能实现协议的自动化调用。本文将详细记录通过 IDA 静志分析与 Frida 动态调试还原这些算法的过程。

0x1 流程分析

• Authorization : 经对比发现，该值直接由登录接口返回的 token 拼接 Bearer 前缀组成，无需额外计算。

• sign: 长度为 32 位的十六进制字符串，疑似 MD5。

• phoneName: 同样为 32 位十六进制字符串。

• phone: 加密后的手机号信息，涉及敏感数据保护。

0x2 sign 签名算法还原

为了找到 sign 的来源，我们将 App 二进制文件放入 IDA Pro 进行分析。通过搜索字符串或交叉引用，定位到了关键的加密簇函数。

1. 静态分析

在 IDA 中发现了如下关键代码片段，调用了 Swift 桥接的加密库：

// 伪代码片段
v55 = static Digest.md5(_:)();
v56 = Array<A>.toHexString()(v55);

从反编译代码来看，程序将特定的参数拼接后进行了标准的 MD5 摘要计算。

2. 动态 Hook 验证

使用 Frida 挂载该函数，打印入参以验证猜想： 通过 Hook 发现，sign 的计算逻辑为：MD5(nonceStr=xxx&time=xxx&uniqueNum=xxx&version=xxx&key=固定盐值)

其中 key 是硬编码在代码中的 Salt 字符串。还原后，验证结果与抓包中的 sign 完全一致。

0x3 phoneName 算法还原

phoneName 字段在抓包中表现为对设备名称（如 "iPhone 12"）的某种处理。

经过分析，其逻辑非常简单直接：

1. 获取设备型号字符串（例如 iPhone 12）。

2. 直接对该字符串进行标准 MD5 加密。

3. 输出即为 phoneName。

0x4 核心业务加密：phone (AES)

对于手机号等敏感字段，应用采用了更高强度的对称加密。在 IDA 中搜索 "AES" 或 "Cipher"，发现其使用了 CryptoSwift 库。

1. 定位 AES 初始化

关键代码如下：

v20 = AES.init(key:blockMode:padding:)(v12, &v35, 2LL);

根据 Swift 混淆后的函数签名分析：

• Mode : CBC 模式（通过参数 v35 对应的枚举值判断）。

• Key/IV : 进一步 Hook AES.init 及其加密方法。

2. 获取密钥与偏移量

通过 Frida 获取内存中的 Key 和 IV：

• Key : 0x... (16字节或32字节)

• IV : 0x... (16字节)

最终确认该 App 使用 AES-128-CBC 对手机号进行加密，填充模式为 pkcs7。