yashsingh1/xdaforums huggingface dataset:
[Magisk] pndwal:
Thanks for clarifying what you meant by 'app system-as-root (SAR) is lost' etc... I think you're a bit confused about what that is, but I'll put something about SAR definition in a later post...

I've just tested this now that I understand your meaning, and, yes, seems this may be new behaviour, or just fixed with this pre 25207 commit:

Fix auto install stub

canyie authored and topjohnwu committed on Jan 23

I too observed that if 26101 App is uninstalled, on opening a root app (even where superuser permission was previously granted) I get a new "... requesting root access" dialogue. This disappears after seconds, and stub app with unpopulated data is found to have been installed...

You say:

Really, it seems Magisk is calling the stub to initiate a full App installation so that if the root app had not already been granted root access, that can be handled after user completes setup...

In the case of apps already granted superuser rights, I think the stub is not further handling the root access. It's just an empty stub w/ 0 user data populated and yet the root apps work... It can't be working with no data ...

So what is clearly happening is that Magisk's daemon is now simply checking for the existence of a Magisk App (stub or full) whenever a root access request is made, and if not found it is now treating all root app calls as new requests (hence the "... requesting root access" dialogue) because the standard means (nb. this can actually be done from CLI also) for granting root access has been removed... Next it ensures that a stub app is called to preempt installation (when user later opens stub and agrees to download full app), after which it checks the root app's preexisting superuser permission stored in /data/adb as before (nothing to do with the new stub), then closes the dialogue without requiring any further action and grants the root permission.

On clicking the new empty stub (which is detected by bank apps as you said because it installs as Magisk w/ package name com.topjohnwu.magisk 🙁), user is asked for permission to install the full Magisk app, and this still requires a network connection (ie. is called from online channel) despite the stub itself being called from installed binaries since this earlier commit:

Make stub patching 100% offline

topjohnwu committed on Aug 26, 2022

Hope this at least reduces confusion... 🙃 PW
[Magisk] zgfg:
If I understand correctly, this means that previous comments about the 'best' method to hide Magisk app and generally about the possibility to uninstall Magisk app and install it only when you need to manage something are no more advisable?

Also, did you maybe test the case when Magisk app is not uninstalled but disabled by pm (like if using AirFrozen)?

Does the daemon also pushes the stub or the disabled/frozen Magisk app will be enabled again
[Magisk] pndwal:
As @J.Michael mentioned above, SAR is not a Magisk or user root concept; it's an Android booting architecture or protocol...

Please check out what I wrote on the Evolution of Android and Magisk booting architecture here:

https://xdaforums.com/posts/88438781/bookmark

🙂 PW
[Magisk] gsmdb:
<spoiler>pndwal

</spoiler>

Strange thing with build 26.1 is

- Delete the stub.apk from /data/adb/magisk folder and modify the boot_patch.sh so the script doesn't install stub.apk into ramdisk (just to have the same behavior as with build 25.2)

- Patch the boot image then install the patched boot image as usual

- Delete the magisk app then open a root app to request root access. It will still install a magisk placeholder app (hidden magisk app)

In both builds (25.2/26.1) there is no need for the extra app stub.apk. In my case I did as described upon then the sequence of self install hidden magisk app is less annoying for now.

Why include the stub.apk in build 26.1 for nothing?
[Magisk] pndwal:
A mechanism to restore the stub on rebooting at least has existed for some time, but I think it has often been broken as vv especially has made numerous changes to stub calling... With recent 'fixes' it seems users can still uninstall app to use/test bank apps/detections, but will now need to avoid calling a root app as well as rebooting in most cases...

I've commented before that I think some of these "idiotproofing" / protection measures clearly designed to protect modders from themselves or at least to reduce reported issues are overkill in my view... And in many cases they only increase confusion, frustration and GitHub issues anyway...

No, and I don't intend to test (or use Magisk w/o App)...

I'm not sure if these scenarios prevent Magisk from seeing App, how it'd be handled or if error conditions would result either... Praps you could test? PW
[Magisk] pndwal:
As I mentioned before, this was removed by LSP/Magisk devs as part their redundant code cleanup... Prerhaps they view is as superfluous also...

However this broke boot patching in some instances as the stub was required by manager.sh + boot_patch.sh as "all listed files from boot_patch.sh header are required for boot patching, but stub.apk was being removed"

Since this regression broke @osm0sis's install magisk via addon.d.sh for custom ROMs, this stub was restored along with other fixes in @osm0sis's PR and merged as Fix scripts by John just prior to 26.1...

Since one dev giveth and another dev taketh away, the duplication of the tiny stub in Magisk .apk archive may be a case of the right hand not knowing what the left is doing...

Anyway, I did cover these changes above... And devs will no doubt continue to clean Magisk's complex code... 🙃 PW
[Magisk] treypop:
I'm trying to install magisk from TWRP but every time it just hangs when the install gets to - magisk mounting /apex/com.android.apex.cts.shim
[Magisk] pydy93:
Poco F3 with LineageOC 19.1+Magisk

Can i get any tip what i missed or should do yet ? The banking app + revolut are working perfecty, but the google wallett throwing : "your phone does not meet safety standards" issue.

USNF by Displax installed & enabled

zygisk enabled

block list is enabled with :

- com.android_vending

- com.google.android_gms

- com.google.android.gms.unstable

are blocked

Any idea what did i missed ?
[Magisk] pndwal:
Remove those items/processes from denylist.

Add Google Pay/Wallet.

May need to clear its data... PW
[Magisk] osm0sis:
It's not duplicated in the APK, that's where it comes from for unrooted boot patching, and AVD, and it appears to still get dumped from the APK for a Direct Install as well.

Then presumably it's in the ramdisk for the same reason it used to be bundled inside magiskinit, to dump and pm install it as early as possible and without anything in /data/adb.
[Magisk] a9381:
Hey friends, I'm fine. I forgot to make a git clone for submodules and I was missing C++ build tools.
[Magisk] pndwal:
Ah... actually member had said it was removed from /data/adb/magisk and boot_patch.sh was modified so script wouldn't install stub in ramdisk before patching/flashing and uninstalling Magisk App, yet stub is still installed when Magisk detects missing App:

... Guess I should have said "...the duplication of the tiny stub in ramdisk..." then!(?) Or is there a different location it can be called from?...

Anyway, that's what you get when suffering from Alzheimer's and Covid both. 🥴 PW
[Magisk] ipdev:
The script I use checks the short head before and after a git pull.

If the current (before the pull) short head and new short head (after the pull) are the same, it will not set the SHEAD variable.

If SHEAD is empty, none of the building, coping and get push parts of the script run.

You can force a build by setting SHEAD manually in the script.

Happy Building. 👍

Cheers. :cowboy:
[Magisk] osm0sis:
Speaking of! :p

Retain PREINITDEVICE in recovery flash if previously found during booted patching by osm0sis · Pull Request #6917 · topjohnwu/Magisk

Should make for fewer cases where the extra reflash step is needed 🙂

github.com
[Magisk] pndwal:
Can I assume this also maintains directory selected for selinux/module rules? PW
[Magisk] osm0sis:
Yeah, that's in PREINITDEVICE. When PREINITDEVICE is missing in /.backup/.magisk after a recovery flash of Magisk that's what triggers the Magisk app to tell you to Direct Install, but I see no reason that that can't be kept during a "dirty" flash of Magisk over Magisk when it was previously detected correctly.
[Magisk] pndwal:
... Another PR to watch!... Guess addon.d supported ROM updates would otherwise have needed an in-App reinstall of Magisk too...

... Just had another thought for an improvement:

Why can't we have an option akin to 'Direct Install' that fetches and patches current already-rooted boot image but saves it like 'Select and patch a file' instead of flashing so Huawei etc devices that can't flash while booted can still use .zip from custom ROM for initial installation and fix that installation by in-App patching and flashing from TWRP (or even fastboot)?...

Can you use this? 🤪

Just to be clear, it seems the only way initial .zip installation can be used for these devices since booted-patching to complete Magisk installation has been needed (since new pre-init partition detection mechanism for selinux/module rules) is to .zip install, then make TWRP backup and extract .win patched boot image backup, boot system and use in-App 'Select and patch a file' to fix this Magisk patched image, then flash from TWRP... I don't think there's currently any other way available...

(Hope it's not just Covid talk!) 😬 PW
[Magisk] osm0sis:
Good idea, but for one thing: if you're rooted and booted there are a number of scripts and apps that can dump your current boot image for you. I use my Flashlt scripts in FX File Explorer myself. I'd also recommend @capntrips' Kernel Flasher app.

I think the Magisk app just expects you'll do something like that and patch the dump yourself if you're in that category.

The best way I can think of would be that Direct Install should try to flash and if that fails then it should offer to save the patched image. Feel free to open a feature request issue with that idea, they might go for it! 🙂

Hope you feel better soon! We've all got a nasty cold/flu right now in our house as well (but not COVID say the tests), and it's been a real struggle. 🤒

Edit: Oh great... Someone at XDA cranked the language filter back up to 11, so now Flash+It = Fla****, and I'll have to start intentionally misspelling it with a lower L again... 🙄
[Magisk] pndwal:
👍

Zachary...

... If I get around to it...

It would make things more straightforward for a few custom recovery users...

Any other users may as well patch fresh image every time since they'll require PC / fastboot anyway and should have current ROM archive or stock boot image AFAICS.

Doubt it'd get far coming from me anyway... They've only ever run with a few of my suggestions... PW
[Magisk] pndwal:
...Just saw the extra...

Thanks... I'm coping better than most it seems, 5 days since positive...

All best to you, yours and mind the little one...

Haha... I love Australian **** Smith peanut butter (goober spread?)...

And my grandpa's name was **** too... 😜 PW

Edit... Yup, thought so... D_ick and D_ick, short for Richard...
[Magisk] Zotac101:
Hello coming back to magisk after quite a while , and was surprised to see that magisk hide is no more.

However it seems a fork by huskydg named "magisk-delta" is still maintaining it . Does anyone know how it compares to magisk official + shamiko ? Using USNF by displax in both cases.

Also there seems to be another popular fork named "magisk alpha" by @vvb2060 but i ain't quite sure what more is it adding to the default magisk.

Other than momo by @vvb2060 are there any other reliable apps that I should be using to detect root.
[Magisk] gsmdb:
I do recognize lot of users suffer with twrp+magisk so my thought

- You can install custom ROM without decryption of your phone (don't format your internal card/ data) since nowadays most of work or bank apps demand your phone is encrypted, especially if using work profile for your company apps

- Why bother backup from twrp? You can always backup your data from builtin backup app from your phone model. Most of the users do some minor changes in system (build.prop, gps.conf, etc) so backup of system, efs in my opinion unnecessary

- Root with patching boot.img is much easier directly from Magisk app

Rooting and app root detection is a catch-and-play game. Some of the apps are good to detect root regardless which setup you have to hide. In my case I must use the elder build/version of some apps to bypass root detection as earlier working, but in near future those elder versions aren't probably supported so new fight in mind
[Magisk] osm0sis:
Better you than me! 🤣😛😅
[Magisk] pndwal:
A number here use this, and restored MagiskHide along with Riru solutions etc do have advantages for hiding root traces from.an increasing number of apps... Probably best to ask questions here:

https://xdaforums.com/t/discussion-magisk-delta-another-unofficial-third-party-magisk-fork.4460555/

vv is an LSPosed and Magisk main dev... Her Alpha used to be more accessible (builds themselves still are), but lately most here have stopped using this daily as sources are no longer available, json changelogs no longer include Alpha changes; they only point to TJW canary base, and the original TG discussion comprises a small Chinese speaking community where discussion is mainly on debugging new changes or food or the weather (+ cats and bugs)...

It is used to test many experimental changes, and current build seems to have new native bridge Zygisk loading which is a WIP... Countless action runs/changes are being tried in several branches of @yujincheng08's (another LSP and Magisk main dev) Metagisk fork to test NB loading, and these are being cumulatively added to several related TJW PRs ... Seems these are being tested further in Alpha...

Indications are (incl. In Alpha discussion) that Magisk 27.0 will have Native Bridge Zygisk loading/injection, and this should close the gap between unofficial forks and TJW Magisk in terms of root hiding as this is the same tried and tested loading mechanism used to allow the memory of Riru and modules be made "anonymous" (read hidden)... I discussed this here:

https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-88392643

Nb. Hiding modules can only do so much on their own, but Shamiko has already been refactored to Support (hide) zygisk loaded by native bridge...

Of course 27.0 Magisk w/ NB Zygisk loading may initially have teething problems, but clearly an enormous amount of testing has already been undertaken over the last 2 months to ensure it's deployment doesn't break stuff...

Someone else can go there... There are many, especially when we branch out into applist and other indicators of tampering detected by banks...

Want a challenge?...

Try to subvert unlocked bootloader detection used by this:

https://github.com/vvb2060/KeyAttestation

Nb. Banks etc implementing this approach would follow Googles method here:

https://developer.android.com/training/articles/security-key-attestation

So RikkaW and vvb2060's app should be easy to bypass since:

🤠 PW
[Magisk] pndwal:
Mate, you're a seasoned pro who still has John's ear!...

😝 PW​
[Magisk] osm0sis:
Nope, they all have a chat together.

Our old Magisk HQ Slack still technically exists but nobody has used it for over a year and John hasn't replied any time recently I've tried to DM him there.

What you see him reply to on GitHub is it.
[Magisk] pndwal:
Yeah, I know, I just meant at least he gave you a fair crack of the whip in the last rodeo... Didn't take away the sauce bottle at the afterparty... fair suck of the sav! 😜 PW
[Magisk] ctcx:
@badabing2003 , anyone else:

I have a doubt regarding vbmeta...

After reviewing Magisk installation docs and util_functions.sh script, I understand that flag PATCHVBMETAFLAG == "Patch vbmeta in boot.img" option actually; meaning that the flag itself must be "true" when there is NO individual vbmeta partition.

As a followup to this

https://xdaforums.com/t/magisk-general-support-discussion.3432382/page-2772#post-88425005

I -just- noticed that boot_patch.sh script, for some reason, actually never uses the get_flags() function, which is why one must manually export the needed flags according to device (when using the app UI, I think it just gets the flags in its own other ways).

With this mentioned, in that previous test I did not set the PATCHVBMETAFLAG flag, thus it was set to "false" by default. But the device I use, a Moto ocean, does not have a vbmeta partition, so the correct flag value should have been "true". And despite all of this, I got an identical patched image to that done with app UI... And on top of this, when flashing the image, it still worked.

Why was this?

Or does Magisk actually no longer care about vbmeta since at least 25.2?

And, shouldn't boot_patch.sh run get_flags() function at least once, at least when being run from command line instead of app UI?

All of this applying to both versions 25.2 and 26.1.

Thanks again.
[Magisk] Zotac101:
@pndwal

Wow , thanks for all the info, it definely cleared things up and your answer was easy to understand as well.

Correct my if I am wrong but from you write up I surmise " MagiskHide along with Riru" is better than " zyzisk + shamiko " atleast we have support for native bridge? Is that correct?

If you wouldn't mind can you or anyone else explain why this is the case, i really enjoy learning about these details . If you are short on time a brief overview will do.

Sidenote:- Learned you caught covid, hope you get well soon.
[Magisk] J.Michael:
Did you try setting the flag to see if the patched image changed?
[Magisk] J.Michael:
If you enjoy learning, try skimming the 50,000 posts in this thread.
[Magisk] Zotac101:
I do so , and that's how I learned many things about magisk. But I yet to encounter anything related to my above query. I am not very good at searching threads so maybe you can help if you have encountered a discussion about this.
[Magisk] badabing2003:
Honestly, I had never seen before the vbmeta checkbox in the UI until very recently when I was flashing One Plus 5 with Lineage (Magisk 25.2), and didn't know if I should check or not, I proceeded without selecting it, created a patch in UI and flashed that (I didn't care because I was just testing)

The system was properly rooted.

Magisk 25.2 boot_patch script available flags are: KEEPVERITY, KEEPFORCEENCRYPT, RECOVERYMODE

Magisk 26.1 boot patch script available flags are: KEEPVERITY, KEEPFORCEENCRYPT, PATCHVBMETAFLAG, RECOVERYMODE, SYSTEM_ROOT

By the way, according to this document, the flags should be set as system environment.

See in the table below, the vbmeta option in UI only shows up for me with Magisk 25206, and only on one device.

Device​

OS​

vbmeta partition​

A/B (Dual slot)​

Magisk Version​

vbmeta option in UI​

Pixel XL	Stock	No	Yes	25206	No
Pixel XL	Stock	No	Yes	26101	No
One Plus 5	Lineage	No	No	25206	Yes
One Plus 5	Lineage	No	No	26101	No
Pixel 5	Stock	Yes	Yes	26101	No
[Magisk] J.Michael:
This thread contains that discussion, many times over.

I really meant "read 50,000 posts". The first ones won't make much sense, but you will pick up words.

You can try searching for terms like "hiding" and "bank apps", but do not only read the posts flagged by the search. Rather, start there and read hundreds of posts in sequence. Not all posts will address your question, but I do not know of a bulletin board function that will help you track down the replies to a thread.

It's a hard slog. There is no one answer. There may be no way to satisfy your particular bank app. But people like @pndwal and @zgfg regularly report success.

There is a search option "this thread". That will restrict the search. Find any post by @IronTechmonkey and read his signature, it describes a procedure to search in spite of long-standing problems with the web site search function.
[Magisk] ctcx:
My big bad.

This I get for not checking commit history in Github... I'm sorry.

There was always the answer: the very same as the SYSTEM_ROOT flag: PATCHVBMETAFLAG is not used at all in 25.2 (I insist that apk version at Github is 25200, according to what device says in the device when patching an image).

@osm0sis :

Reiterating, shouldn't boot_patch.sh run get_flags() function at least once, at least when being run from command line instead of app UI?

Currently script does source util_functions.sh, but the get_flags() function is at most just defined, never actually used.

Thanks again.
[Magisk] osm0sis:
Not sure if anyone runs it solo, it's always being called by the app or by another script which sets the prerequisites. Feel free to submit a PR to have it be more self-contained, but the idea might be that you set those yourself before run so you can influence it however you like in testing.
[Magisk] ctcx:
Not "solo", obviously (otherwise it simply doesn't work); but with at least with all boot_patch.sh dependencies stated in the header of the script itself.

"Not sure if anyone"? Assuming the above true, the very first one would be badabing2003 with PF...

Also, this is why I said "at least when being run from command line instead of app UI".

As far as I understand, app UI automatically gets the prerequisites through its own methods based on current device; but regarding boot_patch.sh, as far as I could search/find in the Github repo, it would get them precisely from util_functions.sh script, specifically the get_flags() function.

But just as you say, the scripts are normally run by app itself, having previously set the corresponding flags beforehand.

Wouldn't there be a way to check whether script is being ran standalone or by calling of app itself?

Wouldn't that be the $SOURCEDMODE variable?

Thanks again.
[Magisk] badabing2003:
I'm not sure this post belongs here, but I experienced this after direct Installing Magisk 26101 (from 25206) hence why I'm suspecting Magisk.

I am unable to boot to bootloader mode, neither from command line nor by holding the power + down volume buttons.

The device reboots back to system.

Anyone has any ideas before I try factory reset?

This is happening to Pixel XL (Marlin).

Update:

This turns out unrelated to Magisk 26101, apologies for polluting the thread.

How do I know, after multiple attempts, I managed to get into bootloader mode by long pressing the power button, and as soon as it rebooted (this took about 10 seconds or so) I immediately pressed the Volume Down button.

I flashed full factory (the latest available for the device) to both slots, with Magisk 25206.

And I'm still unable to boot to bootloader using adb reboot bootloader

Update2:

I take that back, flashing stock boot.img fixes the issue, I flash 25206 or 26101 Magisk and the problem comes back.

Weird.
[Magisk] Nergal di Cuthah:
I'm sure youve already tried this but incase you didn't revoke debug certificate?
[Magisk] badabing2003:
No I haven't, honestly what is a debug certificate, and how do I revoke it?
[Magisk] Nergal di Cuthah:
Developer options

Sent from my pixel 6P but should be the same
[Magisk] pndwal:
Welcome.. Hope it helps others too...

You mean until we get NB Zygisk?... Sure... Seems solutions needing zygote injection (USNF, LSPosed, root hiding mods etc) are hidden better from some apps if hooking framework uses native bridge to load... On the other hand Shamiko may already hide different traces detected better...

Hope the above helps...

Note also, Many hiding solutions (hiding isolated process leaks etc) using Riru have been borrowed from @canyie's MomoHider module which is now depreciated and superseded by her Shamiko project. Shamiko restores MagiskHide functions (for 24.0+ Magisk) in addition to building MomoHider functions and adding many more hiding mechanisms... @canyie's summary with MomoHider depreciation notice gives some insight too:

https://github.com/canyie/Riru-MomoHider

Also, extract and read readme.md from Shamiko module... 👀

Thanks... Seem to be on the up-and-up now! 🙂 PW