Finding 2026.5Unlock-path and verified-boot assessment of a locked MediaTek tablet, with a privacy-hardened stock configuration

§2026.5(i) Purpose and scope

This finding records an assessment carried out on 23 August 2026 on a OnePlus Pad Go 2 owned by the author, and released here on the date shown above. The original objective was to install a community build of Android on the device. Investigation established that this is not achievable on this hardware, and the objective was changed to a full factory reset followed by a privacy-hardened stock configuration. The finding is of interest less for the device than for the discipline: every property below was read from the device over ADB rather than taken from vendor or forum documentation, an early misidentification was corrected by that habit, and the unlock path was abandoned before any write, flash, or unlock operation was executed. Claim status is MEASURED: these are readings from one physical unit, not a model.

§2026.5(ii) Device identification

An early web search identified the device as OPD2504; the device itself reports OPD2505, which is why the table below is taken from getprop and not from a product page. The unit's serial number is omitted.

§2026.5(iii) Bootloader and verified-boot state

The bootloader is locked and the verified-boot chain is intact:

ro.boot.flash.locked = 1
ro.boot.vbmeta.device_state = locked
ro.boot.verifiedbootstate = green
sys.oem_unlock_allowed = <empty>
ro.oem_unlock_supported = <property does not exist>

On stock Android, enabling the developer toggle for OEM unlocking writes Settings.Global.oem_unlock_allowed = 1. A search of every settings namespace returned no such key at all — not set to zero, simply absent — and ro.oem_unlock_supported does not exist. Together these indicate firmware with no working unlock path, which is a different and stronger statement than a policy that declines to unlock.

§2026.5(iv) Custom-ROM feasibility

Three independent blockers were identified; each alone is sufficient.

The absence of a community build is explained by the SoC vendor and the device's market position rather than by vendor policy: MediaTek platforms are thinly documented relative to Qualcomm, kernel sources for budget tablets are published slowly if at all, and a low-volume, region-specific device released in December 2025 with firmware built in May 2026 attracts few maintainers. The tightened OnePlus unlocking policy introduced with OxygenOS 16 applies, by published accounts, to units sold in China and was not the operative blocker here.

§2026.5(v) Method

The toolchain was obtained from the official distribution rather than a third-party bundle, and its digest recorded: platform-tools-latest-windows.zip, SHA-256 45f4d63113e895ebde0c90f194099a4676b6ac653bd28d54314a9e022bbc1a99, ADB 1.0.41 (37.0.1). Connectivity was diagnosed by inspecting the host's USB enumeration rather than by trial and error:

One firmware-specific detail is worth recording because it defeats the standard instruction: on this OxygenOS build the build number is not on the main About screen but inside the Version card, so tapping it on the About screen does nothing.

§2026.5(vi) Reset and hardened configuration

Before the reset, the device held two Google accounts and one vendor account, each a Factory Reset Protection trigger, together with an authenticator application whose one-time-password seeds are device-local and are destroyed by a reset unless exported; this was flagged and resolved before any reset was performed. Accounts were removed first, and the reset was performed from Settings rather than from recovery, which clears the protection state cleanly. The setup wizard completed without an account challenge. The firmware forced a brief network connection for activation, which is a property of the locked vendor firmware and was recorded as such; sign-in and every optional telemetry toggle were declined.

Post-reset verification read: accounts 0; packages 400 against 431 before the reset; ro.boot.flash.locked still 1; ro.boot.verifiedbootstate still green. A caveat is recorded from the session: an initial account check grepped for authenticator types rather than accounts and appeared to show accounts present; the authoritative reading is the accounts line of dumpsys account.

Two applications were installed over USB, each with its digest recorded: RethinkDNS (com.celzero.bravedns, v0.5.6, arm64-v8a, SHA-256 d68c7e3e57c3fd46e6928d2f9e4308bffc72104fbb930b85b0d082aa1207b143) as a default-deny firewall, and F-Droid (org.fdroid.fdroid, SHA-256 985f5181d48bb6bafd54083a048b391271e0ab28385881cc41294fb01a222762). The VPN permission the firewall requires cannot be granted over ADB; Android mandates an interactive consent dialog.

§2026.5(vii) Debloat plan

Removal uses pm uninstall --user 0, which removes a package for the current user while leaving the APK in the system image; it is reversible with cmd package install-existing, and a factory reset restores everything regardless. The first tier, sixteen telemetry, cloud, and marketing packages, is staged and dry-run verified:

A second tier of twenty-two unused or region-locked packages — payment services, identity services, regional lookups, companion and translation utilities, and factory engineering test tools — is staged but not yet reviewed in detail. Twenty packages are documented explicitly as never to be removed, because on this firmware they carry boot-loop or core-interface breakage risk: the application platform, UI engine, battery and power monitor, customisation core, system-UI plugins, location and its proxy, subsystem service, security guard and permission services, encryption, gesture, and notification manager among them. That list is the difference between a debloat plan and a brick.

The pattern these packages form is worth stating plainly, and stating carefully. A device the user cannot unlock nonetheless requires a network call to activate (§2026.5(vi)), and it ships with an advertising-identifier service (com.oplus.stdid), a behavioural-tracing service (com.oplus.onetrace), and a push-and-telemetry backbone (com.heytap.mcs) that are present with no account signed in and no user activity. What the package inventory does not establish is behaviour: whether any of these transmits identifying data off-device, and to what endpoints, is not measured here, and this finding does not claim it. The RethinkDNS firewall installed in §2026.5(vi) logs per-app DNS and connection attempts, and a device held in exactly this state — no account, no user activity — is a clean setting for that capture, where anything reaching for the network is doing so without a user-facing reason. That analysis is deferred to a traffic-analysis follow-up, and only there, on measured packets, could a claim about transmission be made.

§2026.5(viii) Reading

Nothing in this finding is novel about Android; its value is as a record of practice. State was read from the device, not assumed. An identification error from a secondary source was caught by that habit. A destructive path was abandoned on evidence before the first destructive command, and the fact that no write, flash, or unlock operation was ever executed is stated as a result. Every installed binary carries a digest. The one caveat from the session — a wrong intermediate reading, and the authoritative reading that replaced it — is recorded rather than tidied away. These are the conventions of §1.2 and §1.4 applied to a tablet on a desk, and they are the same conventions under which the measured phase of Chapter 3 will be run.