Android root · kernel research · privileged-device management
_{Evidence first. No guessed kernel writes.}

⬇ Download v2.0.0  •  Release notes  •  Security  •  Research credits

Veyra Root

Veyra Root is an Android root, kernel-research and privileged-device-management project built around one rule:

Exact evidence before kernel writes.

A matching phone name, kernel family or installed root manager is not treated as proof that a payload is safe to run. When exact evidence is missing, Veyra prefers analysis, source cross-checks and support-bundle collection over guessed offsets.

The current public release is Veyra Root v2.0.0.

✦ At a glance

⬇ Public release

Veyra Root v2.0.0 is the current official public build.

The official public APK uses the established Veyra signing identity so compatible earlier official Veyra Root builds can be updated in place.

→ Open the complete v2.0.0 release

✦ What makes Veyra different

Veyra separates what can be observed from what is actually proven runnable.

A device can match a family, architecture or kernel generation without automatically receiving a writable/root payload. Veyra keeps those states distinct:

• Verified runnable — exact evidence is sufficient for the route.
• Compatible / candidate — the device or kernel matches known constraints but still needs validation.
• Analysis-only — Veyra can inspect and export evidence, but refuses to invent missing physical addresses, offsets or payload constants.

That boundary is intentional.

⚡ Root detection & provider awareness

Veyra does not mark a device rooted simply because a manager app exists.

It checks whether Veyra itself can execute as UID 0, then classifies the active route. The app can distinguish:

• Veyra temporary root
• external temporary-root providers
• KernelSU root
• Magisk-style boot root
• other real root providers

External providers can be routed into Veyra's provider-migration flow instead of being silently mislabeled as a Veyra session.

🧠 Magic Builder

Magic Builder is Veyra's kernel/device research layer.

It can:

• capture and parse boot images
• identify ARM64 Android kernel Images from the real Image header
• identify ELF64 / AArch64 kernels
• read the Linux kernel banner independently from kallsyms decoding
• analyze kallsyms and symbol layouts
• generate analysis artifacts such as target.generated.h and offsets.json
• cross-check source-derived evidence
• collect support bundles
• keep runnable output blocked when required evidence is missing

Kernel-family routing

The analysis architecture covers both legacy and modern Android kernel families, including:

• 4.x
• 5.x
• 6.x
• 7.x research routing

A family match is not an automatic exploit match.

Deep diagnostics

Magic Builder exposes dedicated diagnostics for difficult ports:

1. Source Match Matrix — ranks research sources against the current device/kernel.
2. Kernel Gate — shows the exact baseline/family decision.
3. KMI Matrix — compares the device with Veyra's local DF/KMI inventory.
4. Live Symbols — reads selected symbols when the privileged backend permits it.
5. Boot Evidence Report — exports architecture/version evidence from the captured boot image.

🧩 Builder Workingbench

The current Veyra generation consolidates builder workflows into Builder Workingbench while keeping builder-specific settings where they belong.

Current tooling includes:

• resumable builder sessions
• OTA range extraction
• local image/hash comparison
• strategy matrices
• evidence grouping and conflict tracking
• risk modes
• report import/export
• candidate/session export
• Termux helper generation
• automatic dependency checks/preparation
• Android Download output handling with fallback paths
• ADB and Shizuku/rish-aware helper paths

🧬 DF Compatible / Veyra DF+

The DF route uses kernel/KMI evidence instead of blindly following the userspace Android version.

The current architecture includes:

• DF Compatible
• Veyra DF+
• Samsung / DEFEX-aware routing
• OnePlus / Oppo / realme profiles
• generic GKI routing
• installed manager / ksud awareness
• KernelSU-Next package awareness
• kernel-release-first KMI selection
• recovery/runtime controls
• root-on-boot and soft-reboot options where supported
• module-disable controls
• image-partition protection controls

Legacy 4.19 targets such as Kona remain evidence-driven and are not silently promoted into modern GKI routes.

💜 CVeyra Permission Provider 2.0.0

CVeyra is Veyra's privileged action broker and permission-management layer.

The 2.0.0 activation flow verifies:

1. provider information has been read,
2. VeyraKSU 2.0.0 is installed,
3. the required KernelSU soft reboot has completed,
4. the permission bridge is live,
5. Veyra itself has the required root grant,
6. existing direct KernelSU grants are backed up,
7. the CVeyra root broker can be enforced.

After activation, CVeyra Access becomes the always-on privileged broker mode.

Permission Management

Supported state changes are persisted only after the device-side action succeeds. Impossible transitions are refused rather than displayed as successful fake grants.

🛡 Public Release hardening

The public v2 release includes Veyra's dedicated ReleaseGuard layer.

Current checks include:

• official signing-certificate pinning
• package/build identity verification
• real non-debuggable / non-test-only verification
• split/repack detection
• trusted APK source/path checks
• SHA-256 integrity checks for critical APK entries and native libraries
• debugger detection
• TracerPid / tracing checks
• Frida marker detection
• Xposed / LSPosed marker detection
• Substrate marker detection
• LD_PRELOAD checks
• suspicious process-map, thread and file-descriptor checks
• repeated runtime guard/watchdog verification
• backups disabled
• cleartext traffic disabled
• shell profiling disabled

No Android client-side protection is mathematically unbreakable. The goal is to make casual resigning, repacking, asset replacement, binary patching and runtime instrumentation substantially harder without rejecting normal legitimate root use.

See Release protection and Security Policy.

🔄 Mandatory public update channel

The hardened public build uses Veyra's public GitHub update channel.

When the published channel reports a versionCode higher than the installed public build, the update is treated as required. The download path validates:

• package identity
• versionCode
• published APK SHA-256
• Veyra signer identity
• HTTPS transport

Public v2 establishes 200000000 as the current stable public versionCode baseline.

🔌 ADB Manager

The Veyra ADB Manager groups the supported startup paths:

• Start via Wireless Debugging
• Start via USB debugging
• Start via Computer

Wireless ADB retains Veyra's own authenticated pairing/session handling.

🧱 System & recovery tools

Veyra also contains system/recovery utilities, including reversible system-update control through CVeyra.

Veyra remembers only updater components it disabled itself so restoring updates does not blindly re-enable unrelated packages that were already disabled by the user.

./gradlew :app:assembleDebug

./gradlew :app:assembleRelease

🔐 Release authenticity

Official signing-certificate SHA-256:

f1d8f55217d1149f88db9e1642735363d0198c33c8da8d77547987cedf08c582

APK checksums are published with each GitHub release.

The Public-v2 source baseline completed:

796 / 796 unit tests passed — 0 failures · 0 errors · 0 skipped

Veyra Root
_{Control. Understand. Verify. Go further.}