【魔改浏览器】确定性噪声注入：从源码层面对抗 Canvas 指纹追踪

声明

：本文所有实验均在本地编译的 Chromium 完成，不涉及任何线上系统，纯粹学术研究，禁商业用途。

1. 背景：浏览器指纹是怎么认识你的

前段时间我在研究浏览器指纹追踪，越研究越觉得离谱。

一个网站，Cookie 没有，LocalStorage 没有，甚至连 IP 都换了，结果你再打开它，它还是认识你。

对，就是这么不讲道理。

我一开始是不信的，直到我亲手把 fingerprintjs 的源码从头到尾读了一遍。

fingerprintjs 在检测 Canvas 指纹时，会连续画两次文字，然后把两次的 toDataURL() 结果做对比。这段代码我第一次读的时候，后背发凉。

// fingerprintjs — canvas.ts 核心片段function renderTextImage(canvas, ctx) {  canvas.width = 240  canvas.height = 60  ctx.textBaseline = 'alphabetic'  ctx.fillStyle = '#f60'  ctx.fillRect(100, 1, 62, 20)  ctx.fillStyle = '#069'  // 用显式内置字体，排除用户字体偏好的影响  ctx.font = '11pt "Times New Roman"'  const printedText = `Cwm fjordbank gly ${String.fromCharCode(55357, 56835)}`  ctx.fillText(printedText, 2, 15)  ctx.fillStyle = 'rgba(102, 204, 0, 0.2)'  ctx.font = '18pt Arial'  ctx.fillText(printedText, 4, 45)}function canvasToString(canvas) {  return canvas.toDataURL()  // ← 这就是指纹的原始来源}

它画了什么？文字、emoji、半透明叠加，然后再画一组几何图形，圆形混合、奇偶环绕规则。全部画完之后调用 toDataURL()，把整个画布编码成 base64。

最狠的是这段稳定性检测：

// fingerprintjs — 稳定性检测核心逻辑const textImage1 = renderTextImage(canvas, ctx, false)const textImage2 = renderTextImage(canvas, ctx, true)if (textImage1 !== textImage2) {  // 两次结果不一样 → 浏览器在故意制造不一致  return 'unstable'  // ← 直接标记：这浏览器在对抗指纹追踪}

你是不是觉得，我只要往 toDataURL() 里加点随机噪声，让它每次输出都不一样，不就能防住了？

想法很自然，但上面这段代码会直接把你揪出来。

2. 对抗思路：为什么"随机噪声"行不通

最直接的想法当然是，我在浏览器里加噪，每次调用 toDataURL() 的时候，往像素里加点随机噪声，这样每次输出的 base64 都不一样，指纹不就失效了吗？

思路很简单，但现实很骨感。

fingerprintjs 的作者比你想的远多了，人家在代码里专门写了一道"稳定性检测"逻辑。

逻辑是这样的：同样的 Canvas 绘制操作，连续执行两次，分别调用 toDataURL()，拿到两个 base64 字符串。如果这两个字符串不一样，说明你的浏览器在"故意制造不一致"。

一旦出现这种情况，fingerprintjs 直接返回一个特殊标记，告诉你：这浏览器在对抗指纹追踪。

你加了随机噪声，本来想让自己"不可追踪"，结果反而直接暴露了。

这就引出了一个非常核心的技术问题：我们要加噪，但不能是"随机噪"，必须是"确定性噪声"。

• 同一个会话（session）里面，同样的输入必须得到同样的输出，这样 fingerprintjs 的稳定性检测才会认为你是"正常的"；
• 不同会话之间（比如你关掉浏览器再重新打开），输出必须变化，这样追踪者就没法跨会话追踪你。

这个"会话内确定、跨会话随机"的特性，就是整个方案最核心的地方。

3. 现有方案的缺陷：Tor Browser 的困境

说到这里，可能有些小伙伴纳闷，那 Tor Browser 是怎么做的？

Tor Browser 确实对 Canvas 指纹做了防护，它的做法是，每次调用 toDataURL() 都返回不同的结果，或者干脆返回空。

但问题在于，fingerprintjs 的稳定性检测会直接识别出这种行为，然后给你的指纹打上"unstable"标签。

从追踪的角度来看，虽然拿不到你的精确指纹，但"这个浏览器在对抗追踪"本身，就是一个非常强的特征。

你本来想藏起来，结果反而站到了聚光灯下。

我们要做的，是一条"中间路线"：

加噪，但是加的是确定性噪声。 让 fingerprintjs 的稳定性检测认为你是正常的，但同时，让每次会话的指纹都不一样。

这件事的难点在于，你得在浏览器的底层动手，而不是在 JS 层做 hook。因为在 JS 层做，很容易被检测和绕过。

4. 方案选型：为什么选魔改 Chromium 源码

我选的是魔改 Chromium 源码。

原因很简单，Chromium 是开源的，你能看到每一行代码。从 JS 调用 toDataURL()，到最终输出 base64 字符串，整个调用链都摊在你面前。

但这也是件很麻烦的事。

Chromium 的代码量大概是几千万行，光是编译一次，在我这台机器上就要好几个小时。

而且，你不能随便改，改错了，轻则编译失败，重则浏览器崩溃。

我一开始的思路是，找到 toDataURL() 在 C++ 层的实现，然后在合适的位置，往像素数据里加噪声。

但"合适的位置"这四个字，说起来简单，做起来要了命了。

你得先搞清楚，从 JS 调用 toDataURL()，到最终编码成 PNG/base64，中间经过了哪些函数调用，数据是怎么流转的，像素数据在哪个环节是以"可写"的形式存在的。

如果选错了位置，要么加噪根本不生效，要么就是破坏了浏览器的其他功能。

5. 源码追踪：从 JS 到 C++ 的调用链

我花了大概一周的时间，把 Chromium 里跟 Canvas 输出相关的源码，从头到尾读了一遍。

从 HTMLCanvasElement::toDataURL() 开始，一路追到 ImageDataBuffer，再追到 Skia 的图像编码器。

5.1 JS 入口：HTMLCanvasElement::toDataURL()

JS 调用 canvas.toDataURL() 之后，C++ 层最先进入的是这个函数：

// blink/renderer/core/html/canvas/html_canvas_element.ccString HTMLCanvasElement::toDataURL(    const String& mime_type,    const ScriptValue& quality_argument,    ExceptionState& exception_state) const {  // 检查 Canvas 有没有未闭合的图层  if (ContextHasOpenLayers(context_)) {    exception_state.ThrowDOMException(        DOMExceptionCode::kInvalidStateError,        "`toDataURL()` cannot be called with open layers.");    return String();  }  // 检查画布是否被跨域图片污染  if (!OriginClean()) {    exception_state.ThrowSecurityError(        "Tainted canvases may not be exported.");    return String();  }  // 解析 quality 参数，然后调用内部实现  return ToDataURLInternal(mime_type, quality, kBackBuffer);}

前面两段校验，图层没闭合就直接抛异常，画布被跨域图片污染也直接抛异常，这都是 Web 标准的强制要求，跟指纹没关系。

真正干活的是 ToDataURLInternal()。

5.2 核心函数：ToDataURLInternal()

// 同一个文件，ToDataURLInternal() 片段String HTMLCanvasElement::ToDataURLInternal(    const String& mime_type,    const double& quality,    SourceDrawingBuffer source_buffer) const {  // 先判断画布还能不能画  if (!IsPaintable())    return String("data:,");  // 把 JS 传进来的 mime 字符串转成内部枚举  ImageEncodingMimeType encoding_mime_type =      ImageEncoderUtils::ToEncodingMimeType(          mime_type, ImageEncoderUtils::kEncodeReasonToDataURL);  // ★ 这一步最关键：从 Canvas 后端缓冲区取像素 ★  scoped_refptr<StaticBitmapImage> image_bitmap = Snapshot(source_buffer);  if (image_bitmap) {    // 包装成 ImageDataBuffer，然后调用它的 ToDataURL()    std::unique_ptr<ImageDataBuffer> data_buffer =        ImageDataBuffer::Create(image_bitmap);    if (!data_buffer)      return String("data:,");    String data_url = data_buffer->ToDataURL(encoding_mime_type, quality);    return data_url;  // 最终返回给 JS  }  return String("data:,");}

Snapshot() 这一步，会把 GPU 或者 CPU 渲染完的像素数据，从后端缓冲区里读出来，包装成 StaticBitmapImage，然后再用 ImageDataBuffer::Create() 包一层。

5.3 像素数据的关键载体：SkPixmap

ImageDataBuffer 的构造函数，是我读得最仔细的一个函数。

它先判断图像是 GPU 纹理还是 CPU 内存，如果是 GPU 的，就用 readPixels() 把像素读到一块新分配的内存里；如果是 CPU 的，就直接 peekPixels() 拿指针。

拿到 SkPixmap 之后，像素数据就静静地躺在那块内存里，等着被编码成 PNG。

SkPixmap 可以理解为：一块 CPU 内存，里面存着整个 Canvas 画布的像素数据，RGBA 四个通道，每个通道一个字节，按行排列。

toDataURL() 最终编码成 PNG 的，就是这块内存里的数据。

5.4 最后一环：ImageDataBuffer::ToDataURL()

// third_party/blink/renderer/platform/graphics/image_data_buffer.ccString ImageDataBuffer::ToDataURL(    const ImageEncodingMimeType mime_type,    const double& quality) const {  DCHECK(is_valid_);  Vector<unsigned char> result;  // ★ 核心：把 pixmap_ 交给 ImageEncoder 编码 ★  if (!ImageEncoder::Encode(&result, pixmap_, mime_type, quality)) {    return "data:,";  }  // 编码结果 → Base64 → 拼接 "data:image/xxx;base64,"  return StrCat({"data:",                  ImageEncoderUtils::MimeTypeName(mime_type),                  ";base64,",                  Base64Encode(result)});}

pixmap_ 作为 const 引用传进 ImageEncoder::Encode()，最终调用 Skia 的 PNG 编码器，把像素数据压缩成二进制，再做 Base64 编码。

所以，理论上，如果我能在这块内存被编码之前，往里面加一点点噪声，最终输出的 base64 就会变化，而且变化是"确定性"的，只要噪声生成函数是确定性的。

6. 核心方案：确定性噪声注入

核心思路其实已经出来了：

在 SkPixmap 被编码成 PNG 之前，往它的像素数据里，加一点点非常微弱的噪声。

噪声的强度要足够低，低到人眼完全看不出差别，但是又要足够高，高到 PNG 编码后的 base64 字符串会发生改变。

这个平衡点的把握，是整个方案里最讲究细节的部分。

还有一件事：噪声必须是"确定性"的。

• 同一个 session 内，同样的像素坐标，加的噪声必须一样，这样 toDataURL() 连续调用两次，输出才会相同，才能通过 fingerprintjs 的稳定性检测；
• 不同 session 之间，噪声模式必须变化，这样追踪者就没法把你上次会话的指纹和这次的关联起来。

这个"会话级种子"的设计，坦率地讲，说简单也简单，说讲究也讲究。

实现上，我在 ImageDataBuffer::ToDataURL() 里，在调用 ImageEncoder::Encode() 之前，对 pixmap_ 的像素数据做 in-place 修改。

噪声生成函数以"会话 ID"为种子，对同一坐标的像素，每次生成相同的偏移量，保证确定性。

7. 踩坑记录：Chromium 编译环境的坑

方案设计完，接下来就是实现了。

在实现过程中，我遇到了一个很典型的问题：Chromium 的编译环境，跟普通的 C++ 项目不太一样，它有自己的一套编译警告规则，有些在你自己项目里完全没问题的代码，在 Chromium 里会直接编译失败，因为人家的警告级别是 -Werror，所有警告都当错误处理。

我印象最深的一个坑是指针算术运算。

在 Chromium 里，直接操作原始指针，会触发一个叫 -Wunsafe-buffer-usage 的警告，这个警告是 Clang 特有的，目的是防止缓冲区溢出。

但问题来了，我要修改像素数据，不可避免地要做指针算术，总不能一行一行地调 setColor4f() 吧，那性能会差到没法用。

最开始我想的办法是用 // NOLINT 注释来抑制警告，结果发现这玩意只对 clang-tidy 生效，对编译器警告完全没用。

然后又试了 UNSAFE_BUFFERS_BEGIN/END 宏，结果编译直接报错说这个宏未定义。

最后正确的做法是用 #pragma clang diagnostic push/pop，这是 Clang 编译器的原生指令，可以直接控制警告的开关。

这种坑，你不亲自踩一遍，光看文档是绝对想不到的。

8. 验证：四层测试全部通过

代码写完了，编译过了，接下来就是验证。

验证分几个层次：

这几层验证全部通过的时候，我跟你说，那感觉，比中了彩票还爽。

做到这里，其实一个可用的"浏览器指纹对抗方案"已经出来了。

9. 延伸：从工具到论文

但这件事的价值，不止于"写了一个工具"。

我在整理这件事的时候，意识到它可以成一篇学术论文。

原因有几个：

1. 现有方案的缺陷
   ：Tor Browser 的随机化方案会被 fingerprintjs 的稳定性检测识别出来，我的方案不会，这是一个实实在在的改进；
2. 改造层次更深
   ：不是在 JS 层做 hook，而是直接在浏览器的渲染管线里动手，这种层次的改造，在学术上更有说服力，也更难被绕过；
3. 可扩展性
   ：这个思路可以扩展到其他指纹维度，Canvas 只是一个维度，WebGL、AudioContext、字体枚举，这些都可以用类似的"确定性噪声注入"思路来防护。

我现在在整理这篇论文，目标是投一个安全领域的顶会。

具体内容这里就不展开了，毕竟论文还没发，有些东西要留到审稿的时候再拿出来。

10. 总结

回头看这段研究，最有意思的不是"我改了哪些代码"，而是"我怎么找到应该改哪里"。

很多人一想到浏览器安全研究，就觉得必须要懂很多底层知识，要懂编译原理、要懂操作系统、要懂图形学。

但这些东西，你真的可以在研究的过程中自学。

我自己在读 Chromium 源码之前，对 Skia 图形库一无所知，对 SkPixmap 是什么东西完全没概念，对 PNG 编码的流程也是一知半解。

但你有了明确的目标，知道自己在追什么问题，源码会带着你学。

每一行代码后面跟着的注释，每一个函数调用链追溯到的那个函数名，都是线索。

这事坦率地讲，就是你得真的下去做，而不是停在"这个好难我肯定做不了"的想象里。

本文涉及的技术细节，部分已整理为学术论文，待发表后会在公众号同步。

>

感谢阅读，欢迎关注公众号逆向狂人，获取更多浏览器安全与 JS 逆向干货。

扫码加我微信，拉你进逆向交流群～

完整代码和调试工具，都在知识星球「Opcode Fight Clube」