Project Lyra

Project Lyra or just Lyra exists to document ongoing hardware and firmware reverse-engineering efforts of Microsoft Zune devices, with the data cataloged as reference documentation for developers. The information gathered so far has been used as the foundation of a modkit system for creating, managing and loading community mods.

The modkit utilizes both CUB3D's zuneslayer exploit and the zuxhook.dll loader vulnerability, which together enables early automatic deployment of code on device after boot using a native loader mechanism left behind in the Zune HD firmware in multiple processes (servicesd.exe, gemstone.exe, zie.exe). Because zuxhook.dll is loaded from flash2 storage by design during UI bring-up, it acts effectively as a boot-applied persistent jailbreak. The modkit system brings with it a number of kernel and userspace tools, patching methods, and other mechanisms to have unrestricted access to the device's runtime state, and implements a platform by which multiple mods can coexist and use shared tools and interfaces.

Reverse engineering

Zune hardware falls into two families with shared software lineage. Both carry the gemstone shell and the XUI engine (xuidll) over a Windows CE kernel and a DirectShow media graph, and those components sit in both the 4.5 and the 3.30 firmware images. Each family is a separate build for its own OS and SoC, though, so the shared names do not imply shared behavior, and concrete details frequently do not transfer between families or even between firmware versions. What differs underneath the UI is the CE version, the SoC, and the graphics and audio backends it is drawn and decoded through.

• Zune HD (Pavo, firmware 4.5). The primary target. An NVIDIA Tegra APX 2600 (ARM11 with a GeForce ULP GPU) running Windows CE 6 R3. gemstone.exe drives the main UI, servicesd.exe hosts background services and the HUD, and zie.exe is a Trident-based web browser. XUI draws through zd3d.dll, a Direct3D-Mobile-style API on the Tegra GPU, and compositor.exe composites the result through OpenGL ES.
• Zune Classic (firmware 3.x, Windows CE 5). The pre-HD line: the Zune 30 (Keel), the second-generation HDD Zune 80/120 (Draco), and the second-generation flash Zune 4/8/16 (Scorpius). The Zune 30 is a Freescale i.MX31 paired with an Atlas PMIC. The gemstone/xuidll engine runs here as a distinct CE 5 build, drawn through DirectDraw over the i.MX image processing unit and its display controller rather than a 3D GPU, hosted by CE 5's gwes.exe, and with no web browser.

The same subsystem is frequently a different module or process across the two:

Subsystem	Zune HD (Pavo, CE 6, device-verified)	Zune Classic (Keel, CE 5, static RE)
SoC	NVIDIA Tegra APX 2600	Freescale i.MX31 + Atlas PMIC
UI shell and engine	gemstone.exe + xuidll.dll	gemstone.exe + xuidll.dll (separate CE 5 build)
UI rendering	zd3d.dll (3D), composited via OpenGL ES in compositor.exe	DirectDraw (ddraw.dll, ddraw_ipu_sdc.dll) over the i.MX IPU, via gwes.exe
Audio and video decode	DirectShow graph, but decode runs on the Tegra AVP coprocessor (nvmm_aacdec.axf, nvmm_h264dec.axf)	DirectShow graph with software DMO codecs (wmadmod, mp3_dec_dmo, aac_dec_dmo, wmvdmod); i.MX VPU filter (mx32_vpu_dec_dshow) for hardware video
User-mode driver host	udevice.exe (CE 6 reflector)	device.exe (CE 5 device manager)
Web browser	zie.exe (Trident/OLE)	none

Coverage is uneven currently. A large fraction of the 4.5 Zune HD firmware is documented and tested on-device with live instrumentation: kernel read/write, arbitrary function calls, breakpoints, and memory snapshots. Of the classic devices, only the Zune 30 (firmware 3.30, build 03.30.00039.00-00435, frozen January 2010) has been examined in any depth, and mostly through static analysis of its extracted firmware image, with minimal live runtime instrumentation. The Zune Classic column above is speculative: its modules are named as they sit in the image, but their live behavior (which decoder the playback graph selects, hardware VPU versus software, whether a given module is even on the active path) is inferred. The Draco and Scorpius share the 3.x base but have not been analyzed on their own. This wiki provides an index of reference material organized by architectural components and research paths I've gone down while trying to implement certain features or mod capabilities. How each finding was obtained is given wherever possible, and anything not proven on-device is marked as such.

Runtime capabilities

On top of a kernel read/write/call primitive, Lyra builds an on-device runtime that every patched process shares without a tethered host:

• Kernel memory and function calls from any process. Kernel-mode read, write, and arbitrary kernel function calls (kerncore), usable in-process from servicesd, gemstone, and zie with no IPC or host connection.
• Read-only code patching. A page-table AP-bit flip makes retail .text writable to install inline hooks and detours, with cache maintenance so a patch takes effect immediately.
• Code injection and execution. Stage shellcode into any process and run it in that process's own context, returning its result.
• Cross-process memory. Per-process, per-slot reads via MapPtrToProcess reach memory a plain process handle cannot, such as another process's loaded module image.
• Physical, MMIO, and graphics memory. Map any physical address or allocate NvRM carveout memory (framebuffer, AVP audio ring, SoC registers), the basis for screen capture, the audio tap, and casting.
• A persistent service runtime. A watchdog-managed daemon hosts loadable DLL plugins and background workers, with on-device file management and kernel-VA-to-flash memory snapshots.
• Runtime UI extension. Register new XUI classes and inject scenes, menu entries, and status icons, and deliver cross-process state events into the shell's message loop.
• Live debugging. Attach to processes, read thread registers, and set breakpoints for on-device stack walks.

Modkit

The modkit is a framework and management system for creating, publishing, installing, and running mods that coexist rather than contend for the same patches.

A mod can:

• add native scenes and interfaces built from the device's own XUI engine,
• share menus, components, and navigation so multiple mods compose into one interface (quick-toggle menu, hud icons, start menu),
• extend, patch, reroute or disable existing device features and capabilities, and
• be installed, enabled, and managed from a single on-device system.

Install mechanics are layered: custom scenes, menu entries, C++ class registration, and boot-time persistence, driven by an on-device runtime that reads each mod's manifest and applies its capabilities. Lyra installs a "mods" entry which appears in the Start menu, from where mods can be managed with per-mod enable state that survives reboots. A browsable repository lets mods be downloaded, installed, and managed from the Zune directly, without an external device.

Lyra itself installs the same way. A Zune HD on Wi-Fi can install it from its own browser with no PC, no MTP and no XNA runtime, and a PC package is there for a device that cannot reach the network.

Mods build against a published SDK rather than against Lyra's internals. Two files give a mod shared state, status publishing, the device's own picker UI, and kernel access, each by name. A mod keeps the knowledge that makes it a mod, such as the addresses it patches and the registers it drives. How Lyra reaches the kernel and where it keeps its state stay Lyra's, so they can change without breaking anything built on them.

Mods are also allowed to fail. A capability that faults while applying is caught, the rest of that mod is dropped, and the mod manager says which one failed. If a boot never reaches the shell, the next one applies less: platform components only, then nothing at all, so a mod that wedges the device does not require a reflash to recover from.

Why Lyra?

The Zune codename constellations, with Lyra among them.

Zune hardware carried development codenames from constellations rooted loosely in Greek mythology: Pavo (Zune HD), Draco (Second-gen HDD), Scorpius (Second-gen flash), and Keel (Carina) (Zune 30).

The constellation Lyra represents the lyre of the bard Orpheus. When his wife Eurydice died, he was determined to carry it down into the underworld and play before Hades and Persephone to get her back. They were so moved by his song that they relented and agreed to let her return, under the condition that he not turn around as he left.

Project Lyra intends to be an instrument by which Zunes can earn their own second chance at life. And unlike Orpheus, I plan to keep looking ahead.