yashsingh1/xdaforums huggingface dataset:
[SuperSU] bobby janow:
I don't think they had a choice. I believe the banks demanded it. Since there were ways around root, i.e. hiding it even though it was still installed, there was only one way to verify that the device was not rooted. Lock it down via bootloader. That's not saying we can't unlock and root, but Android Pay and hopefully other banking apps will use the SafetyNet checks and therefore fail. I do not believe that Google should allow other programs to use it, but I'm not sure they can restrict it. So if a game, you know which, decides they want to make sure the phone is not rooted, then you have a choice to keep the phone locked or simply not play the game.

I hope everyone realizes that an unlocked bootloader is a major security risk whether or not root is installed. If you don't want to use banking / mobile payment apps then unlock and root. They are not preventing you from doing that by any means. They are only optionally securing their platform so that banks around the world can trust the devices and the software and reduce the amount of fraud the banks have to absorb. It's really that simple, imo.
[SuperSU] mdl054:
Unfortunately I think this is the writing on the wall. Doubtful they will proceed to completely block the Root. You will however start to see more and more apps using the safetynet authentication. Doubtful from what I understand that safetynet can be completely contained or removed while keeping that functionality unless it could be emulated somehow. The top Devs have all said they will not actively try to bypass safetynet going forward.

We will have to choose whether or not we want the root or we want the apps. For certain apps there may or may not be equivalents or replacements but I'm guessing there will always be apps that block you. Party's over.
[SuperSU] johnhazelwood:
I just successfully used Android Pay on bootloader unlocked device running the beta. Just thought I'd share.

Edit: Post successful payment, tried safety net: fail, and tried adding a card: fail

Argh!
[SuperSU] gchat:
Yeah right... A company which finds a million ways to avoid taxes can't tell the banks "screw you". Even Apple does have a much more developer-friendly environment right now.

Ah well, a pity that Google has become Apple's little ugly sister who tries always to look like her older sibling but fails miserably...
[SuperSU] bobby janow:
That just sounds silly.
[SuperSU] gchat:
Says the one who posted "Google tries, together with the banks to secure your device by locking it down so that you won't get malware..."

You know, this kind of Malware which installs itself by rebooting into fastboot, flashing twrp recovery, flashing root and installing AdAway...
[SuperSU] photolarry:
Okay this is just REEEE Tarded and I think they are full of crap when they claim it is so they do not get fraud. If I am smart enough to root my phone and even install magisk for example, I should be able to get AP to work. But they now have alienated almost all of the power users now. And do not tell me they do care, because they do not. I was lied to by google employee when AP first was introduced. "Oh dont worry eventually you can root your phone no problem". #FukGoogle Android Pay No Longer Works if Bootloader is Unlocked
[SuperSU] bouchigo:
It does work, check out the posts from #3889 to 3893.

Here's the link to the posts: http://xdaforums.com/apps/supersu/suhide-t3450396/page389
[SuperSU] Citizen_Snips:
Google does love their staged roll-outs. At first it was thought that only newer devices that have secure boot would fail with unlocked bootloaders. Now there's reports from other people on older phones. For example on my Nexus 5 (no secure boot) a factory image with no SuperSU, but unlocked bootloader fails. AP transactions denied in store (tested). Locking the bootloader again and I can pass and AP works. It does appear that more people with unlocked BLs are failing now even on older phones. The reports I'm seeing are newer than those posts as well, yeah. Seems Google went nuclear on this.
[SuperSU] bouchigo:
Mine was failing too (I was already part of/received the roll out) until I compiled a new modified boot.img from source. It removes the verified boot state flag, it's a fix someone linked in the suhide thread.
[SuperSU] Govar Jabar:
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.
[SuperSU] Citizen_Snips:
Interesting. Are you stock, besides the unlocked bootloader / custom built boot.img? Are you avoiding detection with or without root?

Either way I might just have to fire up my virtual machine! Thanks for sharing.
[SuperSU] bouchigo:
My bad, I forgot to post the link to the posts I was talking about, no wonder you were confused...lol

I edited my previous post, but yeah stock beta Nougat 7.1.1 and rooted.
[SuperSU] photolarry:
I have Nexus 6 with Nougat

And I saw no workaround but am tired and been reading a lot. Please advise. I did read the stuff in the suhide thread but did not get any clue of how the safetynet passes with unlocked bootloader (I would think something at boot time must have to trick it no?)
[SuperSU] poulopoulosa:
I have been using latest magisk and I am using the "hide magisk" settings and safetynet passes from my side; OnePlus one CM 13. There are mixed reports about safetynet. Do you think Google has certain safetynet policy per device? Or its just they haven't y updated SN on Opo yet?

Don't forget that it is not just Google in the game but also manufacturers
[SuperSU] bobby janow:
You cannot be this clueless. It's impossible. Oh I get it, you're just fooling around and trolling the thread. Good for you.

---------- Post added at 08:15 AM ---------- Previous post was at 08:03 AM ----------

I understand that you got it to work and feel it's a kernel thing. However, with only unlocking the bootloader, nothing kernel related, it fails. Locking it makes it pass. So unless the kernel can trick the device into thinking it's locked then I can't see how this would work. I'm kind of in the Chainfire camp that you'd be nuts to run banking apps on a rooted device or bl unlocked device anyway. If I really wanted to root then I'd forgo AP and my banking app. I don't believe that any other apps will want to use SafetyNet to check the locked state, but I could be wrong on that. I have no idea about Pogo and what they are doing or why.

This is not to say you don't have it working or that your posts are false. I'm just curious how it is you can bypass the bl check.

edit: btw, I'm on an n5x so I'm not sure if this is device related or not. But I've not seen anyone with this device, bl unlocked, that can make SN pass in the US.
[SuperSU] THE_Roen:
The difference is iSheep phones just work and they don't have to think about these things. Ignorance is bliss.
[SuperSU] bouchigo:
You can test your skepticism by flashing a modified boot.img for your N5X, I think I saw somewhere that "the flash" had created one for it.

You can read more about verifying boot at this link: https://source.android.com/security/verifiedboot/verified-boot.html

The fix as explained by Sultanxda:

Userspace parses this and sets the ro.boot.verifiedbootstate prop

according to the value that this flag has. When ro.boot.verifiedbootstate

is not 'green', SafetyNet is tripped and fails the CTS test.

Hide verifiedbootstate from /proc/cmdline in order to fix the failed

SafetyNet CTS check.
[SuperSU] bobby janow:
Very cool. You think they'll close that loop too? I'm trying to live locked ATM but that might change when the pixel arrives.
[SuperSU] bouchigo:
Probably, eventually. They've been working to close all the loop holes so far, so, yeah. But, for now it's working :good:
[SuperSU] bobby janow:
I think if they're really serious then they'll lock the bootloader at some point. Then we start with the bounties. [emoji6]
[SuperSU] vt0r:
Just wanted to let you know the info he's provided is accurate, and this is pretty close to what's actually happening. The value used to populate the RO value for verified boot state in build.prop is provided by /proc/cmdline, and the referenced commit disables output of that particular value.

I was able to confirm it works on a test build of my angler (N6P) kernel earlier today, but I experienced the same dark camera viewfinder issue others have reported on the dev preview, so I'd rather use the stock kernel for now and fail SafetyNet.
[SuperSU] rgraville:
So is this something that can be done in SuperSU or only in the custom Kernel (ElementalX, Franco, etc.)?

http://www.xda-developers.com/sulta...otloader-check-on-latest-cm13-builds-for-op3/
[SuperSU] Captain_Throwback:
Or you can just set the prop to green manually and use whatever kernel you want ;).
[SuperSU] bouchigo:
All you have to do is switch to video camera and then back to camera to fix the black out issue. Until we get source for 7.1.1 more than likely there will be some weird issues here and there.
[SuperSU] vt0r:
Sadly, this only worked for me once, but I did manage to take a few decent pictures of the pumpkins we carved earlier while using my own kernel.

Tried it again with a bright light photo, and all I saw was white, even after switching to video and back. Then tried the same normal light area again, and it didn't work. Maybe I'll flash my custom build again tomorrow and try some more settings, but I think I can live temporarily with stock. Passing SafetyNet as of right now with xsetprop, so at least one desire is fulfilled.
[SuperSU] bouchigo:
That's too bad, I just tried 4 times and it worked fine every time. I'm on stock 7.1.1 beta though.
[SuperSU] petrs1:
Is a working tool for detecting functionality PoGo? Because SafetyNet Playground or SafetyNet Helper those tools isn't. My SafetyNet Helper red and SafetyNet Playground failed but PoGo working.
[SuperSU] Captain_Throwback:
Seems like opening PoGo would be the easiest...why do you need another tool?
[SuperSU] JW09I4:
I wasn't able to find any references via thread search, so here goes:

Android Pay is not simply a payment app, it essentially acts as a bank in how it processes payments on the backend. There have been a couple of write ups by individuals in the banking sector explaining in depth why Android Pay is different than any other banking app and what occurs on the backend (it's worth the google search for all to understand why Android Pay will never work on a rooted device or a device running a custom ROM, nor should it ever be allowed to do so).

Brief Synopsis of Write Ups

When anyone makes a purchase online, the request for the ACH hold is forwarded to the financial institution's secure payment servers; this request is authorized with a token, and the token is sent back to the merchant's website authorizing payment for goods being purchased.

On Android Pay, the device itself creates the authorization token - the ACH hold request is not sent to a financial institution's secure payment servers for the authorization token; instead, the authorization request is sent to a secure part of the device's hardware, that hardware generates the authorization token, then forwards that authorization back to the app, which then forwards it onto the merchant.

Allowing a rooted, bootloader unlocked, or modded ROMs the capability to run Android Pay would allow a malicious attack to intercept the authorization payment token prior to it reaching the merchant, thereby allowing a purchase to be completed successfully without the merchant ever receiving payment for the goods purchased. This would result in a global financial crisis if done on a large enough scale, severely damaging the trust in digital [online] payments (which is how most commerce occurs in the world today), and would have disastrous consequences not just for merchants, but sovereign nations and the world banks that lend to them.​

Will exploits be found in Android Pay at some point to allow it to be utilized on a rooted device, absolutely... but no one will pass up a significant payday from the app devs, and the financial institutions they in turn protect, to freely offer such an exploit to the public. This isn't some trivial roadblock to make the lives of users inconvenient... this is in place to literally protect the entire world's economy.
[SuperSU] tallgrasshawk:
Thanks for the write up. How does Android Pay differ from Apple Pay in how the transaction is processed?
[SuperSU] photolarry:
Ask Apple....we don't care! They use bsd shell and java too so it's probably a similar implementation of safety api. If you want this level of understanding, study the api. This isn't place to get those answers.
[SuperSU] tallgrasshawk:
On my 5x, I'm on Pure Nexus 7.0 (10/10 release), with Flash kernel patched to disable the boot verify check, SuperSU 2.78, suhide .55, root switch app (latest). Can pass safetynet checks. All greens. Can add a card to Android Pay, but can't actually make a purchase. Still blocked.

Didn't read the pop-up when I tried as there were several people on line and I didn't want to be that guy, so I quickly pulled my card out.

Are they on to looking for something else now?
[SuperSU] westeight:
Probably this:
[SuperSU] tallgrasshawk:
That kinda looks like it.
[SuperSU] CSX321:
Deleted
[SuperSU] JW09I4:
Do you have full usage of AP (i.e. can add new CCs, pay via NFC successfully from start to finish)? It's likely there's more to the security validations safetynet utilizes than just the tamper flag; it seems highly unlikely this would be how the API validates due to the severe real world consequences that would occur should safetynet be able to be "fooled".

If you indeed do have full usage of AP with an unlock code of 3, you should report it to AP devs (to understand why, see post #686). The security validations are not trivial, they are there to literally protect the entire world's economy.
[SuperSU] photolarry:
Dude give me a break. You make it sound like Armageddon and it's trivial. We simply wish to use AP without being told we cannot root and use advanced features that we like. Matter of fact, Google lied to me about eventually allowing root a year ago. World economy.... Please!!
[SuperSU] JW09I4:
You clearly not only know nothing about AP on the backend, your didn't even take the 30 seconds to read the post I referenced.

Since you choose to act like a child, I'll be patronizing and dumb it down as if you were a child... just for you =]

If AP is allowed to function on rooted devices and custom ROMs, it would only be a matter of when, not if, the following would occur on large scale, either by state sponsors or criminal organizations:

A malicious attack would be executed grabbing the device generated payment authorization token after it's been passed to AP, but before being passed to the merchant [at this point, the transaction has been completed successfully on the consumer's end], allowing the funds to be siphoned prior to reaching the merchant. In other words, purchases can be made for free as ACH holds take 3 days to clear; in turn, it would be 3 - 5 days from the original date of purchase before a merchant would realize they not only never received payment for the goods, they have no recourse of obtaining the money for those goods (since the malicious attacker has already claimed those funds with a valid authentication token, the merchant they were intended for has no legal claim to them).

It's clear you have no understanding of even the basics of how economies function... once stock markets were to become aware of billions in losses by merchants around the world who've essentially been giving away their merchandise, or actual cash in the case of gift cards, for free, hundreds of billions would be lost within a matter of minutes, if not hours, happening in waves throughout the day as stock markets open around the world.​

Instead of being ignorant and doing a Donald Trump, perhaps you could do as I recommended and utilize google to read up on the multiple articles that have been written by individuals within the financial sector breaking this down granularly for the average person.
[SuperSU] photolarry:
Try being condescending to one who cares. I don't. As for your pompous attitude, again, calling me childish is rather idiotic. I'm a Hillary supporter by the way. So whatever you say is false. I did read about it. And I simply disagree that it's a huge security hole that's going to be exploited with malicious code in matter of days. Rather than belittle people that disagree, i suggest you try something besides being a pompous azz. Good day.
[SuperSU] JW09I4:
I'm not sure what being a Clinton supporter has to do with the conversation... "doing a Donald Trump" is exactly that, attempting to speak to things one has no knowledge of, all the while pretending they do, quite horribly.

This isn't about an opinion, this is how AP functions. What I've stated in detail in 3 emails now is not my opinion, it is the facts as they are.

AP, for all intents and purposes, operates as a bank's secure payment servers.... I'm not understanding how this is difficult to grasp.

How payments are processed online:

Consumer places order

Request is routed to the consumer's financial institution's secure payment servers

If purchase is approved by the servers:

Authentication Token for the ACH hold is generated, giving the requesting merchant ownership of those funds

Financial institution's secure payment servers send Authorization Token to requesting merchant

Merchant verifies Authorization Token is valid and in the correct amount

Merchant approves the purchase

How payments are processed by AP:

Consumer makes a transaction

If transaction is approved:

Request is sent to a secure portion of the device's hardware

Device's hardware, in lieu of the financial institutions secure payment servers, generates the ACH Authorization Token

Device sends Authorization token to AP, which then completes the transaction

AP then forwards the Authorization Token to the merchant

How it is individuals seem to believe they can choose to agree or not with facts is mind boggling. Facts, like science, don't require one to believe in them; that's faith/religion, not facts and science.
[SuperSU] photolarry:
I'm not disputing facts. That's why you aren't getting it and act pompous. I understand completely how things work. You do not need to reiterate them for me. I'm saying that workaround for many things is needed and my right as owner of this phone to manipulate software as I please. Just like rooting is something which many advanced users do, so is working around limitations of Android pay. And I do not think it's going to destroy the economy by me and others that wish to use Android pay under our terms not those of Google. Furthermore telling me and others we must lock the boot loader and cannot even use custom kernel that might be better for battery life and just as secure is too limiting. I also might add that locking the boot loader forces a wipe of the phone which nobody with advanced changes wants to sacrifice just because AP says it's wrong and not allowed. It's not facts that I'm explaining here.... It's choices. And you claiming that exploited transactions may or could occur isn't happening right now. If it was, then there wouldn't be any workaround and Google would have made certain that firmware was absolutely not altered.
[SuperSU] egingell:
All this is well and good, but the user has to install malicious software AND approve its root request for any of that man-in-the-middle crap to even happen. Not to mention the fact that even root doesn't have direct access to AP's codebase to grab the token from, that would require something like Xposed AND for the user to install a malicious Xposed module.

Sent from: LG G4 MM 6.0 / SGS5 MM 6.0.1
[SuperSU] egingell:
That seems like way more effort than it's worth to me. It seems easier and still very lucrative to just proclaim oneself a prince of Nigeria and send out mass emails.

On the other hand, I know nothing about what criminals do.

Sent from: LG G4 MM 6.0 / SGS5 MM 6.0.1
[SuperSU] JW09I4:
I don't follow, as that reply makes zero sense in regards to what's being spoken to. An Authorization Token is for a specific transactional amount... it's helpful to fully understand what's being spoken about prior to participating in a conversation.

You clearly haven't read what's been written... either way, I've wasted enough of my time this evening explaining things multiple times. The facts are what the facts are... and in two months, this thread will probably have grown several pages by users clearly having little to no knowledge to what they're speaking about. Best of luck =]
[SuperSU] egingell:
I did read it. Every word. You are "clearly" an ass. Whether you're right or not, you're still an ass.

Sent from: LG G4 MM 6.0 / SGS5 MM 6.0.1
[SuperSU] jackmcbarn:
This doesn't match what I've read elsewhere about how Android Pay works. Can you provide a source that confirms this?
[SuperSU] ldeveraux:
Seriously, mods? Shut this junk down!
[SuperSU] poulopoulosa:
One thing is for sure, Google will carry on plugging the holes, securing safetynet. And later people would come up with another weakness in the system to fool Safetynet.

Many/some will eventually give up on finding exploits, but I don't Believe that this race would stop.

This was happening: Apple VS jailbreakers, since the iPhone 2G era. Apple kept plugging weaknesses with new hardware/software updates until people gave up ex. When Geohot stopped working on iPhone jailbreak exploits since they became boring and started working on jailbreaking and installing custom firmwares on Playstation.

Google is trying to eliminate any chances of any incident related to AP, because it would destroy the credibility and contracts towards Banks, we've repeated that over and over.

We've seen well sophisticated attacks to financial companies and banks yet electronic financial transactions thrive. People will always try to steal the medium (electronic or not) doesn't really make a difference.

This safetynet race began with Google since they introduced AP, and later PoGo started using the api as fake locations killed the essence of PoGo. Some people consider it as hate against development community cuz Google is pushing things far.

The reason this race started is not chances of an economic crash or Banks, it's Google's own loss of control over a platform that thrived because of a community, the open source and hacking.
[SuperSU] luigidk:
I flashed pure nexus clean and the flash kernel for the boot verify check. I also rooted by flashing SuperSU 2.78sr1 so I could restore my apps using titanium backup.

Now that I'm done with needing root I unrooted using full unroot in SuperSU.

However safety net still fails.

AM I missing something?
[SuperSU] aR_ChRiS:
Got a question here.

In my first flash (clean update to Pure Nexus Nougat for Nexus 5), I flashed:

Rom+Gapps+SuperSU 2.78SR1 in systemless mode, Franco Kernel

then let my phone reboot and went through the setup.

When I tried to flash suhide-0.55 and reboot, the phone was stuck on a soft bootloop (stays in bootanimation but the OS won't start). I sorted that out by flashing suhide-rm however I really wanted suhide in my system. Is there a way I can avoid the soft bootloop?
[SuperSU] Alxoom33:
I have a similar issue with the Pixel C running latest Android 7.1.1 beta.

Of course I am not flashing Gapps or the Franco kernel in the device.
[SuperSU] 89titanium:
This wouldn't exactly be the most appropriate place to ask, but would I need to uninstall my phh superuser if I want to use this new SuperSU?
[SuperSU] Alxoom33:
Yes you will. flash the stock boot image in your /data file.
[SuperSU] 89titanium:
Thanks