Anti-Fraud

〇、研究证据与方法声明 本文是一篇横向综述，不是单一目标的逆向工程报告。核心方法是文献综述 + 公开材料交叉验证 + 版本样本观察，辅以少量一手逆向实验作为交叉校准。以下声明帮助读者判断每条结论的可信度和适用边界。 方法论 项目 说明 研究方法 文献综述 + 逆向验证 + 横向对比 覆盖范围 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 协议逆向日志 范围限制 本文的"留白"是刻意的设计选择，以下是主要已知限制： ...

〇、摘要 这篇文章起初只准备回答一个问题：社区分析里的 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 继续追函数。样本身份核不实后，这条路越走越像在给旧帖子续写。于是研究问题换了一个方向：不再猜“怎么算”，先检查每层证据究竟有资格证明什么。 ...

〇、摘要 笔者最初以为，这篇文章会围绕 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，安全能力参与封装，随后得到一组协议字段。右侧从协议校验开始，已经是外部无法直接观察的服务端范围。设备历史、账号状态和交易关系被画在右侧，不是因为笔者知道淘宝内部怎样实现，而是因为这些状态不可能从一份客户端调用链里读出来。 ...