SuperSU and SafetyNet / Android Pay

Search This thread

Chainfire

Moderator Emeritus / Senior Recognized Developer
Oct 2, 2007
11,452
87,856
www.chainfire.eu
This 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.
 
Last edited:

mdamaged

Senior Member
Oct 16, 2013
2,109
1,448
South of Heaven
Moto G5 Plus
Google Pixel 4a
Hey, thanks for your continued support for root on Android, was just wondering, is google making it harder to achieve decent root privileges, as in they don't want rooted devices or are they just unrelatedly changing up things which forces you guys to adapt?

On another note, is there any progress on root without the modded boot? This is by no means an ETA, just wanted to know if you think it's possible or the situation looks rather dire.

Thanks again for your many efforts!

Well, just look at Android Pay, it will not allow one to add a credit card if it detects the device is rooted. So yeah, Google definitely wants to stop root, or at least make sure there is a strong dissuasion towards same. It's not a bad thing persae, as Google is just making the devices more secure for the masses. We 'power users' are lucky to have those such as Chainfire working so hard to get us what they can.
 

androcraze

Senior Member
Jan 11, 2013
2,254
1,661
Well, just look at Android Pay, it will not allow one to add a credit card if it detects the device is rooted. So yeah, Google definitely wants to stop root, or at least make sure there is a strong dissuasion towards same. It's not a bad thing persae, as Google is just making the devices more secure for the masses. We 'power users' are lucky to have those such as Chainfire working so hard to get us what they can.

Many banking and financial apps restrict access on rooted devices; it's not just Google.

It makes sense in some ways: root access allows running things in the background to either circumvent, monitor, or interrupt program transactions. They're being paranoid, and I don't blame them.

I don't like the Google Pay concept (or Apple's either); like every other encryption or security system, it's destined to eventually be hacked.
 

jesssiii

Senior Member
Aug 19, 2010
4,942
1,656
Southern CA
Well, just look at Android Pay, it will not allow one to add a credit card if it detects the device is rooted. So yeah, Google definitely wants to stop root, or at least make sure there is a strong dissuasion towards same. It's not a bad thing persae, as Google is just making the devices more secure for the masses. We 'power users' are lucky to have those such as Chainfire working so hard to get us what they can.
Yep, I was able to add my debit card but not credit.

VZW LG G4
 

drawde40599

Senior Member
Aug 11, 2010
5,322
1,967
Well, just look at Android Pay, it will not allow one to add a credit card if it detects the device is rooted. So yeah, Google definitely wants to stop root, or at least make sure there is a strong dissuasion towards same. It's not a bad thing persae, as Google is just making the devices more secure for the masses. We 'power users' are lucky to have those such as Chainfire working so hard to get us what they can.
http://www.androidpolice.com/2015/0...hy-android-pay-doesnt-support-rooted-devices/
 

Srandista

Senior Member
Sep 19, 2010
273
128
Brno
Yet the Note 5 has been rooted for at least a couple of weeks
On Lollipop... And you also have to unlock your bootloader to do that, right? If yes, then you will trip the KNOX, and that mean you will loose some of your device functionality (Samsung Pay for example), without option to take it back. On the Nexus on the other hand, when you want to use Android Pay on Nexus, you can restore your phone to completely stock condition, without any trace of previously used root.

Also, all of this is completely irrelevant to carried device users, since they have a locked bootloaders.
 

shaggyskunk

Recognized Contributor
Nov 22, 2011
19,731
16,043
IDK
On Lollipop... And you also have to unlock your bootloader to do that, right? If yes, then you will trip the KNOX, and that mean you will loose some of your device functionality (Samsung Pay for example), without option to take it back. On the Nexus on the other hand, when you want to use Android Pay on Nexus, you can restore your phone to completely stock condition, without any trace of previously used root.

Also, all of this is completely irrelevant to carried device users, since they have a locked bootloaders.
I believe that it's only at&t and Verizon that locks the bootloader - And none in Canada and many other Countries.

Sent From my SM-N910W8 Running SlimRemix V5.1
 

NYZack

Senior Member
Mar 7, 2011
346
125
New York
Had an interesting event, on 2.52.

I unchecked "Enable Superuser" in Settings, to attempt to use Android Pay (Android Pay still wouldn't work). Then, when I rechecked "Enable Superuser", the re-installation of the binary failed, and I was prompted to reboot to try again. However, then I got a boot loop (never even got the opportunity to enter my encryption code). The only way I was able to boot was to re-flash the modified boot.img and re-install SuperSU from the zip (no idea whether both steps were necessary).

I have a Marshmallow Nexus 6, encrypted. For what it's worth, I was previously rooted on 5.1.1, and, after updating to 6.0 and until I re-rooted, I always got a "Your device is corrupt" message on startup, despite being all stock.
 
Last edited:
  • Like
Reactions: C5Longhorn
Had an interesting event, on 2.52.

I unchecked "Enable Superuser" in Settings, to attempt to use Android Pay (Android Pay still wouldn't work). Then, when I rechecked "Enable Superuser", the re-installation of the binary failed, and I was prompted to reboot to try again. However, then I got a boot loop (never even got the opportunity to enter my encryption code). The only way I was able to boot was to re-flash the modified boot.img and re-install SuperSU from the zip (no idea whether both steps were necessary).

I have a Marshmallow Nexus 6, encrypted. For what it's worth, I was previously rooted on 5.1.1, and, after updating to 6.0 and until I re-rooted, I always got a "Your device is corrupt" message on startup, despite being all stock.

Root doesn't have to be enabled for pay to fail. Any time the system partition is modified pay will not work. There was an xda news article on it. A quick Google search involving Android pay and root should find it.
 

Taomyn

Senior Member
Root doesn't have to be enabled for pay to fail. Any time the system partition is modified pay will not work. There was an xda news article on it. A quick Google search involving Android pay and root should find it.
I also found that having an unlocked bootloader will stop Pay working. When MM released I decided to go fully back to stock but kept the bootloader unlocked so I could flash MM. Pay still failed, so I've given up and gone rooted again.

Sent from my Nexus 6 using Tapatalk
 

dabotsonline

Senior Member
Dec 17, 2009
227
79
@Chainfire if you actually are able to pull off fully working stable root WITHOUT modifying the /system does that mean you MIGHT have opened the door into having root AND still being able to get OTA's?

Yup, all you'd need to do is reflash stock kernel to pass the boot partition EMMC check, or, we could automate restoring the previous stock kernel, flashing the OTA and then injecting the new stock kernel with root after flashing (à la AnyKernel2 or MultiROM). So many exciting possibilities there where custom recoveries are concerned. :)

Honestly it's not so different from using FlashFire to flash re-flash system, then OTA, then re-root. But it is easier, yes.

This is indeed exciting. However, I noticed that @Chainfire posted this downside on Google+ :

Andrew Morykin 12:24
This should retain Android Pay, right?

Chainfire 12:58
+Andrew Morykin if it does, then it's by accident and not by design, and Android Pay will be updated to block it.

https://plus.google.com/+Chainfire/posts/aJbqUZ8PEP4

also, I was confused by this:

Chainfire said:
- I have not tested with encrypted devices

http://xdaforums.com/showpost.php?p=63197935

Aren't

Nexus 6P / angler

angler-mdb08k-boot-systemless.zip

and

Nexus 5X / bullhead

bullhead-mdb08i-boot-systemless.zip

encrypted out of the box?
 

Chainfire

Moderator Emeritus / Senior Recognized Developer
Oct 2, 2007
11,452
87,856
www.chainfire.eu
This is indeed exciting. However, I noticed that @Chainfire posted this downside on Google+ :

How is that a downside?

It's exactly the same with every other form of root you will ever see. They don't want to support Android Pay (and some other stuff) on rooted devices. If we find a root that allows it, they will update their system to detect and block it. That cat and mouse game will not end as long as Google doesn't want Android Pay on rooted devices.

Maybe someone will make apps/modules that help circumvent this, but it certainly will not be me.

also, I was confused by this:

Aren't

Nexus 6P / angler

and

Nexus 5X / bullhead

encrypted out of the box?

Still can't test what I don't have.
 

phishfi

Senior Member
Jul 7, 2009
674
119
San Antonio, TX
I'm not sure if anyone has specifically mentioned this, but Android Pay still works with this form of root on the Nexus 6!!
 
Last edited:

osm0sis

Senior Recognized Developer / Contributor
Mar 14, 2012
16,696
40,164
Halifax
GT-i9250
Google Nexus 4
Starting with Android 5.0, OTA updates are now block-based rather than file-based, so any modification to the system partition will cause the OTA to fail, even mounting the system partition as r/w.

Just to add to this, it's a whole-partition /system patch OTA if the device launched with Lollipop or later, anything that launched with KitKat is still receiving the old file-based patch OTAs. Modifying Settings.apk would likely trip either method for a lot of OTAs though, since it's a pretty central component.

I use Galaxy s6 G9200 HK with Kernel compiled by me, but i have problem with root 5.1.1 and i think in future too 6.0
These root method is integrated in kernel source or i can integrate with those "boot.img systemless" my selfcompiled kernel?(repack boot.img with kernel compiled by me)
Is possible to work this new root method to android 5.1.1?
I have problem with gain root when i use kernel compiled by me ( STOCK kernel have too this problem BOOTLOOPs and FREEZEs on boot system) and i don't know how slove it :/

I found on chineese forums root integrated in boot.img it working good and isn't comunicat "KERNEL is not SEandroid enforced" but when i try integrate my kernel with this boot.img error with boot system :/

Yup, it's all ramdisk changes so should be workable on any version of Android. Chainfire left instructions outlining the ramdisk changes in the WIP thread if you want to give it a try.

I'm not sure if anyone has specifically mentioned this, but Android Pay still works with this form of on the Nexus 6!!

Yup, seems to be the case with most banking and root-detecting apps... for now. ;)
 

JsChiSurf

Inactive Recognized Developer
Feb 5, 2010
2,416
1,396
Hacksville

Attachments

  • 1446295884950.jpg
    1446295884950.jpg
    47.2 KB · Views: 1,957

Kirot

Senior Member
Nov 29, 2011
136
34
Alajuela
Went ahead and installed su on a stock nexus 5, so far working well, android pay does not work but that was me being stupid and changing the host file and dpi before setting it up
I do notice a little input lag after this, not enough to even make me consider removing root, but it is noticeable, anybody else with this?
 

Top Liked Posts

  • There are no posts matching your filters.
  • 54
    This 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
    One fast question: Up there you said that you were not recommending systemless v2.61 "yet" over v2.52, but that you "would soon". For Android 6.0.1 and maybe next releases, the system option will be completely dumpled out, or both options will be eligible? And for now, can we keep with 2.52 forward until new advice or its not recommended anymore? I am one of those that end up doing a lot more modifications to /system so systemless root doesn't seem any better than normal root, and not worth the hassle.

    Thanks for your replies @Chainfire and for your continued work and support. While systemless root is the right longer term move, until we get unionfs/overlayfs I don't think many of us can escape still modifying /system for various reasons. Yes, we can already bind mount by hand various files and directories and manually fix apps that need need to change /system (and even some of them need to be installed as system apps) but this gets annoying quickly at least for Nexus devices that receive the monthly security updates from Google.
    I would appreciate it if you could still have an easy way to have a /system based root. I read your post about touching su in /system, would be possible to provide a flashable zip that does just that? Or a version of SuperSU that has the switch set to install in/system? Just looking for an easy way to be able to take the monthly security updates without going the custom ROM or kernel way. Thank you.

    I completely agree! I change some system sounds and add the no tether check to the build.prop with every update Although systemless root isn't the best option for me. I do think having both as an option would be great, if not too much to hope for.

    +1
    I still use 2.52 while upgrading my 5x to 6.0.1 because I don't need android pay and I want to keep the things simple as possible.

    For updates instead of flash boot&recovery before each OTA I prefer flash boot&system&radio from factory image (that are out sooner on each update).

    So the classic, ever so great method of root has been dethroned then? Just like that? No more system root? Not even a thorough explanation or farewell?

    If systemless is the future, fine. I just won't update atm. Apps that install on the system partition are iffy or they require symbolic link or they just don't work. Too much work if you ask me.

    I understand this is a transition but i would of at least liked system root support until systemless gets good enough.

    With that said, Is there a way to update Nexus 6P to 6.0.1 system root right now?

    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
    If I flashed 2.52 system beta on the Nexus 6p but want to switch to 2.61 systemless, do i have to remove 2.52 system prior or will applying 2.61 systemless handle this? If I do need to remove 2.52, how do I do that?

    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)

    I don't think most people care about being able to receive OTA's. If a new factory image comes out, people usually flash that long before the OTA will hit their device.

    You think wrong.

    Exactly. If you can root you can flash a new build. And what are the chances that OTA updates actually work when you are rooted (systemless) and some app may have modified /system anyway without you realizing? OTA updates are over-rated. Now Android Pay is a different story.

    Don't project your own preferred way of working on a few dozen million users, you will come up short.

    @Chainfire
    Is there anything untoward in this recovery.log which is preventing root on the Tab S2 sm-t710?

    http://pastebin.com/fAufmsZW

    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.

    of course, any modification on /system invalidate Google Pay or OTA, but I think this is irrelevant for most. Ideally we want root and continue to receive and update OTA directly, but even with systemless mode you ca¡n't do it, you have to flash boot anyway.

    On a personal side, I prefer/need access and change my system partition, not only to modify the hosts file, but to delete content, add myself and others.

    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.

    I got everything up and running yesterday on my Nexus 5. All working as expected. I know you backup the stock_boot image file in /data/. I have two backed up stock boot images. I had SuperSU 2.60 first and I have 2.61 currently. Do each of your upgrades create a new stock boot image? and can I delete the old ones?

    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.

    Good catch. It's dynamic and needs to be static to work universally most likely.

    Edit: Hmm it's a recovery command, not an included binary.. so not sure why the linking error. @Chainfire might need to do some of his LD_LIBARY_PATH magic to fix it up or there's something wrong with the recovery build you're using.

    Exactly this.

    Hi, I just flashed Official MMB29K, in my Nexus 5 and SuperSU 2.61 SystemLess, but I have an issue:
    ES File Explorer doesn't prompt me for root permissions; if I try to enable "Root Explorer" toogle in the left panel, a message says that the Test failed, bla bla bla.
    But other apps have successfully obtained the root permissions.
    What the hell?!

    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.
    12
    After reading the last 10 pages I feel like this is now an android pay thread :(