If you are running Lineage OS for the BLU R1HD, or almost any custom ROM on any device, you have probably gotten this message from android pay, PS Vue, or a number of other apps: "can not run on a rooted device". This is easy to fix on a rooted device, but a custom ROM is a whole other story. I kept getting CTS profile mismatch, regardless of what I tried. I'm not a developer, but I am no dummy, work as an OpenStack engineer, and have been in network engineering for 15 years, yet I could not find crap about CTS, other than it is the " Comparability Test Suite ". After hunting the web, I finally stumbled upon a good article that explains it pretty nicely, so here it is:
------------
Rooting your Android device gives you access to a wider variety of apps and a deeper access to the Android system. But some apps–like Google’s Android Pay–won’t work at all on a rooted device.
Google uses something called SafetyNet to detect whether your device is rooted or not, and blocks access to those features. Google isn’t the only one, either–plenty of third-party apps also won’t work on rooted Android devices, although they may check for the presence of root in other ways.
SafetyNet: How Google Knows You’ve Rooted Your Android Phone
Android devices offer a “SafetyNet API,” which is part of the Google Play Services layer installed on Google-approved Android devices. This API “provides access to Google services that help you assess the health and safety of an Android device,” according to Google. If you’re an Android developer, you can call this API in your app to check whether the device you’re running on has been tampered with.
This SafetyNet API is designed to check whether a device has been tampered with–whether it’s been rooted by a user, is running a custom ROM, or has been infected with low-level malware, for example.
Devices that ship with Google’s Play Store and other apps installed must pass Google’s Android “Compatibility Test Suite”. Rooting a device or installing a custom ROM prevents a device from being “CTS Compatible”. This is how the SafetyNet API can tell if you’re rooted–it merely checks for CTS compatibility. Similarly, if you get an Android device that never came with Google’s apps–like one of those $20 tablets shipped direct from a factory in China–it won’t be considered “CTS compatible” at all, even if you haven’t rooted it.
To get this information, Google Play Services downloads a program named “snet” and runs it in the background on your device. The program collects data from your device and sends it to Google regularly. Google uses this information for a variety of purposes, from getting a picture of the wider Android ecosystem to determining whether or not your device’s software has been tampered with. Google doesn’t explain exactly what snet is looking for, but it’s likely snet checks if your system partition has been modified from the factory state.
You can check the SafetyNet status of your device by downloading an app like SafetyNet Helper Sample or SafetyNet Playground. The app will ask Google’s SafetyNet service about your device’s status and tell you the response it gets from Google’s server.
It’s Up to the App
SafetyNet is optional for app developers, and app developers can choose to use it or not. SafetyNet only prevents an app from working if an app’s developer doesn’t want it to work on rooted devices.
Most apps won’t check the SafetyNet API at all. Even an app that does check the SafetyNet API–like the test apps above–won’t stop working if they receive a bad response. The app’s developer has to check the SafetyNet API and make the app refuse to function if it learns your device’s software has been modified. Google’s own Android Pay app is a good example of this in action.
Android Pay Won’t Work on Rooted Devices
Google’s Android Pay mobile payment solution doesn’t work at all on rooted Android devices. Try to launch it, and you’ll just see a message saying “Android Pay cannot be used. Google is unable to verify that your device or the software running on it is Android compatible.”
It’s not just about rooting, of course–running a custom ROM would also put you afoul of this requirement. The SafetyNet API will claim it’s not “Android compatible” if you’re using a custom ROM the device didn’t come with.
Remember, this doesn’t just detect rooting. If your device were infected by some system-level malware with the ability to spy on Android Pay and other apps, the SafetyNet API would also prevent Android Pay from functioning, which is a good thing.
Rooting your device breaks Android’s normal security model. Android Pay normally protects your payment data using Android’s sandboxing features, but apps can break out of the sandbox on a rooted device. Google has no way to know how secure Android Pay would be on a particular device if it’s rooted or running an unknown custom ROM, so they block it. An Android Pay engineer explained the problem on the XDA Developers forum if you’re curious to read more.
Other Ways Apps Can Detect Root
SafetyNet is just one way an app could check if it’s running on a rooted device. For example, Samsung devices include a security system named KNOX. If you root your device, KNOX security is tripped. Samsung Pay, Samsung’s own mobile-payments app, will refuse to function on rooted devices. Samsung is using KNOX for this, but it could just as well use SafetyNet.
Similarly, plenty of third-party apps will block you from using them, and not all of them use SafetyNet. They may just check for the presence of known root apps and processes on a device.
It’s tough to find an up-to-date list of apps that don’t work when a device is rooted. However, RootCloak provides several lists. These lists may be out-of-date, but they’re the best ones we can find. Many are banking and other mobile wallet apps, which block access on rooted phones in an attempt to protect your banking information from being captured by other apps. Apps for video streaming services may also refuse to function on a rooted device as a sort of DRM measure, attempting to prevent you from recording a protected video stream.
Some Apps Can Be Tricked
Google’s playing a cat-and-mouse game with SafetyNet, constantly updating it in an attempt to stay ahead of people getting around it. For example, Android developer Chainfire has created a new method of rooting Android devices without modifying the system partition, known as “systemless root”. SafetyNet initially didn’t detect such devices as being tampered with, and Android Pay worked–but SafetyNet was eventually updated to detect this new rooting method. This means Android Pay no longer works along with systemless root.
Depending on how an app checks for root access, you may be able to trick it. For example, there are reportedly methods to root some Samsung devices without tripping the KNOX security, which would allow you to continue using Samsung Pay.
In the case of apps that just check for root apps on your system, there’s an Xposed Framework module named RootCloak that reportedly allows you to trick them into working anyway. This works with apps like DirecTV GenieGo, Best Buy CinemaNow, and Movies by Flixster, which don’t normally work on rooted devices. However, if these apps were updated to use Google’s SafetyNet, they wouldn’t be so easy to trick in this way.
Most apps will continue working normally once you’ve rooted your device. Mobile payment apps are the big exception, as are some other banking and financial apps. Paid video-streaming services sometimes attempt to block you from watching their videos as well.
If an app you need doesn’t function on your rooted device, you can always unroot your device to use it. The app should work after you’ve returned your device to its secure, factory state.
I am checking every way hoping to find a solution ...
Yes...It's working.
I am using GPay on my rooted device !
Related
I've not got round to trying to root a device yet, and before I root my Nexus 7 in order to access files on USB Flash drives, I'd like to check out a few points please?
I'd heard that Google had previously blocked rooted Android devices from renting movies, eg in Wired and this very forum. Could anyone confirm please if that's still the case, or has Google removed that block since?
Secondly, does anyone know if rooted Android devices are being blocked or restricted in any other way on the Play Store? Eg after rooting, would I still have access to (and be able to re-install) all the apps I'd previously installed from the Play Store, particularly paid apps, would previously-installed apps still show up in my Play account, and would they still be automatically updated? I'd suspect so, & sorry if it may seem obvious, but I want to verify this definitively before rooting.
And what about OS updates, I assume I'd have to do those myself manually thereafter?
Are there any other major disadvantages to rooting please, apart from wiping my existing data and perhaps voiding my warranty? (I'm aware it may be possible to unroot before making any warranty claim - unless of course the fault prevents that!)
I am 99% sure that the root block on movies has now been removed for Google Play Movies
Root does not effect you installing other apps, however certain apps may be root protected i.e. won't work on a rooted device, there are not many of these and most of them you can "hide" root to use.
Lennyuk said:
I am 99% sure that the root block on movies has now been removed for Google Play Movies
Root does not effect you installing other apps, however certain apps may be root protected i.e. won't work on a rooted device, there are not many of these and most of them you can "hide" root to use.
Click to expand...
Click to collapse
Cheers Lennyuk.
What about Play Store accounts, hopefully there's no indication of Google detecting rooted devices and disabling accounts or deleting apps from the accounts of people with rooted devices?
I really don't think Google cares. These devices are meant to be a stable platform that you can develop on, so they are going to expect people to root them.
Google don't care about root at all, people that do are usually OEM's (because they like an excuse to void warranty) and certain app makers like bskyb (they quote security reasons but deep down they just don't really understand root and are fearful of piracy)
Lennyuk said:
Google don't care about root at all, people that do are usually OEM's (because they like an excuse to void warranty) and certain app makers like bskyb (they quote security reasons but deep down they just don't really understand root and are fearful of piracy)
Click to expand...
Click to collapse
Great, thanks very much Lennyuk and pjohnson87. After the movie rental blocking, I thought I ought to check if any other restrictions had been imposed by Google, whether under pressure from app makers or for some other reason.
As long as I don't lose the ability to (re-)install paid apps from the Play Store, that's the main thing I'm concerned about!
can anyone make a patch for all variants of hd2 roms from gb up i used the bluebox app to check if my phone was vunerable for this bug 13678484 (fake id) and my daily driver barebone cm7 v2b was, and id say all roms developed for hd2 are vunerable have searched the net for how to patch this vunerability but cant find the info abywhere this is something i think all xda devs for this device will have to sort out as we cannot get help from carriers on this as this is what advice is given "contact your carrier or phone vendor for patch. if anyone has advice on how to sort this out would be very thankful i think xda should run a piece about this vunerability and what steps are being taken by all devs on xda to patch this vunerabilitu for older handsets likemy hd2.
Bluebox Security revealed a significant security flaw that affects all Android devices since version 2.1. Our hyperbolic title mocks the fact that he had little to ignite the Internet powders. If the fault is real, it should take a step back and put the case in context instead of screaming panic for nothing.
A serious flaw that affects a large number of terminals
Very schematically, the fault Fake ID allows malware to authenticate using the signature of a known application to hide its true origin. The firm provides an example of a virus masquerading as an Adobe Systems and Google software which would be able to become a Trojan horse or steal data used by Google Wallet acquiring the necessary permissions without using the user.
The flaw is serious. However, Google has already been made aware, he has already released a patch he sent to his partners, he corrected the flaw in Android 4.4 KitKat, he scanned the Google Play and can say that no application in its store uses this vulnerability. Finally, Verify Apps, which monitors the behavior of applications on an Android device, is also fixed and can detect an application attempting to exploit Fake ID.
A patch already in place and a flaw in a very limited scope that still show that Google still has work to do in terms of security
In short, it is true that it is possible to be a victim of this fault, but it requires a terminal that has not been updated, download an application containing malware does not come from Google and Play Verify Apps have disabled or have an Android version of which is free. Suffice to say that the cases in question are very limited.
This flaw shows that Google still has work to do in terms of its security strategy. Last month, we décriions lax features the Play Store. Today, we are dealing with a flaw of a limited scope, but was discovered by analyzing the shortcomings of the source code of the operating system.
This flaw shows that Google still has work to do in terms of its security strategy. Last month, we décriions lax features the Play Store. Today, we are dealing with a flaw of a limited scope, but was discovered by analyzing the shortcomings of the source code of the operating system.[/QUOTE]
while the info you have given is fine and i thank you for it, but there are other app stores people use beside google play store and reading up on this bug it is still possible their phones could become compromised downloading apps from them?
A Big Big Thank You
Just an update: opssemnik backported the fake id xposed module and it works perfectly with gb roms a big big thank you to him. he also supplied a link in the comments on http://www.xda-developers.com/android/fight-fake-id-vulnerability-xposed/ So once again a big thank you to opssemnik
Evidently, BlackBerry will be heading straight to a 6 months on surviving root exploits which that is the same reason the device is being sold in the first place.
I knew some of my friends that are "conservatives" on Android and they believe that devices like Priv are the ones that makes Android not fun to deal with as root open big opportunity on having the best from a device.
I had been a faithful user of Google Nexus since Google Nexus 4 to 6 and yes and no I was in rush for a root, although I needed to control ads within the device, I am not a fan on modifying CPU's clock but controlling administrative aspect of the OS it is important too.
But BlackBerry Priv with a modified Android to be secure at least have answered all my needs that I sacrificed with the Google Nexus as previously was a faithful BlackBerry user and (you can correct me if I'm wrong) the bet pool for a fully functional root is currently at $300 and I wanted to ask if my friend are just being dramatic or it is true that not being able to root a phone can be upsetting to some?
BTW, I don't want to start a scuffle or anything, but I do believe BlackBerry has put many of know Android devs really to think about current exploits and if BlackBerry might be the precursor on a trend with other manufacturers.
To me, they are doing security by obscurity.
There are servers with root available that are secure, the access to said root is protected and exploits to access it without proper authentification are patched.
If they were that good, they would provide a secure way to use root privileges themselves.
They call for security, but you cannot manage iptables to prevent apps calling servers they should not talk to, you cannot prevent applications from tracking you using google's advertising ID, and most for all, you cannot prevent Google from tracking you, even when you don't use a Google account, because Googles services are tied to the system partition.
Being unable to root the PRIV with a security flaw is a good thing, being unable to protect yourself because your tools needs root and you cannot obtain it without a flaw is bad.
You should be able to obtain root from Blackberry themselves using a unique token the device can generate when your user password is good and the device unlocked. (Past password prompt, with a check that the password prompt had the right password, and that it wasn't killed some other ways).
Good point and btw, that was one of the argument in the discussion, Google itself is a big data mining system itself.
Magissia said:
To me, they are doing security by obscurity.
There are servers with root available that are secure, the access to said root is protected and exploits to access it without proper authentification are patched.
If they were that good, they would provide a secure way to use root privileges themselves.
They call for security, but you cannot manage iptables to prevent apps calling servers they should not talk to, you cannot prevent applications from tracking you using google's advertising ID, and most for all, you cannot prevent Google from tracking you, even when you don't use a Google account, because Googles services are tied to the system partition.
Being unable to root the PRIV with a security flaw is a good thing, being unable to protect yourself because your tools needs root and you cannot obtain it without a flaw is bad.
You should be able to obtain root from Blackberry themselves using a unique token the device can generate when your user password is good and the device unlocked. (Past password prompt, with a check that the password prompt had the right password, and that it wasn't killed some other ways).
Click to expand...
Click to collapse
Totally agree there - there has to be a secure way of providing root access to power users who know enough to request it and obviously accept the responsibility...
although i feel like the changes in the system you are proposing would probably mean that they wouldn't qualify for Google's android device approval process (whatever it's called) for allowing Google play services on it. That would basically defeat the purpose of moving to android as the app ecosystem is the main reason for the move...
Basically Google and apple are wielding all the power in the industry at this moment. and now with the (seemingly inevitable) slow, painful (especially for us fans) death of BlackBerry 10 on the horizon, i can't see there being an adequate alternative emerging for quite a while... unless you consider windows phone a viable alternative!! [emoji12]
So sit back, relax and enjoy our descent into the brave new world of 1984!!
Sent from my STV100-1 using Tapatalk
can't install a firewall. /thread if you think it's still secure.
well, you could still set up a VPN and filter on a remote server...
Sent from my STV100-1 using XDA-Developers mobile app
Hello xda
I turn to you, as I have great trouble in my project.
I work at a beer distributor / wholeseller in Denmark.
We have 8 trucks and a few vans.
We are in process of upgrading our ERP to Dynamics Navision and for that we need new hard-terminals for our drivers.
We want to go next-level and our hand-terminals will be on smartphones using an app / service called Movilizer.
In theory, it should work on any distro and phone.
I am now in the process of finding the correct setup, so that these work phones stay professional and won't be used to install various apps or tampered with.
Through a contract with our phone-company, we've got 11 Huawei P9 Lite - these are the subject of setup.
Now for my challenges:
I want anti-virus on the phones, for good purpose and I plan on using ESET.
I want to support the phones in the field and I plan on using Teamviewer for that.
What I am in search for is the following:
Block use of various non-work-related stock apps
Block the ability to close the apps I install (so they won't close Teamviewer, for example)
Block install or uninstall of any app.
Million-dollar wish: I would love to be able to deploy that automaticly - most perfect would be through a MDM or by cable to a computer through some software.
I am open to rooting and even flashing roms.
I have tried Cisco Meraki MDM, but the blocking didn't seem to go into effect.
I hope someone has some experience to share - I have used the last week trying out MDMs and configuring them.
Heck, might just be me being a noob. But trust me, I've tried :/
Kind regards,
Christian Sjobeck
To block any apps you can use Greenify, witch hibernate every app you want and has the automatic hibernation function. It is one of my favorite app, and with root and Xposed framework, it is very fast.
To uninstall every app, even system app, I use Link2SD witch has a couple of function including uninstalling system apps. It is simple and fast.
To keep the apps you want, there should be already a whitelist in EMUI where you add the apps that you want to protect.
Hope to be helpful
Hello Potato997
Thank you a lot for your recommendations.
It gives me something to persue.
Do you have any recommendations for pin locking the apps I install? (Anti-virus, mdm, teamviewer for example) it would be prevent changes in settings.
Would it be viable to set one phone up with everything (app whitelisting, system app uninstalls, pinlock, etc.) and then do an android backup and restore that onto the other phones?
For easy deployment, instead of manual handling.
In CyanogenMod and AOSP based ROMs the pin to open the apps is already integrated in the system, I don't know on EMUI since I'm on RR.
For the backup, if the phones are the same model you can do a backup in TWRP and restore it on every phone so you only have to set up the phone one time
They are needed, unlocked bootloader, custom recovery and root.
the problem with pinning apps in cyanogenmod, is that you can only pin 1 app, and it will stay on the foreground untill it's no longer pinned (kinda like a kiosk mode). and the whitelist in emui only prevents the apps that are whitelisted from being closed automatically, but they can still be closed by the user.
without creating your own rom, i think most android phones won't be able to fulfill your needs
It's with great pleasure that I inform you all that AndroIDentity 3.5 has been released, and it has several new features:
SafetyNet Attestation:
Attest the device per Google's SafetyNet API, using secure two-step validation of the results, and scan for Potentially Harmful Applications (PHAs)
System log (logcat)
A convenient and easy-to-use logcat tool, that displays the device's log, even on
non-rooted device (ADB is required to enable logcat on non-rooted devices). The output is color-coded by log type (verbose, info, warning, etc).
Powerful Package & Apps information
AndroIDentity's new Package Information gives you access to several important data on packages: store it was installed from, UID, storage location, direct link to its store (such as Google's, Amazon, Samguns, etc), filters, signing certificates, activities, and many other features usually not found on free apps.
Play Store and Service status
Check the status of the Play Store and Play Services and start Google's repair tool when a problem is found with Google Play Services.
Root Checker
Check for Root and Busybox status and location
KNOX Verification
For Samsung devices, AndroIDentity checks and reports the KNOX status of the device. Neverthless, AndroIDentity works on all brands of devices, from Android 4.0 forward.
Detailed device info
Keeping up with the tradition of AndroIDentity, it's most important feature is still there: it reports back to you several important information about the device under test, that can be compared to the device's datasheet for authenticity attestation.
Over 15,200 devices recognized
AndroIDentity correctly identifies and reports on over 15,200 devices, using an internal database that is kept up to date with new market releases.
Throughout the years, AndroIDentity has helped thousands of users being aware of fake/counterfeit devices, and even, in several cases, prevented users from buying non-genuine phones.
AndroIDentity works on all Androd devices, of all brands, as long as it runs Android 4.0 and newer. It is still donationware, which gives you a few perks, like an enhanced GUI, and the satisfaction to know you're supporting such an important project.
Download it now for free from: https://play.google.com/store/apps/details?id=com.alxdroiddev.gs3identity