yashsingh1/xdaforums huggingface dataset:
[Nexus 5 Q&A, Help & Troubleshooting] dkryder:
who really needs android pay? i have managed to successfully live happily for 63 years without it. i do not understand why anyone would be upset that it will not run on the rooted device. if you feel you can not get by without android pay buy a cheap small device that you will keep in any state necessary to run android pay. my guess is google wants you to use it because in some way they make money when someone uses it, some type of fee someone or some thing gets charged. another thing, i'm almost positive google would want to know about any activity around bypassing the checks android pay uses to disallow rooted devices as well as the forum moderators not allowing any links to supposed solutions as if anyone would really trust clicking on them except possibly google engineers wanting to see if there actually is a way to put android pay on a rooted device. i guess one point is you have to be kinda foolish to post android pay breaks here, have some respect and decency for xda and just say you read something about it on xxxxx without any links if anyone is interested they will find it.
[Nexus 5 Q&A, Help & Troubleshooting] GatoL0c0:
Keep it up! Many of us appreciate your dedication.
[Nexus 5 Q&A, Help & Troubleshooting] skyguy126:
Would there be a way to use Xposed framework, to spoof the signature check the app does and make it seem as if the image was still valid?
[Nexus 5 Q&A, Help & Troubleshooting] Spark1223:
Just a thought, but a sort of replay attack work around comes to mind. Just take a hash of system clean (unrooted without xposed) and use that hash when you need to pay. Wouldn't that work?

The problem I'm having with using it is while I can disable root easily, I can't easily get around with xposed in background if that had an option for easy install/uninstall on 5.x there wouldn't be a problem
[Nexus 5 Q&A, Help & Troubleshooting] Surge1223:
Wow this thread is getting ridiculous. The guy comes here to hear our concerns and work together to find a solution and a bunch of people in here are making us (xda) look horrible. I actually feel embarrassed.

Anyways the point isn't to bypass it...thats relatively easily done by modifying the the libdrmfs.so and QSEEComAPI lib that are responsible for sending the scm calls to retrieve the OEMCrypto flags for the token generation that the Android Pay apk requests.

So for the sake of all of us here at xda, if you're going to go all "L33T HacKR AnOn" in your posts or "us against the man" type of posts please..just stop typing before you hurt you yourself.

At the same time if you're a advocate of security or a person who has had experience in working for or needing security, please don't patronize the group of folks I mentioned above. No one cares if you care about security or think you're obligated to give anyone who disagrees your rhetoric only matched by the representatives of the NSA during the Congressional hearing on mass surveillance.

These two parties of folks I mentioned above, instead might I suggest using logcat and investigating yourselves...believe it or not at one point in time the majority of people on xda used logcat and would debug together.

Anyone with logcat and grep can easily see how the security checks take place.

If not, try to grep for "gsm" or "drm"
[Nexus 5 Q&A, Help & Troubleshooting] AndroidDeveloperLB:
Have you read the post I've written (here and here) ? Having a root access built in (but disabled by default of course) is actually more secure than the current situation, where there are apps like TowelRoot which can gain root access without any problem. Think what would have happened if you've installed an app that has the code of TowerRoot which gains root access, and will do it without your knowledge. This is only one point I've written in the original post. Please read it all.

If Google would have controlled how rooting works on its own devices, and protect the part that's responsible of Android Pay , everyone wins. Nobody will even need to root their device using shady apps.

---------- Post added at 10:06 AM ---------- Previous post was at 10:04 AM ----------

You don't agree to what exactly ? I didn't say it will be enabled by default. Please read the entire post. I've mentioned there multiple points and also suggestions about how it would work.

Here I've barely described what I wrote in the original post.

Why would a normal user dig into the settings, and enable root? It could even be hidden just like the development category. Maybe even added there (because rooting can help a lot for developers too).
[Nexus 5 Q&A, Help & Troubleshooting] blunden:
I agree that preventing root with locked bootloaders etc. is bad as it causes people to hold on to exploits just to use them to root locked devices, instead of properly reporting them so that they can be fixed. It's the same issue we see on iOS. If you would have read my earlier comments in this thread you would see that I completely agree with that. My objection was that even officially sanctioned root access is inherently insecure. The very definition of root access bypasses Android's security model so in that regard it wouldn't be any noticable difference in regards to Android Pay. The solution is rather to expand the availble APIs and permissions to allow users to do what we/they currently need root to do.
[Nexus 5 Q&A, Help & Troubleshooting] tiny4579:
Agreed. I think least permissions needed to do the job is a good security model. It'd be nice if non CTS compliant ROMs like cm would be allowed. Especially when cm is able to patch the latest security exploits even quicker than AOSP.
[Nexus 5 Q&A, Help & Troubleshooting] YaKillaCJ:
I am calling BS. This is NOT about security. Stock roms are the most insecure and most exploitable. They all are behind and have exploits due to there delayed compilation. A nightly is by far more secure than OEM roms. If root was concern, then allow custom roms that dont have root. Im calling it what it is, its about google being able to place the blame on OEMs if something happens. My stand on this is real simple.

If security was really the concern, be more proactive. Instead of checking if the system been altered, check if the system vulnerable to common exploits.

*I honestly wanna hear if any1 can explain why statement isnt accurate.
[Nexus 5 Q&A, Help & Troubleshooting] Stryke_the_Orc:
ZERO DAY EXPLOIT

.

You know what the signature should be, so checking to see if it's modified is the best form of security in this case. Unless you're running quantum computers, you can't spoof the hash of an OEM image, just as they can't be proactive for unknown vulnerabilties. Think before you post.
[Nexus 5 Q&A, Help & Troubleshooting] YaKillaCJ:
I think before I speak and I clearly said Known COMMON exploits. Im talking about the ones that are known. The idea is very simple. Right now I can run a check for Stagefreight/Towelroot exploit on more than half the devices in use today and they will fail. So U need to read my statement very accurately and think before U speak. I aint dumb, I know new exploits get discovered. My whole point is that my stock S4 is more vulnerable to malicious Data (Android Pay Info) than my S3 running CM latest nightly.

*Edit

This very reason is also my concern for security. I see it for what it is. By making it so Android Pay only work on Stock, it gives a template. This means that said hackers now know what devices will be susceptible. Said hackers job just got easier actually.
[Nexus 5 Q&A, Help & Troubleshooting] Stryke_the_Orc:
Your stock S4 is also dependent on your carrier to patch the exploit. Known vulnerabilties are patched pretty quickly through Google, find a Nexus device that is still vulnerable to TowelRoot. Stagefright is a continuing development, but again, Google is patching the CVE's as quickly as they become known, your carrier however, is not. A simple bit of research on your part would explain to you why your devices are vulnerable. You have an issue with a stock ROM being insecure, talk to your carrier. Ask them why it takes months, if ever, before you see any kinds of updates to your devices firmware, then ask them why their bloat and modifications break the basic functionality and security of Google's firmware design.

I suggest you take a small break from your keyboard now before you come back and reply.

Edit - Thread cleaned.
[Nexus 5 Q&A, Help & Troubleshooting] blunden:
CM is in fact almost CTS compliant. There are some things like root and building nightlies with test-keys that cause it to fail CTS but the base is fairly compliant. Don't forget the CTS-complient CyanogenOS stock rom for the OnePlus One is based on the same code. The downside with the CTS is that it takes a long time and any failures require you to rerun it again so it's hard to motive running it on the builds for all devices.
[Nexus 5 Q&A, Help & Troubleshooting] uudruid74:
If any app gets root, your fine grained security is gone and that app can replace parts of the system. This means Android Pay is out. You didn't solve the problem.

My point, was that even buried in settings, an app will pull up the settings and tell them to enable it, or a friend will tell them to enable it for backup. Either way, root isn't fine grained.

They need a built in backup functionality, a way to deinstall ANY app, and a firewall. If they put this into the OS, then most people wont need root. Giving them root doesn't solve the security concerns nor does it make exploits go away.

Luckily, I use a 1+1 and no exploits are needed to root. Just unlock the bootloader and flash supersu.

Taglines suck. https://eddon.systems

---------- Post added at 10:59 AM ---------- Previous post was at 10:48 AM ----------

What? When will it be doing this check exactly? Its going to compute a hash of the whole ROM every time I do a payment transaction? And for that to work, it would need to check against a database of hashes which must be stored remotely. Doesn't seem likely, and any other method opens the door to me changing something or some exploit changing something after the hash has been checked and before the next payment transaction.

I'll keep my secure ROM. When StageFright was announced, I downloaded the checker and my rooted custom ROM was not vulnerable. Everyone on stock was vulnerable for another month. OP has a valid point that known exploits are a better test than known root or custom ROM

Taglines suck. https://eddon.systems
[Nexus 5 Q&A, Help & Troubleshooting] Stryke_the_Orc:
DM-Verity checks the hash of your device at boot, I would assume that AP checks the trusted hash on your device against known hashes, when it does this I don't know, I haven't torn it down to look, but it explains why a few pages back a rooted user was able to use it for a short time, but the ability did not persist through reboot or over multiple payments. It obviously makes the check, but it may not do it for every transaction. And as for the known CVE check, how would that be any more efficient than checking a single known hash against a database? One check vs thousands...
[Nexus 5 Q&A, Help & Troubleshooting] CKD Publishing:
We don't see why Google want to deprecate/abandon Google Wallet + NFC + MasterCard PayPass model. Is Android Pay (AP) any better and how? Perhaps a white paper from Google might shed some light into the [business] logic behind the adoption of AP.

Or, is this more about Google's control and share of the transaction fees incurred from purchases via Google Play or from other Android-compatible payment systems using AP in the future? Seeing that other Android-mobile payment systems already exist (Samsung Pay, etc), we are inclined to think AP is created more as a competitive mobile payment system than it is a security overhaul for the current Google Wallet + NFC + MasterCard PayPass setup?

For the desktop O.S. (Windows, Linux, Mac) via administrative privilege (equivalent to root in Android), we use HTTPS + BPay (BankPay, in Australia) protocols for secured electronic transfers and payments. Why can't similar protocol combos be created for the mobile platform, even if Google want a share of the profit with the financial institutions? Anyway, we can't see the justification for adopting AP in favour of the tried-and-tested Google Wallet + NFC + MasterCard PayPass model.

Again, a technical white paper from Google explaining the benefits, pros and cons might help clear up any confusion between AP and what's already in place for Android.
[Nexus 5 Q&A, Help & Troubleshooting] DAVe3283:
I see what you are saying, but I think you are missing the point here. The point is: why is an outdated stock S4 with many known vulnerabilities enabled to run Android pay, but our updated custom ROMs not? The argument we are making is that even with root, we have less chance of someone getting to our Android Pay / Credit Card data than a stock outdated ROM, no matter who's fault it is the stock ROM is outdated.
[Nexus 5 Q&A, Help & Troubleshooting] HorstiG:
Goodbye Google

In real open source, you have the right to control your own destiny.

Linus Torvalds

https://en.wikiquote.org/wiki/Linus_Torvalds
[Nexus 5 Q&A, Help & Troubleshooting] Stryke_the_Orc:
Simple really, that boils down to $$$. How much potential cashflow do they lose if they block all outdated firmware vs how much do they lose if they block all modified firmware?

Sure, you may not be vulnerable to a known CVE that was patched anymore, but you still provide root access to your applications. Aside from [MENTION=5880917]uudruid74[/MENTION] (who btw, is probably the most on-the-ball person I've seen commenting about security related issues in this thread), I bet 90% of you couldn't tell me what any one of those applications accesses without your approval. Sure you can grant this power management app access to modify the underlying kernel code, what other permissions are requested and how vague are the descriptions? "Read, write, modify and delete files" is pretty vague. Which files exactly? The txt files that are created when you log an activity, or the protected files that house my account information from your banking app? Without explicit and full disclosure or a stateful firewall on your device, you have no way of knowing what that, or any other app you've given su permissions to, is doing.

If you're not rooted, those applications cannot request, nor be granted, those kinds of permissions without utilizing the known CVE's making them inherently safer from any financial institutions point of view, especially if there are patches available (regardless of if a carrier has distributed them yet).
[Nexus 5 Q&A, Help & Troubleshooting] tender82:
Yeah, I am with CKD on this one. I understand bringing Android Pay and the extra security, but if you've got such a vocal group of people who have been using a service for a long time, why not keep that running as an alternative until you can figure out a way to get it working for all. The Google representative mentioned that he didn't think a fix would happen anytime soon, but this process has been fine for years. At least keep it active, if not hidden in a forum like this, for those who are willing to seek it out.
[Nexus 5 Q&A, Help & Troubleshooting] DAVe3283:
And there you have it: it isn't really about security, it is about money. Google will willingly compromise security for a larger userbase, but then blows us off citing security.

I am one of the few who doesn't install a root app without having thou roughly researched it first, and ideally skimmed the source code. Could I miss something? Sure, but I think I do a good job.

However, I absolutely agree with you (and the numerous others who have said this): we need a mechanism to lock down apps (revoke permissions, but better than Marshmallow which gives a ton of "free" permissions), backup/restore, firewall, etc, without root. That would solve this whole problem, IMO.

But until that happens, I feel more secure running some root apps to lock down my personal info & privacy than hoping for the best on a locked down outdated stock ROM.
[Nexus 5 Q&A, Help & Troubleshooting] Stryke_the_Orc:
You've missed and twisted the point. They do not willingly risk users security for money, the risk is simply greater for modified firmware than it is outdated firmware. In a perfect world, every device would be patched and the cve's wouldn't be a threat, but user granted su permissions are a huge risk. No financial institution would ever agree to be a part of that threat model. It's just far too risky and uncontrolled.
[Nexus 5 Q&A, Help & Troubleshooting] ajm786:
I don't like what this thread devolved into: arguing about the merits of root vs unroot.

That being said, let me throw in my 2 cents.

I'm absolutely fine with a stockish/unrooted ROM. As a matter of fact, let me list all the apps I have that request root on my CM12.1 based ROM.

1. AdAway

2. BetterBatteryStats

3. CM SPen Add-on

4. CPU Spy

5. DisableService

6. exDialer MissedCall Plugin

7. Greenify

8. Lightflow

9. Logcat Extreme

10. PNF Root

11. ROM Settings Backup

12. Root Browser

13. Titanium Backup

14. Viper4AndroidFX

15. Wakelock Detector

Out of all these apps, SIX (that's right six) are almost critically necessary to beat down the ridiculous wakelocks that Google Play Services keeps on the device that destroys the battery. The rest, meh, not really necessary. The ones that I absolutely cannot go without? #1, 13, and 14.

Show me how any of these apps "compromise security" in any way. Likewise, if Google got their act together and fixed Google Play Services (don't ask me how many of services I have had to disable using DisableService), at least six of these apps go away. And if Google OFFERED the ability that these apps provide without root, I'm all for it.

The argument that "root is unsecure, so you don't get to use Android Pay even though Google Wallet was working perfectly before" is one that I personally don't buy. As a proponent of all things Android and Google, especially to those around me, this is particularly worrisome.

And no one has still addressed how is it that if root is "so unsecure and scary", why is it that an iPhone can be jailbroken and still use Apple Pay. As a consumer, this tells me it CAN be done. I'm not going to accuse Google of being lazy, but it's either that or they have some backdoor deals going on that they'd rather not tell us about.
[Nexus 5 Q&A, Help & Troubleshooting] YaKillaCJ:
Many custom Roms do not come rooted by default. Once we install them, we have to flash a SuperUser app. The safety is far greater on a Custom Rom (CM, Slim, ect) that lacks SuperUser than a stock rom that lacks superuser. Thats the point. It has nothing to do with security. To me, they just using this as a way to brush power users off. Case in point, the ONLY safe devices that are actually using Android Pay belong to AOSP (Nexus, Motorola, etc) and CM (OnePlusOne, Yu, etc). All others from Samsung, HTC, LG, Blu, Asus, Sony, etc are behind (vulnerable) and yet get to use Android Pay. Exception from this list being Xiaomi (Miui) devices being the most upkept. So tell me again why I cant install my updated and fully secure updated Paranoid Android, never install super user and keep my credit information really safe. Not some false sense of safety.

Side topic. U already seen how this topic turned sideways because people are just gonna figure out how to bypass the checks and use Android Pay with Root anyways. Sad that is has to be that way but Google shouldve known better seeing as how they went thru this same thing with Wallet initially. Sadly Apple Pay (come lately to the game but market it well) works on JailBroken devices, lol
[Nexus 5 Q&A, Help & Troubleshooting] WhosAsking:
That'll probably change once a jailbroken iPhone gets hit with a malware that targets Apple Pay and (because of the new PCI rules that affect liability), Apple ends up with the bill because they weren't secure enough (these new liability rules are what are finally starting a push for Chip cards in the US). Apple Pay may take jailbroken phones now, but it probably won't stay that way for long.
[Nexus 5 Q&A, Help & Troubleshooting] jasondclinton_google:
This is particularly insightful: I totally hear what multiple people on this thread are saying about some cases of unpatched vulnerabilities. (And as we just announced, our monthly security updates should get these numbers down even further.) I wouldn't word this exactly the same way as above but the general theme is right.

Here's the thing: let's say that a hypothetical fraudster wanted to exploit a known vulnerability that is still in the process of being patched. For example, let's say that there's 0.5% of devices in the US that are affected by this particular vector. As the fraudster, I would need to get my app on the Store, somehow convince some subset of that number to install it, evade Bouncer (and other Store countermeasures), and hope that the device that I ended up running on that population has something worth my effort. Possible? Maybe. But at what cost, for how long, and for what payoff, and at what risk?

In contrast, let's say that that same hypothetical fraudster instead targeted rooted users. This is interesting because the numbers have changed: for the sake of this argument, let's assume that the rooted population is larger than 0.5%, but most importantly:

there's no race against the clock for the vector being patched (rooted users tend to stay that way). The fraudster could target some kind of social engineering root escalation prompt or any number of other vectors. The user has already done all the work of breaking through the CVE's on the entire corpus of phones in the wild for him

no Play Bouncer or other countermeasures to circumvent

the target population for his attack hangs out largely in one place and are willing to install software from him if it sounds useful enough

the target population (assuming that we didn't SafetyNet) being enthusiasts would almost certainly have Android Pay configured.

It's true that the risk part of the equation that I listed above doesn't change between the two scenarios.

I hope this does a good job of explaining why I'm really, sincerely worried about this.
[Nexus 5 Q&A, Help & Troubleshooting] Stryke_the_Orc:
I agree, this thread has gone so far from the intended topic it's not even funny. The debate here was never about why your rooted ROM is/is not more secure than an official OEM image, it was about why Google, and the institutions they work with, don't want you to use this app with modified firmware. This was answered by a Google engineer, it was reiterated several times through the course of this thread, still there's argument about why your device should be trusted because it's "more secure". This, simply put, is about an established chain of trust. Google trusts their firmware, they trust the OEM firmware, and banks trust Google. They do not, however, trust Joe Blow down the street who compiled PAC on his S3 with some merged cherry-picks and supposed patches that may or not be functional or may just be entirely placebo. They do not trust any application that asks for root privileges because of the potential for damage, and they do not trust an application that has not gone through their rigorous testing for compliance to their standards. Older firmware or not, CVE's or not, this established chain of trust trumps your arguments (not specifically yours, just in general). The major differences between why Wallet worked and this will not have already been explained, tokenization. As for jailbroken iOS devices, I'm reasonably certain that they have done just what members here are trying to do, and bypassed the security put in place. Considering how difficult Apple makes doing anything with their systems, it seems very unlikely to me that Google has "broken the mold" here and decided to be more restrictive than their competition.

Oh and what backdoor deals would behoove them in this case? Rooted or not, the app functions in the same manner. They restrict usage to unmodified devices to mitigate risk to themselves and keep their contracts with the institutions accepting Android Pay.