How to Inspect Factory Reset Protection and OEM Unlock State on Android Using ADB dumpsys persistent_data_block

In the Android security model, protecting hardware against unauthorized wiping and theft requires hardware-backed state retention that survives recovery wipes and factory resets. The Persistent Data Block (PDB) serves this purpose, utilizing a dedicated, isolated flash partition (often mapped as /dev/block/by-name/frp or persistent). This partition stores Factory Reset Protection (FRP) cryptographic tokens, enterprise device enrollment payloads, and the critical OEM unlock enablement flag that permits bootloader unlocking. Using the Android Debug Bridge (ADB), system administrators and security researchers can query dumpsys persistent_data_block to audit the device’s persistent security posture.

Understanding the Persistent Data Block and FRP Mechanics

When an Android smartphone is provisioned, the operating system creates an encrypted boundary on flash memory that standard recovery mode or user-initiated factory reset routines cannot erase:

• Factory Reset Protection (FRP): When a Google account is added to the device, FRP activates. Cryptographic hashes of the authenticated account and lockscreen credentials are written to the persistent data block. If an unauthorized actor wipes the device via hardware keys in recovery mode, the setup wizard detects the persistent FRP digest and demands previous Google account authentication before granting access.
• OEM Bootloader Unlock Bit: In Developer Options, the “OEM unlocking” toggle writes a specific flag to the persistent data block. The device bootloader checks this byte offset during fastboot flashing unlock or fastboot oem unlock routines. If the bit is set to 0, the bootloader aborts any unlock attempt to prevent kernel tampering.
• Enterprise Zero-Touch Enrollment: Corporate enterprise mobility management (EMM) systems write DPC (Device Policy Controller) enrollment credentials into the block to enforce re-enrollment even after hard resets.

Connecting via ADB and Querying persistent_data_block

To inspect the persistent data block state, enable USB Debugging on the device and establish an authenticated ADB connection:

# Verify device connectivity and authorization
adb devices

# Execute the persistent_data_block service dump
adb shell dumpsys persistent_data_block

The command returns hardware partition attributes, operational flags, and block allocation metadata.

Inspecting OEM Unlock State and Permitted Actions

One of the primary diagnostics exposed by the service is whether the OEM unlock switch is active and allowed by device policy:

# Query specific OEM unlock and persistent partition status
adb shell dumpsys persistent_data_block | grep -i -E "oem|unlock|allowed"

The output reports key attributes:

• OEM Unlock Enabled: Indicates whether the user has toggled “OEM unlocking” inside Developer Options (true or false). If false, the bootloader rejects fastboot unlock requests.
• OemUnlockAllowedByDevicePolicy: In enterprise-managed devices (Android Enterprise Work Profile or Fully Managed), corporate EMM policies can programmatically lock the OEM toggle to prevent employees from compromising Knox or hardware keystores.
• OemUnlockAllowedByUser: Indicates whether the local user has permission to modify the toggle.

To verify the bootloader unlock state directly via ADB shell without entering fastboot mode, compare the service dump against getprop values:

# Check system properties relating to OEM unlock and Knox/VBMeta
adb shell getprop sys.oem_unlock_allowed
adb shell getprop ro.boot.flash.locked

Auditing Data Block Size and Allocation Limits

The persistent data block has strict hardware boundaries defined by the device partition table (typically between 100 KB and 512 KB):

# Inspect block capacity and partition paths
adb shell dumpsys persistent_data_block | grep -i -E "size|path|partition"

The service output exposes:

• Partition Path: Displays the underlying block device node (e.g., /dev/block/platform/bootdevice/by-name/frp or /dev/block/by-name/persistent).
• Maximum Data Block Size: The total raw capacity allocated to the FRP/PDB partition (e.g., 102400 bytes).
• Data Block Size: The active byte count currently occupied by stored credentials, token hashes, and MDM markers.

Inspecting FRP Lock Activation States

To determine if FRP is currently armed and will enforce account challenge upon a factory reset, check the service status flags:

# Check active digest and lock status
adb shell dumpsys persistent_data_block | grep -i -A 5 "digest"

If a SHA-256 or HMAC digest is listed alongside a positive data block size, FRP is actively armed. If the data block size reads 0 or indicates unprovisioned status, the device has no active accounts tied to factory reset protection, allowing clean re-imaging without lockout.

Managing OEM Unlock via ADB in Provisioning Workflows

During automated enterprise provisioning or testing lab management, administrators with elevated system privileges can toggle or verify unlock capabilities:

# Test whether the device allows setting the OEM unlock flag
adb shell cmd persistent_data_block get-oem-unlock-allowed

# Query whether the hardware partition has been written
adb shell cmd persistent_data_block has-frp-credential-handle

If an organization requires clearing the FRP partition prior to recycling a decommissioned enterprise device, removing all Google and corporate accounts through the Android Settings menu prompts the OS to zero out the persistent data block securely.

Auditing the Persistent Data Block via adb shell dumpsys persistent_data_block guarantees complete visibility into device ownership state, bootloader unlocking readiness, and tamper-resistant hardware protections.