TL;DR: SUSFS for KernelSU can reduce filesystem and mount clues that expose root. It cannot make a modified phone look stock to every banking app. Hardware-backed integrity, native checks, app-list scans, custom-ROM signals and private risk rules can still cause a block. Back up before changing anything.
By the PrivacyPortal team
Last updated July 2026
SUSFS helps KernelSU conceal several traces created by root and systemless modules. It works inside the kernel, so it can hide evidence that user-space tools may miss. However, banking apps rarely trust one signal. An app may inspect boot state, installed packages, native libraries or Play Integrity results. Its server may also apply private risk rules. This explains why a root checker passes while a banking app still refuses to run.
What SUSFS for KernelSU actually hides
SUSFS is a set of kernel changes designed for KernelSU environments. It alters what selected processes can see through the Linux virtual filesystem.
Depending on the build and configuration, it can conceal suspicious mounts, paths and filesystem metadata. Some releases can also mask selected kernel or overlay-related details. Support varies between kernel branches, patches and user-space modules.
This approach matters because root modules often create unusual mount entries. Native detection code can read these entries without using Android's Java APIs. A simple denylist may therefore miss them.
SUSFS does not remove root from the phone. KernelSU still has privileged kernel code. The bootloader may remain unlocked. System files, properties and installed tools may still reveal modification.
A kernel-layer diagram shows SUSFS filtering selected filesystem evidence before an untrusted app can inspect it.
Android Native Root Detector v6.8.0 was the exact native test build reviewed for this guide in July 2026.
Why banking apps still detect root
A banking app can combine many signals. SUSFS only addresses part of that detection surface.
- Boot integrity: The app can request hardware-backed information about the device and boot state.
- Native checks: Compiled code can inspect mounts, memory maps, processes and unusual kernel behaviour.
- Installed-app scans: A visible KernelSU manager, terminal or module tool can raise a flag.
- Hook detection: Some apps search for Zygisk, LSPosed or altered runtime behaviour.
- ROM signals: Test keys, debug properties and custom build details may look suspicious.
- Server decisions: The provider can combine device results with account and fraud data.
The official Play Integrity overview describes several verdict types. Passing one verdict does not prove that every local check passed.
In practice, Native Detector may report “Abnormal” while a financial app still works. The reverse also occurs. A clean detector result is useful evidence, but never a guarantee.
PrivacyPortal’s community evidence was refreshed on 27 July 2026; one “normal” detector result still did not guarantee banking access.
Which hiding layer solves which problem?
| Layer | What it can reduce | What it cannot prove |
|---|---|---|
| SUSFS | Suspicious paths, mounts and supported filesystem clues | A locked bootloader or trusted device verdict |
| KernelSU app profiles | Root access and module exposure for selected apps | Removal of every kernel or ROM trace |
| Play Integrity fixes | Some device or app integrity failures | Success against private local checks |
| Hide My Applist | Root-related apps exposed through package queries | Native mount, boot or memory checks |
| Zygisk or hook hiding | Some runtime injection signals | Safety from advanced hook detection |
A smaller stack is often easier to test. Each extra module can add a new fault or detection clue.
The comparison highlights why several independent checks can disagree on the same rooted phone.
How to install SUSFS for KernelSU safely
Use this process only on your own device, with files built for its exact software release.
- Back up first. Copy photos, files, authenticator recovery codes and app data somewhere separate.
- Record the device model, codename, Android build, kernel version and current KernelSU branch.
- Get the KernelSU Manager, matching SUSFS-enabled kernel and SUSFS4KSU module. Use the appended “Modules, apps & files to try” section.
- Check each maintainer, release note and checksum. Never flash a kernel merely because the Android version matches.
- Save the stock boot images and full ROM package. Confirm that you can enter bootloader or recovery mode.
- Unlock the bootloader only if the supported install requires it. Unlocking wipes user data.
- Flash or install the SUSFS-enabled kernel using its device-specific instructions. Do not guess the boot partition.
- Reboot and open KernelSU Manager. Confirm that KernelSU is working before adding any module.
- Install the matching SUSFS4KSU user-space module through KernelSU Manager. Reboot again.
- Enable only the supported SUSFS options. Verify normal boot, root control and app behaviour before adding anything else.
Prerequisites that must match
A SUSFS module alone cannot add missing kernel support. The running kernel must contain a compatible SUSFS patch.
Match the exact device codename, kernel base and Android build. Also check the expected KernelSU branch. KernelSU, KernelSU Next and other forks may use different patches or module interfaces.
The official KernelSU module guide explains its systemless module model. The SUSFS4KSU project source should be checked for current compatibility notes.
Keep the phone charged. Use a reliable cable if flashing from a computer. Remove old hiding modules where the maintainer requires a clean setup.
Bootloader and data-loss warning
Unlocking the bootloader normally performs a factory reset. Treat every unlock attempt as a complete data-loss event.
Unlocking can affect warranty support, device security and over-the-air updates. Some manufacturers do not provide an official unlock route.
Never relock while modified or unsigned images remain installed. A locked device may reject them and fail to boot.
Android’s bootloader specification requires user data to be erased when a supported device changes from locked to unlocked.
How to verify the installation
First, confirm that Android boots twice without intervention. Then check that KernelSU Manager reports the expected kernel integration.
Open the SUSFS module interface or status page. Confirm that the kernel feature is available. An installed module with an unsupported-kernel warning is not a working setup.
Test with Android Native Root Detector v6.8.0, Applist Detector and Play Integrity API Checker. These tools examine different signals. Do not grant them root.
Test the real banking app last. Repeated detector success does not promise access. Avoid clearing financial-app data unless you have working recovery and two-factor credentials.
A verification screen sequence shows kernel support, module status and separate detector results.
When a root checker passes but banking still fails
If a root checker passes, that only means its known tests found nothing. The banking app may have different code or newer rules.
Start with one controlled change at a time:
- Remove root permission from the target app.
- Exclude the app from KernelSU modules where supported.
- Hide or uninstall obvious root-management and diagnostic apps.
- Check whether the app requires a stronger Play Integrity verdict.
- Disable extra hooking frameworks and retest after a clean reboot.
- Check for developer options, USB debugging or accessibility restrictions.
Some providers cache a failed result locally or on their server. Reinstalling may not reset that decision. It can also trigger account recovery, so proceed with care.
If a banking app detects root after every controlled test, stop adding modules. More concealment code can reduce security and create fresh signals.
When Hide My Applist may help
Hide My Applist, often called HMA or HMAL, targets installed-app queries. It can hide KernelSU Manager and other selected packages from a target app.
HMA requires LSPosed. That framework changes the runtime and may itself be detected. Compatibility with ZygiskNext or ReZygisk also varies between setups.
Use HMA only when evidence points to an app-list scan. Whitelist mode can limit what the target sees. It does not hide kernel mounts, boot state or hardware attestation.
This distinction matters when trying to hide root from banking apps. A package-list fix will not solve a native filesystem finding. SUSFS will not hide a visible manager package by itself.
Common SUSFS and KernelSU pitfalls
- Module-only installation: The app installs, but the kernel lacks the required patch.
- Wrong kernel build: A similar model or security patch level is not close enough.
- Stacking fixes: Several modules change the same mount, property or runtime path.
- Testing without rebooting: Kernel and module changes may not apply until a full restart.
- Trusting one detector: Detector apps can miss checks or produce false positives.
- Restoring old modules after an OTA: Their patches may not support the new kernel.
- Relocking too soon: Modified boot images can cause a boot failure on a locked device.
If a module causes a boot loop, use the documented KernelSU safe mode where available. Otherwise, restore the exact stock image through the device’s supported recovery route.
Our Android bootloader unlocking guide explains the wider recovery and data-loss risks.
A practical decision framework
SUSFS for KernelSU is worth considering when native tools report suspicious mounts or paths. It is less relevant when the only failure is an installed-app query.
- Mount or path finding: Check SUSFS kernel support and configuration.
- Manager package found: Remove or isolate the package before adding hooks.
- Play Integrity failure: Diagnose the exact verdict instead of assuming SUSFS will fix it.
- Zygisk or LSPosed found: Reduce injection-based modules and retest.
- Custom-ROM signal: Review build properties and the ROM’s support status.
- No clear signal: Return to a minimal setup or use a stock secondary device.
This framework improves KernelSU banking app compatibility testing. It does not promise that a provider will accept the device.
Security, OTA and maintenance trade-offs
Root and an unlocked bootloader weaken some Android security boundaries. SUSFS conceals evidence, but it does not restore those boundaries.
A third-party kernel also becomes part of the trusted computing base. Review its source, maintainer history and release process. Avoid random builds shared through short-lived file hosts.
An OTA may replace the modified kernel. It may also fail because a boot partition changed. Wait for a matching updated build before restoring SUSFS or KernelSU.
Banking-app rules can change without notice. A setup that works today may fail after an app or server update. Keep a recovery plan and avoid relying on a rooted phone as the sole route to essential funds.
For users who value predictable updates over root access, a supported privacy-focused operating system may be a better fit. See our guide to de-Googled Android phones for the trade-offs.
Frequently asked questions
Why does my banking app detect root when a root checker passes?
The apps may test different signals. A bank can use native code, package scans, Play Integrity and private server rules. A root checker only reports the checks it knows.
Does SUSFS make Play Integrity pass?
No. SUSFS mainly reduces supported filesystem and mount evidence. Play Integrity can use hardware-backed boot information and other signals. Separate changes may affect its verdicts.
Can SUSFS hide root from banking apps?
SUSFS for KernelSU can reduce some root clues. It cannot guarantee access to any banking app. Never rely on claims that a fixed module stack defeats a named provider.
Why does Native Detector still show “Abnormal”?
It may detect Zygisk, unusual mounts, Tricky Store, an unlocked bootloader or another modification. False positives also occur. An abnormal result does not always predict real app behaviour.
Do I need Hide My Applist with SUSFS?
Only consider it when the target scans installed apps. HMA solves a different problem and requires LSPosed. Adding LSPosed can introduce another detection surface.
Will SUSFS survive an Android update?
Not always. An OTA can replace the kernel or change its compatibility. Install only a SUSFS-enabled build made for the updated firmware.
Can I relock the bootloader after installing SUSFS?
Do not relock with modified images unless the device and ROM explicitly support them. Relocking an incompatible build can brick the phone. Restore verified stock firmware first.
Is SUSFS for KernelSU suitable for beginners?
Only with a device-specific guide and a tested recovery path. Beginners should practise backups and stock-image restoration first. A separate unmodified phone remains the safest choice for essential banking.
PrivacyPortal sells ready-to-use, de-Googled GrapheneOS Pixels — hardened, kept updated, and shipped with our encrypted Graphite messenger. Browse privacy phones →
