← 返回博客
RUENESZHARPTDEFRJAKOITTRIDVIFAHI

如何自行提取网站检测卡：寻找指纹脚本

案例 AliExpress：隐藏的音频指纹通过蓝牙耳机暴露了自己。我们分析实用方法——如何在一个小时内确定反欺诈供应商，找到他们的脚本，在 DevTools 中工具化 fingerprint-API，并查看平台实际捕获了哪些信号以及将其发送到哪里。

📅2026年8月25日
如何自行提取网站检测卡：寻找指纹脚本

2026年8月20日，开发者梅特·卡拉根（博客laserphile）发布了一个奇怪的bug分析：他的多点蓝牙耳机无法在电脑和手机之间切换。每当打开AliExpress标签页时，它们就会停止切换。他没有猜测，而是对浏览器API进行了工具化，查看页面内部发生了什么。结果发现，来自阿里巴巴反欺诈栈的两个混淆脚本通过音频上下文提升并通过人耳听不到的声音进行设备指纹识别。

这是一个完美的例子，说明几乎没有人会在设置配置文件或启动解析器之前：不阅读平台的检测栈，而是进行猜测。下面是一个实用的方法，如何在一个小时内手动获取特定网站的检测图，不需要反混淆和付费服务。

为什么要获取检测图

典型的循环是这样的：账户被封禁——随意调整反检测浏览器的设置——更换代理——再次被封禁。在“被封禁”和“设置”之间没有数据：不清楚平台到底读取了什么，以及在哪一层被捕获。

检测图填补了这一空白。这是一个列表：使用了什么保护供应商，哪些脚本实现了它，哪些API被触及，结果去向何处。接下来就能看出，真正的瓶颈在哪里——是在IP、网络指纹还是浏览器的硬件层。这对三个受众都是同样有用：

  • 多账户管理——了解哪些信号将配置文件粘合在一起。它们的IP不同，但音频栈、WebGL渲染器和hardwareConcurrency在整个农场中往往是相同的。
  • 抓取——了解是否真的需要启动浏览器，或者任务可以通过具有正确TLS指纹的HTTP客户端解决。
  • 隐私——看到商店或服务收集了关于您设备的哪些信息，除了cookies。

步骤1. 根据网络确定保护供应商

您首先要做的是在网络标签页打开开发者工具，加载页面并查看第一个文档的标题和cookies。识别标志是已知且稳定的：

  • CF-RAY在响应头和cookie cf_clearance中——Cloudflare。
  • Cookie _abck和包含bmak函数的脚本——Akamai Bot Manager。
  • 带有前缀_px的变量和cookies——PerimeterX（HUMAN）。
  • Cookie datadome和来自供应商域的单独JS——DataDome。
  • 空的429响应体——Kasada的特征签名。

如果手动操作太麻烦，可以使用开放的检测器，如microlinkhq/is-antibot（30多个供应商）和浏览器扩展检测器，支持26个以上的供应商。它们提供快速的初步答案，但无法回答主要问题——您的浏览器中到底测量了什么。要深入了解，您需要进一步探索。

步骤2. 提取可疑脚本列表

按JS类型过滤网络，列出所有不是从主域加载或位于服务目录中的内容。在AliExpress的案例中，这两个文件显然是服务路径：

  • assets.aliexpress-media.com/g/AWSC/uab/1.140.0/collina.js
  • assets.aliexpress-media.com/g/AWSC/fireyejs/1.231.67/fireyejs.js

反欺诈脚本的特征：混淆代码、路径中的版本、单独的静态子域、与页面视觉部分没有任何联系。无需打开和阅读混淆——在下一步中，脚本会自己讲述。

步骤3. 工具化指纹API

这是方法的核心，正是卡拉根所做的：他包装了构造函数AudioContext和AudioNode.prototype.connect()，之后在没有任何媒体元素和play()调用的页面上看到了两个活跃的音频上下文。

逻辑很简单：您用自己的包装替换感兴趣的方法，该包装记录调用的堆栈并将控制权传递给原始方法。调用堆栈显示了哪个脚本调用了API。通过开发者工具的Sources → Snippets插入这样的代码片段最方便，或者通过在document-start执行代码的扩展——重要的是在反欺诈脚本加载之前完成。

覆盖大多数信号的最小陷阱集：

  1. HTMLCanvasElement.prototype.toDataURL和getImageData——画布指纹。
  2. WebGLRenderingContext.prototype.getParameter——显卡和驱动程序的型号，着色器的精度。
  3. AudioContext / OfflineAudioContext和AudioNode.prototype.connect——音频指纹。
  4. 获取器navigator.hardwareConcurrency、navigator.deviceMemory、navigator.plugins、navigator.webdriver。
  5. RTCPeerConnection——WebRTC和本地地址。
  6. screen.width/height、devicePixelRatio、Intl.DateTimeFormat().resolvedOptions()——屏幕和时区。
  7. navigator.mediaDevices.enumerateDevices——音频和视频设备列表。

经过处理，您将得到一个列表：这些API中哪些被调用了，调用了多少次，谁调用的。在分析的案例中，阿里巴巴的脚本触及了画布和toDataURL、WebGL渲染器和着色器的精度、通过振荡器和分析器的音频、屏幕尺寸和devicePixelRatio、hardwareConcurrency和deviceMemory、插件、编解码器支持、WebRTC、性能时序、鼠标和触摸的移动模式、设备的运动传感器和自动化指示器属性。

音频图形具体做了什么

了解测量的样子是有帮助的，以便在其他地方识别它。图形是这样的：锯齿波振荡器→AnalyserNode→ScriptProcessorNode，读取分析结果→GainNode，增益为零→destination。没有声音，音量无关紧要——它根本不存在。但连接到destination，根据作者的说法，会让浏览器积极处理图形，尽管最终音量为零。正是活跃的音频通道保持了蓝牙路径的开启，破坏了耳机的多点切换。

处理该信号的差异取决于处理器、音频硬件、操作系统、浏览器和驱动程序——因此，稳定的标识符能够承受IP的变化和cookies的清理。对这一层的详细分析以及根据它设置配置文件的内容——在关于音频上下文指纹识别保护的文章中。

步骤4. 捕获结果的发送

收集而不发送是没有意义的，因此下一步是找到收集到的指纹去向何处。按XHR/Fetch过滤网络，并单独查看ping类型的请求——它们由navigator.sendBeacon产生，电信脚本喜欢使用它，因为它在离开页面时仍然有效。

几乎总是有用的是额外包装fetch、XMLHttpRequest.prototype.send和navigator.sendBeacon——这样您可以在请求发送之前看到请求体。准备好内容将被序列化和加密：在AliExpress的案例中，数据在发送到阿里巴巴的遥测之前被加密。但即便如此，您仍然获得两个事实：接收者的地址和相对于您的操作的发送时刻。

如果网站不仅在浏览器中工作，还通过移动应用或单独的客户端运行，那么同样的问题在流量层面解决，而不是在DOM层面——拦截和分析的方法在通过mitmproxy进行流量审计的分析中进行了描述。

步骤5. 将地图与您的配置文件进行对比

现在您有了平台实际读取的信号列表。接下来需要检查您的工作配置文件在这些信号下的输出。顺序如下：在普通浏览器中获取值，然后在每个反检测配置文件中获取并进行比较。

同时重要两件事：值必须在配置文件之间有所不同，并且在同一配置文件的会话之间保持稳定。每次启动时指纹波动的配置文件对反欺诈来说看起来同样可疑，就像十个具有相同指纹的配置文件一样。

单独检查替换是否在所需层面上存在。这里浏览器之间的差异很有启发性：Firefox从118版本开始提供恒定的WebAudio输出，根据分析数据，99.24%的用户集中在三个值上；Brave插入随机数据，自2026年8月22日起阻止特定的AliExpress脚本，提醒用户其音频指纹保护默认启用已超过六年；Safari在音频缓冲区中插入错误；Chrome没有激进的保护。

潜在问题

  • 脚本已经执行。阻止文件并不会消除已创建的音频上下文——作者明确指出，必须关闭打开的标签页。您的工具化也是如此：如果包装在脚本之后加载，您将看不到任何内容。
  • 阻止会破坏功能。反欺诈栈通常也负责合法的事情——授权、支付、反机器人保护以防止真实滥用。获取检测图和删除脚本是不同的任务；后者会破坏网站。
  • 检测版本不止一个。栈可能因地理位置、设备类型和A/B组而异。获取检测图的意义在于使用您实际工作的IP和设备，否则您描述的是他人的配置。
  • 工具化本身会被检测。被重写的本地方法失去了正确的toString，而连接的调试器留下了痕迹。对于侦查来说这并不关键，但不要将侦查配置文件与战斗配置文件混淆——自动化伪装技术在无头浏览器伪装指南中进行了详细讨论。

需要什么样的代理来应对结果

从这种地图中得出的主要实用结论几乎总是一个：IP只是第一层，它在所有其他层之前被检查。如果反欺诈在请求阶段就能看到托管地址，音频图和画布就根本不会被触及——您将收到挑战或空的输出，并且会修复错误的内容。

因此，选择逻辑是这样的。对于具有严密栈的网站（Akamai、DataDome、PerimeterX、自主开发的阿里巴巴级别），基础是住宅代理——真实提供商的地址，不会在第一个过滤器上被切断。对于移动应用和主要受众使用智能手机的网站，更接近自然配置的则是移动代理：运营商的CGNAT使地址在多个真实用户之间共享。

反之亦然：如果地图显示平台仅限于标题和cookies，而没有重的JS指纹——浏览器农场就是多余的，任务可以通过普通的HTTP客户端和数据中心地址解决。

结论

耳机案例的价值不在于音频指纹的事实——这一点已经知道多年。其价值在于方法：人们没有相信猜测，而是包装了两种浏览器API的方法，并在一个晚上获得了完整的列表，了解他们收集了什么，以及去向何处。相同的技巧在您工作的任何平台上都只需一个小时，并且可以替代几个月的随机设置调整。在修复封禁之前获取检测图——否则您可能会冒着在所有配置文件上都存在相同WebGL渲染器的问题上浪费代理预算。