Apple platform security research

GLx Research Platform.

Run the firmware. Follow the execution. Understand the crash.

A controlled environment for investigating SPTM, TXM, the Secure Kernel, and Exclaves—with live debugging, recorded execution, and the memory evidence to connect them.

Request a demo Watch TXM boot

Built and used by Antid0te researchers/Commercial licensing available

GLx RUNNER IN ACTIONmacOS 26.2 · FOUR GUEST CPUs

GLx Runner · XRT LauncherRECORDED BOOT

Actual Exclaves boot · playback slowedComplete boot log ↗

The platform

Three tools.
One investigation.

Move from a live firmware experiment to the exact state and execution history that explain its result.

01 / EXECUTE↗

GLx Runner

Boot real firmware, select guest CPUs, attach your debugger, and drive repeatable experiments.

Control the target →

02 / INVESTIGATE↗

SK Core Explorer

Navigate saved SK and Exclave memory, inspect a crash in context, and export a core for LLDB.

Explore the evidence →

03 / REPLAY↗

GLx Trace Explorer

Walk recorded instructions forward or backward, compare registers, and follow control flow across CPUs.

Follow the execution →

01 / GLx Runner

Your experiment.
Your stopping point.

Run Apple security components under Hypervisor.framework with the visibility and control needed for low-level research.

Make it your own with plugins →

START A DEBUGGING SESSION zsh

$ ./runner --version 18pro --cl4 \
    --max-cpus 6 --gdb 1234 --gdb-wait

GL2SPTM

GL0TXM

GL1Secure Kernel

GL0Exclaves

Firmware profiles · selected CPUs · debugger attachment

Multicore bring-up

Select the CPU count supported by the firmware and inspect distinct CPU contexts through coordinated all-stop debugging.

GDB & LLDB

Use software and hardware breakpoints, watchpoints, single-step, physical memory access, and system-register inspection.

Firmware profiles

Keep target-specific offsets and capabilities in loadable profiles. Add supported versions without rebuilding the core runner.

Native guarded execution

Use the native VMApple/ISA4 path on qualified hardware and firmware, alongside the instrumented research environment.

Software MTE

Track allocation and pointer tags, detect invalid tagged accesses, and retain fault-time evidence for the core explorer.

Research automation

Drive component interfaces, collect coverage, schedule controlled interleavings, and build focused fuzzing or validation harnesses.

Run the firmware

Watch TXM
come to life.

Start the iPhone Duo Trusted Execution Monitor on four guest CPUs. Follow the complete console output, from the selected firmware profile through TXM initialization and secondary CPU bring-up.

$ ./runner --version duo --txm-only --max-cpus 4

GLx Runner · TXM-only bootDownload video ↓

Every log line · playback slowed for readabilityComplete log ↗ · Original-speed recording ↗

Live debugging

Watch a real
LLDB session.

Connect to an iPhone Duo TXM guest, stop during four-CPU bring-up, step an instruction, switch CPU contexts, and inspect registers, memory, and code.

LLDB · Four-CPU TXM debuggingDownload video ↓

Recorded from a real debugging sessionCommands and transcript ↗

02 / SK Core Explorer

A crash is more than
a fault address.

Keep the instruction, register values, memory mappings, object metadata, allocator state, and original panic report within reach.

SK Core Explorer · StatsServer parser demoDownload video ↓

Artificial parser bug · real Exclave, allocator, and panicTour transcript ↗ · Original panic ↗

StatsServer's recovered virtual page-table mappings, physical addresses, GL0 and GL1 permissions, and captured allocation bytes. — The Exclave address-space overviewVirtual mappings, physical backing, permissions, and four recovered thread states.

The MTE tag map around the artificial StatsServer parser overflow, with the original fault-time context selected. — Synthetic StatsServer MTE demonstrationCaptured evidence, with fault-time and later observations kept distinct.

Explore every address space

Inspect SK and Exclave mappings, GL0/GL1 permissions, physical backing, CNodes, capabilities, and saved thread contexts.

Understand the allocation

Follow xzone or MFM metadata, allocation boundaries, neighboring slots, and MTE tags around the recorded access. View the allocation ↗

Take the evidence with you

Export LLDB-loadable Mach-O cores. Inspect captured code or restore original bytes where the patch journal proves the change. View code and registers ↗

03 / GLx Trace Explorer

Go back to the instruction
that mattered.

Inspect what the guest recorded, with the relevant code and register state visible together. Step through a short window or navigate a complete bring-up trace.

GLX Trace Explorer displaying an actual TXM instruction trace, source context, CPU selection, and registers. — Complete TXM bring-up captureInstruction outcomes, source/runtime words, and per-CPU register changes.

Navigate execution

Move forward or backward, jump to a sequence, filter by CPU or module, and find the previous or next execution of a PC.

Keep context attached

Examine general, vector, and system registers. Optional recorded stack bytes and frame-pointer backtraces add context where available.

Know what was recorded

Distinguish native execution, modeled instructions, exceptions, host traps, and gaps. Large traces use mapped files and bounded views.

Coverage & existing tools

See which paths
your inputs reached.

Collect basic-block coverage and export drcov data for Lighthouse. Compare runs in IDA Pro or Binary Ninja, then use GLx to investigate the paths that remain unexplored.

Real GLx drcov coverage loaded into Lighthouse inside IDA Pro. — Works with your analysis workflowCoverage shown in IDA Pro with the independent Lighthouse plugin.

C & Python plugins

Turn a question
into an experiment.

Observe lifecycle events, inspect live registers and memory, call component interfaces, and export your own evidence. Start with a small Python observer or build a native C plugin.

Download this example ↓

address_space_observer.pyPYTHON PLUGIN

import runner

PLUGIN = {
    "name": "address-space-observer",
    "version": "1.0",
}

def on_exclave_entry(vcpu):
    rc, space = runner.cl4_current_exclave(vcpu)
    if rc != 0:
        return

    runner.log(
        f"{space['address_space']} "
        f"pc={space['entry']:#x} "
        f"ttbr0={space['ttbr0']:#x}\n"
    )

Model Context Protocol

Give your research
tools a live target.

Connect an MCP client or coding agent to GLx Runner over stdio. Start isolated runner sessions, inspect guest state, set breakpoints, step execution, and collect coverage through structured tool calls.

The server works with any compatible MCP client. Each managed run has its own process, debugger connection, and log.

Download the working MCP example ↓

mcp_debug_session.pyMCP CLIENT

started = result_value(await session.call_tool(
    "run_start", {
        "version": "27",
        "gdb_wait": True,
        "extra_args": [
            "--version", "duo", "--txm-only",
            "--max-cpus", "4",
        ],
    }
))
run_id = started["run_id"]
registers = await session.call_tool(
    "get_regs", {"run_id": run_id}
)
await session.call_tool("step", {"run_id": run_id})
await session.call_tool("run_kill", {"run_id": run_id})

Get started

Bring your research
to the platform.

GLx Research Platform is available for commercial licensing and is used in Antid0te’s SPTM, TXM, SK, and Exclaves training. Tell us which devices, firmware versions, and workflows you want to investigate.

Request a demo →Contact us