SuperSU and SafetyNet / Android Pay - SuperSU

This is the place to discuss anything and everything related to SuperSU and SafetyNet / Android Pay.
To clarify, I am not currently actively doing any development on having SuperSU pass SafetyNet detection, or having Android Pay work; the same way I put no effort into beating other root detection methods such as various enterprise security tools.
In case any SuperSU-rooted device passes SafetyNet, that is a bug in SafetyNet, not a feature of SuperSU.
While I may not agree with Google's stance, I'm not about to go messing with payment systems. Is it possible though? Probably yes.
This thread has been created because you guys simply cannot stop talking about this, so these posts can now go here, where I don't ever have to see them.

Will v2.50 cause Android Pay not to work in 6.0? If so, I am guessing there is no way around it?

0.0 said:
Will v2.50 cause Android Pay not to work in 6.0? If so, I am guessing there is no way around it?
Click to expand...
Click to collapse
Root is a no no with android pay and I think custom ROMs are also out at the moment
Sent from my A0001 using Tapatalk

Pure Drive GT said:
Hey, thanks for your continued support for root on Android, was just wondering, is google making it harder to achieve decent root privileges, as in they don't want rooted devices or are they just unrelatedly changing up things which forces you guys to adapt?
On another note, is there any progress on root without the modded boot? This is by no means an ETA, just wanted to know if you think it's possible or the situation looks rather dire.
Thanks again for your many efforts!
Click to expand...
Click to collapse
Well, just look at Android Pay, it will not allow one to add a credit card if it detects the device is rooted. So yeah, Google definitely wants to stop root, or at least make sure there is a strong dissuasion towards same. It's not a bad thing persae, as Google is just making the devices more secure for the masses. We 'power users' are lucky to have those such as Chainfire working so hard to get us what they can.

mdamaged said:
Well, just look at Android Pay, it will not allow one to add a credit card if it detects the device is rooted. So yeah, Google definitely wants to stop root, or at least make sure there is a strong dissuasion towards same. It's not a bad thing persae, as Google is just making the devices more secure for the masses. We 'power users' are lucky to have those such as Chainfire working so hard to get us what they can.
Click to expand...
Click to collapse
Many banking and financial apps restrict access on rooted devices; it's not just Google.
It makes sense in some ways: root access allows running things in the background to either circumvent, monitor, or interrupt program transactions. They're being paranoid, and I don't blame them.
I don't like the Google Pay concept (or Apple's either); like every other encryption or security system, it's destined to eventually be hacked.

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

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

shaggyskunk said:
Yet the Note 5 has been rooted for at least a couple of weeks
Click to expand...
Click to collapse
On Lollipop... And you also have to unlock your bootloader to do that, right? If yes, then you will trip the KNOX, and that mean you will loose some of your device functionality (Samsung Pay for example), without option to take it back. On the Nexus on the other hand, when you want to use Android Pay on Nexus, you can restore your phone to completely stock condition, without any trace of previously used root.
Also, all of this is completely irrelevant to carried device users, since they have a locked bootloaders.

Srandista said:
On Lollipop... And you also have to unlock your bootloader to do that, right? If yes, then you will trip the KNOX, and that mean you will loose some of your device functionality (Samsung Pay for example), without option to take it back. On the Nexus on the other hand, when you want to use Android Pay on Nexus, you can restore your phone to completely stock condition, without any trace of previously used root.
Also, all of this is completely irrelevant to carried device users, since they have a locked bootloaders.
Click to expand...
Click to collapse
I believe that it's only at&t and Verizon that locks the bootloader - And none in Canada and many other Countries.
Sent From my SM-N910W8 Running SlimRemix V5.1

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.

NYZack said:
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.
Click to expand...
Click to collapse
Root doesn't have to be enabled for pay to fail. Any time the system partition is modified pay will not work. There was an xda news article on it. A quick Google search involving Android pay and root should find it.

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

Ch3vr0n said:
@Chainfire if you actually are able to pull off fully working stable root WITHOUT modifying the /system does that mean you MIGHT have opened the door into having root AND still being able to get OTA's?
Click to expand...
Click to collapse
osm0sis said:
Yup, all you'd need to do is reflash stock kernel to pass the boot partition EMMC check, or, we could automate restoring the previous stock kernel, flashing the OTA and then injecting the new stock kernel with root after flashing (à la AnyKernel2 or MultiROM). So many exciting possibilities there where custom recoveries are concerned.
Click to expand...
Click to collapse
Chainfire said:
Honestly it's not so different from using FlashFire to flash re-flash system, then OTA, then re-root. But it is easier, yes.
Click to expand...
Click to collapse
This is indeed exciting. However, I noticed that @Chainfire posted this downside on Google+ :
Andrew Morykin 12:24
This should retain Android Pay, right?
Click to expand...
Click to collapse
Chainfire 12:58
+Andrew Morykin if it does, then it's by accident and not by design, and Android Pay will be updated to block it.
Click to expand...
Click to collapse
https://plus.google.com/+Chainfire/posts/aJbqUZ8PEP4
also, I was confused by this:
Chainfire said:
- I have not tested with encrypted devices
Click to expand...
Click to collapse
http://forum.xda-developers.com/showpost.php?p=63197935
Aren't
Nexus 6P / angler
angler-mdb08k-boot-systemless.zip
Click to expand...
Click to collapse
and
Nexus 5X / bullhead
bullhead-mdb08i-boot-systemless.zip
Click to expand...
Click to collapse
encrypted out of the box?

dabotsonline said:
This is indeed exciting. However, I noticed that @Chainfire posted this downside on Google+ :
Click to expand...
Click to collapse
How is that a downside?
It's exactly the same with every other form of root you will ever see. They don't want to support Android Pay (and some other stuff) on rooted devices. If we find a root that allows it, they will update their system to detect and block it. That cat and mouse game will not end as long as Google doesn't want Android Pay on rooted devices.
Maybe someone will make apps/modules that help circumvent this, but it certainly will not be me.
also, I was confused by this:
Aren't
Nexus 6P / angler
and
Nexus 5X / bullhead
encrypted out of the box?
Click to expand...
Click to collapse
Still can't test what I don't have.

russlowe73 said:
Factory images
Click to expand...
Click to collapse
So basically I have to go back to 100% stock using ADB, and then flash the new SuperSU stuff with any custom ROM? If so, what are the benefits of this other than getting Android Pay while rooted?

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

efrant said:
Starting with Android 5.0, OTA updates are now block-based rather than file-based, so any modification to the system partition will cause the OTA to fail, even mounting the system partition as r/w.
Click to expand...
Click to collapse
Just to add to this, it's a whole-partition /system patch OTA if the device launched with Lollipop or later, anything that launched with KitKat is still receiving the old file-based patch OTAs. Modifying Settings.apk would likely trip either method for a lot of OTAs though, since it's a pretty central component.
galaxyuserx said:
I use Galaxy s6 G9200 HK with Kernel compiled by me, but i have problem with root 5.1.1 and i think in future too 6.0
These root method is integrated in kernel source or i can integrate with those "boot.img systemless" my selfcompiled kernel?(repack boot.img with kernel compiled by me)
Is possible to work this new root method to android 5.1.1?
I have problem with gain root when i use kernel compiled by me ( STOCK kernel have too this problem BOOTLOOPs and FREEZEs on boot system) and i don't know how slove it :/
I found on chineese forums root integrated in boot.img it working good and isn't comunicat "KERNEL is not SEandroid enforced" but when i try integrate my kernel with this boot.img error with boot system :/
Click to expand...
Click to collapse
Yup, it's all ramdisk changes so should be workable on any version of Android. Chainfire left instructions outlining the ramdisk changes in the WIP thread if you want to give it a try.
phishfi said:
I'm not sure if anyone has specifically mentioned this, but Android Pay still works with this form of on the Nexus 6!!
Click to expand...
Click to collapse
Yup, seems to be the case with most banking and root-detecting apps... for now.

Can someone with the non-system SU use this app: https://play.google.com/store/apps/details?id=com.cigital.safetynetplayground and post the results?
This app is supposed to do the SafetyNet checks cleanly, the same way Android Pay does them.
Would be interesting to see if it succeeds on devices with this new supersu version.

secguy said:
Can someone with the non-system SU use this app: https://play.google.com/store/apps/details?id=com.cigital.safetynetplayground and post the results?
This app is supposed to do the SafetyNet checks cleanly, the same way Android Pay does them.
Would be interesting to see if it succeeds on devices with this new supersu version.
Click to expand...
Click to collapse
Just ran it and it passed.

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

Related

How long till we may see the 6 rooted?

I've never owned a Nexus/Google phone, how long would you all guess it's going to take to root the Nexus 6?
Thanks! :fingers-crossed:
Kidding I hope
Pyros2008 said:
I've never owned a Nexus/Google phone, how long would you all guess it's going to take to root the Nexus 6?
Thanks! :fingers-crossed:
Click to expand...
Click to collapse
Before you even get it
Sent from my A0001 using XDA Free mobile app
Nope, the first time I rooted was a month ago, my Note 3. I take it the device can be rooted off the bat.. or there something else I am missing?
Give Chainfire a couple hours with the phone
Pretty sure the process will be similar to other Nexus devices... Fastboot oem unlock, etc, etc.
http://phandroid.com/2014/11/17/nexus-6-lollipop-root/
all hail king chainfire?
kgeissler said:
http://phandroid.com/2014/11/17/nexus-6-lollipop-root/
Click to expand...
Click to collapse
That has 6 nexus devices with root. Bit not the nexus 6.
I would make sure to wait until Google releases the factory image before rooting just in case something goes wrong
I'm pretty sure that the factory images have to be out as he has to create a modified kernel for the N6 for superuser to work on 5.0.
lordgodgeneral said:
I'm pretty sure that the factory images have to be out as he has to create a modified kernel for the N6 for superuser to work on 5.0.
Click to expand...
Click to collapse
I think he just patches the existing kernel so don't think he would need images. Think being the key word there as I don't know for sure how it works exactly.
You don't need a developer to root a nexus. Boot into the bootloader, connect to your computer, run: fastboot oem unlock, then install the recovery of your choice via fastboot (fastboot flash recovery blahxxx.img), then just flash whatever superuser you want (e.g. SuperSU)
Sent from my XT1053 using Tapatalk
bongostl said:
You don't need a developer to root a nexus. Boot into the bootloader, connect to your computer, run: fastboot oem unlock, then install the recovery of your choice via fastboot (fastboot flash recovery blahxxx.img), then just flash whatever superuser you want (e.g. SuperSU)
Sent from my XT1053 using Tapatalk
Click to expand...
Click to collapse
Sorry but this is no longer accurate. First off, there are no custom recoveries yet. Second, lollipop requires additional work arounds for root other than just flashing superuser.
akellar said:
Sorry but this is no longer accurate. First off, there are no custom recoveries yet. Second, lollipop requires additional work arounds for root other than just flashing superuser.
Click to expand...
Click to collapse
Hm? I'm running oneplus one with root on lollipop. All I had to do was just flash supersu in recovery.
Hopefully we can see a twrp on nexus 6 soon.
Sent from my A0001 using Tapatalk
zephiK said:
Hm? I'm running oneplus one with root on lollipop. All I had to do was just flash supersu in recovery.
Hopefully we can see a twrp on nexus 6 soon.
Sent from my A0001 using Tapatalk
Click to expand...
Click to collapse
It's likely not a complete build with the SELinux improvements that google made to the kernel. You need to modify the kernel on lollipop to have root so your one plus probably just has a ROM not a full image of the lollipop on it. Also as stated earlier you can't root anything without the factory image posted by google for the nexus. Then the developers can have at it. Until your happens we are just left waiting.
Pilz said:
It's likely not a complete build with the SELinux improvements that google made to the kernel. You need to modify the kernel on lollipop to have root so your one plus probably just has a ROM not a full image of the lollipop on it. Also as stated earlier you can't root anything without the factory image posted by google for the nexus. Then the developers can have at it. Until your happens we are just left waiting.
Click to expand...
Click to collapse
SELinux is currently permissive and yep its built off CM12 sources. But to answer OP's question, probably won't take too long but no ETAs.
zephiK said:
SELinux is currently permissive and yep its built off CM12 sources. But to answer OP's question, probably won't take too long but no ETAs.
Click to expand...
Click to collapse
Then that's why you can flash it in recovery. Normally you wouldn't be able to if it wasn't changed.
Chainfire said:
On LPX13D, SELinux, and root
As promised, here are some more details about the current situation.
Why it breaks
Google has really put some effort into better securing Android, and we've seen a lot of SELinux related commits to the AOSP tree over the past months. There is some disconnect between the AOSP tree and actual L preview builds, some things from AOSP are not in the L preview build, and vice versa. Ultimately, it's a pretty good bet these things will mostly align, though.
On most devices and firmwares, SuperSU's daemon is started by the install-recovery.sh service script that runs at system boot time, as user root with the init context. This is what the daemon needs to function.
Recently, they've started requiring all started services to run in their own SELinux context, instead of init. Developers and security guys following AOSP have known this was coming; AOSP builds have been logging complaints about this specific service not having its own context for a while now.
Now this script runs as root, but as the install_recovery context, which breaks SuperSU's operation, as it is a very restrictive context.
In the last AOSP build I have tried (a few weeks old), there were a fair number of other holes that we could use to launch the daemon. At first glance(!), it seems those have all been closed. An impressive feat by the guys working on this, if it proves true.
How to fix it
To fix root, all that really had to be done was ensure the daemon's startup script is run at boot as the root user with the init context.
There are multiple ways to do this, but unfortunately for now it seems that it does require a modified kernel package (changing the ramdisk).
In the modified kernel packages I've posted for the Nexus 5 and Nexus 7, the daemon's startup is fixed by commenting out the line in init.rc that forces the install-recovery.sh script to run as the install_recovery context, so now it runs as init again, and all is well.
Repercussions
As stated above, it seems for now that modifications to the kernel package are required to have root, we cannot attain it with only modifications to the system partition.
Combine that with a locked bootloader (and optionally dm-verity) and a device becomes nigh unrootable - exactly as intended by the security guys.
Exploit-based roots are already harder to do thanks to SELinux, and now because of the kernel requirements for persistent root, these exploits will need to be run at every boot. Exploits that make the system unstable (as many do) are thus out as well.
Of course, this is all dependent on OEMs implementing everything exactly right. If a certain OEM doesn't protect one of their services correctly, then we can leverage that to launch the daemon without kernel modifications. While I'm fairly certain this will be the case for a bunch of devices and firmwares, especially the earlier L firmwares, this is not something you should expect or base decisions on. It is now thus more important than ever to buy unlocked devices if you want root.
It might also mean that every firmware update will require re-rooting, and OTA survival mode will be broken. For many (but far from all) devices we can probably automate patching the kernel package right in the SuperSU installer ZIP. We can try to keep it relatively easy, but updating stock firmwares while maintaining root is probably not going to work as easy and fast as it did until now.
Apps need updates
Unsurprisingly, with a new major Android release, apps will need updates. None more so than apps that go beyond the Android API, as root apps do, but even some non-root apps will be affected by the security changes.
As one example, someone posted in the SuperSU thread of a kernel flashing app that didn't work. From the logcat you could see that it was looking for partitions in /dev/block from its normal non-root user and non-init context. That used to be possible, but now it is restricted: normal apps no longer have read access there.
The solution for that app is actually quite simple: list the /dev/block contents using root instead. But simple solution or not, the app will still need to be updated.
By far most root apps should be updateable for L without too much issue. There are indeed exceptions that will need some special care, but those are rare.
Permissive vs enforcing
The kernel packages I posted for the Nexus 5 and 7 LPX13D firmware keep SELinux mostly set to enforcing. I say mostly, because SuperSU actually switches a small part of the system to permissive, so apps calling su can do most things without much interference. The details on this are lengthy (yes, your apps will be able to modify policies as well if needed, which should be rare), and I will document these for other developers after L retail release, assuming it will all still work at that time.
Alternatively, you can set the whole system to permissive or otherwise disable SELinux. There are other kernel packages released that indeed do this. The advantage here is that it instantly fixes some apps' issues, as the SELinux based restrictions have all gone the way of the dodo. The disadvantage here is that you've just shut down a major part of the security system of the device.
Some would argue that a device with an unlocked bootloader, root, encrypted modem firmwares of which nobody really knows what they're doing, etc, is inherently insecure, and thus disabling SELinux doesn't make much difference.
I personally disagree with this. While I do agree that these things weaken security down from the ideal level, I would still not disable more security features than I absolutely need to. Just because you cannot eliminate all attack vectors, is no reason to just completely give up on defending against them.
It is of course your own choice if you want to run a permissive system or not. I will strive to keep everything working in enforcing mode though, and I hope other root app developers will do the same - as stated earlier in the post, I believe this is still possible.
(everything in this post is subject to change for retail L release, obviously)
Click to expand...
Click to collapse
https://plus.google.com/+Chainfire/posts/VxjfYJnZAXP
http://www.xda-developers.com/android/supersu-beta-2-23-lollipop/
Pilz said:
Then that's why you can flash it in recovery. Normally you wouldn't be able to if it wasn't changed.
Click to expand...
Click to collapse
Good news everyone, starting one of the upcoming SuperSU updates, modified kernels will no longer be needed for root on Android 5.0 ... !
Click to expand...
Click to collapse
https://twitter.com/ChainfireXDA/status/535253476021116928

[Q] Help unrooting Nexus 6

What works with the nexus 6? Any links or videos that you guys know of that work on mac? Device is on my company line and already got notified that i need it to be stock.
thanks in advance, guys.
huxington said:
What works with the nexus 6? Any links or videos that you guys know of that work on mac? Device is on my company line and already got notified that i need it to be stock.
thanks in advance, guys.
Click to expand...
Click to collapse
Do you have any company apps installed?
---
You could try the full unroot option in SuperSU, or go through the process of flashing the factory images available here: https://developers.google.com/android/nexus/images
Note: Flashing factory images will wipe the device
zylstrajs said:
Do you have any company apps installed?
---
You could try the full unroot option in SuperSU, or go through the process of flashing the factory images available here:
Note: Flashing factory images will wipe the device
Click to expand...
Click to collapse
I have exchange set up, and the first notifications were geared towards that. Third notification was "rooted device on network".
huxington said:
I have exchange set up, and the first notifications were geared towards that. Third notification was "rooted device on network".
Click to expand...
Click to collapse
I'm not aware of any root cloak apps currently compatible with lollipop, I'd follow company policy until one is released.
zylstrajs said:
I'm not aware of any root cloak apps currently compatible with lollipop, I'd follow company policy until one is released.
Click to expand...
Click to collapse
well, supersu worked, and root checker backed that up.
That should be enough for the company. Right?
huxington said:
well, supersu worked, and root checker backed that up.
That should be enough for the company. Right?
Click to expand...
Click to collapse
Can't really say. You'd have to check internally to follow up.
If you are going to stay unrooted, might as well flash factory images. That way, you can get OTA without any issues of restoring stock images first
There are a couple toolkits that make it effortless.
http://forum.xda-developers.com/nexus-6/development/toolkit-wugs-nexus-root-toolkit-v1-9-8-t2947452
Also very easy to flash it yourself as others have said, I have oem unlocked, locked rooted unrooted by flashing about 6 or 7 times now. Have also used wugs toolkit above, and works really well, just a little slower than manual.

Stock recovery and upgrading Lollipop with future OTAs after rooting

Hello everyone,
I'm back to a nexus 6 after a very short stint with a 6+.
A little background for my questions: This is the very first time that I rooted a phone. I'm rooting to only install these 3 apps:
adaway
titanium backup
greenify
I do not plan on using any custom ROMs or kernels.
I see from all the guides and tutorials that people also create a custom recovery whenever they root. I haven't done that yet and wasn't sure if I had to. I would like to maintain the stock recovery that I have currently so that I can go back to stock if I unRoot. My questions are:
1. Am I wrong in thinking that I can still use the stock recovery if I unRoot?
2. When a new OTA comes out and I flash it (since I'm rooted an no longer can install them automatically), will that also upgrade my still stock recovery properly?
3. Following up on the previous question, when I upgrade manually because I'm rooted, would that be a fresh install where I have to go in and configure things the way I like them again (system settings, apps and their settings, root the phone again, etc)?
Thanks in advance!
LordGrahf said:
Hello everyone,
I'm back to a nexus 6 after a very short stint with a 6+.
A little background for my questions: This is the very first time that I rooted a phone. I'm rooting to only install these 3 apps:
adaway
titanium backup
greenify
I do not plan on using any custom ROMs or kernels.
I see from all the guides and tutorials that people also create a custom recovery whenever they root. I haven't done that yet and wasn't sure if I had to. I would like to maintain the stock recovery that I have currently so that I can go back to stock if I unRoot. My questions are:
1. Am I wrong in thinking that I can still use the stock recovery if I unRoot?
2. When a new OTA comes out and I flash it (since I'm rooted an no longer can install them automatically), will that also upgrade my still stock recovery properly?
3. Following up on the previous question, when I upgrade manually because I'm rooted, would that be a fresh install where I have to go in and configure things the way I like them again (system settings, apps and their settings, root the phone again, etc)?
Thanks in advance!
Click to expand...
Click to collapse
1. No, you're not wrong. Recovery will stay stock and can be used normally
2. You can't simply flash the new OTA. This will not work manually nor automatically.
3. All you need to do is not flash the user data image and you will not loose your data, settings etc. You will loose root however. See bellow.
Google posts android stock images for each device typically before OTA hits your phone. That's what you want to grab and use for the update. Just make sure you don't run the automatic scripts that come with those images because you need to avoid flashing user data image.
OTA zip file does you no good unless you get your system back to unmodified stock.
Thank you sir!
obsanity said:
1. No, you're not wrong. Recovery will stay stock and can be used normally
2. You can't simply flash the new OTA. This will not work manually nor automatically.
3. All you need to do is not flash the user data image and you will not loose your data, settings etc. You will loose root however. See bellow.
Google posts android stock images for each device typically before OTA hits your phone. That's what you want to grab and use for the update. Just make sure you don't run the automatic scripts that come with those images because you need to avoid flashing user data image.
OTA zip file does you no good unless you get your system back to unmodified stock.
Click to expand...
Click to collapse
Based on the OP, it sounds like he has only rooted. Thus, the OTA will work fine. No need to flash image files.
Edit: I see that at least one other member has stated that an unroot still did not allow OTAs to function. That's a bit strange and unique. Not sure what root is modifying to prevent the OTA.
I'm kinda curious myself. I had no idea root killed OTA's. Maybe I wouldn't have done that if I knew that. I'm very new to the Nexus device. It's my 1st. I unlocked the bootloader and rooted already.
Sent from Mark's Nexus 6
crowbarman said:
Edit: I see that at least one other member has stated that an unroot still did not allow OTAs to function. That's a bit strange and unique. Not sure what root is modifying to prevent the OTA.
Click to expand...
Click to collapse
This is pretty scary. So you can unroot and GI back to stock and still can't update in anyway?
I have always side-loaded OTAs, I have never flashed anything.
After installing an OTA, on the next reboot, Android takes some time to optimize all your apps. Does this also happen after flashing a new system image? Thanks!
LordGrahf said:
This is pretty scary. So you can unroot and GI back to stock and still can't update in anyway?
Click to expand...
Click to collapse
not sure what you mean by GI, but according to some others, after uninstalling root via SuperSU an OTA will still not install. This should not be the case unless the boot or recovery images are modified. Easily fixed by following the procedures above to fastboot the stock images on your phone.
kjnangre said:
I have always side-loaded OTAs, I have never flashed anything.
After installing an OTA, on the next reboot, Android takes some time to optimize all your apps. Does this also happen after flashing a new system image? Thanks!
Click to expand...
Click to collapse
Yes, it behaves exactly the same.
crowbarman said:
Based on the OP, it sounds like he has only rooted. Thus, the OTA will work fine. No need to flash image files.
Edit: I see that at least one other member has stated that an unroot still did not allow OTAs to function. That's a bit strange and unique. Not sure what root is modifying to prevent the OTA.
Click to expand...
Click to collapse
Root on Lollipop is not what it used to be. There are files that need to be modified in order to allow root. That's why this time OTA will fail if you are rooted.
Un-rooting however, will allow OTA as long as it is done properly and all traces are covered up and returned to stock. If it does fail after you have un-rooted, go back to the developer of that un-root method and let the know they missed something.
Here is the best way to un-root. Flash all of the old stock images besides user data image.
obsanity said:
Root on Lollipop is not what it used to be. There are files that need to be modified in order to allow root. That's why this time OTA will fail if you are rooted.
Un-rooting however, will allow OTA as long as it is done properly and all traces are covered up and returned to stock. If it does fail after you have un-rooted, go back to the developer of that un-root method and let the know they missed something.
Here is the best way to un-root. Flash all of the old stock images besides user data image.
Click to expand...
Click to collapse
That makes sense. Is there a manual root procedure or list of required modifications for root out there? I did some precursors searches but Came up empty. Can't tell what's missing in SuperSU unroot without those details.
crowbarman said:
That makes sense. Is there a manual root procedure or list of required modifications for root out there? I did some precursors searches but Came up empty. Can't tell what's missing in SuperSU unroot without those details.
Click to expand...
Click to collapse
Explanation from Chainfire:
https://plus.google.com/113517319477420052449/posts/S5zoKTzKUW1
obsanity said:
Explanation from Chainfire:
https://plus.google.com/113517319477420052449/posts/S5zoKTzKUW1
Click to expand...
Click to collapse
Thanks for this. A good read, but I'm surprised nobody has demanded more details than 'patched the policies in SELinux'. Not that I don't trust Chain fire (I do) , but who really knows what has been done to our phones?
crowbarman said:
Thanks for this. A good read, but I'm surprised nobody has demanded more details than 'patched the policies in SELinux'. Not that I don't trust Chain fire (I do) , but who really knows what has been done to our phones?
Click to expand...
Click to collapse
That's the problem with Chainfire's work... he does not release source.
Again, best un-root method is to flash original images less user data.
obsanity said:
That's the problem with Chainfire's work... he does not release source.
Again, best un-root method is to flash original images less user data.
Click to expand...
Click to collapse
Thanks for sharing this info. Its a bit concerning tbh. Is there a cleaner way to root other than using superSU?
LordGrahf said:
Thanks for sharing this info. Its a bit concerning tbh. Is there a cleaner way to root other than using superSU?
Click to expand...
Click to collapse
I'm afraid not but Chainfire's is probably the cleanest possible. Koush was the one with an open source solution but he hasn't updated his to 5.0 yet.
obsanity said:
I'm afraid not but Chainfire's is probably the cleanest possible. Koush was the one with an open source solution but he hasn't updated his to 5.0 yet.
Click to expand...
Click to collapse
There is an argument that publishing the method would allow Google to close it that much quicker, I suppose.
crowbarman said:
Thanks for this. A good read, but I'm surprised nobody has demanded more details than 'patched the policies in SELinux'. Not that I don't trust Chain fire (I do) , but who really knows what has been done to our phones?
Click to expand...
Click to collapse
The base changes and reasoning for those changes are actually documented on my website. Specific policy adjustments are present in plain text in the supolicy executable, as any hex editor will show you. Those who really wanted to know rather than whine about OSS, know.
By far most policy adjustments just drop audit log output for contexts that are already permissive, though.
All that information is still completely useless unless you understand SELinux in detail and how it's implemented on Android, though.
I assume that the encryption doesn't get in the way of being able to flash the images?
When I went from 5.0 to 5.0.1 on my old Nexus 5 all I did was flash the two new 5.0.1 images I extracted from the full factory image, then re-rooted. This is far cleaner than reverting back to the previous image then doing an OTA. I've not had to update my N6 yet so I don't know if my method will work still, but I hope it does.
Chainfire said:
The base changes and reasoning for those changes are actually documented on my website. Specific policy adjustments are present in plain text in the supolicy executable, as any hex editor will show you. Those who really wanted to know rather than whine about OSS, know.
By far most policy adjustments just drop audit log output for contexts that are already permissive, though.
All that information is still completely useless unless you understand SELinux in detail and how it's implemented on Android, though.
Click to expand...
Click to collapse
Thanks for the additional information.
I did spend a fair amount of time reading your documentation but failed to utilize a hex editor. I am not 'whining' about the lack of open source, rather, simply mildly surprised, but your website aptly describes the challenges with 5.0. Many are used to various root methods being available.
Your solution is fine with me.. I love your work.
Edit: I thought I'd add that the discussion has devolved from the OP, which was whether an OTA can be applied after uninstalling root. The answer was no, due to the unknowns about what still might be modified following the uninstall via SuperSU.

Root and Android Pay

I really want to root my Droid Turbo, but I use Android Pay pretty frequently. I read once the phone is rooted, Android Pay will no longer work. I've read a few different things on the site and I'm just looking for some clarity. What exactly causes it to stop working? Is it rooting, unlocking the bootloader, both?
Since you have to unlock the bootloader for the Turbo root, and it sounds like once I unlock it there's no way to safely re-lock it, if I go through with the root, there's really no going back to Android Pay ever again because unlocking the bootloader.
Is there no shot of this working if I root my Droid Turbo? If this has explicitly been discussed and defined, I apologize, but I couldn't find an definitive answer to it.
hyphy88 said:
I really want to root my Droid Turbo, but I use Android Pay pretty frequently. I read once the phone is rooted, Android Pay will no longer work. I've read a few different things on the site and I'm just looking for some clarity. What exactly causes it to stop working? Is it rooting, unlocking the bootloader, both?
Since you have to unlock the bootloader for the Turbo root, and it sounds like once I unlock it there's no way to safely re-lock it, if I go through with the root, there's really no going back to Android Pay ever again because unlocking the bootloader.
Is there no shot of this working if I root my Droid Turbo? If this has explicitly been discussed and defined, I apologize, but I couldn't find an definitive answer to it.
Click to expand...
Click to collapse
Getting Android Pay to work on a modified device is a constant cat and mouse game. A few workarounds were found and promptly patched by Google in Android Pay/Google Play Services/ Google App updates. If you use it frequently, unlocking is a bad idea. Android Pay might still work on an unlocked device, but any change that you make to any system files will cause it to not work, so there's no point in unlocking.
Even if you managed to root without unlocking (via moforoot or through the terrible kingroot method), you would break Android Pay because root is one of the first things that it looks for, and none of the apps/xposed modules designed to fool it are successful at doing so.
TheSt33v said:
Getting Android Pay to work on a modified device is a constant cat and mouse game. A few workarounds were found and promptly patched by Google in Android Pay/Google Play Services/ Google App updates. If you use it frequently, unlocking is a bad idea. Android Pay might still work on an unlocked device, but any change that you make to any system files will cause it to not work, so there's no point in unlocking.
Even if you managed to root without unlocking (via moforoot or through the terrible kingroot method), you would break Android Pay because root is one of the first things that it looks for, and none of the apps/xposed modules designed to fool it are successful at doing so.
Click to expand...
Click to collapse
Thank you, I rooted, it doesn't work. Now I'm free to flash custom roms and make modifications without the worry of breaking Android Pay. Whatever, small loss to gain so much. Thanks again for your reply.
TheSt33v said:
...any change that you make to any system files will cause it to not work, so there's no point in unlocking.
Click to expand...
Click to collapse
I have an unlocked bootloader, TWRP recovery, and even flashed an emoji mod and the volume boost mods and haven't lost Android Pay.
Just earlier today, I used Sunshine for temp root and used AdAway to modify the hosts file and block ads. Once I rebooted (to disable the Sunshine temp root), Android Pay worked just fine.
Sent from my XT1254 using XDA-Developers mobile app
syphix said:
I have an unlocked bootloader, TWRP recovery, and even flashed an emoji mod and the volume boost mods and haven't lost Android Pay.
Just earlier today, I used Sunshine for temp root and used AdAway to modify the hosts file and block ads. Once I rebooted (to disable the Sunshine temp root), Android Pay worked just fine.
Sent from my XT1254 using XDA-Developers mobile app
Click to expand...
Click to collapse
Makes sense. You didn't add any additional files to the system partition. I think as long as that's the case, Android Pay will work.
syphix said:
I have an unlocked bootloader, TWRP recovery, and even flashed an emoji mod and the volume boost mods and haven't lost Android Pay.
Just earlier today, I used Sunshine for temp root and used AdAway to modify the hosts file and block ads. Once I rebooted (to disable the Sunshine temp root), Android Pay worked just fine.
Sent from my XT1254 using XDA-Developers mobile app
Click to expand...
Click to collapse
did you have android pay PRIOR to root/unlock? I've read somewhere that a work-around is to disable root, reboot, setup android pay, then re-establish root.
thanks...
jco23 said:
did you have android pay PRIOR to root/unlock? I've read somewhere that a work-around is to disable root, reboot, setup android pay, then re-establish root.
thanks...
Click to expand...
Click to collapse
That workaround will allow you to add cards, but paying will fail if you try to use them.
TheSt33v said:
That workaround will allow you to add cards, but paying will fail if you try to use them.
Click to expand...
Click to collapse
I think that changing the system is the only act preventing Android Pay to work properly. Neither unlocking bootloader nor rooting (as long as it is the systemless) does that. I believe that method used by GPS is just checking system hash (MD5 signature). Every system change brakes it. Safetynet test shows you authentically whether Android Pay could work or not. To date I haven't seen a single proof otherwise.
Jj
Has anyone done the systemless root for the turbo? I tried but either missed a step or it didn't work for my device
Sent from my XT1254 using XDA-Developers mobile app

Is rooting with Magisk possible?

Hey im new to Samsung phones and got an S10+ preordered. Will I be able to flash TWRP and Magisk the day I get it or will it take some time? Also is there anything special about rooting Samsung phones?
Thank you for your answers!
I would not expect for immediately. Devs need to reverse engineer/hack their way around the firmware locks to attain root and keep the device bootable. Once they do that, the devices are ours. though I cannot imagine it would be too different from the 9 series with flash counters and such not.
Edit: Typos.
F0rbidN said:
Hey im new to Samsung phones and got an S10+ preordered. Will I be able to flash TWRP and Magisk the day I get it or will it take some time? Also is there anything special about rooting Samsung phones?
Thank you for your answers!
Click to expand...
Click to collapse
If it's the US snapdragon I highly doubt it but with exynos most likely and it will trip knox just like the Note 9.
Misterxtc said:
If it's the US snapdragon I highly doubt it but with exynos most likely and it will trip knox just like the Note 9.
Click to expand...
Click to collapse
I will get the exynos version. What are the disadvantages of triggering knox? Thank you for letting me know.
zerolock said:
I would not expect for immediately. Devs need to reverse engineer/hack their way around the firmware locks to attain root and keep the device bootable. Once they do that, the devices are ours. though I cannot imagine it would be too different from the 9 series with flash counters and such not.
Edit: Typos.
Click to expand...
Click to collapse
Will I have to do a factory reset in order to root my device?
F0rbidN said:
I will get the exynos version. What are the disadvantages of triggering knox? Thank you for letting me know.
Click to expand...
Click to collapse
You will loose Samsung Pay, secure folders and banking apps probably won't work. There is more but that's all that comes to mind right now. Uninstalling root and flashing everything to stock won't fix the lost apps either, it's permanent. I think it will reset your phone too.
Root
Banking apps will work once able to flash Magisk, simply using a system-less root method will allow for work arounds such as Magisk hide etc. which will definitely allow for such apps to work. Exactly as has been seen for the past few generations of devices using Magisk! Anyway... on another note, yes bootloader will very likely be unlockable on Exynos variants allowing for TWRP and custom rom installation but highly unlikely on Snapdragon variants.
Misterxtc said:
You will loose Samsung Pay, secure folders and banking apps probably won't work. There is more but that's all that comes to mind right now. Uninstalling root and flashing everything to stock won't fix the lost apps either, it's permanent. I think it will reset your phone too.
Click to expand...
Click to collapse
Are you sure about permanent block ?!
A0_o said:
Are you sure about permanent block ?!
Click to expand...
Click to collapse
Yes because the past root methods trip knox and blow a efuse witch is not reversible. Unless a different root method is discovered this phone will be no different. As the post says above there are some workarounds but that is not a guarantee. Some apps can not be fooled.
Misterxtc said:
Yes because the past root methods trip knox and blow a efuse witch is not reversible. Unless a different root method is discovered this phone will be no different. As the post says above there are some workarounds but that is not a guarantee. Some apps can not be fooled.
Click to expand...
Click to collapse
i have read about some way to root without trip kNox but you have to dont use magisk or xposed just you got an access to system files.
Wish SuperUser root XDA god 'Chainfire' hadn't retired!
A0_o said:
i have read about some way to root without trip kNox but you have to dont use magisk or xposed just you got an access to system files.
Click to expand...
Click to collapse
Are you talking about sig. spoofing like Firegapps and stuff?
I'm waiting for anyone who has enough guts to try, all I really want is v4a.
This is the last galaxy I buy I think, prolly go one plus next time. But yea this is a waiting game. I'm waiting for someone to bribe the dev's to prenstall v4a for us in an ota update. Hey be a great April fools joke ....heh

Categories

Resources