Firefox 与普通单进程 EXE 在沙箱中的差异分析

Firefox 与普通单进程 EXE 在沙箱中的差异分析

firefox.exe 和普通单进程 EXE 最大的不同是:

它不是"启动一个主进程就结束",而是会快速进入一套 多进程 + 自带沙箱 + 自带 Hook/Trampoline + 高频 IPC 通信 的运行模型。


1. Firefox 会启动多个子进程

普通 EXE 通常只有一个主进程:

复制代码
app.exe

Firefox 启动后通常会出现:

复制代码
firefox.exe                  主进程 / Browser Process
firefox.exe -contentproc      内容进程
firefox.exe --utility         Utility 进程
firefox.exe --socket-process  网络 Socket 进程
firefox.exe --gpu-process     GPU 进程
crashhelper.exe               崩溃辅助进程
WerFault.exe                  Windows 崩溃报告进程

因此,沙箱不只是处理一个 firefox.exe,还要正确处理它拉起的各类子进程。


2. 子进程 Token 处理更敏感

Firefox 自身也会对子进程做降权和隔离。

Sandboxie 同样会处理进程 Token。

两套机制叠加后,如果 Token 限制过强,可能导致:

复制代码
子进程启动失败
子进程启动后无法通信
页面空白
浏览器卡死

之前迁移的逻辑就与此有关:

复制代码
-sandboxingKind

检测到 Firefox Sandbox 子进程后,需要对其 Token 做特殊处理。


3. Firefox 高度依赖 IPC 通信

Firefox 多进程之间会大量使用:

复制代码
Named Pipe
ALPC / LPC
Event
EventPair
KeyedEvent
Timer
Section / Shared Memory

普通 EXE 可能只使用文件、注册表、少量 Mutex。

但 Firefox 会频繁创建和打开这些内核对象。

如果 Sandboxie 没有 Hook 或没有放行某些 IPC 对象,常见表现是:

复制代码
启动卡住
页面空白
输入网址无响应
子进程崩溃
网页无法加载

因此需要补充或兼容:

复制代码
NtCreateEventPair / NtOpenEventPair
NtCreateKeyedEvent / NtOpenKeyedEvent
NtCreateTimer / NtOpenTimer
NtMapViewOfSection

4. 新版 Firefox 有自己的 Hook / Trampoline 机制

这是 Firefox 和普通 EXE 最关键的区别之一。

普通 EXE 的 ntdll!NtXxx 入口通常比较标准。

但新版 Firefox 内部存在自己的 syscall 拦截层,例如:

复制代码
g_originals
original syscall table
trampoline

如果 Sandboxie 仍然按照普通 ntdll stub 方式 patch,就可能 patch 到错误位置。

这也是本次迁移以下逻辑的原因:

复制代码
Hook_CheckChromeHook
findFirefoxTarget
g_originals

简单说:

复制代码
Firefox 已经先包了一层 syscall。
Sandboxie 必须识别这层包装,并找到真正应该 Hook 的入口。

5. Firefox 会映射特殊的非 Image Section

Firefox 146+ 之后存在一个特殊点:

它可能会把某些 非 image section 映射到子进程中,且保护属性可能是:

复制代码
PAGE_EXECUTE_READ

Sandboxie 需要将其临时调整为:

复制代码
PAGE_EXECUTE_READWRITE

这样才能安装 Hook。

因此需要补充:

复制代码
NtMapViewOfSection
NtQuerySection
SEC_IMAGE 判断

这类情况在普通 EXE 中比较少见。


6. Firefox 的崩溃处理链路更复杂

普通 EXE 崩溃后,通常直接进入:

复制代码
Unhandled Exception

而 Firefox 可能经过:

复制代码
crashhelper.exe
WerFault.exe
Firefox Crash Reporter

所以即使进程崩溃,SedeDll 的 MiniDump 也不一定会立即生成。

因为异常可能已经被 Firefox 自己的崩溃处理链路接管。


7. Firefox 网络进程独立

Firefox 的网络访问不一定在主进程中完成,而可能由独立的 Socket Process 负责。

因此:

复制代码
主窗口能启动 ≠ 网络功能正常

如果 Socket Process 的以下任一环节异常:

复制代码
IPC
Token
Hook
Pipe
Section

都可能表现为:

复制代码
窗口能打开
输入网址无响应
网页打不开

Chrome / Edge 可以正常联网,也不能直接证明 Firefox 没问题。

因为它们的进程模型、Hook 结构和 IPC 机制并不完全相同。


总结

普通 EXE 的模型通常是:

复制代码
主进程 + 常规 Win32 / Nt API

Firefox 的模型则是:

复制代码
主进程
+ 多类子进程
+ 自带沙箱
+ 自带 syscall hook / trampoline
+ 高频 IPC
+ 特殊 section 映射
+ 独立崩溃处理链路
+ 独立网络进程

所以 Firefox 在 Sandboxie 中运行失败时,常见原因往往不是"网络本身",而是:

复制代码
子进程 Token 不正确
IPC 对象被拦截
NtMapViewOfSection Hook 不兼容
LowLevel 早期 syscall patch 识别错 Firefox trampoline
崩溃被 crashhelper / WER 接管
Socket Process 启动或通信异常
相关推荐
子兮曰4 天前
jev-ultrafast 深度解析:7 秒订机票的浏览器 Agent 是如何炼成的
前端·后端·agent
子兮曰4 天前
Jev 爆发一周:7 秒 Agent 背后的 System One 生态与三场争议
前端·后端·ai编程
前端小万4 天前
写公众号赚了 3000 块后,我做了一款叫 "一键成稿" 的软件
前端·微信小程序
爱勇宝4 天前
ZCode 开源 24 小时:一份没有历史的账本,回答不了"有没有偷代码"
前端·后端·chatglm (智谱)
三十而立洋4 天前
Cookie 详解:从产生到安全,一次讲透
前端·javascript
卡布鲁4 天前
把一个 Vite + Vue3 应用塞进 qiankun (React + Umi3) 主站:十个坑的复盘
前端·javascript·react.js
汉堡大王95274 天前
Jev:不是聊天机器人, 而是一个智能 if 语句
前端·人工智能·后端
梦想很大很大4 天前
从运行事实到回归证据:Workrun 的 Telemetry 与 Evaluation 实践
前端·人工智能·后端
计算机魔术师4 天前
Meta Muse agent 接入 Shopify 的 Shop Pay 实现代理式购物
前端
沙蒿同学4 天前
我用 Go 搭了一条 AI Agent 流水线:从 1 张商品图到一整套淘宝详情页
前端·javascript·后端