The reasoning really had not so much to do with root. Many apps will declare root / jailbreak if they detect any modification to TEE (Trusted Execution environment).Okay @topjohnwu you're probably sick of the "sell out" stuff and just flaming over the changes in magisk in this new direction you're taking this great project since your employment at Google. I totally agree with you. I think devs and apps and... Should have the option to "opt out" of any modification. but riddle me this, when I have some banking app, some other system app or whatever and that has nothing to do with the modifications I have using root, should they force me to unroot my phone? It's their choice that I shouldn't mess with their app but is it theirs to demand I either choose banking or modifications to other parts of my phone? My point being, if it's at all possible, consider adding Deny list functionality for system apps because currently it doesn't work on any and Hide options for apps that force you to either choose magisk or their app, regardless of what you're modifying. You can factor out any app or service that Google runs but a "choice" for users to bypass detection and modification for apps and services that insist you don't root android and enforce that whether by themselves or using Google services, would be great and probably in sprit of your current decisions.
Other than that, cheers and thanks.
I hope you stay strong and healthy.
As such, Magisk / John / other devs and modders can do nothing to improve this without hiding / spoofing SafetyNet attestation to TEE, CTS (Compatibility Test Suite) result and Play Protect certification, or other flags indicating TEE has been modified.
However Tee is not broken by root; a 'chain of trust' is broken as soon as bootloader is unlocked these days (was different once), and new flags are set for non-verified boot. AVB (Android Verified Boot) and associated DM-Verity (device-mapper-verity kernel feature) have been added / improved since Android 4.4.
Magisk / root simply gives mods more permissions than the apps / processes that detect have to hide such traces.
Well actually denylist does work for such apps exactly as intended!
Further re. this John recently said:
So John states clearly that while he won't work on these personally, 'modules can either utilize the DenyList feature for "hiding" purposes or do everything needed for hiding prrposes tthemselves'. Such 'invasive methods (the only way to workaround HW KA.)' will need to be implemented by others and he says outright 'spending effort such on hide modules is much more productive than Magisk forks'. Earlier he even stated that these would be trivial to produce.John Wu, Oct 6
• I "officially" announced the removal of MagiskHide, not only because of the obvious conflict of interest with my job at Google, but also I wanted to give an early heads up to the community so those who are still passionate about hiding can start "doing their job"
• The new "DenyList" feature of upcoming Magisk versions is me preserving portions of the of hiding codebase and transform it into something I felt is valuable
• It's not a secret that specifically designed modules can indeed utilize the DenyList feature for "hiding" purposes
• DenyList, however, is only meant to "revert all Magisk changes". It will not attempt to manipulate any other signals on the device
• Since Magisk already provides root permissions, modules don't actually need to rely on DenyList for hiding. They can do everything themselves
• There are already modules out there that directly manipulates root detecting processes / system services to workaround HW KA
• This kind of approach to "hide root" is not something I would personally do anyways, regardless of whether I work at Google or not
• However, these invasive methods are actually the only way to workaround HW KA. It will not work forever though, so enjoy while you can
• I wish people won't fork Magisk just to add MagiskHide. Seriously, spending effort on hide modules is much more productive than forks
• But of course, Magisk is open source, you can do whatever you want Man shrugging
• My honest stance on root detection? With HW KA, that war is already over for me. For me right now, within Google we are brainstorming solutions on how to deal with the "root detection abuse" situation
Yes, John actually continues to make the Magisk framework 'more capable of hiding things' despite what nay-sayers argue. He's both done us invaluable service and continues to do so.
Fair point?John Wu, Oct 24
People calling me a traitor or imposter really disgusts me and makes me wonder why am I even spending time defending the community within Google.
I've been looped into so many conversations at Google for this, you have no idea what's happening behind the scenes.
If I'm really a traitor, why will I continue developing Magisk at all? I can also just directly submit code into to SafetyNet and specifically target and *$#@ over every single "hiding"modules out there. Do not tempt me.
I think it's pretty clear from the above that John won't be adding this (or old MagiskHide) back as it involves 'invasive methods' that 'attempt to manipulate other signals on the device', and as he said in his recent 'State of Magisk 2021' article
Having access to almost all Google source code (as all Googlers do) and spoken with various related teams, it simply does not make sense for me to be involved in any root hiding business as it is just straight up conflict of interest...
Magisk will not spoof/alter/manipulate any non-Magisk related signals or traces to circumvent any device state detection.
I discussed above how a chain-of-trust used by AVB and DM-Verity is broken if any such modification is made, including unlocking. Effectively there is no TEE any longer in which to execute code. Really, it's the security of the whole code execution environment that concerns them as it is precisely that that allows you / others to 'mess with' (hack) their app.
I've mentioned Google's stance on this here before:
(Tech Lead for Android hardware-backed security subsystems.), Mar 13, 2020
Some app developers want to know that their code runs in an unmodified environment, whose behavior is predictable. They can't have that assurance with ROMs that haven't passed CTS or that violate the security model.
The Android security team doesn't want to prevent the use of custom ROMs; we're actually quite supportive of that, and do a lot of work to ensure that remains possible. But it's reasonable to let app developers know about the nature of the platform they're running on.
I put a bit more here:
And this has info on Googles own concessions to modders:
John / community has known that effective hiding days are numbered since Google first switched on the newer form of TEE, HK TEE attestation (Hardware Key based TEE) Seems we've been in a testing phase for some time, possibly already longer than expected due to OEMs like OnePlus botching required hardware implementation, but that the switch (aka BIG hammer) for enforcing hardware TEE (no more fallbacks to Basic attestation) could be thrown at any tick of the clock (aka final whistle / game over).
In the meantime (while SafetyNet attestation remains unreliable at best), banks / other parties are resorting to myriad 'custom' ways to detect untrusted (read any modified) environments ('root' in very loose sense) to prevent their code running in these.
A simple way to see the issue is to envisage GPay or bank apps set up to call GPay etc to make payments on such a device. You may think these are secure enough, but if stolen such a device can be a windfall for the unscrupulous; they can likely simply unlock the device using an active ADB (Android Debug Bridge) or installed TWRP and make payments (empty your bank account), access bank / other details etc... Banks want to protect you from now widespread fraud as well as to protect themselves from litigation etc. Also, they will often cover losses from such fraud for customers but need to ensure no doors are left open to abuse for obvious reasons at the same time as such costs are rising every day... There are many more reasons these institutions don't want their code running in untrusted environments (read on devices with any changes OS including bootloader and other partitions) also.
In summary, don't expect John to do any more re. hiding... He's done plenty.
Hopefully we'll see @kdrag0n and other skilled Devs passionate about hiding continue / start "doing their job"!
'Enjoy it while you can!' PW