某社区智慧门禁 App 逆向分析

本文首发于「吾爱破解」论坛，原文地址：https://www.52pojie.cn/thread-1678767-1-1.html

事情的起因是小区楼下更换了一套「智慧门禁系统」，可以通过手机 App / 小程序控制开启单元门。然而每次打开 App 的操作还是过于繁琐，于是准备从安卓 App 入手，分析一下控制单元门的接口，从而简化操作流程。

1 抓包分析

第一步对 App 的网络请求进行抓包分析，采用夜神模拟器配合 Fiddler Classic 进行。为了解密 HTTPS 流量，首先需要将 Fiddler 的根证书安装到安卓的系统分区。

在 Fiddler 设置中导出根证书至桌面：

基于 OpenSSL，将证书转换为 PEM 格式：

openssl x509 -inform DER -in FiddlerRoot.cer -out cacert.pem

计算证书 Hash：

  openssl x509 -inform PEM -subject_hash_old -in cacert.pem

注意记录命令输出第一行的 Hash 值。

将 PEM 格式证书重命名为上一步中的 Hash 值，并以 .0 为后缀，即： 269953fb.0；然后将其上传至模拟器，并通过 adb 或模拟器内安装的 shell 应用进入对应目录，通过如下命令将证书文件移动至系统分区：

su
mount -o rw,remount /system
mv ./269953fb.0 /system/etc/security/cacerts/
chmod 644 /system/etc/security/cacerts/269953fb.0

重启模拟器后，在系统设置-安全-信任的凭据-系统分区，可见到 Fiddler 的根证书：

将模拟器的网络代理手动设置为 PC 的 IP 和 Fiddler 的端口，就可以进行抓包了。

2 网络接口抓包结果

打开 App 并完成登录、开门操作后，分析抓包结果，可看到主要业务共包含三个请求：登录、获取用户绑定的单元门列表、开门。

首先来看登录请求。URL 参数中，timestamp 显然是当前的 Unix 时间戳，sign 参数的生成算法未知；请求体中，login_name 是注册手机号，password 是经过处理的密码（其实简单猜想并验证一下就能发现是密码的 MD5 哈希），reg_id 的生成算法未知，其他参数都是软件版本之类的非关键信息。

登录后，服务端返回 openid 和 token 两个参数，应该就是后续请求鉴权的关键。

再来看获取单元门列表请求。URL 参数中，多出一个 openid，其值正是登录后服务端返回的参数之一，此外同样有 timestamp 和 sign 两个参数。

服务器返回值中包含该账户绑定的单元门信息，其中 ser_num （即单元门序列号）是控制开门接口的关键参数。

最后来看开门接口。URL 中的参数与上一步相同，请求体中 msg_id 也是 Unix 时间戳，ser_num 即上一步中获取的要打开的单元门的序列号。

到这里，App 的主要业务逻辑已经清晰，要想重现打开单元门的功能，只需要逆向分析 App，弄清楚以下几件事：

登录时 sign 参数的生成算法；
登录时 reg_id 参数的含义和生成算法；
后续请求中 sign 参数的生成算法（即登录时获取的 token 如何参与校验）。

3 安卓 App 脱壳

简单用 dex2jar 尝试一下就能发现，该 App 的 apk 进行了加壳，无法直接逆向出源码，首先使用 BlackDex 进行脱壳。

在模拟器中安装 BlackDex 32 位版本，运行后直接点击要脱壳的 App 名即可：

到 BlackDex 提示的路径即可找到脱壳后的 dex 文件（可能有多个），将其全部导出至 PC，准备后续逆向分析。

4 安卓 App 逆向分析

用 jadx 打开脱壳后的所有 dex 文件进行反编译，通过关键词搜索，定位到 LoginActivity 类的如下方法：

红框中，第一行显示了 reg_id 这个参数的来源，看起来与推送通知服务有关。从这个三元操作符的逻辑来看，猜想此参数即使为空也不影响功能（后来验证确实如此）。

在密码登录的代码块中，下面这句验证了 password 参数是密码的 MD5 哈希值的猜想。

reqLoginInfo.setPassword(Md5Utils.getMd5Result(replaceAll2));

红框中代码最后调用了 pwdLogin 这个方法进行登录，下面我们再进入 pwdLogin 方法：

可以看到，该方法调用了 HttpHelper 类的方法进行网络请求，然后将服务器返回的 openid 和 token 两个参数保存在数据库中。然而 sign 参数的生成过程并没有出现，因此其签名算法必然是在 HttpHelper 类中实现的。我们接着打开 HttpHelper 类的实现：

可以看到，该类内部采用 retrofit + okhttp 框架来处理 HTTP 请求，其中，红框内的代码为网络框架添加了一个拦截器。拦截器通常用来修改网络请求的内容，因此与签名、鉴权有关的算法大概率就在拦截器的代码中。我们接着打开 HTTPInterceptor 类的实现：

可以看到，拦截器首先在红框代码中获取了登录时保存的 openid 和 token 两个参数，然后判断请求的 URL，对于登录请求会执行绿框内的代码，我们关注的其他两个请求则都落到 else 分支的蓝框代码中。

绿框代码：

build = build2.newBuilder().url(build2.url().newBuilder()
  .addQueryParameter(a.e, String.valueOf(currentTimeMillis))
  .addQueryParameter("sign", 
    Md5Utils.getMd5Result((httpUrl + currentTimeMillis).trim())).build()).build();

即登录过程的签名为 URL（/api/... 之后的部分）和时间戳字符串拼接后的 MD5：

sign = MD5(URL + timestamp)

蓝框代码：

build = build2.newBuilder().url(build2.url().newBuilder()
  .addQueryParameter(a.e, String.valueOf(currentTimeMillis))
  .addQueryParameter("openid", openid)
  .addQueryParameter("sign", 
    Md5Utils.getMd5Result((httpUrl + currentTimeMillis + token).trim())).build()).build();

即登录后请求的签名为URL 、时间戳和 token 字符串拼接后的 MD5：

sign = MD5(URL + timestamp + token)

5 结束

至此，App 开门相关的所有请求及鉴权流程已经分析完成，总体而言还是比较简单，仅涉及到 MD5 哈希算法，因此可以通过很多种方式进行重现，达到快速开门的目的。由于常用机是 iPhone，这里我使用 iOS 的「快捷指令」重写上述逻辑，从而达到了在 iPhone 通知中心直接点击运行该指令，即可打开单元门的效果。