SuperSU and SafetyNet / Android Pay
- Thread starter Chainfire
- Start date
That's interesting.
On my device (galaxy note 5, systemless root, NO xbin binding), disabling superuser allows safetynet checks to pass. It's very possible that something other than the existence of 'su' is failing safetynet. You might have xbin binding, xposed installed, or something changed that safetynet explicitly checks for.
R
r3t3ch
Guest
As mentioned earlier, if you're on 2.67 it won't work as intended. I can confirm that on 2.67 the disable option actually leaves su active, while on 2.66 it works correctly.
Although temporarily disabling supersu allows safetynet checks to pass and cards to be added in AP, can anyone confirm that AP will allow an actual transaction to go through? I remember in the early stages of the AP fiasco, disabling supersu passed safetynet but still couldn't get AP fully working.
Last edited:
Don't agree. I'm on 2.67 on the Nexus 6, and temporarily disabling Su# allows AP to pass.
Sent from my Nexus 6 using Tapatalk
---------- Post added at 09:50 PM ---------- Previous post was at 09:48 PM ----------
Good point. Not going shopping now. Too cozy and warm. It's cold outside!
Sent from my Nexus 6 using Tapatalk
Unfortunately for me disabling supersu in the app does not allow safetynet to pass.
Can confirm. Going into SuperSU and unchecking it will let me pass SafetyNet. Did not test AP yet though.
when I go into supersu the check mark for enable superuser is grayed out and says not currently available in systemless root mode
shoey63
Recognized Contributor
No need to update the binary and reboot. Open the app, ignore the nags and re-enable in settings.
Done.
Weirdness going on. After my prior problems....I uninstalled SuperSU, unrooted, flashed stock *everything* except for userdata, reinstalled systemless root 2.67, tried Android Pay, got the "can't use" "can't verify OS" or whatever message I had gotten before. Two days later, went to the market, and Android Pay worked. There had been no changes since my prior failed attempt.
I think that perhaps Google is trying different things server-side in an effort to keep Android Pay secure and defeat systemless root.
I think that perhaps Google is trying different things server-side in an effort to keep Android Pay secure and defeat systemless root.
It appears that Safetynet will fail when a file named su exists in /su/bin regardless if it's a valid su or has the correct file permissions. So right now one can only toggle su from within supersu.apk before and after AP usage. That's not a terrible situation. I could live with that, but I suspect this will change on Google's end as Safetynet is altered to dig deeper into the Kernel to look for patching.
Perhaps a Tasker profile which unroots the phone when Android Pay is launched, then roots the phone again when Android Pay is closed.
I don't anticipate Chainfire working to introduce any workarounds on this either as he has already said he won't.
For the people who run custom roms/kernels and temp unroot does NOT fix the situation, then Safetynet is digging deeper than just looking for the SU binary.
Perhaps a Tasker profile which unroots the phone when Android Pay is launched, then roots the phone again when Android Pay is closed.
I don't anticipate Chainfire working to introduce any workarounds on this either as he has already said he won't.
For the people who run custom roms/kernels and temp unroot does NOT fix the situation, then Safetynet is digging deeper than just looking for the SU binary.
This new detection is quite easy to beat really.
The thing is, most work-arounds that aren't ridiculously complicated are fairly easily detectable anyway.
The thing is, most work-arounds that aren't ridiculously complicated are fairly easily detectable anyway.
Update: went to McDonald's to check if AP worked with systemless root. Went and unchecked disable su in app, loaded up safety net app and checked and it passed, went up to counter tried to pay with AP and it failed. Maybe someone else can try the same steps that I did but this time maybe reboot the phone before using AP. If not I will tonight when I get off from work this time with a reboot after disabling. 
Update: went to McDonald's to check if AP worked with systemless root. Went and unchecked disable su in app, loaded up safety net app and checked and it passed, went up to counter tried to pay with AP and it failed. Maybe someone else can try the same steps that I did but this time maybe reboot the phone before using AP. If not I will tonight when I get off from work this time with a reboot after disabling.
Just tried the same with the same results. After disabling su, Safetynet Playground passed, but AP wouldn't work. I did not reboot before trying AP. I also was unable to re-enable root without re-flashing 2.67.
My favorite line from the OP. "This thread has been created because you guys simply cannot stop talking about this, so these posts can now go here, where I don't ever have to see them. "
Made you look, made you buy a penny book. So I'm ready to beat this new detection. Do tell.
The point is that Chainfire said it is easy to beat the new detection a couple of posts above mine. I'd just like to try it. A slight bit of humor as well but obviously lost in translation. :angel:
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
54This is the place to discuss anything and everything related to SuperSU and SafetyNet / Android Pay.
To clarify, I am not currently actively doing any development on having SuperSU pass SafetyNet detection, or having Android Pay work; the same way I put no effort into beating other root detection methods such as various enterprise security tools.
In case any SuperSU-rooted device passes SafetyNet, that is a bug in SafetyNet, not a feature of SuperSU.
While I may not agree with Google's stance, I'm not about to go messing with payment systems. Is it possible though? Probably yes.
This thread has been created because you guys simply cannot stop talking about this, so these posts can now go here, where I don't ever have to see them.33
I think there is a bit of confusion going on here. Let me explain this one more time.
(1) Being able to change things on /system is completely unrelated to having a system-based root or a system-less root. System-less root does not prevent you from making any changes to /system you want. The root itself just doesn't make any changes to your /system. It is true that on some devices modifying /system doesn't work right even with root, but this is not due to root itself or how/where it is installed, these are two separate issues.
(2) On 6.x, even with a system-based root, you still need a patched (custom) boot image (kernel). If you don't want the system-less root because you don't want to need a patched kernel, installing root to /system isn't going to solve that problem for you.
(3) Root on /system still works if installed that way, it just isn't installed that way by default. I'm keeping it available in case the exploiters need it to root locked bootloader devices. I have no idea how they would do this, but I'd rather not limit them at this point.
(4) I will provide a solution to increase compatibility with old apps by doing something with /system/xbin/su, for 2.62.
Aside from point (4), there are no benefits that I can see to using a /system based root over the system-less variant. Please, try to explain to me why you think you need it. What benefit will it bring you? Because none of the points raised in the quoted posts above (again, aside from 4) actually work the way it appears you think it does.29
The upcoming 2.62 will wipe 2.52, but if you want easy OTA in the future, reflashing stock /system is advised (and the only 'supported' upgrade path)
You think wrong.
Don't project your own preferred way of working on a few dozen million users, you will come up short.
2.62 will have a possible work-around for your problem. When it's out (probably some time today), try again, and let me know if the issue was fixed.
The "Full Unroot" option in SuperSU settings will automatically reflash boot. And there's more stuff coming to make OTAs easier. Surprise, not everything can be done in one day. And again, systemless root does not prevent you from modifying system.
Actually it should have removed the old ones automatically. I changed the script from uncompressed backups to compressed backups at some point and forgot to fix up the cleanup part as well. This will be fixed in 2.62. You can figure out which one is the current correct backup by looking at the end of /init.rc, or when 2.62 is out, flash back stock boot image before applying the new ZIP, and the old ones will be removed automatically.
Exactly this.
Root Explorer, like many other apps, will need to be updated.
It's weird how everyone expects everything to just work perfectly out of the box every major Android update even though they change half the system around.14
