I Suddenly Can’t Even Get Basic Integrity: A Definitive Troubleshooting Guide for KSU-Next and Magisk Users

We understand the frustration and technical complexity involved when a rooted Android device suddenly loses Play Integrity certification. The transition from a functioning setup with Basic Integrity and CTS Profile Match to a failed state is a common yet solvable issue for advanced users operating on frameworks like KSU-Next (KernelSU) and Magisk. This guide is designed to provide a comprehensive, deep-dive analysis and solution path for devices specifically running the Redmi Note 8 (ginkgo), Pixel Experience Plus (Android 13), and utilizing modules like Susfs, PIFork, and Tricky Store.

Based on the detailed context provided regarding the specific setup and troubleshooting steps already attempted, we will analyze the root cause of the integrity failure. The specific combination of KSU-Next 1.1.0, Susfs 1.5.12, and Tricky Store requires a precise configuration to bypass Google’s hardware and software attestation checks.

Understanding the Root Cause: Tricky Store and Keybox Attestation

The user reported that the device worked perfectly after a fresh installation using only PIFork and the stock Play Store version. The failure occurred immediately after configuring Tricky Store. This is the critical clue.

Tricky Store is a powerful module designed to spoof the Key Attestation results. It injects a valid “keybox” (a set of cryptographic keys signed by a device manufacturer) into the system to satisfy Google’s requirement for hardware-backed integrity. However, simply installing the module is not enough; the configuration of the tricky_store folder and the targets.txt file is paramount.

The Valid vs. AOSP Keybox Dilemma

The user mentioned trying to switch between a valid keybox and an AOSP keybox. This is a critical variable.

• Valid Keybox: This is a leaked keybox from a real device (e.g., Pixel, Samsung). It provides the highest level of attestation (MEETS_DEVICE_INTEGRITY). However, these keyboxes are frequently revoked by Google. If the keybox is revoked, Tricky Store will fail, often resulting in a “Basic Integrity” failure or a “Strong” integrity failure.
• AOSP Keybox: This is a self-signed keybox generated by the Android Open Source Project or the module itself. It generally cannot pass MEETS_DEVICE_INTEGRITY (Strong), but it is often capable of passing Basic Integrity if the software detection vectors are handled correctly.

Since the user could not get Basic Integrity (the lowest level), the issue is likely not just the keybox, but a conflict in how the system is hiding the root presence.

Analyzing the KernelSU and Susfs Configuration

Using KSU-Next alongside Susfs creates a highly secure environment. Susfs (SuperUser Sensitive File System) is designed to hide root from specific packages and mount points. However, Google Play Services (GMS) and Play Integrity API are extremely aggressive in detecting overlay mounts and hidden processes.

Interference with GMS and Vending

The user attempted to set GMS Vending and GSF packages in Tricky Store using ! and without it.

• ! (Exclusion): This tells Tricky Store not to hook into that package.
• No ! (Inclusion): This tells Tricky Store to apply the keybox spoofing to that package.

If Susfs is hiding the /data/adb/modules directory or the Tricky Store payload from GMS, the injection will fail. Conversely, if Tricky Store is injecting into GMS while Susfs is also attempting to hide root from GMS, the two modules can conflict, causing GMS to crash or report a tampered state, resulting in a failed integrity check.

The Correct Setup for Tricky Store and PIFork

To resolve this issue on the Redmi Note 8 (ginkgo), we must ensure Tricky Store is configured correctly to support PIFork. PIFork (Play Integrity Fork) provides the software-based fingerprints (Device Integrity) while Tricky Store handles the hardware-based attestation (Strong Integrity).

Step 1: Verifying the targets.txt Configuration

The core of the Tricky Store configuration lies in the targets.txt file located in /data/adb/tricky_store/. If this file is missing or malformed, the module will not function.

We recommend the following configuration for maximum compatibility:

com.android.vending
com.google.android.gms

The user should ensure these lines are present. The ! symbol should be used only if you are experiencing specific app crashes. For general Play Integrity fixes, both vending (Play Store) and gms (Play Services) must be targeted.

Step 2: Validating the keybox.xml

The user mentioned trying to set AOSP keybox when the valid one was revoked. If Basic Integrity is failing completely, the keybox might be the culprit.

1. Ensure the keybox.xml inside /data/adb/tricky_store/ is not empty.
2. If using a Valid Keybox, verify it is not revoked. If it is revoked, Tricky Store will fail. In this case, reverting to the AOSP keybox is the correct move for restoring Basic Integrity, provided the PIFork fingerprints are up to date.

Addressing the Play Store Downgrade (Vending.apk)

The user attempted to downgrade the Play Store by deleting it via shell, allowing the system to reinstall the stock version (3.5 vs 4.9). This is a valid troubleshooting step. Newer versions of the Play Store often implement stricter integrity checks and integrity request behaviors.

However, simply downgrading is often not enough if the GMS Core (Google Play Services) is updated. The interaction between Vending.apk and GmsCore.apk dictates the integrity verdict.

• Stock Play Store (3.5): Likely relies on older API calls.
• Latest Play Store (4.9): Hardened against root and custom ROMs.

If the user downgraded to 3.5 and still failed, it suggests that the issue is not the Play Store version, but rather the GMS Core detecting the environment via Susfs or the kernel patch.

The Role of LSPosed, HMA-OSS, and ReZygisk

The user is running LSPosed (JynxMatrix), HMA-OSS, and ReZygisk.

• ReZygisk / Zygisk Next: These are Zygisk implementations for KernelSU. They allow LSPosed to function.
• HMA-OSS (Hide My Applist): This module is critical. It hides apps from the Play Store and other detectors.

The Conflict: If HMA-OSS is configured to hide the Play Store or Play Services from itself (or root detectors), it might be blocking the legitimate integrity request sent by Tricky Store. HMA-OSS must be configured to allow GMS and Vending to see the system clearly, otherwise, the integrity API sees a “sanitized” environment which it flags as suspicious.

Detailed Troubleshooting Workflow

We propose a strict workflow to isolate and fix the Basic Integrity failure on the Pixel Experience Plus (A13) ROM.

1. Clean the Tricky Store Environment

Since the issue started after setting up Tricky Store, we must reset it.

1. Reboot to recovery (or kernelSU manager).
2. Navigate to /data/adb/tricky_store/.
3. Delete the targets.txt file and the keybox.xml file.
4. Reboot the system.
5. Let PIFork work alone.
6. Check Basic Integrity. It should return true.

2. Re-introduce Tricky Store (Methodical Setup)

If PIFork alone gives Basic Integrity, we can now add Tricky Store.

1. Install the Tricky Store module (ensure it is the latest version).
2. Generate a new targets.txt with only:

   com.android.vending
   com.google.android.gms
   

3. Do not add the ! symbol yet.
4. Obtain a working Keybox. If you are using a “Valid” one, ensure it is fresh. If not, use the AOSP Keybox.
5. Place the keybox.xml in the correct folder.
6. Reboot.

3. Susfs Configuration Check

Susfs is aggressive. You must ensure that Susfs is not hiding the tricky_store directory from GMS.

• Check your Susfs configuration. You may need to whitelist GMS from specific hide checks.
• Alternatively, temporarily disable Susfs (via the KernelSU app) to test if it is the blocking agent. If integrity passes with Susfs disabled, you need to adjust the Susfs mount hide settings.

4. LSPosed and HMA-OSS Management

If you are using HMA-OSS, ensure that Google Play Services and Google Play Store are not in the list of hidden apps for the “System Framework” or “Play Store” scope. HMA-OSS works by modifying the app’s view of the installed packages. If it hides the root manager or the Tricky Store payload, the integrity check fails.

We recommend scoping HMA-OSS to hide root only from specific user apps, but keep GMS and Vending completely out of the scope.

Common Pitfalls on Redmi Note 8 (ginkgo) with A13

The Redmi Note 8 running Pixel Experience Plus A13 has specific hardware (Snapdragon 665) and software characteristics.

1. Unlocked Bootloader Detection: Even with root hidden, the bootloader status is often readable by the TrustZone (TZ). Tricky Store specifically attempts to override this via the keybox. If the keybox is invalid, the hardware attestation fails.
2. Vending Downgrade Failure: If the system signature of the downgraded Vending.apk does not match the ROM signature (common in custom ROMs), the Play Store will crash or refuse to pass integrity. Ensure the Pixel Experience GApps package is compatible with the downgrade.

Conclusion: The Path to Restoration

The user’s issue stems from a misconfiguration between Tricky Store and the existing root environment. The fact that Basic Integrity failed only after Tricky Store was set up indicates that the Keybox being used is likely revoked or invalid, causing the integrity check to fall back to a “Strong” check which fails, or the targets.txt configuration is preventing the injection.

To restore Basic Integrity:

1. Validate the Keybox: Switch to a known working “Valid” keybox or revert to “AOSP” if the valid one is revoked.
2. Verify targets.txt: Ensure com.android.vending and com.google.android.gms are present without unnecessary ! symbols if passing Basic is the goal.
3. Manage Susfs: Ensure Susfs is not aggressively hiding the specific mount points required by Tricky Store.
4. Clean PIFork: Ensure PIFork is using fresh, valid fingerprints for Android 13 on the ginkgo device.

By meticulously aligning the Tricky Store injection with the PIFork fingerprints and ensuring Susfs does not obstruct the GMS components, the device should successfully restore Basic Integrity and potentially achieve Device Integrity. We advise users to monitor the Magisk Module Repository for updated versions of these modules, as the integrity landscape changes frequently.

Advanced Diagnostic: Checking Logs

If the above steps fail, we highly recommend checking the LSPosed logs and KernelSU logs. Look for errors related to tricky_store or system_server. Specifically, look for “Key Attestation” failures. This will confirm if the issue is the keybox (hardware) or the fingerprint (software).

Final Verification Steps

After applying fixes, always perform the following:

1. Clear Data for Google Play Services and Google Play Store.
2. Reboot.
3. Open Google Play Store -> Settings -> About. Check the Play Integrity API status.
4. Run the Play Integrity API Checker app to verify basicIntegrity is true.

This comprehensive approach addresses the specific nuances of the KSU-Next, Susfs, and Tricky Store ecosystem, ensuring the highest probability of restoring the missing integrity verdict.