Device-Fingerprinting

〇、研究证据与方法声明 本文是一篇横向综述，不是单一目标的逆向工程报告。核心方法是文献综述 + 公开材料交叉验证 + 版本样本观察，辅以少量一手逆向实验作为交叉校准。以下声明帮助读者判断每条结论的可信度和适用边界。 方法论 项目 说明 研究方法 文献综述 + 逆向验证 + 横向对比 覆盖范围 8 个国内平台（抖音/字节系、快手、淘宝、蚂蚁/支付宝、夸克、拼多多、美团、小红书）+ 7 类海外产品（Fingerprint、Cloudflare、Arkose、Stripe Radar、Sift、ThreatMetrix、Play Integrity）+ Netflix MSL 协议专题，共计 16+ 平台/产品 技术维度 5 大方案类别（第一方状态、概率指纹、完整性证明、网络与行为检测、业务图谱）x 7 个工程环节（采集、封装、校验、归一化、召回、匹配、图关联） 证据分级 A（官方公开文档与平台规范）/ B（架构映射与开源代码分析）/ C（版本化逆向样本与社区观察）– 详见 §1.4 证据来源统计 等级 来源数 典型代表 A：公开确认 ~50 Android 官方文档（标识符最佳实践、Play Integrity、Key Attestation）、W3C 指纹缓解规范、各平台隐私政策（淘宝/拼多多/美团/小红书/夸克/快手）、厂商产品文档（阿里云设备风控、Fingerprint API、Cloudflare Bot Management、Stripe Radar、Sift、Arkose）、火山引擎 DataFinder、Netflix MSL 开源规范 B：架构映射 ~10 学术论文（Laperdrix 浏览器指纹综述、Eckersley Panopticlick、Vastel FP-STALKER）、开源项目代码分析（FingerprintJS、CreepJS、RiskEngine、TrustDevice）、顶象算法公开说明、GeaFlow 流式图计算 C：外部观察 ~7 看雪社区版本样本（淘系 SecurityGuard、美团 mtgsig、拼多多 libpdd_secure）、仓库内抖音 v37.5 MetaSec 实验记录、仓库内 Netflix MSL 协议逆向日志 范围限制 本文的"留白"是刻意的设计选择，以下是主要已知限制： ...

〇、摘要 🧑‍🔬 笔者第一次整理拼多多 libpdd_secure.so 资料时，建了一张很长的字段表：系统属性、Build、网络、SIM、时间、随机量，一项项排得很整齐。表格越完整，文章看起来越像已经还原了”设备指纹”。 问题也恰好出在这里。看雪帖子描述的是特定历史样本中的环境记录、缓存和封装；拼多多隐私政策描述的是产品在安全场景下可能处理的数据类别。前者缺少服务端，后者不是抓包。把两份材料合起来仍然得不到稳定设备 ID，更得不到当前画像模型和交易阈值。 最后只保留那些经得住版本变化的观察：历史 Native 代码曾组织环境记录，记录经过结构化封装和保护后形成输出；部分内容有缓存，动态量会随调用变化。字段顺序、前缀、偏移、密钥和生成步骤则全部省略。研究目的不是做一个 anti-token 生成器，而是看清客户端包裹到达网络边界后，还缺哪些证明。 Research Evidence Methodology Item Detail 文章类型 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-02 C 7.80 历史样本、作者对 7.85 的说明、记录与封装观察 anti-token 纯算法分析，2026-07-06 C Native 记录容器、缓存和动态记录的外部观察 Android 10 隐私变更与 Play Integrity 概览 A 标识符限制、请求绑定和分级处置的通用原则 Scope Limitations 没有可独立核验的 APK 渠道、完整版本、APK/SO SHA-256、ABI、设备构建号和抓取时间。 7.80 与 7.85 的接近程度来自原帖作者陈述，笔者没有做二进制差分。 2026 年帖子未在公开正文中给出可与 7.80/7.85 对齐的 App 版本，笔者不替它补版本号。 网络边界后的画像、图谱和处置流程均为 B 级职责模型，不代表拼多多内部实现。 负责任披露：这次材料复核用于安全评审与隐私核查，不建议把历史材料用于模拟客户端、批量请求、营销作弊或规避平台处置。 ...

〇、摘要 这篇文章起初只准备回答一个问题：社区分析里的 mtgsig2.4，是不是美团的设备指纹？ 🧑‍🔬 笔者把 2024 年看雪帖子、2019 年美团 Web 人机识别文章、2020 年 Zeus 规则引擎文章和 2026 年隐私政策排在一起后，发现这个问题问得太扁平了。四份材料跨越七年，面向不同终端，也在回答不同的工程问题。mtgsig 所在的请求保护、俗称 DFP 的设备连续性判断，以及围绕账号、位置、订单和履约展开的服务端风控，可能互相传递信号，却没有证据表明它们是一套算法的三个名字。 笔者不复现签名，也没有当前 APK、抓包或线上实验。真正要做的是把四份材料拆回原来的时间和职责，看看每一层的结论能走到哪里，又在哪里必须停下。 Research Evidence Methodology Item Detail 文章类型 Type B：官方资料与历史社区样本复核 时间跨度 2019-03 至 2026-06；不同年份材料不视为同一在线实现 证据标记 A：官方公开；B：跨材料架构判断；C：历史社区观察 一手实验 0；没有 APK Hash、运行环境、抓包或服务端原因码 安全边界 不公开生产签名配方、偏移、密钥、调用复刻或阈值试探 Sources & Evidence Grading 来源 等级 使用方式 美团 Web 人机识别文章，2019 A（历史） 观察公开流程如何区分入口校验与业务处理 美团 Zeus 规则引擎文章，2020 A（历史） 理解场景、因子、累计事件、决策和回放治理 看雪 mtgsig2.4 分析，2024 C 只确认某历史请求保护对象曾被社区分析 美团基本功能隐私政策，2026 A 确认安全场景涉及的设备、网络、应用等类别与用途 Android 标识符最佳实践 A 校准标识符作用域、可重置性和隐私边界 Scope Limitations mtgsig2.4 帖子没有提供足以独立复核的完整 App 版本、渠道、ABI、APK Hash 和设备环境。 2019 年 Web 流程与 2020 年 Zeus 是历史公开实践，不能直接映射到 2026 年 Android 客户端。 政策确认数据类别和用途，不提供当前 DFP 格式、字段组合、模型权重或采集频率。 文中的三层模型是职责划分，不声称采用美团内部命名。 一、路线总览：先把三层分开 笔者原来沿着 mtgsig2.4 继续追函数。样本身份核不实后，这条路越走越像在给旧帖子续写。于是研究问题换了一个方向：不再猜“怎么算”，先检查每层证据究竟有资格证明什么。 ...

〇、摘要 🧑‍🔬 这篇文章最初有一个看上去很完整的提纲：先讲 shield 算法，再列设备字段，接着画服务端画像，最后讨论内容风控。真正开始核对来源后，后三步几乎都缺证据。 能回到原文确认的逆向材料只有一篇 2020 年 libshield.so 分析。它展示了 Java 初始化、Native 拦截器与请求签名之间的历史关系，却没有按今天的复核标准留下完整 App 版本、渠道、ABI、APK Hash 和设备环境。官方隐私政策能确认安全场景涉及设备、应用、网络与运行状态等类别，但不能说明哪些值进入 shield。至于服务端怎样合并画像、怎样判断内容和交易风险，公开材料没有答案。 因此，这不是一次“补完小红书风控架构”的尝试，而是一份补不完的材料复核。能确认的地方尽量说清，不能确认的地方不借后来的仓库、相似库名或漂亮流程图补齐。 Research Evidence Methodology Item Detail 文章类型 Type B：历史材料复核与架构边界分析 资料范围 2019 年官方介绍、2020 年原始逆向文章、2023 年历史隐私政策 资料截止 2026-05-26；晚于截止日或无稳定发布日期的材料不进入论证 证据标记 A：官方历史材料；B：通用架构判断；C：社区历史观察 一手实验 无 APK、二进制 Hash、真机日志或服务端原因码 Sources & Evidence Grading 来源 日期 等级 能支持什么 小红书官方介绍页 2019-10 A（历史） 当时平台月活过亿，社区与电商场景并存 《小红书 App 之 shield 逆向》 2020-12-18 C 某历史样本中的 Native 初始化、拦截器与签名路径 小红书用户隐私政策 2023-02-24 A（历史版本） 安全运行与风控验证涉及的数据类别和用途 Scope Limitations 2020 年文章没有留下足以唯一定位发布物的完整样本元数据，笔者不声称复现其结论。 官方政策页面可能持续更新；这里只采用能够核对到 2023-02-24 的历史表述。 未观察设备注册、画像 ID、置信度、规则、模型、原因码和申诉结果。 历史文章包含双用途细节；笔者不传播密钥材料、拼接顺序、偏移或可运行代码。 一、路线总览：图里故意留下的空白 这张图里最重要的不是箭头，而是三个明确写着“未知”的位置。客户端材料能把读者带到网络边界，再往后走就需要另一类证据。 ...

〇、摘要 笔者最初以为，这篇文章会围绕 x-sign、x-umt、x-mini-wua、x-sgext 分成四条线。名字已经替研究做好了分类，似乎只要继续找调用点，就能给四个字段各安排一种职责。 🧑‍🔬 读完现有材料后，这个写法被放弃了。公开的社区帖子能说明四类字段在 MTOP 请求构造阶段经过 SecurityGuard/Native 路径，却没有给出足以确认字段内部语义的版本化证据；淘宝官方政策则说明平台会把设备、应用、网络、账号和服务日志用于账户及交易安全，但它不是协议字段说明书。两份材料彼此有关，却没有严丝合缝地接上。 这次复核记录的正是这段没有接上的距离：客户端请求怎样形成，设备证据可能在哪一层被使用，以及一次接口返回为什么仍不能替代服务端的交易判断。文章不复刻签名，不提供 Hook、模拟请求或线上试探步骤。 Research Evidence Methodology Item Detail 文章类型 Type B：公开材料复核，不是一手逆向报告 研究方法 回读原始社区帖与官方原文，按时间和信任边界交叉核对 资料截止 2026-04-17；只采用此前已经发布的材料 证据标记 A：官方公开；B：受材料约束的架构判断；C：版本化社区观察 一手实验 无 APK、Hash、真机日志或服务端原因码 Sources & Evidence Grading 来源 等级 实际使用的部分 阿里巴巴集团季度业绩披露，2025-05-15 A 业务规模背景，不用于推断安全能力 淘宝网基本功能隐私政策，2026-02-12 生效 A 已披露的数据类别及账户、交易安全用途 《浅谈淘四神的坑点》，2025-10-23 C 历史样本中的字段名、协议构建调用关系和 Native 边界 Scope Limitations 社区帖子没有提供可推广到当前淘宝客户端的完整版本范围，笔者不把它写成 2026 年现行实现。 隐私政策确认处理类别与目的，不能反推某个 x-* 字段的输入、权重或服务端阈值。 文中的服务端部分是 B 级职责模型，不是淘宝内部拓扑。 初稿检索到的后续综述晚于资料截止日，已经删除；后文直接引用原始来源。 一、路线总览：那条断开的链 真正改变路线的不是多找到一个函数，而是发现四个字段都落在同一段协议构建语境里。继续按字段名猜用途，文章会很热闹，证据却不会变多。 🧑‍🔬 图左侧是公开样本能够触及的客户端范围：业务参数进入 MTOP，安全能力参与封装，随后得到一组协议字段。右侧从协议校验开始，已经是外部无法直接观察的服务端范围。设备历史、账号状态和交易关系被画在右侧，不是因为笔者知道淘宝内部怎样实现，而是因为这些状态不可能从一份客户端调用链里读出来。 ...