Awesome Android Root

SUSFS Root Hiding Guide

SUSFS is a kernel-level hiding extension for KernelSU and its variants. Where a userspace module can only lie to apps it manages to hook, SUSFS changes what the kernel itself reports: hidden paths, hidden mounts, spoofed stat results, spoofed kernel version strings and cleaned-up AVC audit logs. This page covers what it does, how the two halves fit together, how to get it on your device, and how to verify it actually loaded.

Requires an unlocked bootloader and root. Read the KernelSU Guide first if you have not rooted yet.

Quick Navigation ​

Related Guides:

What SUSFS Does ​

SUSFS, short for a systemless filesystem hiding layer, is an addon for KernelSU that the upstream project describes as experimental. It does not grant root and it does not mount modules: it hides the traces root leaves behind. The behaviours it provides, as reported by its own feature list:

BehaviourWhat it hides or spoofs
Path hidingFiles and directories disappear from directory listings and lookups
Mount hidingModules' mounts are hidden from non-root processes, and root's own mount view can be hidden entirely
kstat spoofingstat, statx and statfs results for a path report the timestamps, inode and size of the original
Map hidingInjected libraries and their maps entries are removed from a process's memory map view
Kernel identity spoofinguname release and build strings, plus cmdline / bootconfig contents
Open redirectionOpening one path silently returns the contents of another file
AVC log spoofingKernelSU-related SELinux contexts are rewritten in the audit log
Symbol and module hidingKernelSU and SUSFS symbols are hidden from kallsyms, and named kernel modules can be dropped from /proc/modules
Logging switchKernel-side SUSFS logging can be toggled on and off at runtime

What it does not do: it does not fix Play Integrity by itself, it does not hide your app list, and it does not make a rooted device indistinguishable from a stock one. Treat it as one layer. App Profiles, a Zygisk implementation and an attestation layer still matter, as described in the KernelSU Guide.

How It Works ​

SUSFS has two halves and both are required.

Kernel side ​

The kernel patches add hooks around filesystem and process paths in the kernel and in KernelSU itself. Since the 2.0 line these are inline hooks rather than kprobes, so SUSFS no longer depends on KPROBES, KRETPROBES or HAVE_SYSCALL_TRACEPOINTS being available, and the old sus_su mechanism was dropped. A set of CONFIG_KSU_SUSFS_* options controls which behaviours are compiled in, so a kernel can ship a subset: a device with only path hiding compiled in will silently ignore mount-hiding commands.

Userspace side ​

A small tool called ksu_susfs lives in /data/adb/ksu/bin/. It talks to the kernel over KernelSU's supercall and is what you or a module actually run:

bash
ksu_susfs show version           # SUSFS version
ksu_susfs show enabled_features  # which CONFIG_KSU_SUSFS_* options are compiled in
ksu_susfs show variant           # patched kernel or loadable module

ksu_susfs add_sus_path /data/local/tmp
ksu_susfs add_sus_kstat_statically /system/etc/hosts
ksu_susfs add_open_redirect /system/etc/hosts /data/adb/hosts
ksu_susfs set_uname 6.1.75-android14-11-g16c5f6cd5e9b-ab12268515
ksu_susfs enable_avc_log_spoofing 1
ksu_susfs hide_sus_mnts_for_non_su_procs 1

Run ksu_susfs with no arguments in a root shell for the full command list. Most users never type these: a module wraps them into boot scripts and a WebUI.

The userspace modules ​

Two community modules ship the tool plus curated rule sets, so you get sensible defaults instead of an empty rule table:

  • SUSFS for KernelSU - the well established option. Ships ksu_susfs, a config file and a WebUI, hides the usual suspects (root app folders, recovery folders, /data/local/tmp entries, Android/data, Android/media, Android/obb), and includes optional kernel string spoofing.
  • BRENE - a hardening-focused alternative. Beyond hiding it also hides traces left by custom kernels, font and Zygisk modules' map entries, and spoofs selected system properties, with settings surfaced in the Manager.

WARNING

Both modules apply aggressive hiding by default. Hiding a path also hides it from your own file managers and backup apps, which is the most common source of "my storage looks empty" reports. Start with the defaults, then add rules one at a time.

Requirements ​

RequirementDetail
RootKernelSU, KernelSU-Next, SukiSU-Ultra or BakaSU. Magisk cannot use SUSFS
SUSFS-capable kernelEither compiled into the kernel, or loaded as a kernel module (see below)
Matching KMIOnly for prebuilt kernels and prebuilt SUSFS modules
Userspace moduleProvides ksu_susfs and the rules; kernel alone does nothing by itself
A metamodule, if you use mounted modulesKernelSU-Next, official KernelSU and BakaSU still need one for /system modules
Backup and recovery planRoot + kernel changes carry bootloop risk. Keep the stock image

Check what your current setup already reports. KE in the output means the feature is compiled in:

bash
su -c 'ksu_susfs show version; ksu_susfs show enabled_features'
# KernelSU-Next also has a built-in check:
su -c 'ksud susfs support; ksud susfs features'

Getting SUSFS ​

You need a kernel that carries the patches. There are three practical routes.

Option 1: Prebuilt community kernel ​

Fastest route. Community kernel projects build KernelSU or KernelSU-Next with SUSFS already patched in, for example the WildKernels GKI builds. Match the KMI and the kernel's security patch level to your device, flash it, then install the userspace module. See Root Hiding & Play Integrity and the kernel build sources in Resources for current projects.

Option 2: Patch and build your own kernel ​

For control, or when no prebuilt kernel covers your device. Upstream keeps per kernel-version branches rather than one master branch, and the patch set changes between kernel lines:

  1. Clone official KernelSU at a release tag, and the matching SUSFS branch at a tag.
  2. Apply 10_enable_susfs_for_ksu.patch inside the KernelSU directory and 50_add_susfs_in_kernel-<version>.patch at the kernel root, then copy the patch set's fs/susfs.c and include/linux/susfs.h into place.
  3. Enable CONFIG_KSU_SUSFS=y and choose the CONFIG_KSU_SUSFS_* features you want in defconfig or the KernelSU Kconfig.
  4. Build against the Google GKI artifacts (or the DDK toolchain for LKM builds). For Android 14 and newer GKI builds, delete the abi_gki_protected_exports_* files or some vendor modules will not load, and make sure the boot image's security patch level is not older than your device's.
  5. Flash, boot, install the userspace module.

Upstream's README has the exact copy and patch commands, plus notes for -dirty version strings and spoofing /proc/config.gz with your stock config.

Option 3: SUSFS as a loadable kernel module ​

The newest route, and the reason SUSFS no longer forces a kernel rebuild on GKI devices. A loadable SUSFS module, commonly named susfs_guard_lkm, is loaded into a stock or lightly modified GKI kernel through ksud insmod, with the loader filling in symbol addresses from kallsyms at load time.

  • KernelSU-Next ships prebuilt SUSFS kernel modules for each KMI and manages them itself:
    bash
    ksud susfs load            # load for the detected KMI
ksud susfs unload
ksud susfs autoload enable # load automatically at post-fs-data
ksud susfs autoload status
    This is arm64 only. Set the fallback KMI if boot-time detection is unreliable.
  • Other variants use a loader module that detects the device, downloads the matching module file and loads it on boot, for example susfs4ksu-lkm-module. The kernel modules themselves are published by susfs4ksu-lkm.

You still need the userspace module from the previous section: the loadable kernel module provides the kernel half, not the rules.

NOTE

Loading a kernel module into a kernel it was not built for can panic the device. Match the KMI exactly, and prefer the prebuilt set that ships with your root manager.

Configuring It ​

Install the userspace module through your manager's module installer and reboot. Then:

  • Open the module's WebUI (KernelSU Manager, module card) and work through the toggles: path hiding groups, mount hiding for non-root processes, kernel string spoofing, AVC log spoofing, logging.
  • Settings live in files too. SUSFS modules keep configuration and rule lists under /data/adb, so they can be backed up and diffed. Persistent rules belong there, because rules added by hand with ksu_susfs are lost on reboot.
  • Add rules sparingly. Hiding a path means hiding it from everything that does not have root, including your own tools and the apps you use daily.
  • Keep logging on while tuning. It makes the difference between "SUSFS is hiding this" and "SUSFS is not loaded" visible; turn it off once the setup is stable if you prefer a quieter log.

Verifying It Works ​

Do these in order. If step 2 fails, nothing later matters.

  1. Is the kernel side present?
    bash
    su -c 'ksu_susfs show version; ksu_susfs show variant'
su -c 'dmesg | grep -i susfs | tail -20'
    A missing binary means the userspace module is not installed; an error from the command means the kernel half is not patched or not loaded.
  2. Which features are actually compiled in?
    bash
    su -c 'ksu_susfs show enabled_features'
    Compare against what the kernel project advertised. A missing CONFIG_... is a kernel build question, not a configuration one.
  3. Do the rules take effect? List a hidden directory from a root shell and from a non-root context; the two should differ. The module description in your Manager usually shows the detected status too.
  4. Do detectors agree? Run a root detection app before and after, and test the app you actually care about rather than a demo checker. Hiding is app-specific: a bank may check for far more than paths and mounts.

TIP

Detector results are a snapshot, not a verdict. Tools such as Duck Detector, Native Root Detector and Applist Detector are listed under Root Detection & Testing if you want to see what leaks, and Troubleshooting covers the attestation side.

Troubleshooting ​

SymptomLikely causeFix
ksu_susfs: not foundUserspace module missing or removedInstall the module, reboot
Commands return an error, no versionKernel is not SUSFS patchedUse a patched kernel or load the SUSFS kernel module
Feature "supported" but nothing changesComponent not compiled into the kernelRebuild with the needed CONFIG_KSU_SUSFS_* options, or use a kernel that has them
ksud susfs unusableNon-arm64 device or wrong manager variantUse a loader module instead, or a device-specific kernel
Bootloop after installingKernel or rule set mismatchBoot to safe mode, disable modules, reflash the stock or previous kernel
Storage looks empty in file managersPath hiding is hiding /sdcard entriesAllow root for the file manager, or reduce the hidden path set
A module stopped mountingMetamodule removal or uninstallReinstall a metamodule, then reinstall the module
Banking app still refusesDetection beyond kernel signalsAdd app profiles, a hiding module and attestation; test the real app

Recovery basics live in the KernelSU Guide: safe mode with three volume-down presses right after the first boot screen, ksud module disable over ADB or recovery, and flashing the stock image as the last resort.

ResourceLink
SUSFS patches and tool (upstream)gitlab.com/simonpunk/susfs4ksu
SUSFS for KernelSU (module)github.com/sidex15/susfs4ksu-module
BRENEgithub.com/rrr333nnn333/BRENE
SUSFS LKM loader modulegithub.com/Nixie24/susfs4ksu-lkm-module
SUSFS LKM sourcegithub.com/inforcqb/susfs4ksu-lkm
KernelSU-Next (SUSFS kernel module management)github.com/KernelSU-Next/KernelSU-Next
Build a KernelSU kernelkernelsu.org/guide/how-to-build.html

Getting help: include your device model, kernel release (adb shell uname -r), root variant, the output of ksu_susfs show version and show enabled_features, the userspace module you installed, and whether SUSFS came from the kernel or a loadable module.