TL;DR: No. SUSFS can conceal selected kernel and filesystem signs associated with root, but it cannot hide root from every app. A clean detector result only confirms that one detector found no recognised signals. Other apps may examine different artefacts, device integrity, boot state, app history or server-side Play Integrity verdicts.
By the PrivacyPortal team
Last updated July 2026
SUSFS is one of the strongest filesystem-level hiding options available for compatible KernelSU-based setups, particularly when it is built into the device’s kernel. In practice, however, root detection is not a single test. An app may look for mounted files, privileged processes, modified properties, an unlocked bootloader, custom-ROM fingerprints or hardware-backed attestation. SUSFS narrows some of those detection surfaces; it does not control them all. Before changing a kernel, boot image or root configuration, back up everything you cannot replace. Unlocking a bootloader normally wipes the device, and flashing an incompatible image can leave it unable to boot.
Image caption: Root detection is a collection of independent checks rather than one universal pass-or-fail test.
What SUSFS actually hides
SUSFS, commonly expanded as “SUS File System”, is a set of kernel-side changes designed to conceal selected filesystem and kernel artefacts from processes running on Android. It is closely associated with KernelSU and compatible forks such as KernelSU Next and SukiSU Ultra.
The important distinction is that SUSFS is not merely an ordinary root-hiding module. Its core capability must exist in the kernel. A companion userspace module or helper may configure features such as suspicious-path rules, mounted-path concealment and other runtime settings, depending on the kernel and root-manager build.
A correctly integrated setup may reduce exposure of:
- Root-related files and directories visible through normal filesystem queries.
- Mount information that reveals systemless modifications or module overlays.
- Selected kernel and boot-state information exposed to applications.
- Paths deliberately added to the configured SUSFS concealment list.
The exact features depend on the kernel patch version, integration method and userspace component. Check the official SUSFS4KSU project documentation for the release and compatibility details relevant to your build rather than assuming that any file labelled “SUSFS” supports every feature.
SUSFS requires kernel-side support; installing a userspace module alone does not add the underlying kernel functionality.
Why a clean detector result can still fail in a real app
A detector app reports only what its own process could observe using its implemented checks at that moment. It does not certify the device as universally indistinguishable from a locked, unmodified phone.
Two applications can reach different conclusions because Android isolates apps and because detection logic varies. A public detector might test mount tables and familiar root paths. A banking, streaming, workplace or game app might combine local checks with remote risk scoring, account history or an integrity token evaluated by its server.
Detection can also change after an update without anything changing in SUSFS. The target app may add a new check, alter its native code or move a decision from the device to a backend service. Conversely, a detector update can start reporting a signal it previously ignored.
What actually happens in community testing is therefore unsurprising: Duck Detector, Meow Detector or a similar diagnostic tool may show no highlighted findings while a target app still refuses to run. Neither result necessarily proves that the other tool is defective. They may simply be measuring different things.
A clean result means that one detector, with one version and one set of checks, found no recognised signal during that test.
Detection layers SUSFS can and cannot address
| Detection layer | Example signal | Can SUSFS help? | Important limitation |
|---|---|---|---|
| Filesystem | Known root paths or module files | Often | Only configured or supported paths are concealed. |
| Mounts | Overlay or systemless-module mounts | Often | Incorrect ordering or integration can expose them. |
| Kernel information | Selected modified-state indicators | Sometimes | Coverage depends on the exact kernel patch. |
| Root manager | Manager package, process or configuration artefacts | Partly | Manager-specific signals may remain outside SUSFS. |
| Boot chain | Unlocked bootloader or non-stock boot image | Not reliably | Verified Boot state can be obtained through other channels. |
| ROM identity | Custom build properties or signing keys | Not by itself | A custom ROM presents signals beyond filesystem paths. |
| Play Integrity | Device or strong-integrity verdict | No direct control | Verdicts can use hardware-backed and server-side evidence. |
| App risk systems | Account, device or behavioural risk score | No | The decision may occur entirely on the app’s server. |
Play Integrity is separate from local root hiding
Google Play Integrity allows an app to request a signed integrity token and send it to a backend for verification. The response can contain device-integrity and other verdicts, depending on the request and the app’s implementation. Google describes the mechanism in the official Play Integrity API documentation.
SUSFS does not grant a particular Play Integrity verdict. Local concealment may prevent an app from observing certain root artefacts, but it does not independently relock the bootloader, restore the original verified boot chain or dictate what Google’s service returns.
This explains a common result: a local detector looks clean, yet an app still rejects the device after contacting its server. The server may be enforcing an integrity verdict that the detector never requested. Different apps can also require different verdicts, so success in one financial app never guarantees success in another.
No guide, module or kernel can responsibly promise permanent compatibility with a particular bank. Detection rules, backend policy and Play Integrity behaviour can all change.
Image caption: Local filesystem concealment and remote integrity evaluation operate at different layers.
Choose the right SUSFS foundation
SUSFS is most useful when the kernel, root manager and userspace helper are built for one another. Installing components from unrelated releases can produce missing features, boot loops or a configuration that appears enabled but does not conceal the intended paths.
Use this decision framework:
- Stock kernel with no SUSFS support: a companion module cannot supply the missing kernel patch. Use a device-specific supported kernel or build the patch into a compatible kernel.
- SUSFS-enabled custom kernel: confirm the kernel’s documented root-manager and Android compatibility before flashing.
- KernelSU Next or SukiSU Ultra: use only the SUSFS integration and userspace component recommended by that exact project and kernel maintainer.
- Magisk-only setup: do not assume a KernelSU module will work. Magisk uses a different root architecture and ordinarily cannot gain SUSFS merely by installing a module ZIP.
- Custom ROM: expect additional detection signals. A stock ROM with root frequently has fewer identity changes than a custom ROM with root.
The official KernelSU installation guide explains its kernel requirements and supported installation models. Device-specific maintainer instructions take precedence over generic tutorials.
How to install and verify SUSFS safely
This procedure is intentionally device-neutral because flashing the wrong boot, init_boot or kernel image is a genuine bricking risk. Before starting, identify the exact model, regional variant, Android build and current boot-slot arrangement. Download only components explicitly built for that combination.
- Back up the phone. Copy photographs, authenticator recovery codes, messages and important files somewhere independent of the device. Export anything that cannot be restored from a normal cloud or local backup. Bootloader unlocking normally performs a factory reset.
- Prepare a recovery path. Obtain the exact stock boot-related images and full factory firmware for the installed build. Install working Android platform tools on the computer, confirm that the correct USB drivers are available, and learn the device’s documented fastboot or recovery procedure.
- Check bootloader and warranty implications. Unlock only a device you own and are authorised to modify. Unlocking may affect warranty support, erase data, weaken physical security and cause apps to reject the phone. Read our Android bootloader unlocking guide before proceeding.
- Select one compatible root foundation. Choose the device-specific KernelSU Next or SukiSU Ultra kernel, boot image or init_boot image recommended by its maintainer. Do not combine images from different firmware builds, and do not flash a generic GKI image unless the maintainer explicitly supports that route.
- Record exact releases. Write down the Android build, kernel release, root-manager version, SUSFS patch or helper release and download source. Avoid silently mixing a current manager application with an old kernel implementation.
- Verify the downloads. Compare published hashes where the maintainer supplies them. Keep the stock image beside the modified image and label both clearly. The relevant components should be listed in the accompanying “Modules, apps & files to try” section.
- Flash using the maintainer’s method. Some devices use boot, others init_boot, vendor_boot or a full kernel package. Use the documented command and partition for the exact device. If temporary booting is supported, test the image before permanently flashing it.
- Confirm a normal boot first. Allow Android to start fully and verify calls, networking, encryption and basic applications before installing additional modules. If the phone loops, restore the matching stock image rather than repeatedly flashing unrelated packages.
- Install the matching SUSFS userspace component if required. A kernel may include SUSFS capability but still require a KernelSU-compatible helper for additional rules. Other integrations provide what they need without a separate module. Follow the kernel maintainer’s instructions instead of installing duplicate SUSFS helpers.
- Configure conservatively. Add only paths or features required by the documented setup. Large copied concealment lists can hide legitimate files, break applications or make faults difficult to diagnose. Avoid stacking overlapping hiding modules until the baseline works.
- Reboot and verify support. Open the root-manager application and confirm that the installed kernel and SUSFS capability are recognised. Check the helper’s status or logs for unsupported commands, version mismatches and failed rules.
- Test in layers. First run a local detector such as Duck Detector or Meow Detector without granting it root. Then test ordinary apps, Play Integrity diagnostics and the target app separately. Record results, but treat each result as evidence about that test only.
After a successful installation, keep the stock images and version notes. An over-the-air update may replace the modified boot components, disable root or fail to install. Never assume that an image built for the previous monthly firmware remains safe after an OTA update.
Common SUSFS pitfalls in practice
- Installing only a module: the interface may appear present even though the running kernel lacks SUSFS support.
- Mixing releases: kernel and userspace commands can differ, leaving features unavailable or partially configured.
- Using aggressive path lists: broad rules can hide files an app or Android service genuinely needs.
- Stacking concealment tools: two modules may compete over mounts, properties or process timing and expose more anomalies.
- Testing after granting root: a diagnostic app given superuser access is no longer testing the same view as an ordinary unprivileged app.
- Ignoring the manager application: its package, data, processes or notifications may remain detectable independently of filesystem concealment.
- Equating detection with attestation: removing local findings does not repair an integrity verdict tied to the boot chain.
- Updating blindly: OTA firmware can change the kernel or boot image, while reusing an old patched image can cause a boot loop or security regression.
Image caption: Version mismatches and overlapping modules are frequent causes of unreliable SUSFS configurations.
Security and maintenance trade-offs
Root grants powerful control, but it also changes Android’s security assumptions. A poorly protected superuser interface or untrusted module can expose data far beyond what a normal app can access. Hiding root does not remove that risk.
Use the smallest module stack you can, deny superuser access by default and review every root prompt. Obtain source and releases from the official project or a trusted device maintainer. A module that promises universal invisibility should be treated sceptically, particularly if its source, build process or maintainer is unclear.
Kernel modifications also create a maintenance obligation. Security patches delivered through an OTA do not automatically carry SUSFS forward. You may need a newly patched image for every firmware update, followed by another backup, compatibility check and verification cycle. If dependable updates, banking compatibility or a locked boot chain matters more than root, a stock unrooted device is the safer choice. PrivacyPortal’s privacy-first Android phones offer a more maintainable route for people who want less Google dependence without managing a root-hiding stack.
Frequently asked questions
Does SUSFS hide root from every banking app?
No. SUSFS can hide certain kernel and filesystem evidence, but each banking app chooses its own local checks and server-side policy. Some also use Play Integrity or other risk systems. No configuration can responsibly guarantee compatibility with a named bank.
Why does my root detector pass while an app still detects root?
The detector and target app probably examine different signals. The target app may detect the root manager, unlocked bootloader, custom ROM, native-code artefacts or a remote integrity verdict that the local detector does not test.
Is SUSFS a Magisk module?
Not in the ordinary sense. SUSFS requires kernel-side implementation. A module or userspace helper can configure supported features, but it cannot create the kernel capability on an unpatched kernel.
Do I need a separate SUSFS module?
It depends on the kernel integration. Some builds require a matching userspace component for additional concealment rules; others bundle or manage the necessary interface differently. Follow the documentation for the exact kernel and root-manager release.
Is KernelSU with SUSFS undetectable?
No. Kernel-level root may expose fewer familiar userspace artefacts than some alternatives, but it is not inherently undetectable. Apps can inspect unrelated signals, and SUSFS itself may present identifiable behaviour in a particular configuration.
Will SUSFS restore strong Play Integrity?
SUSFS does not directly control Play Integrity verdicts. Strong integrity can depend on hardware-backed evidence, the verified boot chain, device certification and Google’s server-side evaluation. Results may also change without a local configuration change.
Can an OTA update remove SUSFS or root?
Yes. An OTA may replace the kernel, boot or init_boot image containing the modification. It can disable root, cause a version mismatch or require a newly patched image. Restore stock components when required and never flash an image intended for a different firmware build.
What should I do if the phone boot-loops?
Stop adding modules or flashing experimental images. Enter the device’s bootloader or documented recovery mode and restore the exact stock image for the installed firmware and partition. If that recovery path was not prepared before flashing, seek model-specific help rather than guessing partitions.
