What Is SUSFS? Hiding Root from Detection, Explained (2026)

TL;DR: SUSFS (Suspicious File System) is an open-source set of Linux kernel patches plus a userspace module that hides root at the kernel level — concealing suspicious paths, mounts and kernel metadata from apps that scan for tampering. It is not a rooting method itself; you pair it with KernelSU, KernelSU-Next or SukiSU-Ultra on a SUSFS-patched kernel.

By the PrivacyPortal team · Last updated June 2026

If you have rooted a phone and an app suddenly refuses to run, you have met root detection — and SUSFS is the tool the community now reaches for to counter it. So what is SUSFS? It is kernel-level root hiding: a patch baked into a custom kernel that makes a modified device look untouched to the software running on top of it. Unlike older, module-only tricks that operate in userspace (the normal app and system layer), SUSFS works inside the Linux kernel, where detection apps cannot easily look. In practice that makes it the strongest layer in a modern hiding stack — though, as we will explain honestly, it is not a magic switch and cannot guarantee that any specific banking app will cooperate.

A simplified diagram showing where SUSFS sits in the Android stack — inside the Linux kernel, beneath the apps that run detection checks.

What is SUSFS?

SUSFS (often styled SUS-FS, short for "Suspicious File System") is an open-source project that adds filesystem-level root hiding to the Android kernel. It has two halves: a set of kernel patches that must be compiled into a custom kernel, and a userspace module that lets you configure what gets hidden. Crucially, SUSFS is not a root solution on its own — it is a hiding layer that sits alongside a kernel-based root manager.

SUSFS is developed by simonpunk and hosted on GitLab at gitlab.com/simonpunk/susfs4ksu, distributed as kernel patches plus a companion userspace module.

Because it depends on the kernel, SUSFS only works with kernel-based managers such as KernelSU, KernelSU-Next and SukiSU-Ultra. It does not work with stock Magisk, which never touches the kernel and instead relies on its own DenyList and Zygisk hiding. You can read more in our KernelSU vs Magisk comparison.

How SUSFS hides root at the kernel level

Most root-detection apps work by looking for tell-tale signs: extra files in system paths, unusual mount points, or a kernel name that reveals tampering. Userspace hiding tries to intercept those checks after the fact. SUSFS root hiding goes deeper — it removes the evidence inside the kernel before an app can ever read it.

It does this through a handful of named features:

• SUS_PATH — hides specific files and folders so they appear not to exist.
• SUS_MOUNT — conceals the mount points root tools create.
• SUS_KSTAT — spoofs file metadata (timestamps, inode details) so hidden files do not look freshly modified.
• SPOOF_UNAME — rewrites the kernel version string so a check of uname no longer reveals a custom or "KSU" build.

In the community's words: "root hiding modules are just a 0 in front of a kernel patched with SUSFS."

SUSFS vs module-based root hiding

To hide root, you have a few options, and they are not equal. The table below compares the common approaches so you can see where SUSFS fits.

Approach	Where it works	Relative strength	Works with Magisk?	Best paired with
Magisk DenyList	Userspace (Zygisk)	Basic	Yes (built in)	Simple, low-risk setups
Shamiko / Treat Wheel	Userspace (Zygisk)	Moderate	Magisk or KSU	Devices with no SUSFS kernel
SUSFS	Linux kernel	Strongest	No	KernelSU-Next, SukiSU-Ultra

The headline difference: module-based hiding reacts in userspace, while SUSFS removes traces in the kernel itself. That is why many flashers now treat it as the foundation of their stack rather than an add-on.

What you need before you start

SUSFS is powerful but demanding. Use this quick decision check before committing.

Consider SUSFS if:

• A SUSFS-patched kernel exists for your exact kernel version (for example 6.1.25-android14).
• You run KernelSU, KernelSU-Next or SukiSU-Ultra — not stock Magisk.
• You are comfortable flashing kernels and recovering from a boot loop.

Hold off if:

• No patched kernel is available for your device and kernel version.
• You cannot risk a data wipe or losing official updates (OTA).

Three risks deserve plain language. First, unlocking the bootloader WIPES all data on the device — back up everything first. Second, unlocking and flashing can void your warranty, break OTA updates, and weaken your device's security model. Third, flashing the SUSFS module without a patched kernel breaks key attestation and can leave you worse off than before. If kernel-flashing is not for you, a ready-configured de-Googled phone from PrivacyPortal sidesteps the whole process.

How to install and use SUSFS with KernelSU-Next

This is the path most people take in 2026: a SUSFS KernelSU setup using KernelSU-Next. The exact modules and tools are listed in the "Modules, apps & files to try" section below, so grab them there. Read every step before you begin.

1. Back up everything. Photos, app data, 2FA seeds — assume the device will be wiped.
2. Identify your kernel version. Check Settings > About phone, or run uname -r. Note it precisely; the SUSFS kernel must match.
3. Find a matching SUSFS-patched kernel. For many devices, Wild Kernels on GitHub provide builds you can flash with Horizon Kernel Flasher. If none exists for your version, stop — you cannot proceed safely.
4. Unlock the bootloader. This WIPES the device. Confirm you understand the warranty and OTA implications.
5. Install KernelSU-Next. Patch init_boot or flash the GKI kernel. Note that KernelSU-Next supports SUSFS via GKI, not LKM mode.
6. Flash the SUSFS-patched kernel using Horizon Kernel Flasher, then reboot and confirm the device still boots.
7. Install the SUSFS module (SUSFS4KSU). The userspace module is required even when the kernel already has SUSFS — without it, dependent modules fail with "susfs not found". (SukiSU-Ultra users can skip this: it has a built-in SUSFS manager.)
8. Add companion modules. For integrity checks, flash Tricky Store (with a valid keybox) and a Play Integrity Fix / PIF-style module. On a SUSFS kernel, prefer ReZygisk CI builds over Zygisk Next, and Treat Wheel over Shamiko.
9. Configure the SUSFS module. Disable SUSFS logs, spoof the kernel version to remove the "KSU" string, enable "spoof on boot", then press "make it sus". In Custom SUSFS Settings, disable "hide ReVanced" and leave the rest at default.
10. Verify it is active. Open the KernelSU WebUI — if it says "SusFS not supported", the kernel lacks the patch and you must revisit step 6. Then run an integrity checker, and confirm uname -r no longer shows a "KSU" string.

The KernelSU-Next WebUI showing the SUSFS module active, with the "make it sus" control used to apply hiding rules.

Common pitfalls with SUSFS

These are the failure modes we see most often in the community. Most are avoidable.

• Module without kernel. Installing SUSFS4KSU on an unpatched kernel breaks key attestation and shows "susfs not found". Always patch the kernel first.
• Mismatched patch versions. Mixing SuSFS 1.4 kernel patches with 1.5 userspace (or vice versa) produces build errors such as susfs_sus_path_by_filename undeclared. Keep both halves on the same version.
• Conflicts with Integrity Box. The SUSFS developer does not recommend running Integrity Box alongside it.
• The LineageOS display bug. Adding the LineageOS overlay idmap path to /data/adb/susfs4ksu/sus_path.txt causes a horizontal display glitch. Leave that path out.
• Expecting SUSFS to do everything. One reported GrapheneOS-on-Android-16 stack (KernelSU-Next CI + ReZygisk CI + SUSFS + PIF Fork + Tricky Store OSS + Integrity Box v24) still failed basic integrity — proof that SUSFS alone is not always sufficient.

Integrity Box v6 (2025) was reported to conflict with the latest SUSFS4KSU by aggressively adding custom-ROM paths to sus_paths during post-mount, breaking hiding for some users.

An integrity checker app reporting the basic and device verdicts after a SUSFS-based hiding stack is configured.

Does SUSFS guarantee banking apps and Play Integrity pass?

No — and we will not pretend otherwise. SUSFS removes kernel-level traces, which helps with apps that scan the filesystem and with the basic and device tiers of Google's Play Integrity. But it cannot, by itself, produce a hardware-backed STRONG_INTEGRITY verdict, and it cannot defeat any particular bank's bespoke checks.

What actually happens in practice varies by device, kernel and how recently Google has updated Play Integrity. Some users on a plain KernelSU + SUSFS kernel report no banking-app issues without extra modules; others need Tricky Store and a PIF module and still see occasional failures after a Play update. For a fuller picture, see our guide to Play Integrity and banking apps, Google's Play Integrity API documentation, and the KernelSU-Next project.

Frequently asked questions

Is SUSFS the same as KernelSU?

No. KernelSU is a root manager that grants superuser access; SUSFS is a hiding layer that conceals that root from detection. They are designed to work together — SUSFS needs a kernel-based manager like KernelSU, KernelSU-Next or SukiSU-Ultra to be useful.

Does SUSFS work with Magisk?

No. SUSFS requires kernel patches, and Magisk does not modify the kernel — it hides root in userspace via Zygisk and its DenyList. If you want SUSFS, you need a kernel-based root manager instead of stock Magisk.

Do I still need Shamiko with SUSFS?

Usually not. When the kernel includes SUSFS support, it handles filesystem-level hiding that Shamiko used to provide. If you do want an extra userspace layer on a SUSFS kernel, the community generally prefers Treat Wheel over Shamiko and ReZygisk over Zygisk Next.

What is sus_path.txt?

It is the configuration file at /data/adb/susfs4ksu/sus_path.txt where you list filesystem paths SUSFS should hide. It is useful for concealing custom-ROM-specific paths that apps scan for. Avoid adding overlay idmap paths, which can trigger a display bug.

Can SUSFS itself be detected?

In some setups, yes — no hiding method is perfect, and detection evolves. If SUSFS appears to cause problems on your device, a known fallback is using only a KernelSU-Next-patched init_boot on the stock kernel, without the SUSFS patch.

Will SUSFS brick my phone?

It can if you flash the wrong kernel for your version or skip the kernel patch. The most common serious mistake — installing the SUSFS module without a patched kernel — breaks key attestation. Match your kernel version exactly, keep a recovery image handy, and back up before you start.