Telegram

FAILING ALL INTEGRITY

Failing all integrity

Understanding Play Integrity and the Challenge of Modern Attestation

We operate in an environment where digital integrity is the cornerstone of trust for applications and services, particularly within the Android ecosystem. The Play Integrity API has become the gold standard for developers to verify that requests originate from genuine, unmodified applications running on untrusted, clean devices. When a user reports failing all integrity, it signifies a complete breakdown in this trust chain, where the Play Integrity API returns verdicts indicating compromised software or hardware. This is not merely a technical inconvenience; it is a fundamental barrier to accessing high-value services, including banking applications, streaming platforms, and competitive online games.

The core of the issue often lies in the detection mechanisms employed by Google’s attestation servers. These servers analyze a multitude of signals to determine the device’s state. A clean device, running stock firmware with an unlocked bootloader but relocking it, passes the MEETS_DEVICE_INTEGRITY and MEETS_BASIC_INTEGRITY checks. However, when users engage in root access via Magisk, utilize custom kernels like KernelSU with specific hardening features, or employ modules designed to mask modifications, the attestation landscape shifts dramatically. The device begins to emit signals of compromise. Failing all integrity checks—meaning the return of an empty verdict or specific failure reasons like MANUALLY_ROOTED or MEETS_VIRTUAL_INTEGRITY—indicates that the detection algorithms have successfully identified the system alterations.

We understand that users in the Magisk Modules community, such as the one utilizing KernelSU with a KernelSU SusFS kernel, are seeking stability and functionality while maintaining access to integrity-dependent apps. The transition from simply rooting to managing a sophisticated stack of integrity modules creates a complex system of hooks and overrides. When this system fails, it is rarely due to a single factor. It is typically a cumulative effect of kernel-level visibility, system property leaks, and application-level detection routines. The goal of this article is to dissect the anatomy of a total integrity failure, analyze the specific roles of tools like KernelSU and SusFS, and explore the architectural limitations of current bypass methods.

The Mechanics of Play Integrity Verdicts

To address failing all integrity, we must first understand what the Play Integrity API actually returns. It does not simply issue a binary pass or fail. It provides a structured payload containing specific verdicts:

  1. MEETS_DEVICE_INTEGRITY: This verdict confirms that the device’s software and hardware have not been tampered with. It is the highest level of trust. Failing this usually indicates a bootloader unlock, a custom ROM, or the presence of root.
  2. MEETS_BASIC_INTEGRITY: This indicates that the device passes basic integrity checks but may not meet the stricter device integrity standards (e.g., an unlocked bootloader on a stock ROM).
  3. MEETS_VIRTUAL_INTEGRITY: This is often a soft fail or a specific category for emulators or compromised environments.

When users report failing all integrity, they are seeing an empty device integrity verdict. This suggests that the attestation server detects a state that is too anomalous to grant any level of trust. We have observed that this is particularly common with modified kernels. A kernel like KernelSU SusFS introduces a layer of file system hiding and hook protection. While effective at hiding files and processes from the user space, these modifications leave architectural footprints in the kernel space that advanced integrity checks can probe. The SusFS module, designed to hide specific directories and mounts, can inadvertently alter the behavior of standard system calls in ways that differ from the stock kernel, creating a detectable anomaly.

Analyzing the KernelSU SusFS Configuration

The specific scenario involving KernelSU with a SusFS kernel represents a cutting-edge but risky configuration in the world of Android modification. KernelSU differs from traditional Magisk root because it operates directly within the kernel, providing a unique method of superuser access. The SusFS component is a kernel patch set specifically designed to hide the existence of the root environment by intercepting file system operations.

We find that the combination of these tools creates a unique set of challenges for integrity. While SusFS hides files and directories effectively, the Play Integrity API performs a deep scan of the system partition, boot image, and running kernel. The presence of the SusFS patch, which alters kernel behavior, can trigger the MANUALLY_ROOTED verdict. This is because the attestation server performs a checksum comparison of the kernel image against known stock hashes. If the kernel image differs, which it must to include SusFS, the device fails the device integrity check immediately.

Furthermore, the interaction between Magisk modules and a KernelSU environment can lead to conflicts. Users often install Magisk modules recommended for Play Integrity (such as Zygisk, Play Integrity Fix, or Shamiko) on top of KernelSU. While compatibility exists, the layering of these modifications increases the surface area for detection. A Magisk module might attempt to patch a system property that the KernelSU kernel is simultaneously trying to hide, resulting in a race condition or a visible artifact that the integrity app can read.

The Role of Kernel-Level Hiding in Integrity Failure

The kernel is the bridge between hardware and software. When we modify the kernel to include SusFS, we are altering the fundamental logic of how the operating system views files and processes. The Play Integrity API, however, does not just look at what the kernel reports; it looks at the kernel itself.

We observe that kernel-level hiding mechanisms often fail integrity because:

For a user running the latest SusFS kernel, failing all integrity is often a direct result of the kernel’s nature. The attestation server sees a kernel that is not recognized as genuine, leading to an immediate downgrade of the integrity score to zero.

Magisk Modules and the Integrity Ecosystem

The Magisk Modules repository is a rich resource for tools designed to manage integrity. However, the prompt mentions having “every module that is recommended for play integrity.” This approach, while seemingly thorough, can be counterproductive. When multiple modules attempt to modify the same system properties or execute conflicting scripts during boot, the result is often an unstable environment.

We analyze the common modules used for this purpose:

While these modules are powerful, they are not silver bullets. If the underlying kernel (KernelSU SusFS) is leaking information, no amount of user-space spoofing can fully mask it. We see users stacking these modules, hoping for a cumulative effect. However, in practice, this increases the complexity of the system. If the SusFS kernel hides the Magisk mount points, but the Play Integrity Fix module fails to inject its properties correctly because of a mount conflict, the integrity check will fall back to the raw system state—which is modified—and fail.

The Conflict Between Hiding and Spoofing

There is a fundamental tension between hiding modifications and spoofing certifications. Hiding (via SusFS or Shamiko) tries to make the system look “vanilla” to file system scans. Spoofing (via PIF) tries to make the system look “certified” by providing valid hardware and software descriptors to the API.

We argue that failing all integrity often stems from a mismatch between these two layers. For example:

  1. The SusFS kernel hides the /data/adb folder where Magisk and its modules reside.
  2. The Play Integrity Fix module generates a fingerprint file that the integrity app must read to function.
  3. If the SusFS hiding logic is too aggressive and hides the fingerprint file from the integrity app’s user space, the app cannot read the spoofed data.
  4. The app then defaults to reading the actual device properties, sees a modified kernel, and returns a failure.

This chain reaction explains why users with comprehensive module setups still fail. The visibility of the kernel modification overrides the user-space spoofing attempts.

Troubleshooting Total Integrity Failure

When we approach a case of failing all integrity, we must move beyond simply adding more modules. The diagnosis requires a systematic reduction of variables. The user report mentions being “on ksun with a ksun susfs kernel.” This is the primary suspect.

Step 1: Isolate the Kernel

The most aggressive integrity checks validate the kernel signature and structure. To confirm this is the issue, we must test the device with a stock kernel (if available) or a standard KernelSU kernel without SusFS patches.

Step 2: Analyze Magisk Module Interactions

If the kernel is not the sole issue, the module stack is the next variable. We recommend a “clean room” approach.

Step 3: Verify Play Integrity Fix Configuration

The efficacy of PIF relies heavily on the quality of the fingerprint used.

Deep Dive into Attestation Architecture

To truly understand why we are failing all integrity, we must look at the attestation architecture. Google Play Protect uses a remote server to verify the integrity tokens. The process involves the device generating a nonce (a random number), the device signing this nonce with its device-specific keys, and the server verifying the signature.

In a compromised environment, the device keys are often untrusted because the bootloader was unlocked. This is where Key Attestation comes into play. When we root a device, we lose the chain of trust for the hardware-backed keys.

However, tools like Magisk and KernelSU attempt to intercept this signing process or spoof the results. When we see a total failure, it means the interception failed. The attestation request likely bypassed the hooks entirely or the server detected the spoofing attempt.

We must also consider the role of the Clearcut interface. This is the backend service that receives the integrity data. Google updates Clearcut’s detection logic frequently. A method that worked yesterday (e.g., a specific PIF fingerprint) may be flagged today. This leads to the “cat and mouse” game. If the user is failing all integrity, it is highly likely that the specific fingerprint or spoofing method they are using has been blacklisted by Clearcut.

The Impact of SusFS on Systemless Modifications

SusFS is a powerful tool for hiding systemless modifications. It works by creating virtual mount points that overlay the real system files. This is theoretically sound for hiding files, but it creates a complex virtual file system (VFS) layer.

We analyze the impact of this VFS layer on integrity:

  1. Mount Point Leaks: While SusFS hides mounts from mount commands, the kernel’s internal data structures still retain references to these mounts. Deep integrity scans can query these kernel structures directly, bypassing the standard mount command output.
  2. Performance Anomalies: The overhead of the SusFS interception hooks can introduce slight timing delays in system calls. While imperceptible to users, these timing anomalies can be detected by the integrity app’s timing attack vectors.

Therefore, a user running SusFS is not just modifying the file system; they are modifying the kernel’s performance profile. This makes the device highly distinct from a stock device, making it an easy target for integrity failure.

Strategies for Regaining Integrity

While total failure is discouraging, there are strategies to recover integrity, though they often require trade-offs. We prioritize a methodical approach to balancing functionality and attestation.

The Stock Kernel Compromise

For users who absolutely require Play Integrity (e.g., for banking or Google Pay), the most reliable solution is often to abandon the custom SusFS kernel.

Managing the Zygisk Denylist

For users who must keep their custom kernel, optimizing the Zygisk Denylist is critical.

Updating PIF Fingerprints

Since Google constantly updates its whitelist, the static fingerprints used by PIF often become obsolete.

The Future of Integrity and Rooting

We are entering an era where hardware-backed security is becoming non-negotiable. The introduction of Play Integrity API (v2) and the phasing out of the old SafetyNet API makes bypassing integrity checks increasingly difficult.

The concept of Trusted Execution Environment (TEE) and StrongBox adds another layer. These hardware components verify the software stack. Rooting a device generally breaks the trust chain in the TEE. While some devices allow relocking the bootloader with custom keys (like OnePlus or Xiaomi), most devices do not.

For users failing all integrity, the future looks challenging. The reliance on user-space spoofing is reaching its limit. Future solutions will likely require:

Specifics of the Magisk Module Repository

We host a comprehensive repository at Magisk Modules (https://magiskmodule.gitlab.io/magisk-modules-repo/). Users looking for solutions to integrity issues should approach the repository with a strategy. Do not download every module labeled “Integrity Fix.”

Instead, we advise users to:

  1. Read the Documentation: Each module in our repository has a description. Look for modules specifically designed for the latest Android versions and API levels.
  2. Check Compatibility: Ensure the module is compatible with KernelSU if that is the root solution being used. Not all Magisk modules are kernel-agnostic.
  3. Prioritize Quality over Quantity: A single, well-maintained module like “Play Integrity Fix” is superior to five conflicting modules that attempt to patch the same system properties.

Our repository aims to provide the tools necessary for customization, but the responsibility lies with the user to configure them correctly. A “failing all integrity” state is often a configuration error rather than a module defect.

Conclusion

Failing all integrity is a complex state that arises from the intersection of deep kernel modifications (like KernelSU SusFS), user-space spoofing modules (like PIF and Shamiko), and Google’s evolving attestation algorithms. We have dissected the layers of this failure, identifying that the SusFS kernel is likely the primary culprit due to its detectable alterations to kernel structures.

To resolve this, we recommend a systematic approach: isolate the kernel, simplify the Magisk module stack, and prioritize valid device fingerprints. While the path to perfect integrity is paved with technical hurdles, understanding the mechanics of the Play Integrity API and the limitations of current hiding techniques is the first step toward a stable, secure, and customized Android environment. The ecosystem is adversarial by nature, and maintaining integrity requires constant vigilance and adaptation.

You also may like 〣〣
Explore More
Redirecting in 20 seconds...