The Technical Architecture of DarkSword
What makes DarkSword particularly dangerous is its departure from traditional iOS exploitation paradigms. Standard exploit kits historically deployed compiled Mach-O binaries to execute post-compromise tasks, which are increasingly intercepted by modern platform security mechanisms. In contrast, the DarkSword exploit kit performs its entire attack sequence, from initial rendering compromise to local privilege escalation, entirely in-memory using highly optimized JavaScript payloads.
By forcing the iOS WebKit engine to repeatedly run malicious scripts, the exploit constructs stable read and write primitives directly within the browser process. From this initial foothold, the kit progressively compromises lower-level operating system daemons, ultimately escalating privileges to the kernel level. Because no unsigned executable files are written to the disk, legacy mobile security agents often fail to detect the execution of these implants.
The Multi-Stage Technical Attack Chain
Analyzing the leaked source code files, which include core scripts like index.html, rce_loader.js, and pe_main.js, reveals a systematic, four-stage exploit execution pipeline designed to dismantle iOS security controls.
Stage 1: Initial Access and Browser Redirection
The compromise begins when a target visits a compromised legitimate watering-hole website or clicks a link delivered via targeted messaging lures. To guarantee that the exploit runs in the optimal environment, the decoy landing page initiates a protocol redirect. If the user accesses the page using an alternative mobile browser, the page utilizes the x-safari-https handler to force Safari to open the target URL, ensuring WebKit handles the rendering process.
Once loaded inside Safari, the landing page executes profiling scripts contained in index.html and frame.html. These scripts fingerprint the device by checking user-agent strings, canvas rendering behavior, and specific JavaScript engine offsets. If the device matches the targeted iOS version configurations, the main orchestrator, rce_loader.js, is silently retrieved and executed.
Stage 2: WebContent Exploitation and Pointer Authentication Bypass
The exploit kit achieves initial Remote Code Execution (RCE) inside Safari’s tightly restricted WebContent renderer process (com.apple.WebKit.WebContent) by exploiting highly specific memory corruption flaws. Depending on the targeted version of iOS, the framework runs specialized worker threads:
For systems running iOS versions prior to 18.6, the kit invokes rce_worker.js to exploit a JavaScriptCore optimization type-confusion bug.
For systems running iOS versions 18.6 through 18.7, the exploit utilizes rce_worker_18.6.js to target a Use-After-Free garbage collection vulnerability within the Data Flow Graph (DFG) Just-In-Time (JIT) compilation layer.
To turn this browser-level crash into stable execution, the framework chains these RCE exploits with a Pointer Authentication Code (PAC) bypass. By exploiting flaws in the dynamic linker (dyld), the JavaScript payload establishes arbitrary memory read and write capabilities, effectively rendering hardware-enforced pointer signing protections inert in user-space.
Stage 3: Multi-Process Sandbox Escape and Kernel Escalation
With RCE established in Safari, the framework must escape the browser sandbox to access sensitive system databases. The exploit chain accomplishes this through consecutive hops across different security boundaries:
WebContent to GPU Process: The script sbx0_main_18.4.js exploits a memory corruption vulnerability within the ANGLE/WebGL components to escape the WebContent process and execute instructions inside the GPU process.
GPU to Daemon Process: From the GPU process, the exploit invokes sbx1_main.js, targeting memory-locking vulnerabilities in low-level graphics drivers. This allows the attacker to execute arbitrary code within the context of the highly privileged mediaplaybackd system daemon.
Kernel Privilege Escalation: Acting from within the daemon, the payload triggers a race condition in the Virtual File System (VFS) layer of the XNU kernel. This final exploit gives the attacker full read and write capabilities over the entire system memory, completely neutralizing the sandbox architecture.
Stage 4: Post-Exploitation Execution and In-Memory Implants
Once kernel read and write access is obtained, the script pe_main.js initiates the payload deployment phase. To bypass advanced memory protections such as Page Protection Layer (PPL), the exploit programmatically injects the legitimate system JavaScriptCore framework into critical system daemons, including configd, wifid, securityd, and SpringBoard. Malicious modules are then parsed and executed inside these trusted processes, completely in-memory, to commence background data harvesting.