SUSFS Deep Dive: Kernel Root Hiding Explained

TL;DR: SUSFS works by patching the Android kernel so that root traces — hidden files, extra mounts, and modified file state — are spoofed or made invisible below the app layer. Apps scanning the filesystem see a clean device. It needs a custom kernel compiled with SUSFS patches plus a companion module, and it raises the bar against detection without guaranteeing any bypass.

By the PrivacyPortal team · Last updated July 2026.

If you have rooted a phone and then watched a banking or streaming app refuse to open, you have met root detection. How SUSFS works is the question a lot of flashers now ask, because SUSFS (short for SUSFS4KSU) has become the go-to tool for kernel root hiding on Android. In plain terms, SUSFS is a set of kernel patches plus a small userspace module that hides the fingerprints root leaves behind — modified partitions, extra mount points and tell-tale files — by intercepting those queries inside the kernel and returning a clean, spoofed view. Because the deception happens beneath the apps, ordinary filesystem and mount checks come back looking stock. It is not magic and it is not permanent, but it meaningfully raises the bar.

What SUSFS actually is

SUSFS is an add-on, not a root method. It was created by developer simonpunk and lives in the official SUSFS4KSU repository on GitLab, where it was first published in April 2024. Its job is to harden the root-hiding of kernel-based root solutions — chiefly the KernelSU project, KernelSU-Next and SukiSU Ultra — rather than to grant root itself. The name nods to "SUS" (suspicious) filesystem: it makes the suspicious bits look normal.

Two pieces work together:

• Kernel patches — source-level changes compiled directly into a custom kernel. This is the core; without a kernel built to include them, SUSFS cannot run.
• A companion userspace module — the susfs4ksu module (often listed as ksu_module_susfs), flashed inside your root manager to configure and control what the kernel hides.

SUSFS (SUSFS4KSU) was first published by developer simonpunk on GitLab in April 2024 as an add-on for kernel-based root — not a standalone root solution.

How SUSFS works: hiding root inside the kernel

Root detection is really just an app asking the operating system questions and judging the answers: "Is this file present? What is mounted here? Does this path look modified?" SUSFS answers those questions from inside the kernel, so the reply is already sanitised before any app can read it. That is the whole idea behind kernel root hiding on Android — control the source of truth, not the app that queries it.

In practice SUSFS provides several hiding primitives, including:

• SUS paths — specific files and directories are made invisible to apps that stat or list them.
• SUS mounts — extra bind-mounts created by the root manager (a classic giveaway) are hidden from /proc/mounts and mount-info reads.
• SUS kstat — file metadata such as timestamps is spoofed so tampered files match their stock neighbours.
• Try-umount — module mounts are cleanly detached for chosen apps, so they see the untouched partition.

Because these run below the app layer, a detector cannot simply "look harder" from userspace to see past them — it would need its own kernel access. That structural advantage is why the community moved to SUSFS.

A simplified view of where SUSFS sits: it intercepts filesystem and mount queries inside the kernel, beneath the app that is asking.

SUSFS vs userspace hiding: why the kernel wins

The older approach — MagiskHide, and later the Zygisk DenyList — does its work in userspace, patching what apps see from roughly the same level the apps run at. The SUSFS vs userspace difference matters because a userspace trick can, in principle, be out-manoeuvred by a determined detector running in the same space. Kernel hiding changes the playing field.

Magisk removed its built-in MagiskHide in v24.0 (2022), moving root hiding to the userspace Zygisk DenyList — the approach SUSFS is designed to improve on.

If you are weighing root methods in the first place, our KernelSU vs Magisk comparison covers the trade-offs before you ever get to hiding.

What SUSFS can and can't do

SUSFS is powerful, but it is not a universal "pass everything" switch, and treating it that way leads to disappointment. Here is the honest picture as of July 2026.

It handles filesystem, mount and file-state detection very well. What it does not do on its own is defeat hardware-backed attestation. Google's Play Integrity API can ask the device's secure hardware to vouch for it, and the strongest verdict (hardware attestation / MEETS_STRONG_INTEGRITY) is not something a hidden filesystem changes. That is a separate battle, usually fought with keybox and attestation tricks such as a TrickyStore-style module that carry their own reliability and ethics caveats.

As of July 2026 the actively referenced SUSFS release is the 1.5.x line — for example v1.5.9 — paired with KernelSU-Next or SukiSU Ultra.

We will not tell you SUSFS defeats any specific bank's checks. Detection is an arms race: an app can add a new heuristic in an update and quietly start seeing through your setup. SUSFS raises the bar; it does not end the game. For the attestation side, Google's Play Integrity API documentation explains what apps can actually request, and our guide to Play Integrity and safety checks puts it in plain English.

How to install SUSFS: a step-by-step outline

Back up everything first. Unlocking the bootloader wipes your device, and flashing the wrong kernel can leave you in a bootloop. Exact commands differ per phone, so treat this as the shape of the process, not a device-specific recipe.

Prerequisites

• An unlockable bootloader, unlocked (this erases all data — do it before anything else).
• A SUSFS-patched kernel matching your exact device and firmware — usually a GKI or device-specific kernel someone compiled with the patches, shipped as an AnyKernel3 zip or boot image.
• A compatible kernel-based root: KernelSU-Next or SukiSU Ultra, with its manager app.
• The matching susfs4ksu module (ksu_module_susfs) — its version must line up with the kernel's SUSFS version.
• ADB and fastboot on a computer, plus your correct stock firmware for recovery.

1. Back up and record your setup. Save photos, keys and app data off-device, and note your exact model and firmware build.
2. Confirm your root and kernel source. Check whether your device uses a GKI kernel and find a trusted SUSFS-patched kernel built for your firmware. Matching versions here prevents most bootloops.
3. Install the root solution. Flash or patch with KernelSU-Next or SukiSU Ultra and confirm the manager app reports working root.
4. Flash the SUSFS-patched kernel. Use fastboot flash boot with the provided image, or flash the AnyKernel3 zip in recovery. This replaces your kernel with the SUSFS-enabled one.
5. Install the companion module. Reboot, open your root manager, install the susfs4ksu module as you would any KernelSU module, then reboot again.
6. Configure what to hide. Add the apps you care about to the manager's DenyList/hide list and apply the module's SUS-path and mount settings.
7. Verify it booted and is active — check the SUSFS version and run a detector app, as described next.

The KernelSU-Next manager showing the susfs4ksu companion module installed and enabled after reboot.

Verify SUSFS is running. Open a terminal (or adb shell), gain root, and check the SUSFS version — the companion tooling exposes a susfs command that prints the active version, and the number should match your module. Then install a detector such as Momo or the Play Integrity API Checker and confirm root and mount checks report clean. If the version prints and detectors look stock, your patched kernel booted and SUSFS is live.

Checking the running SUSFS version from a root shell to confirm the patched kernel booted correctly.

The specific kernels, root managers, the susfs4ksu module and the detector apps named here are collected in the "Modules, apps & files to try" section at the end of this guide — grab them there rather than hunting around.

Common pitfalls (from real community experience)

• Version mismatch. A kernel built for one SUSFS release paired with a module expecting another is the number-one cause of "it flashed but nothing hides." Match them.
• Wrong kernel for your firmware. Flashing a kernel meant for another build or variant is the classic bootloop. Keep stock boot images ready to restore.
• Expecting a "pass everything" result. SUSFS hides filesystem artefacts; it does not, by itself, satisfy hardware attestation.
• Forgetting the userspace layer. On many setups you still pair SUSFS with a Play Integrity fix module for the basic verdict; kernel hiding alone is not the whole story.
• OTA updates. A system update can replace your kernel and silently undo everything, or fail because the boot image is modified. Re-flash after every OTA.
• Chasing detectors. A green result today can go red after an app update. Don't rebuild your whole setup over a single failed check.

Should you use SUSFS? A quick decision framework

Use this to decide honestly:

• You run a custom ROM and want stronger custom ROM root security: SUSFS is a strong fit, provided a patched kernel exists for your device.
• You just want basic apps working and dislike kernel flashing: a userspace DenyList plus a Play Integrity fix may be enough — less risk, less reward.
• You depend on a specific banking app: proceed with caution and a backup plan; no method is guaranteed, and a second device may be wiser.
• You are new to flashing: learn bootloader unlocking, backups and recovery first. SUSFS is not a beginner's first project.

If the kernel-flashing route sounds like more than you want to take on, that is completely reasonable — and it is exactly why we build de-Googled, privacy-first Android phones that come hardened out of the box. You get the privacy without the bootloop risk.

Frequently asked questions

Is SUSFS a root method like Magisk?

No. SUSFS does not grant root. It is an add-on that hides root for kernel-based solutions such as KernelSU, KernelSU-Next and SukiSU Ultra. You install root first, then add SUSFS on top.

Can I install SUSFS with a flashable zip on my stock kernel?

No. SUSFS lives in the kernel, so you need a kernel compiled with the SUSFS patches. A plain module on a stock kernel cannot add it — the companion zip only configures a kernel that already supports it.

Does SUSFS guarantee my banking app will work?

No, and be wary of anyone who claims otherwise. SUSFS raises the bar against detection, but detection changes constantly and some apps use hardware attestation that kernel hiding does not address.

Will SUSFS survive an OTA update?

Usually not automatically. A system update can overwrite your patched kernel. Expect to re-flash the SUSFS kernel (and often the root solution) after each OTA, and keep your stock firmware handy.

SUSFS vs userspace hiding — which is better?

For resistance to filesystem and mount detection, kernel hiding with SUSFS is generally stronger because it works below the app layer. Userspace hiding is easier to set up and lower risk. Many people combine both.

Which root solutions support SUSFS?

KernelSU, KernelSU-Next and SukiSU Ultra are the main supported kernel-based roots. Magisk, which hides in userspace, is not the target — SUSFS is built for the kernel-root ecosystem.