Basics & Common Knowledge

About 1478 wordsAbout 5 min

2025-1-3

Patching Points of Root Solutions

Magisk

Magisk patches ramdisk, which is located in the boot partition before splitting, and in the init_boot partition after splitting.

提示

If there is init_boot, patch init_boot; if not, patch boot.

This covers original and all its forks.

When using , patches ramdisk to load kernel modules, location same as Magisk.

When using , requires kernel source code to rebuild Kernel to use . The modified partition is boot.

& FolkPatch

is based on secondary development. Its patching point is kernel, which is the boot partition.

重要

At all times, the partition patched by /FolkPatch is boot. Unless Google changes the kernel location in the future, it will always be boot. Patching init_boot is an invalid operation.

The mounting mechanism used by Magisk is generally called Magic Mount, which is built into the Magisk core. It allows you to modify non-writable partitions (EROFS:system) without actually modifying system files.

重要

You can indeed use modules like Mountify to make Magisk support Overlayfs mounting, but this is generally pointless.

This covers original and all its forks that have followed up with Meta Module.

Considering that has switched to Meta Module for mounting, only some Meta Module are briefly discussed here.

Meta-Overlayfs

The mounting implementation maintained by official, based on Linux Kernel's Overlayfs file system implementation, theoretically has better performance and stealthiness than Magic Mount.

Meta- (rs)

Can be compared to Magisk's Magic Mount mounting implementation, implementing more functions on this basis.

Meta-Hybrid Mount

Provides both Overlayfs & Magic Mount mounting implementations. Considering its special HymoFS has been temporarily removed, it has no advantage compared to other Meta Module.

& FolkPatch

has removed its built-in mount system in new versions. Meta Module installation is required for module mounting. The specific mount method is determined by the installed meta module (such as , bind mount, etc.).

does not have built-in .

FolkPatch

FolkPatch extends the mounting system on top of , providing more options:

1. Built-in

FolkPatch adds a Magisk-like (bind mount) mechanism as a built-in feature. When enabled, FolkPatch uses its own mount engine to handle the module's system directory mounting, without relying on external modules.

Controlled by the /data/adb/.magic_mount_enable marker file
Mount source directory is /data/adb/ap/magic_mount
Enable via Settings -> General -> Enable Mount System

2. Meta Module

FolkPatch also introduces Meta Module support. Meta modules are special modules that can take over FolkPatch's core behaviors, declared in module.prop with metamodule=1 or metamodule=true.

After installation, meta modules are linked to the /data/adb/metamodule/ directory, providing the following hooks:

Mount Takeover: Takes over the default mounting logic via metamount.sh (note: not mount.sh)
Install Takeover: Takes over the installation process of ordinary modules via metainstall.sh
Uninstall Takeover: Takes over the module uninstallation process via metauninstall.sh

This enables FolkPatch to extend its underlying capabilities through community-developed meta modules, like .

提示

Built-in and Meta Module should not be used simultaneously. Choose one or the other.

3. Default Mode (No Mount)

Starting from the new version, FolkPatch defaults to not mounting module files. When the mount system is disabled and no meta module is installed, FolkPatch retains only core functions such as Root permission management, without performing any file mounting. This was previously called "Lite Mode" but is now simply the default behavior.

Users who need module mounting must explicitly enable either Built-in or install a meta module.

Comparison with APatch

has removed its built-in mount system in new versions, but still supports meta modules. FolkPatch differs from by additionally retaining built-in as an optional feature that users can enable when needed.

Manager Authentication Mechanism

The manager needs to communicate with in the kernel to perform root operations. Starting from FolkPatch 4.3, a pure signature verification scheme is adopted, completely removing SuperKey password authentication.

Signature Verification

The kernel verifies the manager APK's signing certificate to confirm the manager's identity, without requiring the user to manually enter any password. The authentication process is completed automatically at boot time, and the manager can communicate with the kernel directly after startup.

提示

Signature verification is fully automated and requires no additional user action. As long as you use the officially signed manager, authentication will complete normally.

Authentication Principle

At boot time, the kernel actively scans installed apps' APK signing digests and matches them against a built-in trusted manager signature table
After a signing digest match succeeds, the kernel records the manager's UID. All subsequent kernel communication is authenticated based on this UID
The manager does not need to pass any password or key to the kernel — authentication is granted solely through the UID obtained via signature verification
If the manager is uninstalled and reinstalled, the kernel's recorded old UID becomes invalid, requiring a device reboot for the kernel to re-scan and match

Reinstalling the Manager

After uninstalling and reinstalling the manager, it may show "not installed" or "authentication failed" because the kernel still holds the UID of the old manager. This is normal behavior. Restart your device to restore authentication.

Authentication Scheme History

Version Range	Authentication Method	Description
FolkPatch 4.3+	Pure signature verification	SuperKey completely removed; manager identity verified solely via APK signing digest
Before FolkPatch 4.3	Signature verification + SuperKey (optional)	Signature verification prioritized, SuperKey served as fallback
≤ 0.13.0	SuperKey only	Signature verification not yet introduced; SuperKey was required for authentication

If you are upgrading from a version before 4.3, the previously set SuperKey is no longer needed. The manager will automatically authenticate via signature verification.

About Legacy KPimg

FolkPatch supports patching legacy KPimg files, but note the following:

Version 0.13.1 and above: Supports signature verification, the manager can authenticate automatically
Version 0.13.0 and below: Does not include signature verification, authentication cannot be completed

Signature verification was introduced in 0.13.1. When using earlier KPimg versions, authentication cannot be completed. Please upgrade to 0.13.1 or higher.

Module Conflicts

Do you often wonder whether a certain module conflicts with another?

First, we need to understand why modules conflict:

Mounting or modifying the same system files
Modifying the same system properties
Overlapping module scopes

Their modifications will be overwritten based on loading order, causing one side's modifications to not take effect, or even preventing the system from booting.

How to Determine Conflicts

Same type of modules, such as Zygisk implementations, Meta Modules, Schedulers, Tombstones - these modules usually don't and can't be compatible, so only one can be used.
Various modules with duplicate functions, for example: Background Optimization modules may conflict with Noactive's background optimization feature because they both modify the system's oom_adj.
Modules that require mounting, such as Fonts, Thermal Control, can only use one at a time.

重要

If the original author has made special notes about module compatibility, then defer to the original author.

Material Design 3 Expressive

The latest version of FolkPatch adopts Google's Material Design 3 Expressive (MD3E) design language, with the following major changes:

Large rounded corner cards: Settings items, module cards, etc. uniformly use 32dp corner radius (standard M3 is 12dp), making the interface softer and rounder
Wavy progress indicators: Loading animations and download progress use a wavy style, replacing traditional circular/bar progress indicators
Expanding floating action button: The action buttons on the module management page use MD3E's FloatingActionButtonMenu, which fans out into a menu when tapped
Shape morphing: The selected color in the theme color picker morphs from a circle to a 9-sided cookie shape (Cookie9Sided), using MD3E's shape morphing API

Copyright

License under:Attribution 4.0 International (CC-BY-4.0)