Google Chrome Mojo sandbox escape on Windows

Repository contains a real Windows Chromium exploit chain for CVE-2025-2783 rather than a detector. Structure is split into two main parts: demo/exp.html is the browser-side trigger and staging logic, while src/main.cc is the native payload DLL implementing the sandbox escape and post-escape execution flow. The remaining src/minhook/* files are a bundled third-party MinHook library used for runtime API/function detouring. The exploit purpose is to turn renderer code execution into sandbox escape and arbitrary code execution in a more privileged context. According to the README and visible code, the chain works by hooking Chromium/V8 internals, intercepting console.debug to capture an ArrayBuffer containing second-stage shellcode, locating/versioning chrome.dll internals, and abusing the Ipcz relay path to obtain a duplicated high-privilege thread handle. It then suspends and hijacks that thread, modifies execution context, and arranges calls to Windows APIs to allocate memory and execute the supplied shellcode. src/main.cc is the core exploit implementation. It defines an ExploitManager singleton for storing duplicated handles, captured shellcode, chrome.dll section metadata, and version-specific offsets. It includes hardcoded g_node offsets for several Chrome 128 builds, indicating version-sensitive exploitation. The code uses MinHook to dynamically locate and hook internal Chromium functions, including a V8 console debug path used as a covert bridge from JavaScript to native code. DllMain spawns a worker thread (payloadInit), showing the DLL is intended to be loaded into a Chromium process and initialize itself automatically. The demo HTML is not just a benign page; it contains substantial JavaScript exploit logic. From the visible portion, it prepares executable memory, writes staged machine code, fetches windows/shellcode.bin, derives the shellcode address, and triggers console.debug with crafted arguments so the native hook can capture and later execute the shellcode. README also states the demo relies on a V8 type confusion bug to achieve the initial renderer compromise, making this a full-chain browser exploit demonstration. No external C2 or remote infrastructure is embedded beyond local demo hosting and relative payload fetches. The most fingerprintable observables are the local URL http://127.0.0.1:8000/exp.html, the relative artifact paths payload.bin and windows/shellcode.bin/shellcode.bin, the target module chrome.dll, and the spoofed Ipcz relay message ID 0x69. Overall, this is an operational PoC/full-chain exploit repository with a hardcoded shellcode execution path, not a generalized framework module.

Repository contains a real Windows Chromium full-chain exploit for CVE-2025-2783 rather than a detector. Structure is simple: README documents the chain, demo/exp.html provides the browser-side trigger and staging logic, and src/ contains the native payload implemented as a Chromium-linked shared library plus an embedded copy of MinHook for runtime API/function detouring. The BUILD.gn file shows the intended build model: compile main.cc into a shared library named exploit_mojo with dependencies on Chromium ipcz and mojo internals. The main exploit capability is sandbox escape followed by native code execution. According to README and visible code, the DLL initializes from DllMain by spawning a thread, locates chrome.dll, resolves version-specific offsets, and uses MinHook to detour internal Chromium/V8 functionality. One hook targets V8Console::Debug so JavaScript in the demo page can pass an ArrayBuffer containing second-stage shellcode into native code. Another hook targets ipcz relay handling (described as OnAcceptRelayedMessage) to craft a spoofed RelayMessage request and obtain a privileged thread handle from a higher-privileged process. The exploit then performs thread hijacking: suspend thread, alter context, and invoke Windows APIs such as VirtualAlloc, ReadProcessMemory, and CreateThread to stage and run shellcode. The browser-side demo is not just a static page; it contains substantial JavaScript/Wasm exploit logic and explicitly fetches windows/shellcode.bin, computes addresses, writes staged code into RWX memory, and signals the native hook path via console.debug. README states the demo should be served locally with python -m http.server and opened at http://127.0.0.1:8000/exp.html. This makes the attack chain a combination of web/browser delivery and local/native post-exploitation on Windows. Notable fingerprintable artifacts include the local demo URL, the fetched shellcode path windows/shellcode.bin, references to payload.bin and shellcode.bin, the target module chrome.dll, and hardcoded supported Chrome versions in g_node_offset_map. The repository is operational but not broadly weaponized: it includes a working payload path and shellcode execution flow, yet relies on hardcoded offsets, Chromium source-tree integration, and a narrow Windows/Chrome compatibility window.

ChromSploit Framework is a modular, extensible exploitation and research platform focused on browser and server vulnerabilities. It provides operational exploit modules for several high-profile CVEs (including Chrome, Edge, Firefox, Tomcat, and Git), with a strong emphasis on safety: all exploits default to simulation mode, and real exploitation requires explicit authorization. The framework supports multi-stage browser exploit chains, advanced payload obfuscation, automated tunneling (ngrok), and C2 integration (Sliver, Metasploit). It includes a professional reporting system, live monitoring, and evidence collection. The repository is well-structured, with clear separation between core logic, modules, exploits, and documentation. Numerous endpoints are fingerprintable, including local HTTP servers for exploit delivery, OAuth phishing, and data exfiltration. The codebase is primarily Python, with supporting JavaScript, JSP, and shell scripts. This framework is suitable for advanced security research, red teaming, and educational demonstrations, but should only be used in authorized, isolated environments due to the presence of real exploit code (even though simulation is the default).