[Magisk] pndwal:
At least this latest (recent) issue is still open 🙂 :

Hiding and Restoring Magisk App not working properly on Galaxy A8 2018 (Android 9.0)

#6309 opened on 6 Oct by DarkKnight1995

Related:

Hidden app update (25203->25204) leads to "Full Magisk" screen loop regression

#6317 opened 24 days ago by KaMyKaSii

I believe John leaves it as it doesn't go against his policy that "Magisk will not spoof/alter/manipulate any non-Magisk related signals or traces to circumvent any device state detection".

Also, it doesn't contradict Google's own position that app's should not detect other apps, especially since A11, making this practice an abuse of Google policy.

Banks are in fact now employing 'dirty' tricks for such app detections...

Detecting applist should be prevented in theory since Android 11, but in practice some trickery, eg using Intent queries instead of API requests, using permissions like QUERY_ALL_PACKAGES (Google is now introducing a means to vet use of such sensitive permissions and approve only in specific instances, but still allows unchecked use ATM...) and detecting classes.dex code (which does not change w/ basic app obfuscation unlike the package name) and then using simple pattern-matching to identify the app, allows bank Devs to bypass Google's A11 API level app detection preventions etc.

Info:

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

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

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

Reasons acquiring applist has been allowed despite Google policy that should prevent it (and changes s l o w l y being implemented):

https://xdaforums.com/t/discussion-magisk-the-age-of-zygisk.4393877/post-87078529

Hide the Magisk app obfuscation works differently from HMA and in a number of cases both methods are needed.

Nb. Sparkasse bank's S-PushTAN is an example where classes.dex pattern matching is used and both random package name obfuscation and HMA hiding are required to bypass detection... Using HMA on an unbidden (full) Magisk App isn't enough... It seems likely that other bank apps will also employ these means and may even use the same (Promon) 'protection' security engine...

So if Hide the Magisk app option were removed, even HMA could not hide the Magisk App from all detections.

Yes, member had hidden Magisk App, but had then tried to 'downgrade' from newer Canary to Stable, which is what complicated things / why I addressed new checks by daemon that prevent this...

Also as discussed in posts above, these new checks affect downgrading (from June 19, 25100), using unofficial Magisk builds or even TJW CI (test / Actions runs) builds (from May 30, 24314) whether full Magisk App or an obfuscated stub App is installed, but these combinations are all bypassed by the same options mentioned for Canary users below.*

I know last time this issue was raised you protested that it was possible since you thought you had Canary installed and were successful doing just this... However you later discovered your mistake and that binary installed had been Debug (not release-Canary) all along which accounted for your success...

The Rub (for Canary users, etc)...

Starting from 25.1 (25100), June 19 2022, users need to appreciate that with these new checks,

we can not change to Canary builds and then revert to Stable easily

(using Direct Install) any longer...

Nb. Changing channel and installing Canary is Upgrading. Changing channel back to revert to Stable is Downgrading unless a Stable update build is available... Thus reverting is the issue here...

* The options for reverting are

1) fully uninstall Magisk first,

2) wait for a new Stable build to be pushed (ie. having later version than Canary in use) or

3) install Debug channel build (both App and core/mask) to disable version / sig checks, then install original Stable or whatever build you like...

These changes were designed to "protect users from malicious and unverified Magisk APKs" as well as (presumably) to protect against regressions, config file incompatibilities etc associated with downgrading. As such, downgraders may be wise at least to fully (or selectively if familiar with the file structure used) delete the contents of /data/adb before booting with downgraded Magisk if not fully uninstalling the newer build. Eg, if taking Direct Install (from Debug build), don't reboot when prompted; Use existing root to access /data/adb, delete magisk.db etc, then reboot and config files will be rebuilt from scratch...

------​

Side note:

Personally, I'm not sure I like the implication of these checks any more than other users will, especially those who will no doubt not understand why apps seem to be 'uninstalling themselves' etc in future... I do appreciate the security / compatibility considerations however...

🤠 😆 PW

Ours is not to reason why

Ours is but to do and die...

- whosaiddat?