〇、摘要

🧑‍🔬 笔者第一次整理拼多多 libpdd_secure.so 资料时，建了一张很长的字段表：系统属性、Build、网络、SIM、时间、随机量，一项项排得很整齐。表格越完整，文章看起来越像已经还原了”设备指纹”。

问题也恰好出在这里。看雪帖子描述的是特定历史样本中的环境记录、缓存和封装；拼多多隐私政策描述的是产品在安全场景下可能处理的数据类别。前者缺少服务端，后者不是抓包。把两份材料合起来仍然得不到稳定设备 ID，更得不到当前画像模型和交易阈值。

最后只保留那些经得住版本变化的观察：历史 Native 代码曾组织环境记录，记录经过结构化封装和保护后形成输出；部分内容有缓存，动态量会随调用变化。字段顺序、前缀、偏移、密钥和生成步骤则全部省略。研究目的不是做一个 anti-token 生成器，而是看清客户端包裹到达网络边界后，还缺哪些证明。

Research Evidence

Methodology

ItemDetail
文章类型Type B：官方政策与历史逆向材料复核
资料截止2026-07-06；实质来源均早于 2026-07-23 发布日期
证据标记A：官方公开；B：通用防守架构判断；C：第三方历史样本观察
一手实验无；未下载附件、运行 APK/SO、生成 Token 或请求线上接口
公开边界不提供密钥、IV、前缀、字段顺序、偏移、函数地址和请求模板

Sources & Evidence Grading

来源等级使用方式
拼多多隐私政策，2025-07-08 生效A安全用途、数据类别、IMEI 历史版本边界
libpdd_secure.so 指纹算法分析（下篇），2025-12-02C7.80 历史样本、作者对 7.85 的说明、记录与封装观察
anti-token 纯算法分析，2026-07-06CNative 记录容器、缓存和动态记录的外部观察
Android 10 隐私变更与 Play Integrity 概览A标识符限制、请求绑定和分级处置的通用原则

Scope Limitations

  • 没有可独立核验的 APK 渠道、完整版本、APK/SO SHA-256、ABI、设备构建号和抓取时间。
  • 7.80 与 7.85 的接近程度来自原帖作者陈述，笔者没有做二进制差分。
  • 2026 年帖子未在公开正文中给出可与 7.80/7.85 对齐的 App 版本，笔者不替它补版本号。
  • 网络边界后的画像、图谱和处置流程均为 B 级职责模型，不代表拼多多内部实现。

负责任披露：这次材料复核用于安全评审与隐私核查，不建议把历史材料用于模拟客户端、批量请求、营销作弊或规避平台处置。

一、路线总览：沿证据向外走

逆向文章习惯沿函数向下追，这里反过来沿证据向外追：谁读取、何时刷新、怎样封装、谁验证，最后由谁承担业务判断。

🤖 图中左半边是公开材料能够支持的历史客户端观察：环境读取、版本化记录、包保护和 anti-token 输出。跨过 NETWORK BOUNDARY 以后，入口校验、概率画像、业务关系和分级处置都改用虚线或 B 级标记。那不是装饰，而是提醒读者：客户端二进制里没有后端历史。

这条路线也解释了为什么不再维护“字段大全”。字段只有带着样本 Hash、版本、权限、触发事件和缓存状态才有意义；离开这些条件，一张长表主要证明作者很会排版。

二、先从官方政策校准问题

PDD Holdings 披露的 2025 年全年收入为 4318.457 亿元人民币，其中包括在线营销和交易服务。官方业绩公告 这是集团口径，不是拼多多 App 用户数或单产品收入。这里仅用它说明电商风控的双重成本：放过批量权益滥用和账号接管会产生损失，误伤共享设备、换机和弱网用户同样昂贵。

拼多多隐私政策在账户及交易安全场景中列出账户、交易、设备和日志信息。设备类别涉及应用与版本、Android ID、OAID/IDFA、HarmonyOS OAID、网络环境和部分传感器信息；附录还明确写着“具体以实际收集情况为准”。

🧑‍🔬 最值得注意的不是字段多，而是政策里的三个限制：

  • “可能会”意味着采集与场景有关；
  • “包括”给出类别范围，并不规定 Wire Format；
  • “以实际收集为准”承认系统、权限、版本和功能会改变可得性。

政策还把 IMEI 的使用限定在 6.63.0 之前版本。这是一个难得的公开版本锚点：采集面会随着平台规则和客户端版本变化。任何声称“最新版字段固定如下”的文章，都应该先解释它如何跨过这条版本线。

2.1 安全目的不是无限采集许可

《常见类型移动互联网应用程序必要个人信息范围规定》把网上购物基本功能的必要信息列为注册手机号、收货信息和支付信息。风控信号可以有正当安全目的，却不会因此自动成为所有浏览与购物动作的必要信息。

🧑‍🔬 工程上仍要回答触发场景、精度、保留期和访问范围。字段增加会稳定增加合规与泄露成本，却未必稳定提高画像质量；许多低区分度字段只会让相同型号设备更像。

三、历史样本里究竟看到了什么

两篇帖子真正互相呼应的地方，不是某个密钥，而是都把“环境观察”与“输出外观”分开了。记录先产生，之后才被组织、缓存和保护。

3.1 7.80/7.85：只保留类别级观察

7.80 样本分析通过模拟执行与 Native 侧观察，报告了系统属性、Build、网络和 SIM 状态、时间、随机量等记录。原帖作者同时称当时 7.85 的总体算法结构与 7.80 接近。

🧑‍🔬 这里有两个容易被省略的主语：原帖作者和历史样本。笔者没有拿到两个 SO 做差分，所以“接近”不能升级成独立确认；帖子中出现过某类记录，也不能说明今天所有渠道、所有事件仍以同样顺序采集。

3.2 封装揭示的是格式，不是信任

7.80 分析观察到由小记录组成的结构，以及 Gzip、AES、Base64 这类结构级处理。安全地说，它说明内容不是把字符串裸拼后直接发送，包格式有自己的记录与版本语义。

🧑‍🔬 再往前一步就需要谨慎。压缩处理体积，编码处理传输表示，加密提高直接阅读成本；这些名称本身不提供新鲜度、动作绑定和服务端授权。只要固定材料随客户端分发，就应假设它最终能被观察和版本差分。真正限制重放与跨事件复用的机制，必须在包格式之外另有证据。

3.3 缓存让“代码存在”与“本次发生”分开

2026 年 anti-token 帖讨论了记录缓存，以及不刷新时只补动态记录的行为。由于笔者没有复现，只把它记为 C 级观察。它提示了一条非常实用的阅读规则：

1
2
3
4
5

二进制里存在读取路径
      不代表
本次调用执行了这条路径
      更不代表
本次请求上传了所有可能字段

Build 类信息变化慢，网络和时间变化快，传感器可能只在特定场景触发。某项读取失败还可能表现为未触发、权限拒绝、不支持、读取错误或沿用缓存。把这些状态都写成空字符串，客户端看起来简单了，服务端却失去了判断证据质量的能力。

四、为什么 anti-token 很难成为稳定设备号

🧑‍🔬 如果输出同时包含相对稳定的环境属性与时间、随机量、会话上下文，它便可能帮助比较环境连续性，同时又在相邻调用间变化。这种对象更像一次事件附近的环境证据包，而不是一个终身不变的编号。

观察到的性质对连续性判断的帮助无法单独证明
系统、Build、网络等环境记录比较当前环境与历史候选唯一物理设备或自然人身份
时间、随机量、动态记录提供事件上下文和变化性Token 可长期复用或稳定落库
记录容器与加密封装约束格式，提高直接分析成本官方 App 未被篡改、来源一定可信
缓存与刷新逻辑控制性能和字段时效每次调用采集面相同

即使服务端最终有一个稳定画像 ID，它也更可能是内部句柄：背后带着候选、置信度、冲突、最近观察时间和拆分/合并历史。把客户端某个字段直接抄成画像主键，会同时放大碰撞与漂移。

4.1 版本不是一条数字

分析这类材料时，至少要同时记录 App build、Native Hash、渠道/签名、ABI/Android/OEM 和服务端协议代际。同一个 App 版本可能因渠道和 ABI 带来不同 SO；客户端不升级，服务端解析与模型权重也照样能变化。

🧑‍🔬 五条轴合在一起才是一份可复核的观察身份。只写“7.80”或“7.85”，等于把另外四个坐标留空；随后出现的字段对不上、偏移失效或服务端语义变化，也就无法区分是样本差异还是系统演进。

字段顺序、偏移、前缀和函数地址适合作为带 Hash 的样本注释，不适合作为跨版本知识。它们最容易复制，也最先过期。

五、网络边界之后还缺什么

客户端分析越完整，越应该承认画像和交易判断不在 SO 里。这不是研究失败，而是系统边界本来如此。

🧑‍🔬 服务端收到证据包后，至少还要解决四类问题：

  1. 接入：识别协议代际、版本、渠道和失败语义，检查材料是否绑定本次动作；
  2. 画像：从历史候选中处理碰撞、漂移、拆分和合并，并输出置信度；
  3. 关系：把设备放回账号、活动权益、订单、地址、支付、商家和时间关系；
  4. 处置：按动作价值选择放行、限频、挑战、延迟、复核或拒绝。

这些是通用职责，不是拼多多内部架构披露。它们之所以必须存在，是因为同一台家庭设备登录多个账号可能正常，一次换机或异地网络也不应单独定罪；反过来，多台真机若在短窗口内重复触发高价值权益，设备本身“真实”也解决不了业务风险。

Play Integrity 官方文档同样建议把完整性声明绑定受保护请求，与其他信号组合并采用分级处置。这里引用的是设计原则，并不声称拼多多接入了这项服务。

5.1 一次页面结果无法当原因码

售空、失败、验证码或一次成功响应都可能同时受库存、账号、地域、实验分桶和服务降级影响。没有服务端原因码和对照组，反复试请求得到的是混合结果，不是干净的风控实验。

这也是笔者不做线上阈值试探的原因：既可能影响真实业务，又很难得到可解释结论。

六、一次来源审计带来的改动

🔬 初稿曾引用一份后来更新的 Android 页面来说明硬件标识限制。检查发布日期后发现，该更新晚于文章日期，于是改用 2023 年可定位的 Android 10 隐私说明。这个改动没有让技术结论发生戏剧性变化，却暴露了 Type B 写作最常见的问题：今天打开的官方页面，未必能证明文章当时已经知道什么。

同样的原则也适用于两篇看雪材料。当前能够留下的是：7.80 历史样本出现过环境记录与结构化保护；作者称 7.85 总体结构接近；2026 年帖子观察到另一套记录拼装与缓存行为。它们之间的精确谱系、当前版本和服务端语义都仍然空缺。

6.1 笔者不建议做的事情

  • 不把历史前缀、密钥、IV、偏移和字段顺序整理成生成器；
  • 不用模拟环境批量访问真实业务接口；
  • 不靠反复试错推断营销、账号或交易处置阈值；
  • 不在缺少版本、渠道和 Hash 时宣称“最新版已还原”。

七、让防守少依赖“没人看懂 SO”

以下建议面向同类电商系统，不是对拼多多生产实现的漏洞判断。

优先级检查项预期效果
P0证据绑定业务动作、账号上下文和短时新鲜度，最终裁决留在服务端降低跨事件复用与本地篡改价值
P0建立协议/特征注册表，记录 App、SO Hash、渠道、ABI 和缺失语义防止旧字段污染模型，支持回滚
P1区分未授权、不支持、未触发、缓存命中、读取失败和矛盾减少 OEM、旧系统和隐私设置误伤
P1画像输出候选、置信度和冲突，再与账号、订单和权益关系组合控制共享设备与换机误判
P2提供限额、冷却、挑战、延迟、复核和申诉，而非只有放行/拒绝降低误伤，也减少阈值泄露
P3同时监控漂移、误伤、申诉翻转、特征可用率与隐私成本避免把“拦得多”当唯一指标

🧑‍🔬 客户端混淆仍有价值，它会提高一次性复现转化为稳定批量工具的成本。只是其角色应当是延迟和扰动，而不是唯一信任根。固定秘密如果必须永久保密，发布 App 的那一刻就已经开始倒计时。

八、原帖用了 AI，这能说明什么

2026 年 anti-token 原帖主动说明使用 AI 分析。AI 确实擅长从大段反编译代码中聚类数据流、识别算法轮廓和生成差分脚本草稿，但这些能力不会自动补齐样本 Hash、控制变量和服务端证据。

🤖 AI 在写作中用于资料索引、结构初排和图表实现，没有运行拼多多样本，也没有产生 A 级或实验级事实。早期草稿把第三方帖子的观察标成 Experimental，这会让读者误以为实验由笔者完成，现已删除。

🧑‍🔬 Human 负责决定哪些结论只能停在 C 级、哪些细节具有直接滥用价值，以及什么时候宁可留下空白，也不替帖子补版本和服务端用途。

九、借来的事实与留下的判断

9.1 借来的事实

来源借鉴内容使用限制
拼多多隐私政策安全用途、数据类别和 IMEI 版本边界不反推单次采集、Token 格式和模型
7.80/7.85 看雪材料历史环境记录及结构级处理不复述密钥、前缀、字段序列和偏移
2026 anti-token 材料记录容器、缓存和动态记录观察不替原文补 App 版本，不声称复现
Android、网信办与 PDD Holdings 官方材料平台限制、必要信息边界和业务背景不据此声称具体技术已接入

9.2 留下的判断

工作结果
删除字段大全改按来源、版本、触发和缓存状态解释记录
提出环境证据包模型区分事件附近的输出与稳定画像句柄
审计五条版本轴阻止字段、偏移和格式跨版本外推
标出服务端盲区将画像、业务关系和处置保留为 B 级职责模型

十、结论

拆开历史 anti-token 以后，能看到环境记录、记录容器、缓存和保护链，却看不到一个天然稳定的设备身份。动态量会变化，慢变量会漂移，读取还可能失败或沿用缓存；服务端若要维护连续性，只能把这些观察放进带时间和置信度的历史里。

官方政策确认安全场景会处理设备、应用、网络和标识符等类别，也公开了 IMEI 的旧版本边界。它说明采集面会变化，却没有把历史帖子升级成当前协议说明书。

这次复核最有价值的产物不是多一张字段表，而是一个停止条件：客户端证据到达网络边界后，画像、账号与交易关系、处置原因和反馈都需要新的证据。研究若没有越过这条边界，就应该如实写到这里，而不是用“风控已还原”替未知项收尾。