SUSFS for KernelSU: Why Banking Apps Still Detect Root

TL;DR: SUSFS for KernelSU can hide selected filesystem, mount and kernel traces from local checks. It cannot change hardware-backed boot state or guarantee banking access. A bank may still detect an unlocked bootloader, an uncertified system image, installed root tools or other device changes. Back up before testing.

By the PrivacyPortal team

Last updated 12 August 2026

SUSFS for KernelSU is useful when an app searches for local signs of root. It can conceal selected paths, mounts, file metadata, memory-map entries, kernel strings and boot settings. However, it is an experimental kernel patch rather than a universal banking-app bypass. Google Play Integrity and a bank’s own checks may expose facts that SUSFS cannot alter. In practice, a root checker passes while a banking app still refuses to run. That outcome is technically possible and quite common.

What SUSFS for KernelSU can and cannot hide

SUSFS is a set of kernel-level hiding features developed for KernelSU-based systems. Because the changes work inside the kernel, they can hide traces before an ordinary Android app reads them.

Its controls can conceal selected paths and mount points. They can also spoof file metadata, hide memory-map entries, change visible kernel strings and redirect selected files. The precise controls depend on the kernel patch and userspace companion in use.

SUSFS does not make a modified phone identical to a locked, certified device. It cannot independently rewrite hardware-backed attestation. It also cannot predict every check written by a bank, identity provider or anti-fraud supplier.

Active GKI branches identified SUSFS v2.2.0 on 12 August 2026.

Caption: SUSFS sits inside the kernel and filters selected local evidence before an app can inspect it.

Why a banking app detects root despite SUSFS

A banking app rarely relies on one “rooted” flag. Modern detection combines several signals. Hiding one signal may only cause the app to test another.

• Boot state: the bootloader is unlocked or the verified boot chain has changed.
• Play Integrity: a required server-side verdict is missing.
• Local traces: mounts, paths, properties or kernel strings reveal modification.
• Installed apps: the bank finds KernelSU Manager, LSPosed or another root tool.
• Native checks: compiled code inspects the process, kernel or filesystem directly.
• Device policy: developer options, USB debugging or accessibility services trigger a block.
• ROM identity: the build fingerprint, signing keys or system files look unusual.

Some apps also combine device data with account risk signals. A clean local test therefore cannot promise access to a specific bank.

The unlocked-bootloader conflict

The central problem is simple. The official KernelSU installation guide requires an unlocked bootloader for normal installation. Unlocking allows a modified boot or kernel image to start.

Android 13 and later use hardware-backed evidence when evaluating device integrity. Google states that a qualifying device needs a locked bootloader and a certified manufacturer image for the relevant verdict. See the official Play Integrity verdict documentation.

KernelSU normally requires an unlocked bootloader, while Android 13 and later require hardware-backed proof of a locked bootloader for MEETS_DEVICE_INTEGRITY.

SUSFS can hide ordinary software traces. It cannot make trusted hardware report a locked boot chain when that chain is unlocked. An app which enforces that result may still reject the phone.

Passing Play Integrity is not the final test

Play Integrity is only one source of evidence. A bank can run its own native checks after receiving acceptable Google verdicts. It may also use a commercial fraud-detection library.

This explains reports where strong integrity appears to pass but a banking app detects root. It also explains the reverse case. A detector may label a phone “abnormal” while the user’s real banking app continues working.

Do not treat one green screen as proof. Test the Play Store certification state, hardware-backed attestation and the actual apps you need. Avoid repeated login attempts if a bank may lock access.

Which hiding tool addresses which check?

The best diagnostic question is not “Which module is strongest?” Ask which detection layer is failing.

Detection layer	Useful tool or check	Key limit
Paths, mounts and file metadata	SUSFS for KernelSU	Only hides configured local evidence
Root app list queries	Hide My Applist through LSPosed	Does not change boot state or attestation
Root permission exposure	KernelSU deny rules	Denying root is not the same as hiding modification
Play Integrity verdicts	Official Play Integrity checks	SUSFS cannot forge hardware-backed trust
Native or custom bank checks	Momo or Meow Detector for diagnosis	Results may include false positives
Bank-specific policy	The bank’s real app and support policy	No module can guarantee acceptance

Hide My Applist, also called HMA or HMAL, addresses package visibility. It is an LSPosed module. Use it only when an app appears to scan installed applications. It is distinct from root hiding and integrity work.

How to install and use SUSFS safely

This workflow applies only to your own device and must be adapted to its maintainer-approved flashing method.

1. Back up photos, files, authenticator recovery codes and app data. Bootloader unlocking wipes the phone.
2. Record the exact model, device codename, Android release and kernel version. Similar product names are not proof of compatibility.
3. Install current Android platform tools and the correct USB driver. Confirm that both ADB and fastboot can see the phone.
4. Download a device-approved KernelSU or KernelSU-Next kernel with the matching SUSFS patch. Use the files named in the “Modules, apps & files to try” section.
5. Verify the release source and any published checksum. Do not flash an image copied from an unrelated device or chat attachment.
6. Unlock the bootloader through the manufacturer’s documented process. Stop if OEM unlocking is unavailable or the consequences are unclear.
7. Save the stock boot or init_boot image and obtain the full matching factory package. These files provide the safest recovery path.
8. Flash through the kernel maintainer’s stated fastboot, fastbootd or installer process. Check the active slot and target partition before confirming.
9. Boot Android and install the matching KernelSU Manager plus the SUSFS userspace companion. Reboot before changing hide rules.
10. Confirm root, SUSFS status and normal device operation. Add the smallest required hide rules, then test again.

Prerequisites and compatibility checks

Active GKI branches cover Android 12 or 13 with kernel 5.10, Android 13 or 14 with 5.15, Android 14 with 6.1, Android 15 with 6.6, and Android 16 with 6.12. A matching branch does not prove that an image suits your device.

Read the device maintainer’s release notes. Confirm the expected Android security patch, kernel base and KernelSU manager version. Check whether the image targets boot, init_boot, vendor_boot or a custom installer.

Start with a charged battery and a tested data cable. Know how to reach the bootloader without Android. Keep the stock image on another computer.

The SUSFS4KSU project describes SUSFS as an experimental kernel patch, not a universal compatibility layer.

The SUSFS4KSU source and branch history should be the reference for supported features. Device maintainers may add separate changes which affect behaviour.

How to verify the result

First, open KernelSU Manager and confirm that its reported kernel support matches the installed build. Check the SUSFS companion for a supported state. A blank status or version mismatch is a reason to stop.

Next, test basic functions. Check calls, Wi-Fi, Bluetooth, the camera, encryption and screen locking. Reboot twice before trusting the setup.

Use Momo and a community detector such as Meow Detector to identify exposed signals. Treat their findings as clues rather than verdicts. Meow Detector can inspect mounts, KernelSU traces, overlays, Zygisk, Android IDs and custom-ROM indicators.

Finally, check Play Store certification and your required apps. A root checker passes only when that checker misses or accepts the tested signals. It does not establish kernelsu banking app compatibility.

Caption: Verification should compare kernel status, device integrity and real app behaviour rather than relying on one root checker.

How to diagnose the remaining detection

Change one variable at a time. Large module stacks make failures harder to trace and can create new detection signals.

1. Test the bank app on the clean rooted kernel before adding optional modules.
2. Deny root access to the app in KernelSU Manager and reboot.
3. Clear the app’s storage only if you understand its login and device-registration process.
4. Review SUSFS status, exposed mounts and kernel strings.
5. Check whether the app can see KernelSU Manager or other root-related packages.
6. Use HMA only if package-list detection is likely and LSPosed is already compatible.
7. Disable developer options, USB debugging or third-party accessibility services for a controlled test.
8. Remove one optional module, reboot and repeat the same checks.

HMA whitelist or template rules should hide root tools from the target app. Include HMA itself where its documentation requires that. Some combinations of HMA, LSPosed and alternative Zygisk implementations do not work reliably.

If the app still blocks access, its check may be native, remote or policy-based. That is a valid stopping point. Do not keep adding untrusted modules or leaked attestation material.

Common pitfalls that cause avoidable failures

• Flashing by kernel number alone: two 5.15 devices can use different boot layouts and vendor changes.
• Mixing manager and kernel releases: an incompatible userspace app can show incomplete controls.
• Using broad hide rules: excessive filtering may break apps or conceal useful diagnostic evidence.
• Installing every suggested module: each module adds code, mounts, packages and possible conflicts.
• Restoring bank data from a rooted backup: cached state may survive after the technical issue changes.
• Assuming strong integrity guarantees access: banks can enforce extra checks.
• Relocking carelessly: relocking with modified or incompatible images can make a device unbootable.
• Testing without recovery files: an OTA or wrong-slot flash can leave no quick route back.

Community reports about one bank, device or ROM are useful leads. They are not universal fixes. App releases and server policies can change without notice.

Security, OTA and warranty consequences

Kernel-level hiding increases complexity in a security-sensitive part of Android. Use reviewed source, known maintainers and reproducible releases where possible. A malicious root module receives unusually powerful access.

SUSFS can also hide information from diagnostic and security tools. Grant root only to apps you trust. Review KernelSU permissions and remove unused modules.

Over-the-air updates may overwrite the patched image or fail validation. Keep the stock image and note the active slot before each update. Wait for a compatible kernel release after a major Android or kernel update.

Bootloader unlocking may affect warranty support, device protection, DRM and corporate enrolment. The position varies by manufacturer and country. Banking and payment access can change after any app update.

If dependable banking matters more than root, restore the full certified firmware and leave the bootloader locked. A supported unrooted device is the lowest-maintenance choice. PrivacyPortal’s practical Android privacy guide covers privacy steps which do not require kernel modification.

Caption: Keep the stock factory package beside the tested patched image so recovery does not depend on a working phone.

Should you use SUSFS for KernelSU?

Use SUSFS when you understand kernel flashing, have exact recovery files and need to reduce local root traces. It is most suitable for enthusiasts who can diagnose boot loops and restore the correct partition.

Do not use it solely because one banking app is essential. The app may require a hardware-backed state that an unlocked rooted device cannot provide. No honest guide can promise to hide root from banking apps in every case.

A useful decision rule is simple:

• Choose SUSFS when local mount or filesystem detection is the known problem.
• Add HMA only when installed-app scanning is the likely problem.
• Return to stock when hardware-backed integrity or dependable banking access is essential.
• Avoid rooting when you lack a tested backup, factory image or recovery route.

For a broader foundation, read PrivacyPortal’s guide to rooting Android safely before modifying a daily-use phone.

Frequently asked questions

Does SUSFS for KernelSU make banking apps work?

No. It can hide selected local traces, but a banking app may inspect boot state, Play Integrity, installed packages or native signals. Compatibility depends on the phone, ROM, kernel, app version and the bank’s current policy.

Why does my root checker pass while my bank still blocks me?

A root checker passes only its own tests. The bank may use different native code, hardware-backed attestation or remote risk rules. Passing one detector is not proof that the device appears stock.

Can SUSFS make an unlocked bootloader look locked?

It may hide some locally readable boot information. It cannot independently change the boot state reported by hardware-backed attestation. Do not treat a spoofed local value as genuine locked-bootloader proof.

Is Hide My Applist a replacement for SUSFS?

No. HMA hides selected installed apps from package-list queries. SUSFS hides selected kernel and filesystem evidence. Neither tool guarantees that a bank will accept the device.

Will installing SUSFS wipe my data?

Installing a module may not wipe data, but the required bootloader unlock normally does. Back up first. Flashing an incompatible kernel can also cause a boot loop or data loss.

Can I relock the bootloader after installing KernelSU?

Do not relock unless the device maintainer explicitly supports the exact signed images in use. Relocking with modified or mismatched partitions can brick the phone. Returning to complete stock firmware is usually required first.

What should I do when a banking app still detects root?

Stop adding random modules. Check the app’s root denial, package visibility, SUSFS status, Play Store certification and device integrity. If hardware-backed or bank-specific policy is the cause, restore certified stock firmware or use a separate unmodified device.