yashsingh1/xdaforums huggingface dataset:
[Magisk] HippoMan:
I have a Linux box and a MacOS box, and both have an "su" program as well as a "sudo" program, and on both, it is trivially easy to obtain root.

And yet, my bank does not require me to run software which detects "su" and "sudo" and then cripples capabilities on my systems before I am allowed to perform any banking functions from these machines.

As for Windows, I haven't used it at home for more than a decade or two, but at least I remember this much: that it's possible to simply log in as Administrator and then remotely perform banking functions. Again, banks don't require Windows users to install any system-crippling software on their machines before allowing this banking access.

Plenty of home computers get hacked, and malware that can be installed during these hacks can obtain root or Administrator rights and then install keystroke-capturing malware. Then, the users' login credentials for web-based bank access can be captured. And yet, banks don't even require their customers to install anti-virus and anti-malware software.

These root-and-Administrator-enabled home computers from all over the world make up a massive attack surface which is orders of magnitude larger than the worldwide rooted-Android-device attack surface.
[Magisk] Renate:
Windows and Linux/Android are two different animals.

Of course both have all sorts of file permissions, users and groups.

SELinux (used on Android) has very fine grained permissions on all sorts of actions.

sepolicy is the file describing all that, which is compiled from .cil files using the secilc compiler (found on your Android).

I've got 2.5 Megs in 4 .cil files on my Android 10 device.

Take a peek if you want to get a sense of SELinux.
[Magisk] HippoMan:
And I don't know of any banks who require customers using Linux to prove that they have certain SELinux settings in force before they can log into their banking accounts.
[Magisk] V0latyle:
Well...again, I think you may be attributing motive where there may be none, or otherwise reading too much between the lines.

Banks require secure browser sessions, right? HTTPS with TLS. They do this to prevent the "man in the middle" attacks between the client browser and the bank server. This inevitably means that at a certain point, browsers that are incapable of newer TLS versions won't be able to negotiate a secure session. Try booting up Windows 98 in a VM and see if you can access any bank site. At best, you'll get a warning that IE6 is not supported. Are they doing this to specifically exclude users of Windows 98? No...they're just trying to maintain that minimum standard of security. And as you've mentioned, a secure browser does not guard against compromised security on the client PC, such as keyloggers, and a browser cannot generally report whether the client has indeed been compromised.

The difference with banking apps specifically is the desire for some sort of guarantee of a secure and sterile environment; hence, they use APIs such as SafetyNet and Play Integrity. Some have gone so far as to use other methods as an attempt to detect root, as you've mentioned; I would still argue that from their perspective, there is no difference between a device that's been unintentionally compromised by a persistent rootkit, and a device that's intentionally compromised by a power user/modder/rooter. You may think there is a difference, but to these mega billion (or trillion!) dollar corporations, there isn't one...and good luck trying to convince them otherwise.

Ultimately the debate on whether or not they're intentionally trying to disadvantage rooted users will soon be irrelevant, because when Play Integrity becomes the de facto standard, all devices that cannot meet complete integrity will be left in the dark - not out of some ulterior motive, but simply because it is not possible to meet the security standard.

I had raised the question previously but I'll ask again: if an enterprising OEM wanted to extend specific freedoms to developers and provided rooted firmware...could this still run in a trusted environment, if the OEM intended it to? Obviously it's a huge vulnerability, because root access means anything can be changed in /system or /boot, which would then defeat the purpose. But simply for the sake of argument, is it possible? I'm not talking about a custom root of trust; I'm talking about something signed with OEM keys to run in "green state".
[Magisk] HippoMan:
On my Android device, I can access my bank via an HTTPS-enabled Android web browser, and I have all the banking features available to me that I have when I access the same HTTPS bank URL from my desktop computer.

I just have to utilize one of the Android browsers which permits the user to set it in "desktop mode".

This is on my rooted Android device.

And on this rooted Android device, the same bank's Android app detects that my device is indeed rooted and modded, and that app only offers me crippled banking functions.

For my own personal enjoyment, I went so far as to do the following: I picked an Android browser that I don't normally use, I set its home page to my bank's HTTPS-based access URL, and I set the browser to desktop mode. And then I replaced that particular browser app's icon with a copy of my bank's app's icon, and I changed the name of the app to be "My Bank Name #2".

I can access my bank via that Android browser instead of via my bank app, and the look-and-feel is almost identical to what is offered to me via my bank app. And as I mentioned, I get the same capabilities that are available to me when I access my bank via the browser on my desktop machine at home.

Perhaps there are other banks with whom this procedure won't work. But at least with my bank, all their Android-targeted security is totally and completely useless.

Also, regarding the "man in the middle" attack. Thousands, if not millions of desktop computers have been hacked. Anyone using high-grade HTTPS-based and other security to prevent man-in-the-middle attacks are still totally vulnerable to keystroke loggers once their machine has been hacked. And the hacker can then obtain the login ID and password that the user utilizes to log into the bank, irrespective of how secure the browser-to-bank-server internet connection might be.
[Magisk] dr4go:
Is this the only phone where tee works with a rooted phone or is it only the rog phone 3?
[Magisk] pndwal:
I don't know of any where TEE itself breaks with root! 🤪

Asus ROG Phone 3 is one of many devices where keymaster implementation (Keymaster Hardware Abstraction Layers (HALs) that enable cryptographic communication with secure hardware where actual keymaster, keystore TEE OS etc reside) is borked by OEM however...

This does NOT mean that the TEE OS itself (Google's Trusty TEE or OEMs alternative selection) doesn't work; The TEE actually works fine so HD widevine video decryption and other data handling requiring processing in TEE generally are not affected...

It seems One Plus is the most notorious culprit for messing up keymaster for some time and in many devices... They may be partly responsible for Google's slow implementation of properly enforced hardware keystore based attestation to CTS Profile match etc...

One Plus devices and others where keymaster fails generally can't pass CTS Profile match with HARDWARE Evaluation type or strongIntegrity PI verdict even in stock (B/L locked) condition... ROG Phone 3 is the only device I know of where the implementation has been messed up in such a way that the opposite occurs, ie. these attestations always pass! 😜 PW
[Magisk] HippoMan:
To @V0latyle ...

Actually, you and I agree on most of what we've been discussing about banks' approach to security. I agree that banks have a right and a need to implement security policies. I just don't believe that they are doing so in a very intelligent manner.

And I don't believe that banks are picking on users of rooted Android phones, or anything like that. It just so happens that rooted Android phones are a cheap and easy venue in which banks can implement a tiny bit of minimal transactional security. This anti-Android-rooting-and-modding security only affects a minuscule percentage of bank customers, but having such security still looks good to the bank's shareholders and potential bank customers.

HTTPS has nothing whatsoever to do with the case that I mentioned ... where a home computer is hacked and a keystroke monitor is installed to capture whatever the user types. Such a keystroke monitor would allow the intruder to obtain the login credentials which are typed by the user when signing in to the bank's web site, irrespective of whether or not the browser ultimately implements the connection via HTTPS.

And also, I already utilize HTTPS on the Android web browser that I use in order to access my bank's site via my Android phone. If someone hacks my device, that person could obtain the bank's login credentials that way.

Actually, even if I stick with my bank's standard Android app, I still have to enter a user ID and password to gain access to the bank via that app, and anyone who hacks my Android phone could also obtain those login credentials. And mobile phones can be hacked in this way whether or not they are rooted, jailbroken, or whatever ... for example, via Pegasus spyware, and that's probably not the only way.

With this in mind, if banks really want to offer protection against mobile-phone-based hacking, they should not permit access via any mobile device, whatsoever, irrespective of whether or not it's rooted, and even irrespective of whether or not it runs Android.
[Magisk] Renate:
A bit of a different theme...

I see that the Play Integrity API hits Google servers (presumably on each app start).

I presume that it also reports the app in question.

As the PI becomes more well-known and more well-used will developers start putting it into Flappy Birds?

Google would probably appreciate the free info.

The game developers could see that the game isn't hacked.

Will it get to the point that you can't use a calculator if you don't pass PI?

And will Google black-list devices arbitrarily?
[Magisk] zgfg:
You are asking questions that should either answer Google or developers of the particular apps😁
[Magisk] HippoMan:
Governments would love that info also, when they decide to subpoena Google.
[Magisk] Nekromantik:
hi posted on magisk general but not much help

So I run Magisk 26.1 with UNSF 2.4.0 MOD 1_2 with Shamiko. I pass basic integrity and all other apps dont detect root and device is certified. However since last update Starling Bank app in UK shows message when you exit it to say modified device detected.

Anyone else here using Starling found a fix?
[Magisk] robuser007:
use shamiko 0.7(161), latest version is having issues for me.
[Magisk] spida_singh:
Does starling work with this version of Shamiko?
[Magisk] Nekromantik:
i never updated to 161
[Magisk] HippoMan:
However, banks do not cripple their access from desktop devices which happen to not have proper anti-virus software installed.

And banks do absolutely nothing to force linux and macos devices to be de-rooted or to force Administrator capabilities to be removed from Windows devices.

I don't want some bank trying to tell me that I can't use my device the way I want, simply because I might have accidentally downloaded malware. I know how to protect my Android device a lot better than some amateurish programmers working for a bank can try to "protect" me from myself by means of the poorly-thought-out anti-root/anti-modding capabilities that they try to program into their apps.

I'm willing to take responsibility for any errors I might make in performing my own device protection, and I will never try to blame such errors of mine on the bank.

I prefer for the bank to issue me some sort of waiver that I can sign in which I promise never to hold the bank responsible for any errors that I commit on my device.

As for the sudo utility: it is not the only way to get root. Anyone logged in as root under linux or macos can do the following ...

chmod og+sx /path/to/executable

chown root:root /path/to/executable

After logging out from root, that executable now will run with root privileges, even if a non-root user invokes it. This is equivalent to setting an app to run as root via Magisk on an Android device.

No banking software that I know of checks for the existence of such setuid programs on the linux or macos machine which is accessing the bank.

I'm not as familiar with Windows, but I know that there are similar facilities available to cause any executable to run as Administrator under Windows.

And again, no banking software that I know of checks for the existence of such programs on Windows machines.

Also ... as I've mentioned, banks gladly issue us debit cards. These devices have even less security associated with them than Google Pay requires on Android devices, and these debit cards are just as easy to steal as mobile devices.

And there are millions more people who have been given these non-secure debit cards by banks than there are people who are rooting Android devices.
[Magisk] sawdoctor:
Unfortunately it doesn't matter what we want or what we think big corporations like banks will just do what they want and we have to live with it. Hopefully it won't get to the stage where you need a separate device for banking apps but we will be in the cat and mouse game until the modding society runs out of ideas
[Magisk] HippoMan:
Yes, I agree. I created this thread mostly so I could rant and complain and pontificate about how the banks and other app developers (with Google support) are making our modding/rooting lives more and more difficult, and about how I believe their anti-rooting motives are very poorly thought out.

I don't think that we modders are going to win this cat-and-mouse game, and believe that not very much more time will pass before rooting becomes a huge liability on Android devices.
[Magisk] Humpie:
The case against modders becomes even stronger with this set of apps I discovered and discuss here: https://xdaforums.com/t/tap-to-phone-to-pay-on-android-attestation-failure.4619383/

You can now turn your phone into a payment terminal and receive in-person payments! Well, unless your bootloader is unlocked of course...

I have a strong suspicion hardware checks are in place for this one. Hopefully I can be proved wrong (because how awesome would that be :) ), but I fear the worst. Especially since nothing is stopping any app from implementing this type of security.
[Magisk] HippoMan:
Yes, more and more developers are adding this and similar security to their apps, even for non-"banking" applications.

The difference in usefulness between Android and iOS phones continues to narrow.
[Magisk] HippoMan:
Given the continuing deterioration of Android as newer OS versions and newer app versions are released, and given the fact that we rooters and modders are losing the cat-and-mouse game with developers and with Google itself, perhaps the time has come for this following idea ...

Someone invents an inexpensive Android "banking device" with a small amount of memory and storage, and with a bare minimum of native apps installed. It could be credit-card sized.

It would have just enough capacity to hold a very small number of banking apps and not much of anything else.

Because of its credit-card size, there wouldn't be room for a keyboard for PIN entry, so it would rely on fingerprint identification.

It would come with an auxiliary charger and hub which would allow apps and OS upgrades to be downloaded and installed.

This would allow us to forget about trying to shoehorn banking apps into rooted and modded Android devices which become increasingly crippled as new Android versions and new app versions are released.

If I had millions of dollars at my disposal, I'd get such a thing developed. But perhaps someone else who actually does have access to a sufficient amount of funds might want to work on something like this.

At least I can dream.
[Magisk] HippoMan:
PS: In the interim while we wait (probably forever) for this dreamed-for device to come into existence, we can buy a small, used, cheap, very low-capacity Android device running a stock OS upon which we can run our banking apps.

This situation reminds me of a joke:

A guy goes to the doctor.

Doctor: "What seems to be the problem?"

Guy: "Well, doc, when I move my arm like this, it really hurts." He demonstrates by moving his arm.

Doctor: "So don't move your arm like that."

I apply the same thought process regarding the use of banking and other banking-like apps on my own rooted phone.

Doctor: "What seems to be the problem?"

Me: "Well, doc, the only way I can run banking apps on my rooted Android phone is to cripple the phone's rooting capabilities or to jump through a number of annoying hoops."

Doctor: "So don't run banking apps on your rooted Android phone."

And that's what I do. I don't attempt to run banking apps on my rooted phone, and instead, I do my banking in old-fashioned ways: via my desktop browser, via an Android-resident browser, via my bank-issued debit cards, and by actually walking into the bank and dealing with a teller.
[Magisk] zgfg:
I remember that joke, it's good

Btw, I do my banking from my rooted phone and I removed all my plastic cards from the wallet, I happily pay everything by phone

And I obtain my e-citizen token from the phone when I have to use the e-citizen services (also from the phone)

Only, I keep my NFC disabled (just in case, it's not really necessary) and I unlock the phone and enable NFC only when I'm really going to pay in the store, caffee, etc
[Magisk] HippoMan:
I remember that I told that joke to you before, and I was wondering if you'd reply. :)

You and I are the opposite regarding plastic cards. I much prefer them.

Actually, Delta 26.3 seems to work to hide a couple of my bank apps. One is being hidden for sure, and the other might not even do root checking in the first place. I won't name the banks, in case any go-getters from from their IT departments might be reading this.

A couple other bank apps don't get hidden, but I don't care, due to my preference for plastic.
[Magisk] zgfg:
If I would loose my wallet with plastic, thieves will have some time to pay contactless (and with limited amounts)

But if I loose the phone, they cannot unlock and they can't pay
[Magisk] HippoMan:
I understand.

As for me, I hate having to deal with a locked phone, so I stick with Swipe Lock. This means that I take the same risks with my phone as I take with my wallet.

And I'm gladly willing to accept those risks.
[Magisk] zgfg:
Now an easter egg for you (nostalgia like plastic cards and so)

Type the following to the Chrome address bar and play:

chrome://dino
[Magisk] lolvatveo:
Is magisk a best tool for hide root now? Zygisk have a bug and still won't fixed
[Magisk] zgfg:
If you're brave, try with this (cannot advise about, I didn't):

GitHub - chenxiaolong/avbroot: Sign (and root) Android A/B OTAs with custom keys while preserving Android Verified Boot

Sign (and root) Android A/B OTAs with custom keys while preserving Android Verified Boot - chenxiaolong/avbroot

github.com

Seems that with this you could relock BL and pass everything, by keeping the root
[Magisk] HippoMan:
Thank you!

I have Chrome frozen on my mobile devices, so I'll check out the Easter egg on my home computer.

I'm traveling now, and I'll be back home on Monday to view the Easter egg.

Then, I'll report back about it.
[Magisk] HippoMan:
I finally had a chance to play with this "dino" Easter egg on Chrome on my home laptop. It's cute. Thank you!

I wonder how much of my personal information Google was able to extract from my home computer when I was playing the game. :):)
[Magisk] Incomtus:
I can not use my uber driver app anymore with my phone with custom ROM even with safetynet OK and shamiko... It s very annoying, what are they scared about....
[Magisk] Incomtus:
Don't really agree. Apps doesn't refuse root for our security but for their company security.
[Magisk] zgfg:
However, most of the rest was perfectly depicted

Particularly about the poor Bob who doesn't understand technicality (and doesn't take time to study and learn) but bothers instead by asking the same things several times

Repetitio est mater studiorun🤪
[Magisk] HippoMan:
Well, actually, some things about root and sudo and setuid on Linux and MacOS devices were also not perfectly depicted. And functionality under Windows that's parallel to root/sudo/setuid was not perfectly depicted, either. I explain these things above in my original response to the post in question.

However, the parts about an ill-informed user getting hacked because of not understanding how to manage root (or even because of not understanding how to manage a computing device) were indeed well-depicted.
[Magisk] Pro-me3us:
Is it possible to hide the bootloader unlock status so that even Momo can't detect an unlocked bootloader? Momo uses key attestation to detect bootloader unlock status?
[Magisk] zgfg:
With Bootloader Spoofer module for LSPosed you can hide unlocked Bootloader from Key Attestation app

You can also hide it from Momo - but:

- without that module, Momo detects only Magisk found

- with that module, Momo detects additionally Zygisk found and Zygote injected

See the screenshots

Hence not much use here

And btw, who cares for Momo (if it detects unlocked BL).

Anyway, that module does not help anything for Play Integrity (Strong Integrity)

Btw, install the module (search on GitHub) and Play yourself😀
[Magisk] Pro-me3us:
Yea I'm not worried about Momo itself, I'm only using it as a guide to see what's exposed. The app I'm actually dealing with force closes on a bootloader unlocked device, even when using the stock boot.img, Magisk Manager and LSPosed Manager are uninstalled. This made me think that it might be checking the bootloader lock status.

Using Magisk+Zygisk+Shamiko the app still force closes, but I can see that the safetynet check is passing. I tried using Hide My Applist and now BootloaderSpoofer, but it still force closes. I can't say that it isn't looking for and finding Zygisk now. The device is on Android12 for better or worse.
[Magisk] HippoMan:
Yes, it's entirely possible that the app is checking bootloader lock status, in addition to whatever further checks it might perform in order to look for Magisk, LSPosed, Zygisk, etc.

More and more app developers are jumping onto the "Let's cripple Android even more!" bandwagon, because they over-react to security concerns. Some of them go beyond simply using Google's mod-detecting and root-detecting tools, and they come up with addtional ways to check for rooted-or-modded devices ... such as looking for an unlocked bootloader.

That might be happening in your case in the following manner: some sort of LSPosed or Magisk or Zygisk (or whatever) checking might be done, and that would block the app in question when any of those items are installed and detected. And without any rooting or any of those items, then the unlocked bootloader check would still find your unlocked bootloader.

I'm just guessing, but that could explain the behavior you are seeing.
[Magisk] HippoMan:
It's totally irrelevant as to whether or not the Googlefrinchians are *trying* to work against modders. Their underlying motives don't matter in the least, and it's simply the end result that counts.

Lots of their ancestors, the Golgafrinchians, were telephone sanitizers, and today's Googlefrinchians are simply carrying on that tradition and working to sanitize our smartphones. If this happens to thwart the efforts of modders, that's just an unintended and unfortunate side effect.

And in any case, we modders represent only a very small subset of Android users, and it's a financial DIS-incentive for the Googlefrinchians to cater to our wants, given that their primary business is capturing information about the users of their services and selling that data to advertisers and other clients.

So, we modders are just going to end up suffering the same fate as the original Earth inhabitants whom their Golgafrinchian ancestors displaced after they (crash-)landed here eons ago.