yashsingh1/xdaforums huggingface dataset:
[SuperSU] Alxoom33:
I don't understand! I don't catch any of these issues. My Systemless root 2.66 works perfectly. Android Pay works as well. I feel so left out! Thanks [MENTION=2242032]chaifire_eu[/MENTION]. ;)
[SuperSU] Pig Vomit:
Stock Nexus 6P, systemless 2.66, MMB29P. I deleted xbin folder.

Android Pay worked just fine yesterday. Tonight I tried to use it.....and I got the "can't verify" OS and "Android Pay won't work" error. Nothing has changed since I last used it. Didn't try a reboot and haven't tried again.

Anyone else have this problem?
[SuperSU] double RL:
I've never encountered a problem with with using root explorer, but today I installed a new 6.0.1 rom and supersu 2.66 on my opo and any root file explorer app I tried would force close immediately. I flashed your busybox and everything is tip top now. Thanks.
[SuperSU] Alxoom33:
No! And if you deleted the right folder, you wouldn't either! It's the xbin_bind folder! LMFAO! Try again! [emoji2]
[SuperSU] Pig Vomit:
Did this.

I can run SafetyNet Playground shortly after boot, and it passes the SafetyNet checks just fine.

Run SafetyNet Playground a few minutes later....fail.

Tested some more......sometimes it passes, sometimes it fails. I just ran it before opening Android Pay, and it passed. Opened AP, then it failed.

No rhyme or reason. How reliable is SafetyNet Playground?

No opportunity to actually pay for something using AP yet. I'm on AP version 1.2.111627672.
[SuperSU] bdorr1105:
I want to do this on the LG v10 that is running Lollipop 5.1.1, I see a lot of these questions getting avoided. If it is possible what would my steps be?

1. Open SuperSU

2. Unroot

3. Fast boot flash stock system.img and stock boot.img

4. Flash latest SuperSU in TWRP

5. Reboot and it might work ?

Long story short, your ROM can or can't be custom if you have to flash a stock.img, that is the part I do not understand....

I built a ROM with v2.66 part of the install and Android Pay does not work
[SuperSU] Manuel15:
If it's installed in system move it will modify the system. In systemless mode it will modify the boot.
[SuperSU] Pig Vomit:
So today SafetyNet Playground was consistently indicating I passed the check. This evening I used Android Pay....and it worked for me.

So.....this worked:

I would reflash BOTH stock "system" and "boot" from fastboot.

Before you flash 2.66 do this in adb Shell via TWRP:

echo BINDSYSTEMXBIN=false>>/data/.supersu
[SuperSU] bdorr1105:
So I tried this to no avail, I did a complete full unroot, flashed the unsu zip, rebooted and no more root. I wiped Google play services, Google services framework and Android Pay, I went to add a card and boom, I had success.

So I went and reboot, selected the current folder which was / and entered the commands. Then I flashed the latest 2.66 su zip, and it still installed to system...

Guess the LG v10 is not capable of a Systemless Root at this time
[SuperSU] Captain_Throwback:
Systemless root is for Android 6.0+. Are you running Marshmallow on your device? If not, that's why you don't have systemless root.
[SuperSU] bdorr1105:
I had actually seen some TouchWiz 5.1.1 and 5.1.1 devices it worked with. I asked the question in the thread because of this, but ok I guess I am stuck like chuck until marshmallow
[SuperSU] Captain_Throwback:
Does your LG device use Samsung TouchWiz? In that case, it's not relevant to you. You are correct, though - Samsung 5.1.x devices also use/require systemless root.
[SuperSU] bdorr1105:
I said TouchWiz and 5.1.1 (meaning other than TouchWiz) so I tried with the LG v10 to see if it fit the some 5.1.1 devices. Seems it doesn't
[SuperSU] backslashV:
safetynet passes 40% of the time on my nexus 6p! what's happenin?
[SuperSU] Smurph82:
Yeah have noticed that safetynet has become very inconsistent in the last few days. With systemless root the safetynet result change constantly. But without it systemless root everything passes like you would expect
[SuperSU] FletchF:
Hmm, since upgrading both my N5 and N72013 to 2.67 (and deleting xbin_bind), both devices consistently PASS the SafetNet check according to SafetyNet Playground and both consistently fail the test according to Root Checker Pro. I haven't had a chance to actually try AP yet.
[SuperSU] backslashV:
I reflashed everything and realized that once the phone connects to WiFi, CTS profile match starts to be inconsistent. Here I shot a video:

https://youtu.be/tH9FzWJobuQ
[SuperSU] Darke5tShad0w:
Quote from http://xdaforums.com/showpost.php?p=64433511&postcount=3969
[SuperSU] en11gma:
vzw note 3 sm-n900v on jasmine v6.1 OF1

i have supersu 2.49 i believe.

safetynet does not pass

can i upgradw to a higher version supersu to get it to pass?

1 more thing

i edited my hosts file basically it is this now

127.0.0.1 localhost

::1 localhost

does this also make it fail?

i dont think i have a backup
[SuperSU] Alxoom33:
You should upgrade to Systemless Root and delete the su/xbin_bind file. Use su v. 2.67. Android Pay working without a hitch.

---------- Post added at 10:41 PM ---------- Previous post was at 10:40 PM ----------

Have no idea about the host file. Why did you do that?
[SuperSU] NYLimited:
The ::1 lines are to handle ipv6 which may or may not be needed depending on the connection to the carrier. All new devices on t-mobile, for example, connect on ipv6 by default.
[SuperSU] DROITURK182:
Working great with su v. 2.67, and systemless root, but had to uninstall xposed. Very sad :(
[SuperSU] JimSmith94:
Now if someone can figure out how to get Android Pay working with Xposed, we'll be golden!
[SuperSU] en11gma:
you are thinking this will work for my setup

could you tell me the location of that bind file?

what settings in supersu do i tell it to do?
[SuperSU] garyd9:
I realize that you're using a different device (and even a different version of android)... However, on the samsung note 5 ('i' variant), safetynet is very happy with stock (5.1.1) firmware and systemless root. This is 12 hours after the most recent reboot after cycling through 4 different wifi SSID's, etc.

(The point of the reply is to help isolate the fault.)
[SuperSU] shag_on_e:
What I'm trying to figure out is why some custom ROMs pass the compatibility test suite. I know systemless root with stock ROM on angler 6.0.1 works fine with Android Pay, but I'm curious how custom ROMs pass the tests. The reason is, I was hoping to sneak an app into /system/priv-app and keep Pay working. Maybe adding the necessary files to the ROM zip before flashing or something similar would work, while using the latest systemless root? In short, if a custom AOSP ROM with systemless root is able to slide by the test suite, we should be able to push it a bit further.
[SuperSU] Captain_Throwback:
If you push an APK with a signature that doesn't match the other signatures in the ROM, it will likely cause the SafetyNet check to fail.
[SuperSU] spainter:
Both my N6 and N7 have been upgraded to 2.67 on stock MM 6.0.1 latest build. Renaming the xbin_bind and running Root Checker Pro, I have not had a fail once on the test. Su 2.6.7 works extremely well.
[SuperSU] shag_on_e:
Wow I just found an Xposed module that disables SafetyNet compatibility checks! About to test
[SuperSU] DROITURK182:
Yes let us know if you can get Android pay to work with xposed, with that module you mentioned.
[SuperSU] JRJ442:
[MENTION=4243910]shag_on_e[/MENTION] It's incredibly rude to come in a thread and say something like that without any links or a module name. Shameful.
[SuperSU] Alxoom33:
Yes,it should. The file location is # Root/su/xbin_bind. Delete or disable the xbin_bind folder and reeboot.

The ones that pass have a pristine, unmodified System Partition. The failures are probably the ones in which the System Partition has inadvertently been modified so it fails the Safty Net check. I don't think your idea will work. To pass, you need to modify outside the System Partition, as [MENTION=631273]Chainfire[/MENTION] has done with Systemless Root.
[SuperSU] garyd9:
It's a dead end anyway. I suspect the module he's referring to is here: http://repo.xposed.info/module/com.pyler.nodevicecheck

It doesn't work. Just having xposed installed causes the safetynet integrity checks to fail before any of the checks handled by this module are done.
[SuperSU] shag_on_e:
I apologize, I didn't want to look too much like an idiot sharing something that didn't work. So I figuring I'd test dummy first. It is in fact no good. At least right now it doesn't work.
[SuperSU] JRJ442:
Lol. I was only kidding anyway man. No need to apologize.
[SuperSU] clevebb:
I have wiped /system and /data, then installed cm13 nightly (bacon) and gapps. Android Pay still doesn't work. I am not rooted, but su is a part of the rom. Could that be the issue with all CM editions?
[SuperSU] nathanchance:
Most likely. AP doesn't just check for the presence of root, it does other system compatibility checks, which CM is certain to fail. Some AOSP ROMs have it working but even then they are still pretty finicky.
[SuperSU] RandomPooka:
Hell, I hear it's even finicky with a lot of stock ROMs just using systemless root. That it works at all with some custom ROMs is rather impressive
[SuperSU] GatorsUF:
Can't get AP working on my 6p running PureNexus ROM and SU 2.67.

Any idea on how to fix this issue?
[SuperSU] luigidk:
I've been running on SuperSu 2.66+ since 2.66 came out - but today - I'm noticing that I can't get AP to work with SuperSU...

I understand this is a systemless root/AP issue - and I've posted a more detailed thread here: http://xdaforums.com/showpost.php?p=65046518&postcount=100

Basically, I've been running on my N6P: CataROM, CustomKernel (or not, no diff), SUPERSU 2.66+, and all the appropriate busybox installers, systemless hosts, etc... and never had a problem - but now I can't get systemless root and AP to work (safetynet keeps failing) - I've been able to determine that safetynet fails after I flash SUPERSU 2.66+

Anyone else had this problem?
[SuperSU] r80ies:
I am experiencing the same exact thing. I am trying SUPERSU 2.67, but prevoiusly 2.66 was working ok just started out of nowhere it seems.
[SuperSU] luigidk:
Clarification - Up until the last day or two - I've been running with SuperSU 2.66+ with AP and no issues. Today I just happened to check with SafetyNet - and saw it failed, surprisingly so as it has always passed before. What may have changed is I switched back and forth between kernels (Cata Stock and God's Kernel), my guess is somewhere in that flashing I mucked something up. Note that I'm very careful to flash:

- Full ROM

- Custom Kernel (or not)

- SuperSU 2.66+ (note that my data/.supersu file has the correct entries, this has been in place and has always worked)

What I've been able to determine - is once I flash SU 2.67 OR 2.66 - safetynet is failing, nothing else is causing safetynet to fail. my data/ .supersu file is correct - there is no xbin_bind directory.

Examples:

flash the full CATA ROM, nothing else - safetynet passes

flash the full CATA ROM, Custom Kernel - safetynet passes

flash full CATA ROM, Custom Kernel - SuperSU 2.66+ - safetynet fails

flash full CATA ROM, SuperSU 2.66+ - safetynet fails

SuperSU 2.66+ is the common denominator - makes no sense to me.
[SuperSU] garyd9:
FYI - it appears that safetynet has been updated so that it detects "systemless" root.

If you disable root, safetynet checks will pass again (but it appears that supersu 2.67 has issues re-enabling it...)
[SuperSU] Captain_Throwback:
Welp, there ya go. It was bound to happen eventually. That might explain why all my Google accounts disappeared earlier today . . .
[SuperSU] luigidk:
NUTS... this was my concern - I'd flashed these things so often that I was pretty confident in my procedures.

BUMMER
[SuperSU] r80ies:
Great, now I have to carry my credit cards again.
[SuperSU] garyd9:
Why? If you want to use android pay, just disable supersu.
[SuperSU] backslashV:
Lol. That doesn't work 99% of the time.
[SuperSU] rebretz000:
Well that kind of sucks. Android Pay was a convenience but not mandatory for me.

At least I can start using other ROMs now.
[SuperSU] adrman:
I also just started experiencing AP issues today, stock with systemless 2.66. I guess it was only a matter of time until Google caught up.
[SuperSU] ConTejas2:
This just happened to me today. Stock (w/EX) N6, v2.66, MMB29S. After deleting /su/xbin_bind Android Pay was working fine. New vending machines that accept AP at work so I've been using it more than usual (caf always worked back to GW days). Went to use it today at the vending machine and got the "can't verify OS." I even clean flashed, stock kernel, no busybox pro, and I can't add the cards (still had them when I first got the error, of course). I'm hoping as I read forward I find a solution but wanted to post that I have the same issue.
[SuperSU] r80ies:
I read your post and I will do that. I also like your post about an "on-demand supersu". I think its a brilliant idea and I hope it can be a reality.
[SuperSU] ConTejas2:
Rabble rabble rabble!!! Wonder if all this bs with AP over GW is paying off for Google. Sure as hell isn't for me lol.
[SuperSU] Alxoom33:
I can confirm that AP now detects Systemless Root on my Nexus 6, even with the su/xbin_bind file disabled. Minor inconvenience, just temporarily disable Super Su in the app and AP works fine. Then enable SuperSu after your transaction, update binary and reeboot. Easy, peasy at least for now.
[SuperSU] nathanchance:
Unchecking "Enable Superuser"?
[SuperSU] garyd9:
I REALLY can't understand the thought process of google here... why are they specifically looking for "/su/bin/su" or "/system/bin/su", etc?

This is google's security team, and I have a hard time believing they are as clueless as.. say.. Samsung. We KNOW that google employees read this forum. I couldn't even begin to believe that people on the Google team who create the CTS tests haven't installed supersu on some of their devices and played with it.

So, they HAVE to know that supersu has a simple option to disable superuser and re-enable it. That means that they intentionally blocked one aspect of supersu's systemless root while leaving a known hole the size of Google's annual revenue. That just does NOT make sense. The change they made is as useless as using a piece of scotch tape to secure a bank vault.

Why?

Why not check to see if eu.chainfire.supersu is installed? Sure, Chainfire could simply change the name of the program, but that would at least be a more effective plug to the security hole than what they've done. (At the very least, it would block all existing supersu installations, instead of the useless change they made here.) They could have detected one of the various other "su" related files that supersu installs (instead of just the simple "su" file that Chainfire ALREADY has a workaround for.) There are literally dozens of things they could have done to block root more effectively... why didn't they?

I can only come up with two possible answers: First, they contracted out the work to Samsung. Second, they are PURPOSELY allowing root as long as it isn't obtainable with the "su" command directly.

The first possibility doesn't really need any explanation. While it's sarcasm, it's only partially so. (I can't believe some of the crap samsung leaves unfixed on their devices.)

The second possibility is more interesting... but also doesn't make sense either. (If you disagree that it doesn't make sense, think about it before reply. At least 2 vectors off the top of my head: A rooted daemon could already be running in memory, and just because "/su/bin/su" is missing doesn't mean that it's not easily put back.)

So... what is going on?
[SuperSU] luigidk:
That doesn't work for me. I disabled superuser but safetynet still fails
[SuperSU] Darke5tShad0w:
delete
[SuperSU] garyd9:
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.
[SuperSU] Alxoom33:
Yes, that's the ticket!#
[SuperSU] :
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.
[SuperSU] Alxoom33:
Don't agree. I'm on 2.67 on the Nexus 6, and temporarily disabling Su# allows AP to pass.

---------- 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!
[SuperSU] luigidk:
Unfortunately for me disabling supersu in the app does not allow safetynet to pass.
[SuperSU] Cares:
Can confirm. Going into SuperSU and unchecking it will let me pass SafetyNet. Did not test AP yet though.
[SuperSU] AndrewM3:
when I go into supersu the check mark for enable superuser is grayed out and says not currently available in systemless root mode
[SuperSU] shoey63:
No need to update the binary and reboot. Open the app, ignore the nags and re-enable in settings.

Done.
[SuperSU] rebretz000:
Really? Thanks for the info. Will give that a try.
[SuperSU] Pig Vomit:
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.
[SuperSU] bunklung:
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.
[SuperSU] Chainfire:
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.
[SuperSU] DROITURK182:
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. :(
[SuperSU] FletchF:
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.
[SuperSU] bobby janow:
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.
[SuperSU] Alxoom33:
OK, but what is your point Bobby?
[SuperSU] NuShrike:
It also looks for su.img so you have to rename/delete that.
[SuperSU] bobby janow:
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:
[SuperSU] Chainfire:
What makes you say that ?

And are you talking about AndroidPay here or SafetyNet ?

The latter works fine for me without removing /data/su.img ?
[SuperSU] NuShrike:
Android Pay, maybe both?

AP wouldn't "validate" me to add a card even after I disabled SuperSU, uninstalled the app, deleted all the binaries with su, flashed OEM recovery, reflashed OEM /system, OEM /boot.

Then I went into /data and deleted su.img and AP then it let me add a card. This was at least an Android Pay revision back.

But we're not talking about circumventing it -- just another thing they look for. I've chosen to circumvent AP by no longer using something that makes me, the customer, the 'criminal'.
[SuperSU] Chainfire:
If anybody else can confirm this, I'd be interested.

Again, my goal is not to beat SafetyNet or AndroidPay, I'm just curious about how it works.
[SuperSU] :
I did not have to delete anything manually. I disabled using the check box in the app then was able to add cards. However.... I am unable to re-enable using the app and had to reflash 2.67

If we can manually disable/enable using the checkbox to use AP then that is acceptable to me but it seems like everyone is getting different results.

P.s. stock 6.0.1 and rooted with 2.67 no kernel or build prop mods etc...
[SuperSU] bobby janow:
Same here with stock and Cataclysm overlay on the 5x. Custom kernel but happened on 2 different ones. Reflash of 2.67 brought everything back to normal.
[SuperSU] Chainfire:
Regarding en/disabling root through SuperSU's settings and that not working, please report that bug to the beta thread with any and all information that may be related. It works fine for me on my test-devices.
[SuperSU] sansnil:
Way to bite the hand that feeds.
[SuperSU] bobby janow:
Oh come on, get a sense of humor. No one is biting anything. If you can't have a little fun what's the point?
[SuperSU] garyd9:
Are you certain?

On my Note 5 (lollipop), I just removed supersu, put back the stock boot image, reinstalled TWRP and SuperSU (systemless mode with no xbin binding.) After the initial bootup, I dropping to a terminal shell and manually deleted /su/bin/su. At that point, safetynet passes.

You know... [MENTION=631273]Chainfire[/MENTION], is it possible to use SEAndroid to block safetynet (via google play services, I think) from accessing the /su directory whatsoever?
[SuperSU] Alxoom33:
Just bought tea at McDonalds with AP! [emoji2] [MENTION=631273]Chainfire[/MENTION] is completely correct! Need to just disable SU in the app and reeboot! [emoji106] If you don't reeboot it doesn't work. No need to delete any .img files. Buy tea *****es![emoji2]

I'm on a Nexus 6 running Systemless Root 2.67

---------- Post added at 05:49 PM ---------- Previous post was at 05:47 PM ----------

Works just fine!

---------- Post added at 05:51 PM ---------- Previous post was at 05:49 PM ----------

Easy peasy! [emoji2]
[SuperSU] DROITURK182:
[MENTION=631273]Chainfire[/MENTION] what is the solution? Do I need to reboot after disabling su in app. And can you provide a link to the thread your talking about, can't really search right now for it at work. Thanks
[SuperSU] Alxoom33:
Look at my post above. Hehe!
[SuperSU] elreydenj:
That is good to know, however if you have to reboot then many of the small tweaks that people use in kernels and with scripts will not apply upon reboot. Best case scenario would be for a way where you can boot up with root and then disable somehow and still have Android Pay work without having to do a reboot.
[SuperSU] Alxoom33:
That's also easy to solve. They can use their credit cards fo now;)