指纹浏览器：MediaDevices 枚举指纹的伪装策略

在指纹浏览器的对抗中，当 Navigator、Canvas、WebGL 和 Audio 这四大主力防线被底层 C++ 编译级伪装稳固后，很多开发者会忽略一个极度隐蔽但杀伤力极强的侧翼战场——MediaDevices 枚举指纹。

风控系统的逻辑极其简单粗暴：一致性校验。如果你声称自己是一台普通的办公笔记本电脑，但你的浏览器却枚举出 4 个高清摄像头和 5 个顶级麦克风；或者你声称是 Mac，却暴露出 Windows 独占的虚拟音频驱动名称，风控系统甚至不需要计算哈希，一条 SQL 规则就能将你瞬间封杀。

更可怕的是，MediaDevices.enumerateDevices()是一个异步 API，且极度依赖底层操作系统的硬件状态。传统的 JS Hook 在这里不仅容易穿帮，还会破坏异步时序，导致页面崩溃。

本文将直插 Chromium 的媒体底层架构，拆解 MediaDevices 枚举的底层逻辑，给出基于 C++ 源码级的精准伪造与屏蔽策略。

一、 杀机暗藏：为什么 MediaDevices 是重灾区？

风控对媒体设备的检测，通常不是看你有什么，而是看你的设备列表是否符合物理常识与环境声明。

1. 典型的风控探针逻辑

navigator.mediaDevices.enumerateDevices().then(devices=>{letvideoCount=0;letaudioinputCount=0;devices.forEach(device=>{if(device.kind==='videoinput')videoCount++;if(device.kind==='audioinput')audioinputCount++;});// 陷阱 1：数量异常if(videoCount===0&&navigator.userAgent.includes('Mac')){// Mac 不可能没有摄像头（除非是 Mac Mini/Pro，需严格匹配）flagAsBot();}// 陷阱 2：名称暴露虚拟环境devices.forEach(device=>{if(device.label.includes('OBS')||device.label.includes('VAD')){// 暴露了 OBS 虚拟摄像头或虚拟音频驱动flagAsBot();}});});

2. 致命的 JS Hook 死角

面对这种检测，初级爬虫工程师习惯用 JS 拦截enumerateDevices的 Promise 返回值。
这种做法必死，原因有三：

1. 时序异常：真实的设备枚举需要查询底层 OS 驱动，耗时在几毫秒到几十毫秒不等。JS Hook 往往是瞬间 resolve，风控测量时间差即可识破。
2. 权限悖论：在真实浏览器中，如果用户未授予摄像头/麦克风权限，device.label是空字符串。JS Hook 往往无脑返回带有 label 的设备列表，直接触碰安全红线。
3. 跨域 iframe 隔离：风控在跨域 iframe 中执行检测，JS Hook 无法穿透。
   唯一出路：深入 Chromium 的 C++ 层，在媒体设备管理器查询操作系统的源头进行拦截。

二、 核心认知：Chromium 媒体管线的运转真相

要伪造设备列表，必须理解 JS 调用enumerateDevices()后，Chromium 内部发生了什么。

1. JS 调用：navigator.mediaDevices.enumerateDevices()。
2. Blink 层：MediaDevices::EnumerateDevices()将请求通过 Mojo IPC 发送至 Browser 进程。
3. Browser 进程：MediaDeviceManager收到请求，调用平台相关的系统 API（Windows 的 DirectShow/MediaFoundation，Mac 的 AVFoundation）。
4. OS 返回真实列表：系统查询硬件驱动，返回真实的设备 UID、名称和类型。
5. 权限过滤：Browser 进程检查当前页面的权限状态，如果未授权，将所有label清空，只保留kind和deviceId。
6. 原路返回：列表经 Mojo 传回 Blink，返回给 JS。
   关键点：

• 渲染进程无权知情：出于安全考虑，Renderer 进程绝对无法直接访问系统硬件。
• 权限决定可见性：label的有无完全由 Browser 进程的权限管理器控制。

三、 核心破局：Browser 进程的拦截与替换

我们的 Hook 点必须选在Browser 进程的MediaDeviceManager中，即 OS 返回真实列表之后，权限过滤之前。这是唯一能同时控制设备数量、种类、名称和时序逻辑的黄金节点。

1. 精准坐标定位

文件：content/browser/media/media_device_manager.cc（或类似命名的媒体中心文件）
找到处理设备枚举请求的方法，通常叫OnEnumerateDevices或EnumerateDevices。

2. C++ 源码级伪造实战

voidMediaDeviceManager::EnumerateDevices(intrender_process_id,intrender_frame_id,consturl::Origin&security_origin,boolenumerate_audio_input,boolenumerate_video_input,boolenumerate_audio_output,EnumerateDevicesCallback callback){// 1. 先让真实的底层 OS 枚举发生（保证正常的时序消耗）// 底层会查询 DirectShow / AVFoundation 等DoRealEnumerateDevices(render_process_id,render_frame_id,security_origin,enumerate_audio_input,enumerate_video_input,enumerate_audio_output,base::BindOnce(&MediaDeviceManager::OnDevicesEnumerated,weak_ptr_factory_.GetWeakPtr(),std::move(callback)));}voidMediaDeviceManager::OnDevicesEnumerated(EnumerateDevicesCallback callback,constMediaDeviceArray&real_devices){// real_devices 包含了宿主机真实的硬件列表// 【指纹浏览器拦截点】constauto&fp_config=FingerprintConfig::GetInstance();MediaDeviceArray final_devices;if(fp_config->IsMediaDevicesFakingEnabled()){// 策略一：根据预设配置，直接生成虚拟设备列表替换真实列表final_devices=GenerateFakeDeviceList(fp_config);}else{// 策略二：过滤掉黑名单中的设备（如 OBS 虚拟摄像头）final_devices=FilterRealDevices(real_devices,fp_config);}// 2. 执行正常的权限过滤逻辑（极其重要！）// 将 final_devices 交回给原始管线，由它根据页面权限决定是否清空 label// 这保证了如果页面没有权限，返回的 label 依然是 ""，逻辑自洽ProcessPermissionsAndReturn(render_process_id,render_frame_id,security_origin,std::move(callback),final_devices);}

3. 虚拟设备列表的构造原则

在GenerateFakeDeviceList中，不能闭门造车，构造的设备必须与你的Navigator/UA声明强一致。

MediaDeviceArrayGenerateFakeDeviceList(constFingerprintConfig*config){MediaDeviceArray devices;std::string os_type=config->GetString("os");// e.g., "mac"if(os_type=="mac"){// Mac 环境标配：FaceTime HD 摄像头 + 内置麦克风if(config->HasVideoInput()){MediaDeviceInfo camera;camera.device_id="fake_mac_camera_uid_001";camera.kind=media::MEDIA_DEVICE_VIDEO_INPUT;camera.label="FaceTime HD Camera (Built-in)";// 必须是 Mac 专有名称devices.push_back(camera);}if(config->HasAudioInput()){MediaDeviceInfo mic;mic.device_id="fake_mac_mic_uid_002";mic.kind=media::MEDIA_DEVICE_AUDIO_INPUT;mic.label="MacBook Pro Microphone (Built-in)";devices.push_back(mic);}if(config->HasAudioOutput()){MediaDeviceInfo speaker;speaker.device_id="fake_mac_speaker_uid_003";speaker.kind=media::MEDIA_DEVICE_AUDIO_OUTPUT;speaker.label="MacBook Pro Speakers (Built-in)";devices.push_back(speaker);}}elseif(os_type=="windows"){// Windows 环境通常更为复杂，但切忌暴露 "VAD" 等字眼// 构造通用的 Realtek HD Audio 等}returndevices;}

核心优势：
通过在 Browser 进程拦截并替换，我们将底层的硬件差异彻底抹平。JS 层拿到的设备列表，无论从数量、名称还是权限表现，都 100% 符合我们预设的系统特征，且没有任何 JS 层的 Hook 痕迹。

四、 致命陷阱：deviceId的哈希闭环

在MediaDeviceInfo中，deviceId是一个极度敏感的字段。
根据 W3C 标准，deviceId是基于当前 Origin（域名）和设备的底层硬件 UID 生成的哈希值。这意味着，同一个摄像头，在a.com和b.com下获取的deviceId是不同的。
风控系统会校验这一点：

1. 在a.com获取摄像头 ID 为hash_A。
2. 跳转到b.com获取摄像头 ID 为hash_B。
3. 校验hash_A和hash_B是否对应同一个底层硬件。

致命错误：硬编码 DeviceId

如果你在GenerateFakeDeviceList中硬编码了device_id = "fake_mac_camera_uid_001"，由于这个字符串是固定的，无论在哪个域名下，deviceId都不会变。这直接违背了 W3C 规范的跨域隔离原则，风控一测便知。

破局策略：接管 DeviceId 的哈希生成

Chromium 生成deviceId的逻辑通常在MediaDeviceSaltAndOrigin相关的类中。它将底层设备的真实 UID + 页面 Origin + 浏览器内部的 Salt 进行哈希。
为了合规，我们的fake_device_uid必须参与这个哈希流程，而不是直接作为最终的deviceId输出。
修正后的构造逻辑：

// 我们构造的只是底层硬件的 UID，而不是最终暴露给 JS 的 DeviceIdcamera.device_id="fake_hardware_uid_mac_camera_001";// 后续 Chromium 的管线会自动根据这个 UID + Origin 生成合规的哈希 deviceId

只要我们保证这个fake_hardware_uid在同一个浏览器配置文件中保持稳定，那么同一个域名下多次枚举的deviceId就会保持一致，跨域时又会产生不同的哈希，完美符合规范。

五、 高阶对抗：媒体权限的时空伪装

设备列表的伪造只是基础，风控的终极杀招是模拟请求权限。
当风控 JS 执行navigator.mediaDevices.getUserMedia({video: true})时，如果浏览器没有抛出权限请求弹窗，或者瞬间拒绝/通过，都是极度异常的。

1. 拒绝策略的陷阱

很多爬虫环境为了防止弹窗阻断，会在底层直接将所有的getUserMedia请求拒绝。
死因：真实用户面对权限请求，从弹窗出现到点击，至少需要几百毫秒。直接拒绝的耗时通常是微秒级的，时序异常。

2. 正确的权限降级：静默拦截与延迟拒绝

我们需要在 Browser 进程的权限管理器中拦截getUserMedia请求。
精准坐标：content/browser/media/media_stream_manager.cc或MediaStreamDispatcherHost

voidMediaStreamDispatcherHost::OnRequestMediaStreamAccess(...constMediaStreamRequestOptions&options){// 【指纹浏览器拦截点】if(FingerprintConfig::GetInstance()->IsBlockMediaAccessEnabled()){// 1. 构造延迟拒绝（模拟人类思考或系统响应时间）base::TimeDelta delay=base::Milliseconds(300+base::RandInt(0,700));// 300-1000ms 随机延迟base::SequencedTaskRunner::GetCurrentDefault()->PostDelayedTask(FROM_HERE,base::BindOnce(&MediaStreamDispatcherHost::DenyMediaAccessWithReason,weak_ptr_factory_.GetWeakPtr(),render_frame_id,"User denied permission"),// 伪造拒绝原因delay);return;}// 兜底：走真实的权限弹窗逻辑DoRealRequestMediaStreamAccess(...);}

效果：
风控 JS 调用getUserMedia，等待 300-1000 毫秒后，收到NotAllowedError。这在风控看来，是一个活生生的用户点击了“拒绝”按钮，逻辑完美闭环。

六、 避坑实录：媒体伪装的三大暗礁

1. 虚拟声卡的幽灵

在云服务器或虚拟机（如 AWS EC2）上运行浏览器时，底层 OS 通常没有物理声卡，而是安装了虚拟音频驱动（如 Windows 的 “Stereo Mix (Realtek HD Audio)” 或虚拟机增强工具注入的设备）。
破局：如果宿主机存在无法卸载的虚拟设备，必须在前文提到的FilterRealDevices中将其强制剔除，否则无论怎么伪装，都会暴露虚拟机环境。

2.getDisplayMedia的降维打击

除了摄像头和麦克风，风控还会检测屏幕共享navigator.mediaDevices.getDisplayMedia。如果底层 API 返回了支持，但你的设备列表却没有对应的屏幕源，逻辑冲突。
破局：对于无需 GUI 的 Headless 爬虫，直接在底层将getDisplayMedia禁用，并返回NotSupportedError，声称环境不支持屏幕共享，这比伪造屏幕共享流更安全。

3. 设备热插拔的时序炸弹

真实世界中，设备插拔会触发devicechange事件。如果你在 JS 层伪造了设备列表，却无法模拟devicechange事件的底层触发机制，风控只要快速插拔一次设备（通过驱动层模拟），你的 JS Hook 就会与底层状态脱节。

破局：得益于我们在MediaDeviceManager的 C++ 层拦截，底层的设备热插拔事件依然由 OS 驱动。只要我们确保过滤/替换逻辑在每次事件触发时都能实时生效，JS 层监听的devicechange事件自然会在底层被阻断或放行，不存在状态脱节的风险。

七、 结语：细节中的魔鬼

媒体设备枚举指纹，看似只是几个设备名称和数量的拼接，实则是浏览器与操作系统硬件驱动深度交互的缩影。

风控系统正是利用了这种交互的物理必然性，在指纹浏览器的防线上撕开口子。通过深入 Browser 进程的MediaDeviceManager，我们不仅替换了冰冷的设备列表，更重塑了权限请求的时序逻辑，让每一个被伪造的麦克风和摄像头，都拥有了呼吸的温度。

当本地环境的伪装达到极致，浏览器将不再是信息孤岛。它必须向世界发出请求，而网络层正是风控布下天罗地网的最终修罗场。