Lyra runtime

What Lyra plants on the device and the control it provides. Where Zune documents the retail firmware as it shipped, this section documents the layer added on top: how the platform gains kernel access, how it keeps that access across reboots, and the primitives every patched process then shares without a host connection.

How it loads

Initial access comes from CUB3D's zuneslayer exploit. Persistence comes from zuxhook.dll, which the firmware auto-loads from flash during UI bring-up in several processes, making it in effect a boot-applied jailbreak. zuxhook launches the nativeapp daemon, which runs the kernel exploit and stands up the shared runtime. From there the exploit is no longer involved. The platform is self-loading.

Runtime primitives

The pages here document the on-device capability set:

• Kernel memory and function calls from any patched process, in-process, with no IPC or host tether (kerncore).
• Code patching of read-only retail .text, via a page-table permission flip with cache maintenance so a patch takes effect immediately.
• Code injection and execution inside a target process's own context.
• Cross-process memory reaching addresses a plain process handle cannot.
• Physical, MMIO and graphics memory mapping, including framebuffer and AVP carveout, the basis for screen capture, the audio tap, and casting.
• A persistent service runtime hosting loadable plugins and background workers, with on-device file management and memory snapshots.
• Host tooling for driving all of the above over Wi-Fi or a USB tunnel.

The techniques for building user-facing mods on top of these primitives are under Modkit.