yashsingh1/xdaforums huggingface dataset:
[Magisk] pndwal:
@HippoMan , not me, but I have posted about origins in HHG... 😜 PW
[Magisk] HippoMan:
Yes, I'm the one who started it. There were telephone sanitizers among the original Golgafrinchians, and today's Googlefrinchians are continuing that tradition with all their Play Integrity efforts for our phones.

And I sometimes think that modern Googlefrinchians are engaging in endeavors that are as desirable and inspired as the Golgafrinchians' proposed project of defoliating the earth's forests in order to increase the value of the leaves that they were using as currency.

However, I can't say that the term "Googlefrinchians" has actually caught on with anyone other than myself.

42
[Magisk] HippoMan:
I don't see any evidence of panic. Please show me such evidence, if I am missing it.

No one is being compelled to participate in this thread, and very few are doing so.
[Magisk] brackenhill_mob:
Try Migrate or Swift Backup - works for me but YMMV
[Magisk] HippoMan:
Thank you. However, Migrate and Swift (both of which I'm already using) only work on the Data partition, not Boot, System, nor Vendor. Nandroid backups and restores can be performed on all of those partitions.
[Magisk] zgfg:
On the new Read only SAR systems, no hard changes could be done on System, Vendor - hence you can always (if needed) reflash the ROM.

Magisk performs only Systemless changes

When installing/updating Magisk by patch and flash, you actually have your latest/current boot.img

You could also disk-dump the current Boot img from Terminal (su required):

dd if=/dev/block/bootdevice/by-name/boot of=/sdcard/boot.img

---

On the old, not read-only systems, you have old Android and you can still use TWRP
[Magisk] TheObcd:
Just as a little reminder, LineageOS give security patchs for most of his branches even after 2 years unlike some other customs ROMS.

I let you check it here, but LineageOS17 (Android 10 / Q) received the March, 2022 security patches.

Thus if you're fine with LineageOS, you could be up to date in term of security, even on an old android version ;).
[Magisk] scorpio76r:
Thanks but, I'm using the Jaguar rom with the latest April patch. The developer update the patch same day as Google releases it.
[Magisk] HippoMan:
Thank you. I was thinking about perhaps writing my own disk-dump procedure for this.

I already used that disk-dump methodology in the past for a different purpose, and it worked, so I think I'll make some sort of generic script for this.
[Magisk] HippoMan:
Yes, and that is one of my reasons for not upgrading to Android 11 nor any later versions on my OP 7Pro.
[Magisk] HippoMan:
Well, the cat-and-mouse game keeps escalating:

https://www.androidpolice.com/safetynet-deprecated-for-play-integrity-api/

And see this related XDA comment:

https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-87185601
[Magisk] BootloopedMillennials:
At that point, why stay with Android?
[Magisk] Renate:
All these counter measures are a bit outside my expertise.

I've got my stock crappy phone and my rooted and modded eReader (Android 10).

I gave up on Magisk even though it's a clever thing, all those extra mounts make my head spin.

I just modify the DTB to not verify /vendor, then modify the fstab in vendor to not verify /system.

Then I modify both partitions to not use FEC, add some CIL files and recompile sepolicy, modify init.rc and adbd.

And you're rooted!

I'm not sure if this would pass any detector.
[Magisk] HippoMan:
This is great!

So, for those of us who would actually like to try this, could you point us to more detailed instructions as to how to perform all these steps?

And if all this could somehow be packaged into some sort of script or module, maybe it could be distributed as an alternative to Magisk.
[Magisk] HippoMan:
I wondered about that same question in my message that my second link points to.
[Magisk] samy233:
A question about that, How many user you think in the world who will use root/mod/custom ROM?​

​

I think it's marginal. And I think it's good for google to have some dev Modding things so they can improve their knowledge/products.​
[Magisk] eclipsek20:
Because there is no good alternative that I am aware of, it would be nice if someone could code a new Phone OS from scratch (kernal etc.) but that is just wishful thinking.
[Magisk] scorpio76r:
I was worried about this day coming about 2 years ago. I'm guessing that our rooting and, rom'ing days have come to an end or are dying very quickly at best.
[Magisk] Renate:
Well, abandoning a clean SAR means that you have to make sure that no incremental OTA updates come down.

If the updates are not unconditional then you have to restore the two partitions to the last clean state and then update, then modify again.

I'd think that a universal solution would be difficult as which partitions get loaded in the DTB might be variable.

There's also a bit of rebooting and stuff involved.

The notes to myself list 17 steps what to do when a new update comes down.

But yeah, I probably should start a thread.

Edit: 17 steps? I just fixed up my recovery so that I could build sepolicy there, saving a few steps.
[Magisk] HippoMan:
Here's my proposed workaround for us modding people to be able to win this cat-and-mouse game.

Unfortunately, it would require a multi-million-dollar investment ... but here it is, anyway, for us to at least wish for ...

There already are A/B devices. I propose taking that to the next level.

I propose that a device be designed to be essentially a fully "double" Android device. It would be pretty much two separate, fully functional Android-based phones inside of one case.

One of those contained phones would run a standard, non-rooted Android OS, and the other one could run any kind of rooted OS.

By means of hardware (hardware ONLY ... and no firmware or software!), the screen and buttons on this device could be switched to be active for one or the other phone.

Also, there would be some sort of shared storage that is also managed solely by hardware (again, no firmware or software), which lets both phones access the same blocks of storage.

One possibility would be to use dual SIM cards, and another possiblity might be for a single SIM card to be switched (again via hardware only) to be active for one or the other phone. The latter SIM option might not be realizable, but the dual-SIM methodology could still be feasible, I think.

With such an imagined device, people could run their banking and other root-detecting apps on the phone with the standard, non-rooted OS, and they can do all their rooted-enabled work on the other phone. By just flipping a switch (hardware switch!), the device could switch to the non-rooted ROM in order for banking, etc. to take place.

The shared storage would allow apps on both contained phones to access the same data in storage.

I think that at least in principle, such a device could be designed and built.

Now, all we have to do is convince someone like Elon Musk to take on the project of building and selling such "double Android" devices! :)
[Magisk] scorpio76r:
I definitely think that you could be on to something. Great idea 👍
[Magisk] HippoMan:
Thank you! Now, all we have to do is come up with a few dozen millions of dollars in order to fund this development! :)
[Magisk] Renate:
Mmm, anything with hardware becomes a limitation. I don't think anybody here agrees on hardware.

It's not my area of knowledge, but there are multiple executables loaded at boot, TrustZone, TEE and more things that I don't understand.

It might be possible to run multiple virtual OSes under the top-level supervisor if that's what you want.
[Magisk] scorpio76r:
The funding seems to be easier to achieve than finding a legit person to make this happen
[Magisk] xtcislove:
Your idead sound interesting but i cant imagine a phone like this.

Usually its this way: You have a normal OS with a emulated OS where you can do anything. Why not the other way around? The modern chips are fast enough for this and we could have a seperated section to use banking apps while modifyng the original OS the way we like.
[Magisk] HippoMan:
It's because other software running on the phone (Google's "SafetyNet" which is built into Android) can examine all of the software on the phone and can detect this emulated OS.

Having two separate phones with separate OS instances would have two separate SafetyNet implementations in effect, each one only looking at what's running on its own phone.
[Magisk] xtcislove:
I get why you like to have a "real" a/b device and it makes sense, but that would be a very expensive phone.

So whats problem with safety net detecting the emulated os? You have the come up with 1 method to hide the emulated os from it. Instead of hiding several things.
[Magisk] HippoMan:
The following is a copy of what I wrote in a comment in another thread, which turns out to be off-topic for that thread. It's totally on-topic here ...

I can't speak for anyone else, but for me, my editorializing about what I perceive as banks' stupidity doesn't mean that I have any expectation about these banks changing their policies. In other venues, I also editorialize about other things (for example, certain societal trends) which also have little, if any chance of changing.

Anyway, it's of course important for security purposes to reduce the attack surface, but rooted/modded Android devices make up much less than one percent of the attack surface area that banks need to pay attention to. And even with the use of the security tools that Android offers, I still believe that the banks pay proportionally more for their anti-Android-modding software development (which in many cases goes beyond the mere use of Android's Safety Net and Play Integrity facilities) than the losses they would incur without having developed this additional software.

But like I said, I have no expectation of any banks making any changes to these policies.

There's no law against being stupid.
[Magisk] HippoMan:
The following is a copy of most of what I wrote in a comment in another thread, which turns out to be off-topic for that thread. It's totally on-topic here ...

Yes. Play Integrity (and SafetyNet in the past) are used for the purpose of identifying compromised devices, and the use of these Google-supplied features doesn't cost the banks very much, relatively speaking.

I'm talking about all the other efforts that many banks make which go beyond Play Integrity and Safety Net. Not all banks go this far, but those who do are spending (OK, I'm willing to say "wasting") programmer-hours and money going after a minuscule attack surface.

[ ... etc. ... ]
[Magisk] V0latyle:
I mean, a lot of that isn't necessarily the banks, but rather the developers contracted by the banks to develop the apps; such developers more likely than not incorporate the same measures in most of their secure apps. I'm still not sure I agree that it's specifically targeting developers, and the PC analogy doesn't work for a few reasons:

Banks (and their developers) aren't building applications to run on Windows; they use websites, which they can protect with browser measures such as HTTPS, SSL, TLS, etc. This is why only some browsers are supported, and even then generally require a certain minimum version - many bank websites don't support older versions of Internet Explorer, for example.

Windows, even when the user has administrative rights, still segregates system files and processes from the userspace. While Android does this to a degree, the Windows kernel and the Android kernel behave differently when it comes to root access - administrator rights on Windows does not constitute total root access, because said rights extend mostly to the file system, not system processes.... whereas SU permissions on Android (to my knowledge) can access and change anything and everything, because root literally lives in the kernel. So, I go back to my earlier point: it makes little difference to developers whether a responsible and cautious modder is running Magisk, or an unaware user's device has been compromised by a rootkit. One must also consider the mechanisms of Android (and the device) that are disabled by unlocking the bootloader, simply because with an unlocked bootloader, no trust can be established, any image can be loaded, and there is literally no way to verify that operational integrity is secure. The one difference here is the ability to set a custom root of trust - meaning that a custom ROM developer can implement a custom signed key used by Verified Boot and similar mechanisms to verify the integrity of boot and system images. What I don't know, because this is beyond my degree of knowledge and expertise, is whether such a custom signed ROM (and kernel) could still include root. Perhaps @pndwal and @ipdev could weigh in on this.
[Magisk] HippoMan:
Desktop computers can be hacked, and the fact that there are ways to get admin rights on all such computers (Microsoft, Linux, Apple) means that a hacked desktop allows the hackers to obtain "admin" or "root" and do essentially anything they want on those machines, including keystroke capturing for users accessing their bank accounts via the web.

Conversely, I can access my bank via the web from my Android device, and that will give me more capabilities via my device than my bank's banking app will give me.

Therefore, I still consider rooted desktop computers and rooted Android devices to be more or less equivalent risks to banks, in terms of ease of obtaining information via hacking.

And again, I mention the fact that banks gladly issue us debit cards which are just as easy to steal as mobile devices. And even without stealing the debit cards, there are ways to capture the debit card info and then spoof the use of the card.

Even though it may very well be developers and not banks themselves who put all that extra checking (i.e., beyond SafetyNet and Play Integrity) into the apps that they write for the banks, the banks are the ones paying the developers for this extra work, and again, I don't believe that this cost of blocking the tiny (comparatively speaking) attack surface offered by rooted/modded Android devices is comparable to the cost of the fraud that could be committed if this specific tiny attack surface was not blocked.
[Magisk] HippoMan:
The following is a copy of what I wrote in a comment in another thread ...

As the use of Play Integrity (and its likely descendants) continues to spread, more and more apps will cease to function fully (or at all) on a rooted/modded device.

Sure, rooting will still be possible, but rooted devices will become more and more crippled for normal use as time goes on.
[Magisk] zgfg:
Sorry guys, but for me most of this classifies as (not applicable) philosophy

But ok, maybe that was the purpose of this thread
[Magisk] HippoMan:
Yes, this thread is a catch-all for philosophy, opinons, ranting, etc. concerning the fact that it's getting increasingly difficult to root and mod our Android devices and still expect them to generally behave in a non-crippled manner.

Non-philosphical, non-opinionated, and non-ranted technical discussion is also welcome here.
[Magisk] V0latyle:
I'd like to be clear on this...The whole point of my Play Integrity API thread is to be informational: to provide a place to lay out and discuss the Play Integrity mechanism itself. I have no issue with the philosophical/ideological discussions/rants in principle, as I have zero issue with this thread here - I just don't want those rants, conjectures, and assumptions in the informational thread.

Well, I personally don't have any experience with apps that are able to detect the presence of root beyond SafetyNet/Play Integrity. I don't doubt that they're out there...but I still think that a lot of these issues with rooting are more of side effects. Since unlocking the bootloader disables AVB as well as TEE, meaning HKA won't work, an unlocked device will never pass Play Integrity STRONG attestation. I don't think that's really deliberate - unlocking the bootloader by design allows custom images to be flashed and booted, meaning that nothing can be verified against any root of trust.

But beyond that, more to the point of what you're saying about extra checks for root (such as looking for the presence of the Magisk app)...I'm going to make an assumption here, but I believe it's in response to our advances in spoofing SafetyNet attestation. Granted, they could have always required HARDWARE_BACKED evaluationType, but for some reason didn't, and that in of itself is a reasonable question (I think @pndwal or someone had mentioned that this was never fully implemented by Google)...but, since they know that we could at least force BASIC evaluationType, they resorted to other means to try to verify integrity of the device, which inevitably means looking specifically for the presence of rootkits. MagiskHide and the ability to disguise the Magisk app came as a response to this, though I don't know how successful they have been.

At the end of the day, someone will always try to build a better mousetrap (security) and someone else will always come up with a way to circumvent or defeat it. It's a bit of a cat and mouse game; this is why software/information security companies offer bounties for significant exploits, and why so many "black" hackers end up in the employment of said companies specifically in the role of trying to defeat their own security, most often with paychecks that would make our eyes water.
[Magisk] HippoMan:
Your assumption seems to be warranted.

And I still believe that the costs of paying for this enhanced security against Android rooting and modding (I use the word "enhanced" here to mean beyond SafetyNet and beyond Play Integrity) on the part of those "

black" hackers

(and anyone else who is involved) exceed the amount of money the banks could lose via fraud if this enhanced anti-rooting/modding security was not developed.

And yes, your characterization of this as a "cat and mouse game" is exactly the way I have characterized it in naming this thread. And I continue to believe that we mice are well down the road towards losing this game.
[Magisk] pndwal:
Sure, root can be obtained with any boot state...

custom root of trust would be Yellow boot state...

https://source.android.com/docs/security/verifiedboot/boot-flow

This would pass basicIntegrity only as the OS hasn't passed CTS certification... So bank apps won't run ordinarily... PW
[Magisk] V0latyle:
If the OS is otherwise factory, would it still fail CTS?

For example, the Pixel devices - AOSP with heavy Google service integration. If someone were to simply modify the kernel to allow user root access, and set a custom root of trust so that everything passes verity and verification, then lock the bootloader (yellow state) wouldn't it still pass CTS?

Or maybe I'm thinking of basic?

In that regard, does a custom root of trust also break TEE and HKA?

You understand the workings of this far better than I do. Thanks for tolerating my stupid questions
[Magisk] pndwal:
Top of head; signing keys would be certified, not custom if stock, so green boot state indicating Compatibility Test Suite pass... If images are altered at all I believe these keys won't work (ie. bootloop most devices if re-locked) so new (custom) keys would be needed and boot state would be yellow if locked, orange if unlocked...

basicIntegrity can pass with custom or uncertified ROM and with unlocked bootloader, but not with root unless signals are manipulated... PW
[Magisk] HippoMan:
Unless I am missing or misunderstanding something, in summary, this means that you can have "BASIC_INTEGRITY" or "being rooted", but never both ... correct?
[Magisk] pndwal:
Asus ROG Phone 3 does! 😜 PW
[Magisk] m0han:
Are you sure it was me? Could you link to that? I'm not subscribed to this thread.
[Magisk] pndwal:
I said unless signals are manipulated... But not if used as Google intended...

Of course signal manipulation is what USNF and other mods do and MagiskHide did... So with these we can of course have basicIntegrity w/ root.... PW
[Magisk] pndwal:
Did I say pounded? 😝 Meant founded...

And no, I read this just before mod removed the members comments and responses... Though you'd said 1998... Someone did.

I apologise that my memory has failed me again... 🙁 PW
[Magisk] Renate:
???Confusion???

Does it? (I thought) I had to write a complaisant vb_meta (flags=2) to boot a modified image.

Can you even run without TEE? Can you erase the TZ partition?
[Magisk] V0latyle:
I'm less knowledgeable on this, but it's my impression that unlocking the bootloader does disable AVB - you can boot whatever image you want, the only thing that's checked against vbmeta is the image header...OR, maybe it's just what the device "thinks" if the image header is bad.

As I understand it, vbmeta is more or less the "checksum" against which the hash of the image is checked to verify its integrity. A modified boot image obviously won't pass, yet we've been able to successfully boot Magisk patched boot images on the Pixels without touching vbmeta. The only exception to this is when Android 12 released; Magisk prior to Canary 23016 (IIRC) did not properly handle the boot image HEADER, which was updated to version 4 with Android 12. I don't know exactly why, but until Magisk got fixed, the only way a patched boot image would boot was if vbmeta was reflashed with --disable_verity and --disable_verification. Canary 23016 fixed this, so we no longer had to do anything with vbmeta; the vbmeta image is left stock, only the boot image is patched, but it boots just fine.

Obviously, if the bootloader is locked, the device will fail to boot because the patched boot image fails verity.
[Magisk] HippoMan:
OK. So now I understand that these signals can indeed be manipulated.

Thank you.
[Magisk] ipdev:
Hi all. 🙂

I have typed a few pages worth of a reply trying to figure out the best way to describe this..

I decided on a short recap of what ended up being paragraph after paragraph of over explaining..

Please stop comparing mobile OS to full desktop OS. 🙃

---

All systems have controlled levels of access, permissions, privilege, security, ... (what ever it is referred to).

Root (System)

Admin (Administrator)

User (Normal)

Limited (Restricted)

Each includes the level of access below it.

Depending on setup, there might be more than just a normal user level.​

Since security is on the top of everyone's list.

Linux and MacOS have been restricting more and more.

Root access is not removed but, there are more and more steps to enable it and give access to it.

---

I am not sure how much permission(s) is given to Admin in Windows.

Might be higher than Linux and MacOS but...

I would not call Windows Admin Root. 🙃

Admin windows shell. 🙂

C:\Windows\system32>whoami
mb-win\ip

Root windows shell. 😜

C:\Windows\system32>whoami
nt authority\system

Since I am not an active Windows guy..

I am not sure if the way I did it on Win 7 is the best way.

I would recommend searching https://docs.microsoft.com to find how to obtain full system access to the version of Windows you are running.​

Cheers all. :cowboy: