Mura Flash

Host-side inspection and installation tooling for Mura target headsets.

Version 0 remains inspection-only. Version 1 adds typed target records and machine-executable procedure graphs shared by Python and JavaScript. Procedures can be planned and deterministically replayed, but all current state-changing operations remain test-only, unqualified, and disabled.

Version 1 also adds the exploit-capability layer: exploit-agnostic records declaring the primitives a privilege chain grants (kernel memory access, credential patching, raw partition reads), the provider chain that grants them, pinned artifacts, kernel constants, the validation model, and known traps. A different exploit family is a new capability record, not a new vocabulary. Procedures compose capabilities by pinned reference (path plus SHA-256, target binding verified at load). The first fully-declared capability is pfdm-dirtyfrag-root (DirtyFrag page-cache poison chain, owner-executed on one retail unit), composed by the play-for-dream-mr-mrd3a0-oem-unlock procedure together with the generic android-pdb.oem-allow-set (AOSP persistent-data- block digest model) and qualcomm.flashing-unlock registry operations. Plans mark per-boot states as invalidated at reboot steps. Capability records ship disabled like every other procedure; the live write boundary remains policy- gated.

Run

nix run git+https://git.mura.dev/mura-os/mura-flash.git
nix run git+https://git.mura.dev/mura-os/mura-flash.git -- targets
nix run git+https://git.mura.dev/mura-os/mura-flash.git -- capabilities
nix run git+https://git.mura.dev/mura-os/mura-flash.git -- show-capability pfdm-dirtyfrag-root
nix run git+https://git.mura.dev/mura-os/mura-flash.git -- procedures
nix run git+https://git.mura.dev/mura-os/mura-flash.git -- plan \
  samsung-galaxy-xr-ayke-to-ayia-rollback-unlock \
  --flow simulation-only-unqualified-ayke-rollback-unlock-disabled-plan
nix run git+https://git.mura.dev/mura-os/mura-flash.git -- replay \
  samsung-galaxy-xr-ayke-to-ayia-rollback-unlock \
  --scenario replay/scenarios/samsung/samsung-ayke-rollback-unverified.json

The first public revision remains available by commit:

nix run git+https://git.mura.dev/mura-os/mura-flash.git/<commit>

Develop

Clone recursively because the browser fastboot transport is pinned as a submodule:

git clone --recursive https://git.mura.dev/mura-os/mura-flash.git
cd mura-flash
nix develop

The Python CLI is managed with uv. The browser library is strict TypeScript compiled by Rollup into committed ESM files under dist/.

uv run pytest
npm test
npm run build
python tools/check_replay_parity.py
nix flake check

Inspection recipes under recipes/targets/ and executable procedure graphs under recipes/procedures/ are consumed by both implementations. The machine-readable contracts under contracts/ define stable IDs, limits, error codes, operation semantics, CLI grammar, and the JavaScript export surface. Target records, evidence manifests, shared record schemas, and replay scenarios live under catalog/, evidence/, records/, and replay/.

On-device lifecycle join

The host contracts in contracts/{v1,procedure-v1}.json, their schemas, the target-record schema and the backup/transcript schemas join to Mura's specs/boot-update-recovery.md vocabulary at the documentation boundary: target lifecycle facts, compatible image sets, update/boot-health state, recovery capability, USB lifecycle facts, protected-state roles and same-unit binding. Unknown or mismatched facts remain disabled before an adapter runs. These references add no procedure recipe, target qualification, restore authority or write authorization, and do not choose the administrator's trust, source, recovery or USB-function policy.

Safety boundary

Recipes are research evidence, not hardware qualification. Every shipped procedure is test-only, unqualified, and write-disabled. Destructive flows can only be simulated; live policy refusal occurs before an adapter is created. Device inspection is restricted to compiled-in read-only probes.

The Galaxy XR procedure pins the authenticated TXV AYIA factory donor, exact member inventory, PIT-protected state classes and offline boot/LP/AVB findings. It preserves the unproven AYKE (U1) to AYIA (U1) rollback shape as disabled plan data, but execution stops at an evidence gate before any write. Launch unlock eligibility remains community-reported and requires independent post-reboot lock-state observation. Download transport, accepted custom-image signing, the public Kubuntu write set, duplicate state backup, thermal safety and stock restore are not invented. U2 and later builds refuse the U1 rollback without executing writes.