Telegram

ROOT MODULE’S DON’T SEEM TO BE WORKING ANYMORE TO PASS STRONG INTEGRITY. I’VE HEARD OF

Root Modules Fail Strong Integrity: Mastering SUSFS Custom Kernels for Google Pixel 9a

In the rapidly evolving landscape of Android rooting, the battle between device integrity and user freedom has reached a critical tipping point. We understand the frustration many enthusiasts face: you root your device using Magisk or KernelSU Next, hoping to maintain full functionality, only to find that Root Modules and systemless interfaces are no longer sufficient to pass Strong Integrity checks. For owners of the Google Pixel 9a, this challenge is compounded by the specific hardware architecture of the Tensor G4 chip and Google’s aggressive enforcement of Play Integrity API requirements. While patching the boot image remains the standard entry point for many, the sophistication of detection mechanisms has outpaced basic rooting techniques.

The solution increasingly lies in advanced kernel-level modifications, specifically utilizing SUSFS (Sudden System File System) integrated within custom kernels like those developed by Wild Kernels. However, navigating the technical requirements to assemble a custom kernel for the Pixel 9a, or determining if a pre-compiled version exists, requires a deep dive into the Android Open Source Project (AOSP), kernel source trees, and the specific implementation of loop device concealment. We will provide a comprehensive guide on bridging the gap between standard root methods and high-level integrity bypassing, ensuring your Google Pixel 9a remains both rooted and compliant with strict system checks.

Understanding the Crisis: Why Standard Root Modules Are Failing Strong Integrity

The core of the issue lies in the distinction between Basic Integrity and Strong Integrity within the Google Play Integrity API. For years, Magisk and its vast ecosystem of modules (such as MagiskHide, Shamiko, and Universal SafetyNet Fix) were sufficient to mask the presence of root from banking apps and streaming services. These modules operated by modifying system properties, hiding specific files, and masking the status of the su binary. However, Google has shifted the attack surface. Strong Integrity verifies the boot chain from the hardware root of trust up to the system partition. If the boot.img is modified, or if the kernel is patched, standard modules often fail to conceal these modifications at the hardware level.

The Role of Loop Devices in Detection

One of the primary vectors for detection is the mounting of loop devices. When Magisk mounts its internal infrastructure (such as .magisk), it utilizes loop devices to inject modules into the system without altering the actual partition. While this is “systemless,” the existence of these mounted loop devices is a tell-tale sign of a compromised system. Kernel-level root solutions like KernelSU Next attempt to mitigate this by operating directly within the kernel space, but without proper concealment, they remain visible to integrity checks.

KernelSU Next vs. Magisk in the Pixel 9a Ecosystem

For the Google Pixel 9a, the choice between Magisk and KernelSU Next is significant. Magisk relies on the init process patching, which is effective but often leaves more footprints in userspace. KernelSU Next, conversely, integrates directly into the kernel, offering a more native root experience. However, even KernelSU Next requires kernel modifications to ensure that the kernel itself does not report unauthorized modifications. This is where the concept of a custom kernel pre-loaded with concealment features like SUSFS becomes the gold standard.

Deep Dive into SUSFS and Custom Kernels

SUSFS (Sudden System File System) is not merely a module; it is a kernel-level file system redirection and hiding mechanism. Unlike userspace modules that attempt to block access to root binaries, SUSFS operates at the VFS (Virtual File System) layer. It intercepts system calls (syscalls) related to file listing and reading, ensuring that sensitive directories (like those used by Magisk or KernelSU) are invisible even to privileged processes running with root access.

What is Wild Kernels?

Wild Kernels represents a community-driven initiative to build optimized, feature-rich custom kernels for specific Android devices. These kernels are typically compiled from source code provided by the device manufacturer (in this case, Google) but are modified to include custom schedulers, voltage controls, and, crucially, anti-detection features. When the community refers to a “Wild Kernel” with SUSFS, they are referring to a kernel binary where the SUSFS patch set has been applied during the compilation process.

The Tensor G4 Challenge

The Google Pixel 9a utilizes the Tensor G4 processor. Compiling a custom kernel for Tensor chips is distinct from Snapdragon devices due to Google’s specific DTB (Device Tree Blob) configurations and the integration of Titan M2 security modules. A generic SUSFS patch will not work; it must be specifically ported to the kernel source branch matching the exact firmware version of the Pixel 9a (e.g., bp1a.250305.019 or similar).

Acquiring and Building the Custom Kernel for Pixel 9a

For users who have only previously patched boot images, the concept of assembling a custom kernel can seem daunting. However, for the Pixel 9a, the process involves obtaining the correct source code and applying the necessary modifications. Currently, there is no “one-click” installer for the Pixel 9a SUSFS kernel, as the device is relatively new, and development is ongoing. Therefore, building from source is the most reliable method to ensure compatibility with your specific firmware version.

Prerequisites for Kernel Compilation

To assemble a kernel for the Pixel 9a, you must set up a Linux environment (Ubuntu 22.04 LTS is recommended) with the Android build toolchain. You will need:

  1. The Android Kernel Source: Google maintains the kernel source for the Pixel 9a on the Android Git repositories. You must checkout the branch corresponding to your current active slot firmware.
  2. The SUSFS Patch Set: The SUSFS source code is available on GitHub. You must apply the patch to the kernel source tree.
  3. The AnyKernel3 Script: This is required to package the compiled kernel into a flashable zip that can be used with Magisk or directly flashed via Fastboot.

Step-by-Step Assembly Process

1. Retrieving the Kernel Source

Navigate to the Google Source repository for the Pixel 9a (codenamed akita or similar, depending on the specific variant). Use git clone to download the kernel source. It is imperative that the kernel source version matches your device’s running firmware version exactly. Mismatched versions can lead to bootloops.

2. Applying the SUSFS Patch

Once the source is downloaded, apply the SUSFS patch. This involves modifying the fs/exec.c, fs/namei.c, and fs/proc/base.c files to intercept and redirect file visibility. The patch effectively creates a “whitelist” of processes that can see hidden files, while all other processes (including Play Integrity services) see a sanitized file system.

3. Configuration (.config)

You must copy the kernel configuration from your device. This can be extracted from /proc/config.gz on your running Pixel 9a. Load this configuration into the kernel source menu (make menuconfig) to ensure all drivers (WiFi, Bluetooth, Camera) remain functional. Overlooking this step often results in hardware failures.

4. Compilation

Using the AARCH64 toolchain (typically aarch64-linux-android-4.9 or a Clang-based toolchain provided by AOSP), compile the kernel:

make -j$(nproc)

This generates the Image.lz4 and dtb files.

5. Packaging with AnyKernel3

Place the compiled kernel artifacts into the AnyKernel3 directory. Edit the anykernel.sh script to target the boot partition (or init_boot for newer Pixel devices). Zip the contents to create AnyKernel3-Pixel9a-SUSFS.zip.

Integration with Magisk and KernelSU Next

Once the custom kernel is assembled or obtained, it must be integrated with your root solution. Unlike standard rooting where you patch a boot.img via the Magisk app, a custom kernel replaces the kernel component of the boot image.

Flashing the Kernel

If you are currently using Magisk (rooted via patched boot image), you can flash the custom kernel via Fastboot:

fastboot flash boot AnyKernel3-Pixel9a-SUSFS.zip

However, if you are using KernelSU Next, the process is similar. The custom kernel essentially supersedes the kernel patched by KernelSU. In many cases, you will flash the custom kernel first, and then flash the KernelSU Next manager APK to gain root access, as the kernel now supports the necessary interface.

Ensuring SUSFS Activation

After flashing, SUSFS is usually active by default, but it requires configuration. You may need a specific Magisk Module (often included with the kernel release) to define which paths to hide (e.g., /data/adb, /sbin, /dev/.magisk). Without this configuration, SUSFS is active but not hiding anything specific.

Managing Firmware Updates and OTA Updates

A major concern for root users is the ability to update the device without losing root or breaking the custom kernel. With the Pixel 9a, Google uses an A/B partition scheme (seamless updates). This complicates matters when using a custom kernel that may not support the stock OTA update mechanism directly.

The OTA Update Workflow

When a new firmware version is released for the Pixel 9a:

  1. Do Not Flash the Full Factory Image: Using the Google Online Flash Tool (Web Flasher) to flash a full factory image will overwrite your custom kernel and restore stock partitions, breaking root.
  2. Use the OTA Method:
    • Download the OTA zip for the new firmware version (not the factory image).
    • Keep your custom kernel and root intact.
    • Install the OTA zip via Magisk -> Install -> Install to Inactive Slot (After OTA). This updates the system without touching the active kernel slot.
    • However, if the new firmware includes a kernel update (which it almost always does), your current custom kernel will not be compatible with the new system partition. You will likely need to wait for the custom kernel developer (Wild Kernels) to release a version for the new firmware, or re-compile the kernel yourself using the new source code.

Managing Integrity After Updates

Firmware updates often reset Google Play Integrity verdicts. After an OTA, you may need to re-configure your hide lists. With SUSFS, the process is more stable than with standard modules, but we recommend clearing the Play Services data and re-running the Integrity API check to ensure Strong Integrity is maintained.

Troubleshooting RCS and Banking App Failures

The user mentioned issues with RCS (Rich Communication Services) failing after a day or so. This is a common side effect of incomplete root hiding.

Why RCS Fails

RCS relies on Google Play Services and the carrier’s messaging app. It performs periodic background checks. If a root module fails to hide the su binary or the Magisk manager app, RCS registration will drop. Google’s Play Integrity verdict changes from MEETS_DEVICE_INTEGRITY to NO_INTEGRITY or MEETS_BASIC_INTEGRITY only, causing RCS to de-register.

SUSFS as the Solution

Standard modules like “RCS Fix” often work by downgrading Google Play Services or modifying build.prop. These are temporary hacks. SUSFS solves the problem at the source. By completely hiding the existence of the root file system from the Google Play Services process (even if that process runs with elevated privileges), SUSFS prevents the integrity check from triggering a failure. This ensures RCS remains active consistently.

Banking Apps

Similarly, banking apps like Chase, HSBC, or Revolut scan for common root binaries (su, busybox). SUSFS hides these binaries not just from the user, but from the kernel’s file listing API. When the banking app scans /system/bin or /data/adb, it sees nothing unusual, allowing the app to launch without triggering the “Device Compromised” error.

The Philosophy of Ownership: Google vs. The User

The user’s sentiment that “these are our phones” is the driving force behind the custom kernel community. Google’s tightening grip via the Play Integrity API is an attempt to secure the ecosystem, but it inadvertently penalizes power users. By moving the modification from the userspace (where Magisk modules live) to the kernel space (where SUSFS lives), we reclaim a layer of privacy that Google has sought to eliminate.

The Risk of Custom Kernels

It is important to acknowledge the risks. Flashing a custom kernel like those from Wild Kernels modifies the core of your device.

However, for enthusiasts, the trade-off is acceptable. The ability to control the device fully—bypassing artificial software restrictions—is the primary goal.

Advanced Configuration: Customizing SUSFS for Pixel 9a

Once you have successfully flashed the custom kernel, fine-tuning is required for optimal performance and stealth.

Defining Hide Paths

SUSFS typically uses a configuration file (often located at /data/adb/susfs/config.txt or integrated into the kernel command line). You must specify paths that require hiding. For a standard Magisk setup, these include:

Systemless Etc Hosts

If you use systemless hosts modules to block ads, ensure that SUSFS does not interfere with the redirection. The hosts file is usually mounted via a loop device. SUSFS must be configured to allow the visibility of the modified hosts file to the network stack while hiding the mounting mechanism itself.

Zygisk and Riru

If you rely on Zygisk (for LSPosed), SUSFS must not block the Zygote process. Modern SUSFS patches are Zygisk-compatible, but you should verify that LSPosed functions correctly after installation. If apps detect Zygisk, you may need to toggle “Enforce DenyList” in Magisk, although SUSFS often renders this unnecessary.

Alternatives to Custom Kernel Assembly

If compiling a kernel from source proves too complex, there are community resources where pre-assembled kernels are shared. However, for a device as new as the Pixel 9a, these are scarce. We advise caution when downloading pre-compiled binaries from unverified sources.

KsuNext + KernelSU Manager

For users preferring not to compile, KernelSU Next offers a middle ground. By patching the kernel via the KernelSU Manager app, you gain root. However, to achieve Strong Integrity, you must still utilize a SusFS module or a kernel that supports SusFS natively. Currently, the most stable method for Pixel 9a remains a custom-compiled kernel.

Magisk + Shamiko + SusFS Module

For Magisk purists, you can install a SusFS-specific Magisk Module that attempts to replicate kernel-level hiding in userspace. While less effective than a kernel patch, it can sometimes pass Basic Integrity. However, for Strong Integrity, the kernel-level approach is superior.

Conclusion: The Path Forward for Pixel 9a Rooting

The era where simple root patching sufficed for passing integrity checks is over. For the Google Pixel 9a, the combination of the Tensor G4 security architecture and Google’s updated Play Integrity API demands a more robust solution. While the learning curve for compiling a custom kernel with SUSFS is steep, it is currently the most effective method to maintain root access, pass Strong Integrity, and keep features like RCS and banking apps functional.

We recommend that users stuck in the cycle of patching boot images and fighting temporary module fixes transition to a custom kernel environment. By taking control of the kernel, you bypass the userspace detection vectors that Google exploits. While this requires patience—particularly in waiting for or building kernel updates alongside firmware releases—the result is a device that truly belongs to the user, free from artificial software restrictions.

For those looking to explore compatible modules and tools that complement this setup, we invite you to visit the Magisk Modules repository. Here, you can find additional resources to refine your rooting experience. Remember, the goal of rooting is freedom, and with the right kernel, that freedom is fully restored.

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