本次分析的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签名

本分析仅面向受控样本、授权测试目标或本地研究环境，目的在于理解应用实现、协议流程、加密逻辑与安全机制，不针对任何未授权真实业务系统实施攻击或滥用。

文中涉及的 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

• 标准HMacSM3

• timestamp 参与签名
• 所以相同业务数据下，只要时间戳变化，signature 就会变化

[培训]《冰与火的战歌：Windows内核攻防实战》！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。