当前位置：首页 > news >正文

逆向解析Shopee的ds cookie生成：从MD5魔改到设备签名

news 2026/4/15 22:36:19

1. 从32位字符串开始的逆向之旅

第一次看到Shopee的ds cookie时，那个32位的字符串立刻让我联想到常见的MD5哈希值。作为一个经常和加密算法打交道的老手，这种直觉往往很准。但现实情况总是比想象复杂得多——这可不是标准的MD5实现。

在实际抓包分析中，你会发现ds参数出现在几乎所有关键请求里，特别是下单、支付这些敏感操作时。这就好比进小区要刷门禁卡，没有正确的ds值，服务器根本不会理你的请求。我花了整整三天时间，用Charles抓了上百个请求，才确认这个参数的重要性。

2. 定位魔改MD5的关键线索

2.1 标准MD5的特征值追踪

逆向工程就像侦探破案，需要抓住关键线索。标准MD5有四个特征常量：

A = 0x67452301 B = 0xefcdab89 C = 0x98badcfe D = 0x10325476

在Chrome开发者工具的Memory面板里，我通过搜索这些特征值，最终定位到一个可疑的wasm模块。有意思的是，Shopee并没有直接使用标准MD5，而是做了几处关键修改：

初始化向量被调整了最后一位
轮函数中的位移量有细微变化
填充规则增加了特殊字符处理

2.2 动态调试的突破点

在Fiddler设置断点时，发现每次生成ds前都会调用一个名为getWebUniqueCCD()的函数。这个函数返回的字符串看起来像是设备指纹，后面拼接的UUID也不是随机生成的，而是来自localStorage中的__WIR_SZ_UNIQ_DC字段。

这里有个坑我踩过——直接复制这个UUID会导致生成错误的ds值。原来Shopee在存储时会对UUID做base64编码，使用时需要先解码还原。

3. 参数拼接的隐藏逻辑

3.1 设备指纹的生成机制

shopee_webUnique_ccd这个参数特别有意思，它由三部分组成：

屏幕分辨率哈希
浏览器插件列表的CRC32
WebGL渲染器特征码

在Node.js环境下模拟时，必须确保这三项参数与真实浏览器环境一致。我写了个自动化测试脚本，可以批量生成不同设备配置下的ccd值：

function generateCCD() { const screenHash = md5(`${screen.width}x${screen.height}`); const pluginsCRC = crc32(navigator.plugins); const webglFingerprint = getWebGLInfo(); return `${screenHash}_${pluginsCRC}_${webglFingerprint}`; }

3.2 UUID的特殊处理

逆向分析发现，__WIR_SZ_UNIQ_DC这个UUID的生成算法也很特别：

前8位是浏览器启动时间戳
中间16位是硬件信息哈希
最后8位是随机盐值

在本地复现时，如果直接使用随机UUID，会导致生成的ds值被服务器拒绝。必须严格按照这个规则构造，这也是很多逆向者容易忽略的细节。

4. 完整生成流程的实现

4.1 算法还原步骤

经过多次调试，最终确定的ds生成流程如下：

获取设备指纹shopee_webUnique_ccd
从localStorage读取__WIR_SZ_UNIQ_DC
拼接字符串：${ccd}${uuid}
使用魔改MD5计算哈希
对结果做二次base64编码

Python实现的核心代码如下：

def generate_ds(): ccd = get_web_unique_ccd() # 模拟浏览器环境获取 uuid = get_wir_uuid() # 从localStorage读取 raw_str = f"{ccd}{uuid}" # 使用魔改版MD5 modified_md5 = ModifiedMD5() modified_md5.update(raw_str.encode()) digest = modified_md5.hexdigest() # 二次编码 return base64.b64encode(digest.encode()).decode()