When did this happen? A Deep Dive into Android System Integrity, Bootloader States, and Persistent Data Access

We have observed a fascinating and complex scenario circulating within the Android enthusiast community that demands a rigorous technical explanation. The situation involves a Samsung Galaxy S21 FE, powered by the Snapdragon 888 chipset, running One UI 8 based on Android 16. The user, after a history of rooting, transitioned back to a completely stock configuration—unrooted, with a freshly flashed firmware, a locked bootloader, and confirmed Strong Integrity status. Yet, a paradox emerged: the device still allowed direct Read/Write (R&W) access to the /data and /obb directories without the need for Shizuku or ADB shell commands.

This anomaly raises critical questions about the state of Android security, the effectiveness of Verified Boot, and the true meaning of “Strong Integrity” in a post-root environment. When did this happen? It happened at the intersection of complex partition management, residual SELinux contexts, and the often-misunderstood behavior of Android’s file system encryption. In this comprehensive guide, we will dissect every layer of this scenario to provide a definitive answer on why this access persists and what it signifies for the device’s security posture.

Understanding the Android Partition Landscape and Root Modifications

To comprehend why a “clean” installation might still exhibit behaviors associated with a rooted device, we must first analyze the partitions involved. The transition from a rooted to an unrooted state is not merely a software toggle; it is a physical alteration of the memory blocks on the device.

The Role of System, Vendor, and Boot Partitions

When a user roots a Samsung device using Magisk, the process typically involves patching the init_boot or boot image. This image contains the kernel and the initial ramdisk (initramfs). By patching this, we inject the Magisk daemon, which intercepts system calls and mounts system partitions as read-write (RW) even if they are normally mounted as read-only (RO) in a stock environment.

Furthermore, root access often requires disabling or patching vbmeta (Verified Boot metadata) to skip signature verification on the boot and system partitions. This effectively lowers the device’s Verified Boot state to Orange (unlocked), signaling that the device integrity has been compromised. In the user’s scenario, they claim to have a locked bootloader and Strong Integrity. This implies that the vbmeta partition has been flashed back to its stock state (with avb=4 or similar enforced settings) and the boot partition has been replaced with a clean, signed image from the new firmware.

The Persistence of Data and OBB Partitions

The /data and /obb partitions are distinct from the system partitions. They are designed to store user data and application assets, respectively. When a device is rooted, applications or users with root privileges can write to these directories freely. More importantly, if a user has modified the SELinux (Security-Enhanced Linux) policies to Permissive mode—which is common in rooting scenarios—these permissions are not strictly enforced.

The critical question is: When did the transition from Permissive to Enforcing happen? If the firmware flashing process did not fully restore the default SELinux contexts on the /data and /obb partitions, the file system might retain the relaxed security policies from the previous rooted session.

The Paradox of Strong Integrity and Data Access

The user reports meeting Strong Integrity. In the Android ecosystem, particularly with Google Play Integrity API, Strong Integrity is the highest level of assurance. It confirms that the device is running an unmodified Android operating system, has a locked bootloader, and has Google certification.

How Strong Integrity is Verified

Strong Integrity checks several factors:

1. Bootloader State: It must be locked.
2. System Partition: Must be unmodified and signed by the OEM (Samsung).
3. Verified Boot: Must be in a Green state, indicating no tampering.

If the user truly has Strong Integrity, it means the boot partition is clean and verified. However, this verification does not inherently scan the /data partition for permission anomalies. The integrity checks focus on the executable code and the kernel, not necessarily the permission attributes of every file in the user data partition.

The SELinux Context Anomaly

The ability to R/W to /data and /obb without ADB or Shizuku is highly unusual on a stock device. By default, Android uses a strict SELinux Enforcing policy. Even with su (superuser) privileges disabled, the kernel should block direct write access to sensitive directories unless specific file system capabilities are utilized.

If the user can write to these folders, it suggests one of two possibilities:

1. The SELinux policy is still Permissive: Even though the root binary (Magisk) is removed, the kernel command line or the SELinux policy file in the ramdisk might still be configured to ignore enforcement.
2. The Mount Points are Misconfigured: The /data partition might be mounted with incorrect flags, or the user is operating within a shell environment that retains elevated privileges from a previous session (cached credentials).

Decoding the Firmware Flashing Process: Where did it go wrong?

The user mentioned “reflashed new firmware.” This is a standard procedure to restore a Samsung device to stock. We must examine the specific tools and methods used, as these dictate the integrity of the restoration.

Flashing via Odin vs. Soft Reset

When using tools like Odin to flash firmware (BL, AP, CP, CSC files), the process typically wipes and rewrites the system, vendor, boot, and vbmeta partitions. However, the data partition is often preserved unless the user selects “Home_CSC” (which keeps data) instead of “CSC” (which wipes data).

If the user performed a firmware flash but selected “Home_CSC” to preserve their data, the /data partition from the rooted state remains intact. While the system files are replaced, the user data—including residual scripts, binaries, or altered permission attributes—remains. This is a common pitfall. To achieve true stock status, a full wipe (selecting the CSC file) is almost always necessary.

The Bootloader Locking Mechanism

Locking the bootloader (oem unlock disabled) re-enables Verified Boot. However, if the data partition contains keys or metadata that the bootloader does not check, the lock is merely a flag. The device reports Orange or Green based on the vbmeta hash. If the vbmeta partition was flashed correctly with the stock hash, the device will report Green (or Strong Integrity) even if the data partition contains unverified data, because the bootloader does not mount and verify the data partition at boot time in a way that affects the integrity report.

File System Encryption and Metadata Residue

Android uses File-Based Encryption (FBE) and Metadata Encryption to secure user data. When a device is rooted, the encryption keys are stored in the Keymaster module (part of the TrustZone). Root access allows the OS to decrypt files on the fly.

Residual Decryption Keys

If the rooting process involved modifying the keymaster or gatekeeper blobs (which is rare but possible in deep system modifications), it could theoretically leave the device in a state where encryption checks are bypassed locally. However, in the user’s case, they likely did not modify these low-level components.

A more plausible explanation is User Credential Persistence. When a user unlocks a device and uses a root manager (like Magisk), the shell session often retains the uid=0 (root) context. If the user performed a reboot and immediately accessed the file manager before the security daemons fully loaded, or if the file manager app itself was granted permanent root access via a previous profile, the access might appear persistent.

The Role of the “Root” App Profile

Even without Magisk installed, if the user utilized a root explorer app that was granted access during the rooted phase, and if that app stores its own encryption keys or session tokens, it might still function. However, without the Magisk daemon, the app should fail to obtain root privileges.

The user’s claim of accessing data “without Shizuku or ADB” implies they are using a standard UI-based file explorer. This is the most critical clue. On a stock device, a standard file explorer cannot write to /data or /obb. Therefore, the device is likely not in the stock state the user believes it to be, or a system service is misconfigured.

Analyzing the Transition: One UI 7 to One UI 8 (Android 16)

The transition from Android 14 to Android 16 (One UI 8) involves significant changes in the underlying security architecture. Google has progressively tightened security with each iteration.

Android 16 Security Enhancements

Android 16 introduces stricter scoped storage enforcement and enhanced Hardware-Backed Keystore requirements. It is significantly harder for a rooted device to maintain Strong Integrity in Android 16 compared to older versions. If the user updated to One UI 8 while the bootloader was unlocked, the OTA update mechanism would have failed or triggered a factory reset.

The user stated they switched back to unrooted, reflashed, and locked the bootloader. This sequence suggests a clean slate. However, if the firmware they flashed was not the correct region or build number for their specific device variant (e.g., SM-G990B vs. SM-G990U), the vbmeta partition might not match perfectly, potentially causing integrity verification failures. Yet, the user reports Strong Integrity, which is contradictory if the partitions are mismatched.

The “Keep Data” Trap

We suspect the user utilized the “Keep Data” option during the Odin flash or performed a soft reset via settings rather than a full Odin flash. In Android, a factory reset via settings wipes the /data partition but preserves the metadata partition. The metadata partition contains file system formatting information and encryption context.

If the metadata partition was not wiped, the file system might retain the inode structures and extended attributes from the rooted session. These attributes include SELinux contexts. If the context was set to u:object_r:system_data_file:s0 (which is broad) instead of a restricted context, the OS might allow broader access.

Root Cause Analysis: Why can we still R/W?

We have synthesized the technical data to pinpoint the exact cause of the persistent access.

Hypothesis 1: The SELinux Context Mismatch

It is highly probable that the SELinux contexts on the /data and /obb partitions were altered during the rooting process and were not reset during the firmware flash. When a file is created or modified in a Permissive environment, it retains the security context at the time of creation.

If the user flashes the system but does not wipe the data partition, the kernel loads the new system policy (Enforcing), but the existing files on the data partition still possess the old contexts. The kernel checks these contexts. If the old context was permissive or if the file attributes include the CAP_DAC_OVERRIDE capability (which allows bypassing file permission checks), the access persists.

Hypothesis 2: The Superuser Binary Residue

Magisk uses a “stub” APK and a mounted binary. If the uninstallation process was incomplete—perhaps the user manually deleted the Magisk app but left the patched boot image temporarily (before replacing it with stock firmware)—some hooks might remain. However, with a locked bootloader and Strong Integrity, the kernel is verified. This makes a persistent hook unlikely unless the hook was in the data partition (e.g., a sepolicy.rule file).

Magisk allows the installation of “modules” that modify the system. If a module was installed to allow R/W access to specific folders, it might have injected a script into /data/adb. Even after unrooting, if this script is executed by a background service that still has permissions, it could maintain the access.

Hypothesis 3: The “0” UID Anomaly

In Unix-based systems (including Linux and Android), the user ID 0 is the root user. It is possible that the file manager app the user is utilizing was assigned the 0 UID during the rooted session due to a misconfiguration or a specific exploit. While highly unlikely on a patched kernel, if the app is running on a system service that hasn’t been killed or restarted since the unroot process, it might retain that privilege.

How to Truly Restore Stock Integrity

For users facing similar anomalies, we recommend a strict procedure to ensure the device is truly stock. The “When did this happen” question is answered by the moment the data partition was preserved during a reflash.

Step 1: The Full Odin Flash (CSC not Home_CSC)

To eliminate all root remnants, one must flash the firmware using Odin with the CSC file (not Home_CSC). This triggers a complete wipe of the data partition. This ensures that no residual files, SELinux contexts, or cached scripts remain.

Step 2: Verification of Verified Boot State

After flashing and locking the bootloader, we must verify the Verified Boot state via the command line (using ADB):

adb shell getprop ro.boot.verifiedbootstate

Ideally, this should return green. If it returns orange, the vbmeta partition is not correctly signed.

Step 3: Checking SELinux Status

Even with a clean flash, checking SELinux is crucial:

adb shell getenforce

This must return Enforcing. If it returns Permissive, the kernel command line or a persistent rule is overriding the default policy.

Step 4: Testing File Access

To confirm the anomaly is resolved, attempt to write to /data or /obb via ADB:

adb shell touch /data/safe_test_file

If the operation fails with “Permission denied,” the device is stock. If it succeeds, the system is compromised.

Conclusion: The Verdict on the Anomaly

So, when did this happen? The anomaly occurred during the firmware reflash process where the user likely preserved the data partition (/data and /obb). While the system partitions (System, Boot, Vendor) were updated to One UI 8, giving the appearance of a clean device and passing Strong Integrity checks, the underlying file system metadata on the data partition retained the permissions and contexts from the previous rooted session.

The device is effectively a Hybrid State: a verified, locked bootloader executing a stock kernel, but operating on a data partition that has not been sanitized of root-era modifications. This is a rare but documented occurrence in advanced Android modding. To resolve this, a full data wipe via Odin’s CSC flashing is the only solution. The persistence of R/W access is not a ghost in the machine, but a residue of the past, preserved in the magnetic (or flash) memory of the device, waiting for a complete format to be purged.