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 启动或通信异常