Related
As we know google is going to pre enable the Data encryption on Android L and we already have it as an optional extra security ..
So before anyone rushes to enable it to feel more Secured . First let's learn about it ..
As this option is available in Security .
If you enable it you have to enter password/PIN(compulsory) ..
80% minimum battery + plugged in for charging is necessary .
Once the encryption starts it will take about 15 minutes to complete the process ..
Once it's complete , it will automatically reboot the phone . booting will be in 2 stages.. On first stage it will ask for password/PIN to decrypt the phone/phone storage
And then the second boot process will be the normal one ..
And now comes the warning part ..
Once you encrypt the data , you have to decrypt it on every boot and you can't disable this .. You have to factory reset the phone to remove this .
And here at XDA we flash mods and zips etc almost every day/week ..
So if you encrypt your phone and then you flash anything via bootloader ..IT WILL FORMAT EVERYTHING ..(including internal storage, basically factory reset)
So if you are an advanced user with custom rom/recovery etc i suggest you to first do a complete backup If you really want to try the data encryption .
So i hope this information be helpful for those who are unaware and don't know what can happen , and i suggest you to read about it before you enable it ..
For most of us, we already know that encryption causes issues, always. Maybe not immediately, but always at some point.
Its the new people that go "oh encryption, sounds good, must use", when they don't have any data that's actually important enough to justify the need for encryption.
Lethargy said:
For most of us, we already know that encryption causes issues, always. Maybe not immediately, but always at some point.
Its the new people that go "oh encryption, sounds good, must use", when they don't have any data that's actually important enough to justify the need for encryption.
Click to expand...
Click to collapse
That's why i created a new thread specially for those who are inexperienced .
Not everyone are born developers/pro
Everyone learns with making mistakes
And our Job is to help them at XDA .
IMO this is what XDA is for at the first place ..
I'll rely on custom ROMs as always, that certainly have it disabled by default.
I think it's insane google would try to force this on us. Shame on them. ?
How does android L handle staying unlocked in trusted areas if encryption is enabled?
Despite the warning, we will see how the encryption will work in Android L. It might not be the same process as described from Kitkat/JB of encryption.
Who know if the process of encryption will be changed in Android L, so that you don't have to do each step to encrypt/decry pt and the flashing/modding issues.
I see many bricks coming from this as well, from unknowing flashers.
inferol said:
Despite the warning, we will see how the encryption will work in Android L. It might not be the same process as described from Kitkat/JB of encryption.
Who know if the process of encryption will be changed in Android L, so that you don't have to do each step to encrypt/decry pt and the flashing/modding issues.
Click to expand...
Click to collapse
Probably they are going to change the way it works .. , because they haven't updated it since it first came out with ICS ..
The inability to use pattern lock is enough to turn me off Android encryption. All the other problems just makes it a no brainer.
May be they have overcome these issues and thus made it default....
I find no sense in making some hectic procedure as default
wow. wonder who will have access to the encryption keys.. or more likely supplied the encryption technique in the first place?
cough... nsa, feds, gchq, ect...... cough
don't believe the security services fake crying about encrytion... just a fairy story to pacify the sheep
meangreenie said:
wow. wonder who will have access to the encryption keys.. or more likely supplied the encryption technique in the first place?
cough... nsa, feds, gchq, ect...... cough
don't believe the security services fake crying about encrytion... just a fairy story to pacify the sheep
Click to expand...
Click to collapse
When NSA forced TrueCrypt to hand over their keys, they essentially and purposely updated their product to be broken to ensure no one used it. Wonder what Google would do?
Sent from my Nexus 5 using Tapatalk
Wakamatsu said:
The inability to use pattern lock is enough to turn me off Android encryption. All the other problems just makes it a no brainer.
Click to expand...
Click to collapse
You can't do it out of the box, but you can make it work fairly easy with twrp and a backup. The quick version is:
before encryption, setup your pattern lock, do a nandroid backup in twrp. Reboot, change to a PIN/password to allow encryption, perform encryption process. Boot back into twrp, it will prompt you to enter your pin/password, since it can decrypt and then function inside of the encrypted volume (and therefore restore an unencrypted backup inside of the encrypted envelope in essence). Restore your backup that has pattern unlock and reboot. It should prompt you for your strong pin/password on each initial boot, but once booted, it will use your pattern unlock. Downside is you can't change your pattern after that, so pick what you want the first time. You can change your pin/password if you want, I use EncPassChanger myself. I also use bootunlocker to relock the bootloader after I'm done, just have to make sure to unlock before flashing any updates.
I use this process on both my N5 and 2013 N7.
rootSU said:
When NSA forced TrueCrypt to hand over their keys, they essentially and purposely updated their product to be broken to ensure no one used it. Wonder what Google would do?
Sent from my Nexus 5 using Tapatalk
Click to expand...
Click to collapse
Source for this?
markassbuster said:
Source for this?
Click to expand...
Click to collapse
Action speaks louder than words sometimes all u need is to observe
markassbuster said:
Source for this?
Click to expand...
Click to collapse
They can't really openly say that buy the industry "knows".
But the opening paragraph of this page hints at it.
http://truecrypt.sourceforge.net
rootSU said:
They can't really openly say that buy the industry "knows".
But the opening paragraph of this page hints at it.
http://truecrypt.sourceforge.net
Click to expand...
Click to collapse
AH OK thanks. I thought there was some recent, concrete news about what went down.
Thing is, now what will we gotta do to still be able to flash zips with encrypted device? XD
So I recently encrypted my phone....because I read it only encrypts the data partition...so if I wanted to update my CM11 version (m9 to m10 for example) I wouldn't be able to?
I should have read into it more I guess...
edit: TWRP saved my ass. Just looked at it and it decrypts the data partition.
I encrypted my phone, but now wish I hadn't. I'm pretty sure it is the cause of some small issues I have had flashing different ROMs.
fml :crying:
I'm new to the 6 and I haven't really read too much into the whole encryption thing, so I don't know the pros/cons of having it that way, or not.
During my first boot of this thing, I started the unlock/root process, then I quickly remembered about encryption...and what the whole thing was about. Well I'm curious, are these custom ROM's built without the encryption? In the security menu of Chroma, encryption is enabled. In another ROM which specifically stated encryption was off...it was actually on.
So I'm confused.
Thanks.
Some ROMs do not force encryption. They can still be encrypted. It depends on the kernel. You will need to perform a wipe to unencrypt
stevew84 said:
I'm new to the 6 and I haven't really read too much into the whole encryption thing, so I don't know the pros/cons of having it that way, or not.
During my first boot of this thing, I started the unlock/root process, then I quickly remembered about encryption...and what the whole thing was about. Well I'm curious, are these custom ROM's built without the encryption? In the security menu of Chroma, encryption is enabled. In another ROM which specifically stated encryption was off...it was actually on.
So I'm confused.
Thanks.
Click to expand...
Click to collapse
It depends on the state of your device before you flash the ROM. If you are unencrypted prior to flashing the ROM, you will stay unencrypted. And if encrypted, you will stay encrypted. For most ROMs. Read the fine print in the OP.
cam30era said:
It depends on the state of your device before you flash the ROM. If you are unencrypted prior to flashing the ROM, you will stay unencrypted. And if encrypted, you will stay encrypted. For most ROMs. Read the fine print in the OP.
Click to expand...
Click to collapse
I've also read about long "encrypting now" screens during first boot of fresh ROM's, I've never seen those.
Encryption depends on the kernel or more accurately the fstab, so it depends what kernel is supplied with the ROM or which kernel you plan on flashing with the ROM.
There are 2 types of ROM. Stock based and AOSP based. I find it hard to believe any AOSP ROM dev would turn on force encryption, but with a stock ROM, it could be on or off - depending. Read each thread to find out.
All ROMs and kernels are encryption enabled by the way. Turning off force encryption inky prevents first boot from encrypting your data partition. You can still turn on encryption yourself in settings and if you're already encrypted, turning off force encryption will not unencrypt your data, so it will still be on. Once force encryption has been turned off, you must then format /userdata to remove encryption
stevew84 said:
I've also read about long "encrypting now" screens during first boot of fresh ROM's, I've never seen those.
Click to expand...
Click to collapse
Correct. If you are unsure of your kernel status go to Settings/Security/Encryption. If it says "Encrypt phone", then you are unencrypted.
cam30era said:
Correct. If you are unsure of your kernel status go to Settings/Security/Encryption. If it says "Encrypt phone", then you are unencrypted.
Click to expand...
Click to collapse
Ah alright, well each and every time I flash something new, I'm encrypted. I'm interested in getting rid of that, but not sure exactly how to do it.
stevew84 said:
Ah alright, well each and every time I flash something new, I'm encrypted. I'm interested in getting rid of that, but not sure exactly how to do it.
Click to expand...
Click to collapse
It says in my post
Encryption will stay on unless you completely wipe the device and have a kernel installed that doesn't force you to encrypt. So you'll never see an option for decrypting your device. This comes with a huge warning that ANYTHING on the internal storage will be lost, that goes for the ROM and your files, including your ROM zip files for flashing. If you want to decrypt the device I suggest you first practice by flashing a ROM that you copy into your phone while in recovery so you know you can do it.
Guide: http://forum.xda-developers.com/nexus-6/development/disable-forced-encryption-gain-root-t2946715
This will get you to a clean slate, make sure you test MTP (file transfer over usb from computer) in recovery and verify that you can move files over to your device in recovery. You should already have a custom recovery installed such as TWRP. If you are considering disabling make sure you know exactly what is going on first, its not as straight forward as it seems. Goodluck
stevew84 said:
Ah alright, well each and every time I flash something new, I'm encrypted. I'm interested in getting rid of that, but not sure exactly how to do it.
Click to expand...
Click to collapse
If you are on stock, rooted, or a non-CM12 based ROM, one way is to go here > http://forum.xda-developers.com/nexus-6/development/disable-forced-encryption-gain-root-t2946715
Remember, after flashing the boot.img, you need to "fastboot format userdata" to unencrypt. This will wipe your SDcard.
rootSU said:
It says in my post
Click to expand...
Click to collapse
Sorry, I didn't see you posted.
Right now with Chroma + Vindicator kernel...Encryption states Enabled in the security menu.
stevew84 said:
Sorry, I didn't see you posted.
Right now with Chroma + Vindicator kernel...Encryption states Enabled in the security menu.
Click to expand...
Click to collapse
Because you were already encrypted.
stevew84 said:
I don't know the pros/cons of having it that way, or not.
Click to expand...
Click to collapse
Pros for encryption;
- security. This is pretty obvious, if somebody hostile gets their hands on your phone, your data will not be obtained by them.
Cons;
- performance and battery life. There is indication in AOSP that google *intends* to activate hardware crypto, but as of yet, have not. That means that the crypto function is done on your main CPU, which is (a) not as fast as the hwcrypto block, and (b) takes up valuable CPU cycles from other software that is running, and (c) anything that uses CPU heavily will consume battery.
Another con with encryption that I have (which I admit is extremely unlikely - but has happened in the past) is that files that are backed up off the device may not get decrypted correctly, leaving them corrupt. That is my main hate of encryption. That and the fact that I cannot automate my TWRP backups
rootSU said:
Another con with encryption that I have (which I admit is extremely unlikely - but has happened in the past) is that files that are backed up off the device may not get decrypted correctly, leaving them corrupt. That is my main hate of encryption. That and the fact that I cannot automate my TWRP backups
Click to expand...
Click to collapse
That isn't a con of encryption. That's a con of using broken software to perform your backup.
doitright said:
That isn't a con of encryption. That's a con of using broken software to perform your backup.
Click to expand...
Click to collapse
The con of encrypting data is that it may not always decrypt-able. Regardless of the root cause being Android, Windows, Linux or "broken software". If doing something to your data leads to it being useless via whatever means, then there is a negative effect of doing that something to your data
I finally decided to take advantage of having a Nexus 6 and flash a factory image. I downloaded Wug's NRT and commenced to flashing. I also wanted to disable forced encryption and Wug's NRT has an option to apply this during the flashing process. It appears to go through the process but when the phone boots back up, I'm still on the same build as when I started. What am I doing wrong?
Phone - Nexus 6, bought directly from Motorola
Carrier - Verizon
Toolkit - Wug's NRT 2.0.5
Build - LMY47D
Android version - 5.1
Goal - flash LMY47Z to get to 5.1.1 and no forced encryption
NRT says it can talk to my phone in all modes, has all the files it needs, etc. I've got to be missing something; just don't know what I'm doing wrong. Thanks in advance!
Lucky Armpit said:
I finally decided to take advantage of having a Nexus 6 and flash a factory image. I downloaded Wug's NRT and commenced to flashing. I also wanted to disable forced encryption and Wug's NRT has an option to apply this during the flashing process. It appears to go through the process but when the phone boots back up, I'm still on the same build as when I started. What am I doing wrong?
Phone - Nexus 6, bought directly from Motorola
Carrier - Verizon
Toolkit - Wug's NRT 2.0.5
Build - LMY47D
Android version - 5.1
Goal - flash LMY47Z to get to 5.1.1 and no forced encryption
NRT says it can talk to my phone in all modes, has all the files it needs, etc. I've got to be missing something; just don't know what I'm doing wrong. Thanks in advance!
Click to expand...
Click to collapse
what are you doing wrong? well thats an easy one, youre a first time flasher, what are you doing using a root toolkit? did you learn anything from it? did you learn how to flash the factory image the right way? no. that's your issue. it takes less than 5 minutes to flash a factory img the right way.
if you know how to do things properly, then its alright to use a toolkit. if you have no idea jow to do things right, a toolkit wont show you how.
Does NRT tell you it was successful? Usually there are quite a lot of messages...
To get a grip on what simms22's taking about, check out the faq thread:
http://forum.xda-developers.com/nexus-6/help/nexus-6-frequently-questions-t3106029
Didgeridoohan said:
Does NRT tell you it was successful? Usually there are quite a lot of messages...
To get a grip on what simms22's taking about, check out the faq thread:
http://forum.xda-developers.com/nexus-6/help/nexus-6-frequently-questions-t3106029
Click to expand...
Click to collapse
right, thats what i was trying to say
Thanks for the replies, guys. I was able to figure it out. I didn't have the bootloader unlocked. I know, noob mistake. I've got LMY47Z and no encryption now. Sure hope this fixes the jank I've been experiencing, which was the whole purpose of this little experiment.
But to answer your question, I used a tool because it automates the commands and makes the experience easier. Yes, I ran into trouble at first but I figured it out. In my defense, I did read that thread before posting that recommended issuing commands rather than using a tool. I was already vested in NRT so I figured I'd see it through.
Guess the joke is on me. Not only did my efforts NOT fix the lag and stutter I'm experiencing, but the internal storage was reported at 32GB rather than 64GB. So I ran through the tool again but this time I chose the "post-flash factory reset" option which wipes the user cache. The storage is now correct, I'm on LMY47Z, and no encryption. I only installed the Google apps and still had the lag.
This is a replacement device from Motorola (first one developed battery issues). I might do that again. At least I figured out what was wrong with the flashing process. Thanks again everyone!
Lucky Armpit said:
Guess the joke is on me. Not only did my efforts NOT fix the lag and stutter I'm experiencing, but the internal storage was reported at 32GB rather than 64GB. So I ran through the tool again but this time I chose the "post-flash factory reset" option which wipes the user cache. The storage is now correct, I'm on LMY47Z, and no encryption. I only installed the Google apps and still had the lag.
This is a replacement device from Motorola (first one developed battery issues). I might do that again. At least I figured out what was wrong with the flashing process. Thanks again everyone!
Click to expand...
Click to collapse
personally, the way that google sets up the cpu makes me unhappy. it does lag a bit at times. what i always do, and have done with every nexus, is unlock the bootloader, flash a custom recovery, and supersu. then when i boot up, i adjust the cpu my own way. only then does any remnant of lag disappear. i set up my cpu to have all cores online all the time(as of 5.1, google did this as well), i disable mpdecision(hate that google sh*t), and i use ondemand/dwadline
Lucky Armpit said:
Guess the joke is on me. Not only did my efforts NOT fix the lag and stutter I'm experiencing, but the internal storage was reported at 32GB rather than 64GB. So I ran through the tool again but this time I chose the "post-flash factory reset" option which wipes the user cache. The storage is now correct, I'm on LMY47Z, and no encryption. I only installed the Google apps and still had the lag.
This is a replacement device from Motorola (first one developed battery issues). I might do that again. At least I figured out what was wrong with the flashing process. Thanks again everyone!
Click to expand...
Click to collapse
To fix your storage issue, either factory reset or fastboot format userdata.
Evolution_Tech said:
To fix your storage issue, either factory reset or fastboot format userdata.
Click to expand...
Click to collapse
or just format the cache.
simms22 said:
personally, the way that google sets up the cpu makes me unhappy. it does lag a bit at times. what i always do, and have done with every nexus, is unlock the bootloader, flash a custom recovery, and supersu. then when i boot up, i adjust the cpu my own way. only then does any remnant of lag disappear. i set up my cpu to have all cores online all the time(as of 5.1, google did this as well), i disable mpdecision(hate that google sh*t), and i use ondemand/dwadline
Click to expand...
Click to collapse
Well, the joke's on me x 2, actually. There's all around UI lag (which isn't terrible, but it seems that it's worse than my original Nexus 6), with the biggest hesitation in the Messenger app. Reading the reviews of Messenger shows that I am not alone. That was definitely a smack-my-forehead moment as I didn't realize until then is that Messenger is the worst culprit. So I probably could have saved myself a lot of frustration, but it was a good exercise to go through. I know what to do (and what not to do) next time around.
You have some excellent suggestions, thank you very much! As far as the tuning you mentioned (cores, mpdecision), is that achieved with something like Kernel Tuner from the Play Store once I'm rooted?
Evolution_Tech said:
To fix your storage issue, either factory reset or fastboot format userdata.
Click to expand...
Click to collapse
simms22 said:
or just format the cache.
Click to expand...
Click to collapse
Sorry, didn't see this until after I replied. I formatted the userdata and that fixed the storage issues. I'm back to 64GB. Thanks!
Lucky Armpit said:
Well, the joke's on me x 2, actually. There's all around UI lag (which isn't terrible, but it seems that it's worse than my original Nexus 6), with the biggest hesitation in the Messenger app. Reading the reviews of Messenger shows that I am not alone. That was definitely a smack-my-forehead moment as I didn't realize until then is that Messenger is the worst culprit. So I probably could have saved myself a lot of frustration, but it was a good exercise to go through. I know what to do (and what not to do) next time around.
You have some excellent suggestions, thank you very much! As far as the tuning you mentioned (cores, mpdecision), is that achieved with something like Kernel Tuner from the Play Store once I'm rooted?
Click to expand...
Click to collapse
yea, any kernel/cpu control app should do. some have more features, some have less, but it would only matter if the kernel included those features. good luck
simms22 said:
yea, any kernel/cpu control app should do. some have more features, some have less, but it would only matter if the kernel included those features. good luck
Click to expand...
Click to collapse
Personally, I think the elementalX kernel tuner is the best. Trickster won't keep all of my settings stick after boot (like disabled mp-decision). When I had the elementalX app that worked great...that was a couple.months ago but when I wiped my phone the app wasn't available anymore lol I think the dev had to remove it from play. That was 4 bucks out the window and no working kernel tuner app... Haha
JNMM said:
Personally, I think the elementalX kernel tuner is the best. Trickster won't keep all of my settings stick after boot (like disabled mp-decision). When I had the elementalX app that worked great...that was a couple.months ago but when I wiped my phone the app wasn't available anymore lol I think the dev had to remove it from play. That was 4 bucks out the window and no working kernel tuner app... Haha
Click to expand...
Click to collapse
i still have the old elementalx app, and im still using it as my cpu control app :angel:
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?
Title says it all. Is there any known way to have root and device encryption still possible?
Thanks a lot.
plop12345 said:
Title says it all. Is there any known way to have root and device encryption still possible?
Thanks a lot.
Click to expand...
Click to collapse
Not currently. Unless you can trick the device into thinking it's fully charged and plugged in at the same time??
Jammol said:
Not currently. Unless you can trick the device into thinking it's fully charged and plugged in at the same time??
Click to expand...
Click to collapse
I never thought of this question, but good question. So root trips knox to stop encryption? Kinda lame if so.
Jammol said:
Not currently. Unless you can trick the device into thinking it's fully charged and plugged in at the same time??
Click to expand...
Click to collapse
Got it working with the stock ROM in the mean time. Just don't use TWRP to flash Magisk. Keep the stock recovery, Use Magisk Manager to patch boot.img (check tar format in settings) , then flash back via Odin, boot and factory reset. Done.
No luck with any custom ROM yet. Desperately looking for help. Would also pay quite a bit to have someone skilled looking into this. I don't want to keep the Korean ROM of my N950N
Nick216ohio said:
I never thought of this question, but good question. So root trips knox to stop encryption? Kinda lame if so.
Click to expand...
Click to collapse
No, flashing with TWRP requires to format data. That step loses encryption.
For some reason it's then impossible with Magisk or pph root to just reencrypt the phone from a custom ROM. It dies with invalid encryption and looses all your data when you try.
It's a bit different with SuperSU. Here it thinks encryption went well and tries to mount it on next boot, but then fails.
From my current knowledge it seems it needs stock recovery to recreate an encrypted data partition that actually works. That's the bit I'm stuck now...
plop12345 said:
No, flashing with TWRP requires to format data. That step loses encryption.
For some reason it's then impossible with Magisk or pph root to just reencrypt the phone from a custom ROM. It dies with invalid encryption and looses all your data when you try.
It's a bit different with SuperSU. Here it thinks encryption went well and tries to mount it on next boot, but then fails.
From my current knowledge it seems it needs stock recovery to recreate an encrypted data partition that actually works. That's the bit I'm stuck now...
Click to expand...
Click to collapse
On the Snap version, using SamFail gets rid of encryption. There's no way to encrypt for us with root because of the 80% short coming.
Jammol said:
On the Snap version, using SamFail gets rid of encryption. There's no way to encrypt for us with root because of the 80% short coming.
Click to expand...
Click to collapse
Ah crap, didn't even think of that issue
Anyway, at least to me a phone without reliable encryption is not usable as daily driver. I wonder why this gets so little attention. I spend some days now trying to resolve this, but there is not much information out there or I'm not capable to dig it up.
I couldn't even find a clear statement, what it actually is that prevents TWRP to mount encrypted /data on modern Samsung phones.
I known they do their own SOC based hardware encryption, but what is it that TWRP can't get? Does the trusted zone not release the key if a custom binary boots? I really like to understand a bit more on how this actually works.
Thanks
Figured it out: https://forum.xda-developers.com/galaxy-note-8/how-to/guide-how-to-root-device-encryption-t3742493