-
-
[原创]某政务APP登录链路逆向:datagram 参数与 signature 签名分析
-
-
[原创]某政务APP登录链路逆向:datagram 参数与 signature 签名分析
本次分析的APP信息(因保密原因不能完全透露):

本次分析重点为登录时请求参数分析

感觉是base64编码后的,通过hook base64调用看下情况:

是base64加密后的,跟踪调用链看下cn.gov.chinatax.gt4.bundle.tpass.depend.util.SM4Util.encryptData_ECB,发现函数下面有SM4标准加密

参数都对的上
hook一下这回两个加密函数,看下到底是哪个加密的

发现是参数String那个

将入参明文直接用SM4加密,发现前面全都对得上,只有最后21个字符串对不上,这里怀疑是填充方式有问题

把b64-->hex,发现是最后32位对不上,也就是说最后一轮有问题
在刚刚的代码里发现了轮函数线索:

尝试hook一下,和普通加密最后一轮对比一下

这是标准SM4加密后的最后一轮:

对比一下发现最后填充的有问题。
不是“纯标准 SM4 ECB PKCS5”,而是 先在明文末尾追加一个 0x00,再做剩余长度的 PKCS5/PKCS7 补位;因此最后一个分组从 ...0808 变成了 ...00070707...,最终导致看到的最后一段密文不同。

到这datagram参数已经还原到了第一步
接着我们分析一下sm4加密传入的参数,进一步分析一下直到原始数据

分析一下这个值怎么来的,参数一眼b64加密后的
追一下b64 hook

追一下这个调用链cn.gov.chinatax.gt4.bundle.tpass.depend.util.RequestUtil.getCompressedDatagram
发现也是个native函数

hook一下

账号密码明文传入,加密成这个数据
返回值H4sIAAAAAAAAAKtWKkgsLi7PL0pRslIyNDI2MTUzt1DSUUpMTs4vzSsBCRobmZobmZhZmhoq1QIA7XQPhy8AAAA=
是base64加密
前四个b64字符为:H4sI → 1F 8B 08 这是gzip压缩的头标志(感谢GPT)
尝试一下结果正确

梳理一下整个调用链:

也是和datagram一样,从b64调用开始追

追一下这个调用函数,发现是SM3HashMac,hook一下

签名每次都在变化,大概率和时间戳有关

这里观察到入参明文:

刚好和其他参数相对应
zipCode+encryptCode+datagram+timestamp

所以每次只有时间戳变化,每一次的结果都不一样
直接就还原出来了,标准的HMacSM3签名

推荐一下比较好用的 Frida 工具:Frida-Hookers
本分析仅面向受控样本、授权测试目标或本地研究环境,目的在于理解应用实现、协议流程、加密逻辑与安全机制,不针对任何未授权真实业务系统实施攻击或滥用。
文中涉及的 Hook、解包、流量分析、协议还原、加密验证等操作,仅用于安全研究与技术验证。所有结论仅作学习记录和研究参考,不作为未授权利用指南。
{
"access_token": "",
"datagram": "Vs0sGlHrcqzFO6umQ2CEUKLhCCUIzMN9n3UZeGY3OHN5iOaVNOg/r1s3dx9fNK1X0Ast0GzfsG4KEFn56kh9bNfE5jph0GMNYxq5G2FEh09a8arW8RkqMRhqg0knoRUW",
"encryptCode": "2",
"signature": "wv22glX8Thg6M0Nj8yDSGmPJK+nqnRpcbovdHk11Wbw=", //抓包每次都会变化
"signtype": "HMacSM3",
"timestamp": "20260509195242",
"zipCode": "1"
}
RequestUtil.getCompressedDatagram(String) 的返回值是 gzip 后再 base64 的字符串
SM4Util.encryptData_ECB(String, String) 是实际命中的加密入口
- 此处不是“纯标准 SM4 ECB PKCS5/PKCS7”
- 实际行为是:先在明文末尾追加一个
0x00,再按剩余长度做 PKCS5/PKCS7 样式补位
- 账号密码明文 JSON
RequestUtil.getCompressedDatagram(String)
- 返回
H4sI... 字符串
SM4Util.encryptData_ECB(String, String)
- 最终生成
datagram
- 原始 JSON
gzip 压缩
base64 编码
- 得到
H4sI... 字符串
- 明文末尾追加
0x00
- 再做剩余长度补位
SM4 ECB 加密
- 最终输出
datagram
signature 由 SM3Util.sm3HashMac(...) 生成
- 参与签名的明文与:
zipCode + encryptCode + datagram + timestamp 对应
- 因为
timestamp 每次变化,所以 signature 每次都会变化
zipCode + encryptCode + datagram + timestamp
timestamp 参与签名
- 所以相同业务数据下,只要时间戳变化,
signature 就会变化
RequestUtil.getCompressedDatagram(String) 的返回值是 gzip 后再 base64 的字符串SM4Util.encryptData_ECB(String, String) 是实际命中的加密入口此处不是“纯标准 SM4 ECB PKCS5/PKCS7”实际行为是:先在明文末尾追加一个 0x00,再按剩余长度做 PKCS5/PKCS7 样式补位
[招生]科锐逆向工程师培训(2026年7月3日实地,远程教学同时开班, 第56期)!
最后于 2026-5-12 18:43
被Mengz3编辑
,原因: