Chrome Is Open Source and Still Hard to Reverse Engineer. Here's Where the Real Work Is!

Chromium's source code is available, yet people still spend years reverse-engineering Chrome. The code itself isn't the challenge; the complexities lie in the process model, the Google layer atop it, and the behaviors not covered in design documents. This section maps where that work provides significant value, identifying which repositories and documentation are the most critical.

Begin by examining what is documented, as most Chrome internals reverse-engineer what is already written down. The design documents provide a straightforward description of the multi-process architecture, where browsers and renderers communicate over Mojo or the legacy IPC system, with each renderer process containing a single RenderProcess object.

Mojo also enables the browser's services to interact with each other. The network service operates as a Mojo service, capable of running in a utility process or within the browser process. Site Isolation is crucial here, as each renderer process can be confined to documents and workers from a single site, even when those documents are in iframes.

However, this model varies across platforms. Desktop systems achieve full site-per-process, while Android implements a partial mode on devices with 2+ GB of RAM, and Chrome for iOS runs on WebKit, which lacks out-of-process iframe support. Thus, Chrome's security model comprises three distinct models, depending on the platform.

The primary source for understanding Chrome's security model is Charles Reis and the Chrome team's paper on deploying Site Isolation. This document highlights the performance and compatibility issues that arise when retrofitting a production browser with the new architecture. For hands-on testing, the security documentation outlines the process.

By enabling --enable-features=MojoJS, developers can call Mojo methods from JavaScript, simulating a compromised renderer. This approach exposes the real attack surface, which lies in the Mojo APIs that can lead to code execution in the browser process, a far more severe outcome than executing code in a sandboxed renderer.

V8, Google's JavaScript engine, operates differently than a traditional pipeline, serving as a tiering policy driven by runtime feedback. Initially, V8 featured only Ignition and TurboFan. However, in 2021, Sparkplug was introduced, followed by Maglev, which debuted in Chrome M117. The trade-off for using Maglev is that it compiles approximately 10 times slower than Sparkplug but is about 10 times faster than TurboFan.

The practical approach to reverse-engineering V8 involves reviewing the thresholds, which can be found in v8pedia. These thresholds indicate the number of invocation counts for each tier, such as 400 for Maglev and 3000 for TurboFan. These values should be treated as a snapshot, as flag defaults may change between V8 versions. To explore the exploitation side of things, a curated resource list is provided, including bug-hunting-101, Jack Halon's browser exploitation series, and doar-e's TurboFan introduction.

Although some entries in this list are outdated, they serve as a useful starting point for further investigation.

Three projects stand out in terms of reversing different layers within Chrome. Ungoogled-chromium focuses on reversing the Google dependency graph, addressing the fact that Chromium relies on some Google web services and binaries, even without user authentication. The method involves domain substitution, replacing Google domains in the source with non-existent domain names and pruning binaries.

This patch set functions as a map of every place Chromium communicates with Google services. Another project, chrome-devtools-mcp, exposes Chrome DevTools and Puppeteer to coding agents, enabling tools like Gemini, Claude, Cursor, or Copilot to control and inspect a live Chrome instance. This setup collects usage statistics and checks for updates by default, but users can disable both features using specific flags.

Lastly, js-reverse-mcp and the api-mapper skill serve as reverse-engineering tools for the sites within Chrome. Both tools trace function calls through logpoints, inject scripts before page load, and capture XHR/Fetch traffic over Chrome DevTools Protocol (CDP), inspecting JavaScript bundles when requests contain computed values.

This approach underscores the shift in which Chrome itself becomes a reverse-engineering tool, alongside its target.

One significant development within Chrome involves On-Device AI, specifically Gemini Nano. This feature integrates the Gemini Nano model directly into Chrome, allowing it to be downloaded in the background without prompting the user. The model supports English, Spanish, and Japanese as of Chrome 140. Developers can inspect this model, including its flag settings, by accessing chrome://on-device-internals.

A notable gotcha is that Chrome's internal pages, built from web components with content in shadow DOM, require automation to traverse shadow roots. The model footprint is approximately 4 GB on the test machine, though this size varies with updates. Understanding these aspects is crucial for a comprehensive grasp of Chrome's inner workings and security architecture, extending beyond the browser itself.