一份条理清晰、结构完善的文档，帮助你入门 chrome 漏洞利用 & v8 漏洞利用
本文档的组织方式
浏览器是当今最常用的技术之一。在每一台现成的计算机上，只要我们即插即用，就会看到已安装的浏览器。因此，从攻击者和威胁模型的角度来看，如果攻击者能够通过恶意页面攻破浏览器，那将是非常有回报的。基于上述理由，我选择研究 Google 的 JavaScript 引擎，尤其是 v8。
鉴于 v8 项目规模庞大，我选择以解释器（即 d8）作为起点。尽管针对 d8 已经进行了大量研究，但我们仍希望至少能找到一个 bug；即使找不到，也能继续推进浏览器漏洞利用研究，因为 v8 为浏览器漏洞利用中常用的基础利用开发策略提供了切入点。
我之所以选择 v8 作为目标，另一个原因是它被多个浏览器使用。
如果我们深入研究，就会发现该引擎也用于 MicrosoftEdge，因此有机会获得多个漏洞赏金计划的奖励。对于底层操作系统，研究者将混合使用 Windows 和 Linux，因为在获取 shell 方面没有限制，v8 漏洞允许通过 wasm 页面执行代码，并且不绑定任何特定平台。
遗憾的是，虽然 v8 中被利用的漏洞会导致代码执行，但由于沙箱的存在，我们无法执行任何代码；也就是说，我们只能在渲染器上下文中获得代码执行，而无法在机器上执行代码。为此，我们需要另一个沙箱漏洞利用，也就是需要一条完整的攻击链才能攻破系统。
因此，为了能够开始浏览器安全研究，我们定义了以下目标
在项目的第一阶段，有必要尽可能多地收集有关 Chrome 架构以及各个组件之间如何交互的知识。为了更好地理解这一点，我们需要将 Chromium 项目拆分为多个子组件，以便能够隔离各部分并正确分析。更确切地说，下列每个组件会拆分成多少个子组件：
那么，对于第一步来说，最合乎逻辑的步骤是理解 Chromium 架构。 好的，我们想要利用浏览器，但当我们第一次启动浏览器时会发生什么？嗯，点击 Chromium 可执行文件之后，该可执行文件会启动一些进程。
它们的启动顺序和名称如下：
第一个叫作 content 进程。这个进程是做什么的？
既然我们大致了解了它的作用，现在是时候更深入地探讨它了：
.
chrome_exe_main_win.cc，如果你好奇想阅读完整代码，它位于 chromium/src/chrome/app。好，顺着执行流程往下走，我们可以看到它调用 MakeMainDllLoader() 来调用 dll 加载类；之后它启动“loader”（加载器），也就是加载 chrome.dll，如果有必要，还会使用必要的命令行重启它。为了进一步分析 Loader，我们需要理解它的代码，这些代码位于同一目录下的 mail_dll_loader_win.cc 文件中。一直滚动到文件底部，我们可以看到对 MakeMainDllLoader 的调用，它会根据你所拥有的版本调用 ChromeDllLoader 或 ChromiumDllLoader。
ChromiumDllLoader 是一个继承自 MainDllLoader 的类。从定义中可以看出，这个类所做的只是根据传递给 cmdline 和进程类型的参数来加载 dll。
.
.--no-sandbox 参数，这基本上就是告诉二进制文件不要在沙箱中运行。它检查这些条件中是否有任何一个被设置，如果任一为真，它就会使用相应的选项调用沙箱。最后我们来到
chrome_main 的封装。