TL;DR: BRENE v0.0.55 is a module for people running susfs for kernelsu with a SUSFS-patched kernel and susfs4ksu 2.2.0 or newer. Released on 17 July 2026, it improves Android 16 property handling, adds a sus mount feature and updates its WebUI. It cannot guarantee that banking or integrity checks will pass.
By the PrivacyPortal team
Last updated July 2026
BRENE v0.0.55 is a targeted hiding and configuration module for KernelSU installations backed by a compatible SUSFS kernel patch. Its most important Android 16 change is the removal of the obsolete sys.oem_unlock_allowed property on API 36 and later, rather than setting it to 0. That distinction matters because recreating a property removed by Android can itself become an unusual, detectable signal. BRENE also adds sus mount functionality, moves property work later in the boot process and exposes clearer Android and SUSFS information in its WebUI. It is useful refinement, not a universal bypass: apps can inspect bootloader state, device integrity, installed software and server-side risk signals beyond the filesystem.
What is BRENE v0.0.55?
BRENE is a KernelSU module designed for devices whose kernels have already been patched with SUSFS. SUSFS, short for “suspected filesystem”, adds kernel-level mechanisms for concealing selected mounts, paths and other root-related artefacts from userspace processes.
This arrangement has three distinct layers:
- KernelSU or a compatible fork provides root access from the kernel.
- susfs4ksu adds the required SUSFS functionality to the kernel and its userspace interface.
- BRENE configures additional hiding behaviour, properties and custom-ROM indicators.
Installing BRENE does not patch a kernel or turn an ordinary KernelSU installation into a SUSFS installation. The kernel-level prerequisite must already be present. The module’s documented minimum for v0.0.55 is susfs4ksu v2.2.0.
BRENE v0.0.55 was released on 17 July 2026 and requires susfs4ksu v2.2.0 or newer.
BRENE sits above KernelSU and the SUSFS kernel patch; each layer has a separate job.
What changed in BRENE v0.0.55?
Version 0.0.55 focuses on Android 16 compatibility, mount handling and better visibility into the active configuration.
| Change | What it does | Why it matters |
|---|---|---|
| Android 16 property handling | Deletes sys.oem_unlock_allowed on API 36 and later instead of setting it to 0 | Avoids recreating an obsolete property that normal Android 16 builds may not expose |
| sus mount feature | Adds control for SUSFS-assisted mount hiding | Helps reduce mount information exposed to selected userspace checks |
| Later property changes | Moves Android property work to boot-completed.sh | Applies changes after Android has reached a more stable boot state |
| Version-check change | Disables BRENE’s SUSFS version checks | Reduces false rejection of compatible variants, but places more responsibility on the user |
| Improved WebUI | Shows the Android version and SUSFS variant | Makes configuration mistakes easier to diagnose before changing hiding options |
The disabled version check should not be interpreted as compatibility with old releases. Users still need susfs4ksu 2.2.0 or newer. BRENE simply avoids relying on a rigid check that may misidentify forks or differently labelled builds.
On Android 16 and later, BRENE v0.0.55 deletes sys.oem_unlock_allowed instead of spoofing its value to 0.
Why Android 16 property handling matters
sys.oem_unlock_allowed historically reflected whether OEM unlocking was permitted. Android 16 removed this obsolete property from the expected platform behaviour. A module that forcibly recreates it with a reassuring value can produce the opposite of the intended result: software may notice a property that should not exist on that Android version.
BRENE v0.0.55 therefore uses version-aware behaviour. On API level 36 and later, it deletes the property. On older releases, different handling may remain appropriate because the property can still be part of the expected environment.
This is a useful example of why hiding should reproduce ordinary device behaviour rather than merely replace suspicious values. A value of 0 may look harmless to a person, but its unexpected presence can be machine-detectable.
The relevant Android platform concepts are documented in the official Android system-property guidance. Android’s rules change over time, so modules that manipulate properties need to account for the installed API level rather than assuming one configuration fits every release.
Android 16 removes an obsolete signal instead of expecting a cosmetically safe replacement value.
What SUSFS can and cannot hide
Module-only hiding usually operates after the kernel has already exposed files, mounts or process information to Android. SUSFS moves selected controls into the kernel, allowing supported information to be filtered closer to its source. In practice, that can produce a cleaner view for unprivileged applications than scripts which merely unmount paths late in boot.
SUSFS is not an invisibility switch. An application may still inspect:
- Whether the bootloader is locked and whether verified boot reports an expected state.
- Play Integrity verdicts and hardware-backed key attestation.
- Unexpected packages, services, processes or developer settings.
- ROM fingerprints, signing keys and system properties.
- Behavioural or server-side risk signals unrelated to root files.
No guide can promise that BRENE will satisfy a particular bank, game, workplace app or Google Play Integrity tier. Detection changes frequently, and two devices with apparently identical modules can receive different results because of firmware, keys, ROM signing or account-side factors.
SUSFS filters supported filesystem and mount information in the kernel; it does not alter every signal available to an app or attestation service.
Check compatibility before installing
Back up everything first. Keep copies of photos, authenticator recovery codes, messages and app data away from the phone. Unlocking a bootloader normally performs a factory reset, and flashing an incompatible boot or kernel image can leave the device unable to start.
You should have:
- Your exact device codename, firmware build and current kernel version.
- A bootloader that is already unlockable or unlocked; unlocking wipes user data.
- KernelSU, KernelSU Next or a compatible fork installed using a device-appropriate kernel.
- A kernel explicitly built with compatible SUSFS support.
- susfs4ksu v2.2.0 or newer, unless the kernel maintainer clearly documents an integrated equivalent.
- A copy of the original boot, init_boot and other images required by the device’s recovery procedure.
- Working platform tools and a tested route into the bootloader or recovery mode.
Do not flash a generic image simply because its Android and Linux versions look similar. Kernel configuration, ramdisk layout, security patches and vendor modules must match the device. Google’s Generic Kernel Image documentation explains the GKI model, while the official KernelSU installation guide covers supported installation routes.
Non-GKI phones generally require a kernel compiled specifically for that device. A Magisk-patched boot image is not a substitute for a KernelSU-patched kernel.
How to install BRENE v0.0.55 with SUSFS for KernelSU
The exact kernel-flashing command varies by device, partition layout and maintainer. Follow the device kernel maintainer’s documented method rather than copying a fastboot command intended for another phone. The steps below begin with the compatibility decision and finish with functional verification.
- Create an off-device backup. Copy important data to an encrypted computer or other trusted storage. Export authentication recovery codes. Confirm that the backup opens before changing the bootloader or kernel.
- Record the current configuration. Note the device codename, full build number, Android version, kernel string, KernelSU manager version and active modules. Retain the matching factory boot or init_boot image so you have a known recovery target.
- Confirm genuine kernel support. Check the kernel’s release notes for explicit SUSFS or susfs4ksu support and the supported version. A ZIP labelled only “KernelSU kernel” is insufficient. If the KernelSU WebUI reports “SusFS not supported”, BRENE cannot add that missing kernel capability.
- Install or update the compatible kernel and susfs4ksu layer. Use the method documented for that exact device, such as a maintainer-provided flasher, recovery package or precisely matched boot image. Do not relock the bootloader with modified partitions. Boot once and confirm that Android, Wi-Fi, mobile data and storage work normally.
- Download BRENE v0.0.55. Use the verified file supplied in the “Modules, apps & files to try” section attached to this guide. Avoid renamed mirrors and chat reuploads when a project release is available.
- Install BRENE through KernelSU Manager. Open the manager, enter the Modules section, choose installation from local storage and select the BRENE v0.0.55 module ZIP. Read the installer output rather than assuming that a completed progress bar means the prerequisites were detected.
- Reboot the phone fully. Do not test while Android is still optimising apps or before the boot-completed stage. Version 0.0.55 deliberately performs property work from boot-completed.sh.
- Open BRENE’s WebUI. Verify that it identifies the expected Android version and SUSFS variant. On Android 16, confirm that the configuration reflects the new property-removal behaviour. Enable only the hiding options you understand, then reboot if the interface requests it.
- Verify SUSFS independently. Open the SUSFS module interface or the information page provided by your KernelSU fork. Confirm that kernel support is active and that the userspace component reports a compatible version. A working BRENE interface alone does not prove that kernel hooks are present.
- Test ordinary device functions before sensitive apps. Check calls, camera, storage, biometric unlock, charging, VPNs and OTA status. Then test each banking, work or media app individually. A successful launch is evidence only for that app version and configuration, not a permanent guarantee.
The decisive verification is active kernel support, not merely seeing BRENE in the installed-modules list.
Common failure modes and practical fixes
“SusFS not supported” appears
The active kernel lacks the required patch, the wrong boot slot is active, or a stock boot image replaced the custom kernel. Reinstalling BRENE will not fix this. Restore a known-good image or install a correctly matched SUSFS-enabled kernel.
The phone bootloops after installation
Use the device’s documented safe mode, recovery procedure or KernelSU module-disable method. Disable BRENE first if the failure began immediately after adding it. If the kernel itself was changed, restore the exact stock or previously working boot-related image. Do not erase user data until less destructive recovery options have been exhausted.
Integrity becomes worse after adding more modules
Overlapping tools may alter the same properties, mounts or path lists at different boot stages. Integrity Box has previously been reported to add broad custom-ROM paths to SUSFS lists, creating conflicts in some combinations. The SUSFS developer does not recommend treating Integrity Box as a required companion. Start with the smallest stack and add one component per reboot.
OTA updates stop working or remove root
Kernel and boot modifications can break incremental over-the-air updates or be overwritten by them. Keep the original images and follow the ROM or device maintainer’s update procedure. Never assume that an update built for a stock boot chain is safe to install over modified partitions.
Battery drain or performance changes
A custom kernel can change scheduling, power management and vendor-module behaviour independently of SUSFS. Compare battery use and responsiveness against the same ROM with the original kernel. Remove optional modules before blaming one component.
A sensible decision framework
| Your situation | Recommended decision |
|---|---|
| Stock kernel with no SUSFS support | Do not install BRENE; first find a maintained, exact-match kernel or stay stock |
| Compatible SUSFS kernel and susfs4ksu 2.2.0+ | BRENE v0.0.55 is reasonable to test with a recovery plan |
| Android 16 with an older BRENE release | Consider updating for the corrected sys.oem_unlock_allowed handling |
| Critical banking or workplace access | Prefer an unmodified secondary device; no hiding stack offers a guarantee |
| Unsupported non-GKI device | Use only a device-specific build from a trusted maintainer or compile from reviewed source |
Readers new to kernel modification may want to begin with our Android bootloader unlocking guide and practical KernelSU installation guide. The safest endpoint may be remaining stock if essential apps or reliable OTA updates matter more than root access.
Frequently asked questions
Does BRENE v0.0.55 include SUSFS?
No. BRENE requires a kernel already patched for SUSFS and a compatible susfs4ksu userspace layer. It configures hiding behaviour but cannot add missing kernel hooks from an ordinary module ZIP.
Can I use BRENE with Magisk?
BRENE v0.0.55 targets KernelSU installations with a SUSFS-patched kernel. Magisk normally patches boot userspace components and does not provide the required SUSFS kernel implementation. Do not install BRENE on a Magisk-only setup.
Will SUSFS for KernelSU make every banking app work?
No. SUSFS can conceal supported filesystem and mount artefacts, but apps may evaluate verified boot, Play Integrity, hardware attestation, ROM signatures and other signals. Never depend on a hiding configuration for guaranteed access to a specific bank.
Why does BRENE delete sys.oem_unlock_allowed on Android 16?
Android 16 removed the obsolete property. Deleting it more closely matches normal API 36 behaviour than recreating it with a value of 0, which could become an unexpected detection signal.
Do I need the separate susfs4ksu module?
Usually you need both the kernel patch and its matching userspace component. Some kernel distributions bundle part or all of the integration, so follow the maintainer’s release notes. BRENE’s minimum documented requirement remains susfs4ksu v2.2.0 or newer.
Can I relock the bootloader after installing a modified kernel?
Do not relock unless the device and ROM explicitly support relocking with your exact signed images. Relocking with incompatible modified partitions can make a device unbootable. Bootloader unlocking also wipes data and may affect warranty support, OTA behaviour and device security.
The bottom line
BRENE v0.0.55 is a focused update for experienced KernelSU users, particularly those moving to Android 16. Its version-aware removal of sys.oem_unlock_allowed is technically more coherent than spoofing an obsolete property, while sus mount controls and improved WebUI indicators make the stack easier to inspect.
The module is only as sound as the layers beneath it. Use an exact-match, maintained kernel; confirm susfs4ksu 2.2.0 or newer; keep original images; and change one component at a time. Most importantly, treat root hiding as risk reduction rather than a promise of invisibility. For a phone that must always run critical financial or workplace apps, an unmodified device remains the dependable choice.
PrivacyPortal sells ready-to-use, de-Googled GrapheneOS Pixels — hardened, kept updated, and shipped with our encrypted Graphite messenger. Browse privacy phones →
