[Custom] Enhancement for modules

[1q23lyc45]

Describe your problem.

Is it possible to make the module function without img?
This 1tb sparse file img brings a lot of serious bugs.
When some modules are installed, the system storage space will become 2TB or bigger(I'd like to specifically note that the bug is present on other devices besides Samsung devices. known to reproduce are oppo, Xiaomi, and lineageos, all of which show 2TB of storage.). This causes the automatic cleaning of many junk cleaning apps to fail.
Using a single img file seems very rigid and greatly reduces compatibility, leading to problems with many devices and modules that don't work, especially modules that require files to be downloaded during installation or large modules.
It even causes trim to not work at all.
Even, it has become a kernelsu fingerprint, which can be used to detect kernelsu directly.
APatch has already deprecated img, I think KernelSU should follow suit.

[backslashxx]

Maybe they will update it eventually now that modules.img mount detection method is public

See: https://github.com/reveny/Android-Native-Root-Detector/releases/tag/v6.5.3

[1q23lyc45]

Maybe they will update it eventually now that modules.img mount detection method is public

See: https://github.com/reveny/Android-Native-Root-Detector/releases/tag/v6.5.3

Without installing modules, it will not be detected, but as long as any module is installed, it will be detected. When KSU is detected, the phone storage space will also become 2TB(fake space).

[backslashxx]

Without installing modules, it will not be detected, but as long as any module is installed, it will be detected. When KSU is detected, the phone storage space will also become 2TB(fake space).

basically the logic is

for device in $(ls -d /proc/fs/jbd2/loop*8 | sed 's|/proc/fs/jbd2/||; s|-8||'); do ls -d /proc/fs/ext4/${device} && echo suspicious loopdev! ; done

from

grep "/block/" /proc/mounts | cut -f4 -d "/" | sort -u | grep -v by-name | sed 's/ //' > 1
ls -d /proc/fs/*/* | cut -f5 -d "/" | sort -u > 2
grep -Fxvf 1 2

basically it sees a journaled loop device due to the mount

the phone storage space will also become 2TB(fake space).

yeah I guess sparseness can also be used as another detection point

[1q23lyc45]

bmax121/APatch@b843480

It is able to refer to this commit from APatch for repair. However, some method names and variables have significant differences and need to be noted.

[Vigilans]

One more thing to add for modules.img: I found my KernelSU module's webui will report 404 with err:ERR_INVALID_RESPONSE (cannot load https://mui.kernelsu.org/index.html).

After some investigation, I found it is because my modules only exists in modules.img, but not in native storage.

• For privileged processes, modules.img are mounted on /data/adb/modules, so everything works fine.
• But for webui's webview process, modules.img is not mounted and therefore /data/adb/modules is empty, resulting in the 404 error.

I copied my modules to native storage and webui works now. Since I am migrating from Magisk and thus not using standard method to install my modules, this is basically my fault (to solves issues when migrating I obliviously cleared modules in native storage).

Though basically my fault, I am sharing this experience here to mention that kernelsu's webui is not using files in modules.img, which may cause inconsistence somewhere sometime, in case someone also falls into it.

[backslashxx]

@Vigilans I recommend that instead of migrating to magisk, migrate to MKSU.
This is KernelSU with magic mount.

https://github.com/5ec1cff/KernelSU/

[Vigilans]

@backslashxx Thanks for your recommendation.

More precisely I am migrating from Magisk + KernelSU (Magisk for module, KernelSU for root) to KernelSU only, since I encountered some strange issues in former setup these days, and some apps start to detect root/suspicious mount.

Considering Magisk and its ecosystem is not being actively maintained in foreseeable future, I get rid of Magisk and use KernelSU only for my modules. With some fixing everything works well now, so I will keep using this setup for now. If some more issues occur in the future, I will try out other alternatives.