I am concern about access to user data (pictures, videos, emails, app data, etc.) on my unlocked bootloader phone if phone is lost or stolen,. As I understand it, with the bootloader unlocked, one can install custom rom and thus bypass screen lock. Does this mean that with the new OS it can access the user data? Does phone being encrypted make a difference?
robchow said:
I am concern about access to user data (pictures, videos, emails, app data, etc.) on my unlocked bootloader phone if phone is lost or stolen,. As I understand it, with the bootloader unlocked, one can install custom rom and thus bypass screen lock. Does this mean that with the new OS it can access the user data? Does phone being encrypted make a difference?
Click to expand...
Click to collapse
If you don't need root lock it.
Sent from my Pixel using XDA-Developers Legacy app
robchow said:
I am concern about access to user data (pictures, videos, emails, app data, etc.) on my unlocked bootloader phone if phone is lost or stolen,. As I understand it, with the bootloader unlocked, one can install custom rom and thus bypass screen lock. Does this mean that with the new OS it can access the user data? Does phone being encrypted make a difference?
Click to expand...
Click to collapse
there is Android Device Manager to control phone remotely then you can erase it and keep your personal data safe.
:good:
robchow said:
I am concern about access to user data (pictures, videos, emails, app data, etc.) on my unlocked bootloader phone if phone is lost or stolen,. As I understand it, with the bootloader unlocked, one can install custom rom and thus bypass screen lock. Does this mean that with the new OS it can access the user data? Does phone being encrypted make a difference?
Click to expand...
Click to collapse
They would need to know your password to get into TWRP to decrypt the storage(assuming you're encrypted) They don't need to flash a custom rom to see your stuff, they can view it by connecting the phone to their computer and enable mtp mode in TWRP. If you are that concerned, you probably should lock your bootloader after making sure you are 100% stock.
I really dont see any reason for concern.
Say your phone has a password, but your bootloader is unlocked, here are the only things you can really do.....
A: Use fastboot to flash twrp. however, once they get into twrp, they will still need to know your password. And twrp will not allow
mtp or adb access until it is has decrypted.
B: Use fastboot to Flash a factory image. But once they boot the phone, it will ask for the email and password
of the original account that was on the phone, and all data will be gone.
C: Use fastboot to flash a factory image without the -w paramter. All data will still be there, and they really have gained nothing.
i dont see any real risk.
noidea24 said:
I really dont see any reason for concern.
Say your phone has a password, but your bootloader is unlocked, here are the only things you can really do.....
A: Use fastboot to flash twrp. however, once they get into twrp, they will still need to know your password. And twrp will not allow
mtp or adb access until it is has decrypted.
B: Use fastboot to Flash a factory image. But once they boot the phone, it will ask for the email and password
of the original account that was on the phone, and all data will be gone.
C: Use fastboot to flash a factory image without the -w paramter. All data will still be there, and they really have gained nothing.
i dont see any real risk.
Click to expand...
Click to collapse
No matter the path, if your data is intact they still need your pattern.
Thank you all for your input and knowledge dissemination on how a unlocked bootloader affect user data.
noidea24 said:
I really dont see any reason for concern.
Say your phone has a password, but your bootloader is unlocked, here are the only things you can really do.....
A: Use fastboot to flash twrp. however, once they get into twrp, they will still need to know your password. And twrp will not allow
mtp or adb access until it is has decrypted.
B: Use fastboot to Flash a factory image. But once they boot the phone, it will ask for the email and password
of the original account that was on the phone, and all data will be gone.
C: Use fastboot to flash a factory image without the -w paramter. All data will still be there, and they really have gained nothing.
i dont see any real risk.
Click to expand...
Click to collapse
Not using the -w parameter will keep the user data intact; understood, thank you. If that is the case, will the theft be able to access user data if user data partition is encrypted?
By removing -w even your lock screen will still be there, so no. No security concerns.
If you want it to be secure then lock your bootloader, otherwise it will be insecure. It's a trivial matter to someone knowledgeable to get into your files.
Sent from my Pixel XL using Tapatalk
superchilpil said:
If you want it to be secure then lock your bootloader, otherwise it will be insecure. It's a trivial matter to someone knowledgeable to get into your files.
Click to expand...
Click to collapse
I guess the question is how if they cannot decrypt the file system?
pcriz said:
I guess the question is how if they cannot decrypt the file system?
Click to expand...
Click to collapse
If the right person stole you're phone and wanted to waste the resources needed to decrypt the info, they could. Since it's possible, it's considered a security risk. Although let's be real. It's highly unlikely that it would ever happen. Unless you're some vip or something crazy like that.
toknitup420 said:
If the right person stole you're phone and wanted to waste the resources needed to decrypt the info, they could. Since it's possible, it's considered a security risk. Although let's be real. It's highly unlikely that it would ever happen. Unless you're some vip or something crazy like that.
Click to expand...
Click to collapse
In that case I doubt even a bootloader would matter.
pcriz said:
In that case I doubt even a bootloader would matter.
Click to expand...
Click to collapse
Yes it would. You can't access anything unless you factory reset. Then it's all gone, decrypting won't do a thing. Reset is a total wipe. Brand new device.
Sent from my Pixel using XDA-Developers Legacy app
bobby janow said:
Yes it would. You can't access anything unless you factory reset. Then it's all gone, decrypting won't do a thing. Reset is a total wipe. Brand new device.
Click to expand...
Click to collapse
I think you are missing the context of my statement. No information system is 100% impenetrable, so even with a bootloader if someone really really wanted in a system and had the means they can crack it. That's just general rule of security.
The other side of the discussion is how safe is the data. Well if you factory reset the data is plenty safe because it's wiped.
Seem what your statement is talking about is basically can someone use the phone they aquired, in that instance yes but that's also why we have insurance.
pcriz said:
I think you are missing the context of my statement. No information system is 100% impenetrable, so even with a bootloader if someone really really wanted in a system and had the means they can crack it. That's just general rule of security.
The other side of the discussion is how safe is the data. Well if you factory reset the data is plenty safe because it's wiped.
Seem what your statement is talking about is basically can someone use the phone they aquired, in that instance yes but that's also why we have insurance.
Click to expand...
Click to collapse
Well multiple things going on now. If data can be extracted from a locked bootloader device I'd like to see proof of concept. I'm not saying it can't be done.
By the time a person wiped the device you'd probably have the IMEI blacklisted so the device will be useless.
Sent from my Pixel using XDA-Developers Legacy app
bobby janow said:
Well multiple things going on now. If data can be extracted from a locked bootloader device I'd like to see proof of concept. I'm not saying it can't be done.
By the time a person wiped the device you'd probably have the IMEI blacklisted so the device will be useless.
Sent from my Pixel using XDA-Developers Legacy app
Click to expand...
Click to collapse
Data extracted from a bootloader locked device, data decrypted from an encrypted device, same argument when it comes to proof of concept.
Not to mention you realize bootloaders have been defeated before, its the whole reason bootloader bounties exist. Frankly given some of the exploits that have gotten around bootloaders, it seems in some cases defeating a boot loader would be easier than decrypting.
Every google bootloader probably has the same signed key (in relation to BL version)
pcriz said:
Data extracted from a bootloader locked device, data decrypted from an encrypted device, same argument when it comes to proof of concept.
Not to mention you realize bootloaders have been defeated before, its the whole reason bootloader bounties exist. Frankly given some of the exploits that have gotten around bootloaders, it seems in some cases defeating a boot loader would be easier than decrypting.
Every google bootloader probably has the same signed key (in relation to BL version)
Click to expand...
Click to collapse
Is it really the same thing or proof of concept? How do you extract data from a locked bootloader device even pre-decryption? Whereas if you have encrypted data then decrypting is a matter being able to hack that encryption algorithm. I see that as two distinct operations.
If you mean defeating bootloaders so you can unlock, I'm not arguing that point at all although if you recall the Samsung S4 could not be unlocked after the first firmware update no matter how much they tried. I think they were able to get around it by some other method but the bootloader was never unlocked again. (btw I have the original S4 still unlocked and never updated the firmware) The Verizon bootloader is not unlockable either on their OEM device. I'm not sure if it's possible but no one is even working on it afaik. But I digress. Even if you manage to unlock the Pixel VZW bootloader or any locked bootloader for that matter, the device is wiped clean on the unlock. So there is no data to decrypt thus making accessing it moot as far as compromising your data.
That is why I keep the bootloader locked and the oem switch off. (On my 5x since my VZW oem switch is grayed out) With a start-up pin and ADM at the ready in case it's lost I feel pretty safe storing my data on the device. Pretty safe, not perfectly safe.
bobby janow said:
Is it really the same thing or proof of concept? How do you extract data from a locked bootloader device even pre-decryption? Whereas if you have encrypted data then decrypting is a matter being able to hack that encryption algorithm. I see that as two distinct operations. )
Click to expand...
Click to collapse
You don't simply "hack an encryption algorithm", you can hypothetically "hack" or exploit a BL. That's not how it works when are you using randomly generated keys tied to the unlock method. Essentially you would need their unlock method and how it translates into the keys generated on the device.
You ask for a proof of concept, the concept of bootloader broken has been proven time and time again.
I'm still looking for am instance where a BL unlocked device has been stripped of it information and decrypted so it can be read by another device.
You could also lock your device away in a safe and it would be safer than any device created but you lose certain experiences.
Essentially your implication as I read it is this guy wide open for his data to be stolen if his bootloader is unlocked and encryption provides no protection.
pcriz said:
You ask for a proof of concept, the concept of bootloader broken has been proven time and time again.
Click to expand...
Click to collapse
No that's not what I was saying or asking. I know a bootloader can be broken and unlocked, I've seen that. The concept I was referring to was unlocking a bootloader with OEM unlock turned off and then, after unlocking it, accessing the data that was there before the unlock. That to me is the security of a locked bootloader.
pcriz said:
I'm still looking for am instance where a BL unlocked device has been stripped of it information and decrypted so it can be read by another device.
Click to expand...
Click to collapse
That would be interesting to me as well.
pcriz said:
You could also lock your device away in a safe and it would be safer than any device created but you lose certain experiences.
Click to expand...
Click to collapse
Be great on battery life too.
pcriz said:
Essentially your implication as I read it is this guy wide open for his data to be stolen if his bootloader is unlocked and encryption provides no protection.
Click to expand...
Click to collapse
Well not really. If the bootloader is unlocked then the security is compromised as far as I'm concerned. You can flash a new rom without wiping data and I'd say that would be an easy target. You'd still need to decrypt but the challenge would be multiples of easier.
But one thing I'm not entirely clear on since I'm not unlocked or rooted. Someone mentioned that you couldn't log into the phone if you don't have the proper account credentials. How exactly does that work? On my 5x I can wipe the system but keep the data intact and have full access. What am I missing?
bobby janow said:
But one thing I'm not entirely clear on since I'm not unlocked or rooted. Someone mentioned that you couldn't log into the phone if you don't have the proper account credentials. How exactly does that work? On my 5x I can wipe the system but keep the data intact and have full access. What am I missing?
Click to expand...
Click to collapse
Hello,
Do you have OEM unlock enabled?
I have an unlocked bootloader and i usually leave OEM unlock enabled. This way, when i wipe clean and want to test some features or modifications, i simply reinstall and can skip the setup part.
If OEM unlock is disabled, you'll have to add the same account used before the phone has been wiped.
Is that what you were referring to?
Cheers...
Related
I'm curious if anyone has been able to re-lock their bootloader or if there is a way to do so once a custom ROM has been loaded onto the Nexus 5X. I know that locking the bootloader on this phone once the system partition has been altered can brick the phone as the locking implementation of the bootloader is more secure from older phones as the option inside of the ROM to unlock the bootloader must be enabled in developer options in order to use the fastboot command to unlock the bootloader.
I'm interested in this as having an unlocked bootloader leaves the system partition exposed for people to bypass android's implementation of disk encryption.
With the bootloader unlocked the system partition is capable of being modified, which leaves a door open for someone to use an exploit on the system partition to steal the encryption key for the data partition and thus unlock the android phone and bypass the encryption feature.
In order to secure the encryption feature the bootloader needs to be locked, so the system partition can not be modified to allow an attacker to utilize an exploit and steal the encyption key for the data partition, however with the implementation of the newer bootloader this isn't possible on a custom ROM and can result in a brick if the bootloader is re-locked.
Just curious if there is a way to accomplish this without bricking the phone. So I would be able to run say Cyanogenmod with on a rooted phone with a custom recovery and lock the bootloader to ensure the security of the encryption that is used on the data partition. Additionally getting the bootloader to verify the validity of the system partition could be beneficial from a security perspective as well, so it can be ensured that it hasn't been modified.
Is this possible with a custom ROM?
Beakfire said:
I'm curious if anyone has been able to re-lock their bootloader or if there is a way to do so once a custom ROM has been loaded onto the Nexus 5X. I know that locking the bootloader on this phone once the system partition has been altered can brick the phone as the locking implementation of the bootloader is more secure from older phones as the option inside of the ROM to unlock the bootloader must be enabled in developer options in order to use the fastboot command to unlock the bootloader.
I'm interested in this as having an unlocked bootloader leaves the system partition exposed for people to bypass android's implementation of disk encryption.
With the bootloader unlocked the system partition is capable of being modified, which leaves a door open for someone to use an exploit on the system partition to steal the encryption key for the data partition and thus unlock the android phone and bypass the encryption feature.
In order to secure the encryption feature the bootloader needs to be locked, so the system partition can not be modified to allow an attacker to utilize an exploit and steal the encyption key for the data partition, however with the implementation of the newer bootloader this isn't possible on a custom ROM and can result in a brick if the bootloader is re-locked.
Just curious if there is a way to accomplish this without bricking the phone. So I would be able to run say Cyanogenmod with on a rooted phone with a custom recovery and lock the bootloader to ensure the security of the encryption that is used on the data partition. Additionally getting the bootloader to verify the validity of the system partition could be beneficial from a security perspective as well, so it can be ensured that it hasn't been modified.
Is this possible with a custom ROM?
Click to expand...
Click to collapse
No. Unless you want a paperweight
Sent from my Nexus 5X using Tapatalk 2
In short, doing so could brick your device and leave you without any method of recovery. You need to be stock to re-lock the bootloader. There are several threads about how to accomplish this (I would recommend Heisenberg's guide here under section 10: http://forum.xda-developers.com/nexus-5x/general/guides-how-to-guides-beginners-t3206930).
If this seems too daunting, you could also use the nexus toolkit, you can find info about that here: http://forum.xda-developers.com/nexus-5x/development/toolkit-wugs-nexus-root-toolkit-v2-1-0-t3258492.
I get it, reverting to stock isn't a problem for me I can do everything from fastboot without the toolkits.
I'd just like to be able to use the security features of the locked bootloader and the phone's encryption on a custom ROM, which at this point doesn't seem possible and wanted to see if anyone had been able to accomplish this somehow or if there were any progress in that direction.
In another note along these lines can the phone be de-googled (removal of GAPPS, google framework, etc... e.g. modify the system partition, root, etc.) and then re-locked? Or will the bootloader see that the system partition has been altered from the factory condition and error out? I could try.. just hesitant to as I don't want to brick it which is why I wanted to see if anyone had done something like this before.
Beakfire said:
I get it, reverting to stock isn't a problem for me I can do everything from fastboot without the toolkits.
I'd just like to be able to use the security features of the locked bootloader and the phone's encryption on a custom ROM, which at this point doesn't seem possible and wanted to see if anyone had been able to accomplish this somehow or if there were any progress in that direction.
In another note along these lines can the phone be de-googled (removal of GAPPS, google framework, etc... e.g. modify the system partition, root, etc.) and then re-locked? Or will the bootloader see that the system partition has been altered from the factory condition and error out? I could try.. just hesitant to as I don't want to brick it which is why I wanted to see if anyone had done something like this before.
Click to expand...
Click to collapse
This has never been possible since the origin of android. I wouldn't hold your breath
Sent from my Nexus 5X using Tapatalk 2
hopesrequiem said:
This has never been possible since the origin of android. I wouldn't hold your breath
Sent from my Nexus 5X using Tapatalk 2
Click to expand...
Click to collapse
Actually it is.
I have a 1st generation nexus 7 that I use in an in-car install that is running TWRP recovery, a kernel from SGT Meow that supports OTG host-mode charging and CM13 that I locked the bootloader on after I was done installing everything. It also has the data partition encrypted on it and everything on it works perfectly fine.
Beakfire said:
Actually it is.
I have a 1st generation nexus 7 that I use in an in-car install that is running TWRP recovery, a kernel from SGT Meow that supports OTG host-mode charging and CM13 that I locked the bootloader on after I was done installing everything. It also has the data partition encrypted on it and everything on it works perfectly fine.
Click to expand...
Click to collapse
I stand corrected I guess. That makes no sense to do in my opinion. The whole reason to unlock it initially is to be free to modify it. You modify it and give back that power? Makes no sense
Sent from my Nexus 5X using Tapatalk 2
Just curious, why does the OP think the encryption key could be stolen using the system partition?
Beakfire said:
Actually it is.
I have a 1st generation nexus 7 that I use in an in-car install that is running TWRP recovery, a kernel from SGT Meow that supports OTG host-mode charging and CM13 that I locked the bootloader on after I was done installing everything. It also has the data partition encrypted on it and everything on it works perfectly fine.
Click to expand...
Click to collapse
I also had nexus 4 and 5 running cyanogenmod or omnirom with a custom kernel and locked bootloader.
Of course, they did not have the idiotic 'allow oem unlocking' so there was no danger (and there was the bootunlocker app anyway).
Then again, if you use full disk encryption I'm not sure if there is a benefit to a locked bootloader from the encryption key perspective as that's in the ram memory, not on the system partition. Cold boot attack? Yes, probably, but the ordinary thief won't be able to spell cold.
My 5x is unlocked and at each reboot the bootloader says my device is corrupted, scary initially but I don't want the gapps cancer on my phone.
jisoo said:
Just curious, why does the OP think the encryption key could be stolen using the system partition?
Click to expand...
Click to collapse
I read a few papers on the weak points to android's encryption scheme.
The classic evil maid attack works against android using something called EvilDroid and there is also a forensic tool out there called FROST that can also accomplish the task of bypassing android's encryption.
Frost would be easier to use, since it only needs to be flashed to the recovery partition of an unlocked device. I was just reading up on it some, if someone could find the FROST image it would actually be very easy for someone with very little skill to implement a cold boot attack against an android device and gain access to the data on the encrypted partition of the phone.
The evil droid attack would be more difficult and someone would have to specifically target your phone. FROST could be used on any unlocked phone with an encrypted data partition and unlocked bootloader.
Here's a few links to the articles I was reading on the exploits:
http://isyou.info/jowua/papers/jowua-v5n1-4.pdf
https://www1.cs.fau.de/filepool/projects/frost/frost.pdf
There's also a kernel patch out there called ARMORED that is essentially TRESOR (TRESOR runs encryption securely outside RAM) for android driven ARM devices that would prevent FROST from working on a device with an unlocked bootloader. The evilmaid attack would still work though, but is really impractical for the average person to use such an attack on a smartphone.
ARMORED patch is available here:
https://www1.cs.fau.de/tresor/
I was reading on the android boot process here:
https://source.android.com/security/verifiedboot/verified-boot.html
The Nexus 5X supports the unlocked state so must be a class B implementation based up on that read, which means if a signed key is added to a ROM that is flashed it should boot with the yellow boot prompt indicating that the system was verified against an embedded certificate and not the OEM key.
The bootloader checks the /boot and /recovery partitions during the verification process from that article.
Currently mine boots with an orange screen, since it's unlocked.
I know most people aren't concerned with it, just with a modded device if I were to want to use the encryption feature if that FROST app were easily found on the web (I don't know if it is available somewhere) anyone that knows how to stick a phone in a freezer and use a single fastboot command would be able to decrypt the encrypted data partition on an unlocked phone.
haha and here's actually the attack with all the tools to use it available here:
https://www1.cs.fau.de/frost
It's obviously an older implementation of frost from 2012/2013 for the Galaxy Nexus that is up on that site though.
Beakfire said:
I read a few papers on the weak points to android's encryption scheme.
Click to expand...
Click to collapse
Honestly just steal the finger together with the phone instead of freezing stuff and messing around.
It is quickly done and and 95% of people will have the finger print sensor configured to bypass the lockscreen.
Beakfire said:
I read a few papers on the weak points to android's encryption scheme.
The classic evil maid attack works against android using something called EvilDroid and there is also a forensic tool out there called FROST that can also accomplish the task of bypassing android's encryption.
Click to expand...
Click to collapse
Look, I'm not expert I'm this, but I fail to see (even after reading on the FROST attack) how this attack would work.
The encryption key is itself encrypted by your password. If you use a strong enough password, this can't be bruteforced. It doesn't matter that someone retrieves the encryption key if they can't read it.
The FROST attack seems to be a method to retrieve the encryption key from a bootloader locked device (but you'd still need to bruteforce the password). So it's actually an attack which demonstrates how little unlocking the bootloader impacts encryption security in this case.
What's more, Nexus 5x uses HW storage for the encryption key, which makes it practically impossible to retrieve the key, locked or unlocked bootloader doesn't matter.
So apart from an evil maid attack (where someone changes your system so that it will record and transmit your password), I don't see how an unlocked bootloader would compromise the encryption itself.
---------- Post added at 01:26 PM ---------- Previous post was at 01:25 PM ----------
user822 said:
Honestly just steal the finger together with the phone instead of freezing stuff and messing around.
It is quickly done and and 95% of people will have the finger print sensor configured to bypass the lockscreen.
Click to expand...
Click to collapse
Fingerprint won't provide the password needed for decryption, so it only works if the device is already fully booted and partitions mounted.
jisoo said:
Fingerprint won't provide the password needed for decryption, so it only works if the device is already fully booted and partitions mounted.
Click to expand...
Click to collapse
That is absolutely true, but normally you steal phones that are switched on
And the "freezer" attack also needs a phone that was turned on before it seems
jisoo said:
Look, I'm not expert I'm this, but I fail to see (even after reading on the FROST attack) how this attack would work.
The encryption key is itself encrypted by your password. If you use a strong enough password, this can't be bruteforced. It doesn't matter that someone retrieves the encryption key if they can't read it.
The FROST attack seems to be a method to retrieve the encryption key from a bootloader locked device (but you'd still need to bruteforce the password). So it's actually an attack which demonstrates how little unlocking the bootloader impacts encryption security in this case.
What's more, Nexus 5x uses HW storage for the encryption key, which makes it practically impossible to retrieve the key, locked or unlocked bootloader doesn't matter.
So apart from an evil maid attack (where someone changes your system so that it will record and transmit your password), I don't see how an unlocked bootloader would compromise the encryption itself.
Click to expand...
Click to collapse
The critical paragraph from the article describes the vulnerability in dm-crypt which is the encryption subsystem android uses. Once it's booted and decrypted traces are left in RAM that expose the key and are not removed until power cut. The unlocked bootloader simply allows the FROST application to be installed without wiping the data partition. It can still be used to expose the key on a phone with a locked bootloader, however it's pointless as installation of FROST requires the data partition to be wiped as a result of unlocking the bootloader during the process. Below is from the paragraph about the dm-crypt vulnerability from the article from the people that used FROST to do a cold boot attack on an android phone.
However, it has not been reported yet if cold boot attacks are applicable against ARM-based devices such as smartphones and tablets, or against Android devices in particular. We conjecture such devices
are vulnerable, because Android's underlying encryption solution dm-crypt is already known to be vulnerable. Technically, it makes no difference if dm-crypt is running on ARM or an x86 architecture, because the vulnerability relies in the AES key schedule that is stored inside RAM. AES key schedules can be identified by recovery tools like aeskeyfind that search for suspicious patterns of a schedule in RAM. Dm-crypt is vulnerable to such tools, because it creates the AES key schedule initially inside RAM during boot and it gets lost only if power is cut.
Beakfire said:
The unlocked bootloader simply allows the FROST application to be installed without wiping the data partition. It can still be used to expose the key on a phone with a locked bootloader, however it's pointless as installation of FROST requires the data partition to be wiped as a result of unlocking the bootloader during the process.
Click to expand...
Click to collapse
Many devices allow you to boot external image even with bootloader locked. Using "fastboot boot" command which means, you can boot FROST on a device with bootloader locked, which makes things even worse.
Beakfire said:
Actually it is.
I have a 1st generation nexus 7 that I use in an in-car install that is running TWRP recovery, a kernel from SGT Meow that supports OTG host-mode charging and CM13 that I locked the bootloader on after I was done installing everything. It also has the data partition encrypted on it and everything on it works perfectly fine.
Click to expand...
Click to collapse
The reason you can lock your bootloader on a custom kernel is that LG's signing certificate had been leaked (available on XDA too) and it is therefore possible to sign a custom boot image (and recovery) with it. Those will pass bootloader signature check on boot. However, this is an anomaly; it was a scandal and LG has already "fixed" the situation. However, older devices (quite a few of them) can enjoy custom roms on locked bootloaders and they don't even have to unlock...
The other poster was right: it is impossible to boot a kernel that is not signed by OEM on a locked bootloader. Also, you won't hard brick your device, even if you install custom kernel on it: all you need to do is to reflash (not in fastboot) stock kernel and rom...
As far as forensics: if your data is encrypted; you have a long boot password that is not included into "word dictionary" used by brute-forcing apps; and your device is off, I wish a very good luck to even sophisticated crackers. They won't be able to brute-force you. However, your adversaries will use a "Moroccan Police" method: they'll beat you on the head until you give them the password. Never fails...
optimumpro said:
The reason you can lock your bootloader on a custom kernel is that LG's signing certificate had been leaked (available on XDA too) and it is therefore possible to sign a custom boot image (and recovery) with it. Those will pass bootloader signature check on boot. However, this is an anomaly; it was a scandal and LG has already "fixed" the situation. However, older devices (quite a few of them) can enjoy custom roms on locked bootloaders and they don't even have to unlock...
The other poster was right: it is impossible to boot a kernel that is not signed by OEM on a locked bootloader. Also, you won't hard brick your device, even if you install custom kernel on it: all you need to do is to reflash (not in fastboot) stock kernel and rom...
As far as forensics: if your data is encrypted; you have a long boot password that is not included into "word dictionary" used by brute-forcing apps; and your device is off, I wish a very good luck to even sophisticated crackers. They won't be able to brute-force you. However, your adversaries will use a "Moroccan Police" method: they'll beat you on the head until you give them the password. Never fails...
Click to expand...
Click to collapse
My nexus 7 is an Asus device, not LG.
I think most people missed the bus on this one, the idea is to have an alternate signing certificate that matches up with the custom ROM's software so that way you can use the bootloader locking feature with a non-OEM certificate that will be used instead of the OEM certificate to verify the boot and recovery partitions.
Per the read on the way the bootloader verification procedures work this should be possible, but I'm unaware of anyone doing it or that has made it possible yet.
On my Nexus 7 it's running Lollipop, so that may be part of it as well, I'm not sure if the boot verification parts came into play in android until Marshmallow and now it's becoming more strict with Nougat.
We should, however, be able to get to a yellow boot prompt during the verification procedure that verifies a modified boot, recovery and now system partition (with nougat) based off a non-OEM signing certificate that would have to be added to the boot image to verify those partitions during the boot process.
I just don't think anyone has bothered with it, as most people consider their devices insecure once physical security is lost on them or just don't care. However the point of this was to defeat the ability of an attacker to bypass the android encryption features on a device running a custom ROM and provide the added security of a locked bootloader on a modified device.
A locked bootloader is absolutely necessary to maintain the integrity of an android device, especially if physical control of that device is lost. I just wanted to see if anyone had managed to do so on a Nexus 5X with a custom ROM to regain the security features provided by a locked bootloader and secure android's encryption scheme.
Beakfire said:
My nexus 7 is an Asus device, not LG.
I think most people missed the bus on this one, the idea is to have an alternate signing certificate that matches up with the custom ROM's software so that way you can use the bootloader locking feature with a non-OEM certificate that will be used instead of the OEM certificate to verify the boot and recovery partitions.
Per the read on the way the bootloader verification procedures work this should be possible, but I'm unaware of anyone doing it or that has made it possible yet.
On my Nexus 7 it's running Lollipop, so that may be part of it as well, I'm not sure if the boot verification parts came into play in android until Marshmallow and now it's becoming more strict with Nougat.
We should, however, be able to get to a yellow boot prompt during the verification procedure that verifies a modified boot, recovery and now system partition (with nougat) based off a non-OEM signing certificate that would have to be added to the boot image to verify those partitions during the boot process.
I just don't think anyone has bothered with it, as most people consider their devices insecure once physical security is lost on them or just don't care. However the point of this was to defeat the ability of an attacker to bypass the android encryption features on a device running a custom ROM and provide the added security of a locked bootloader on a modified device.
A locked bootloader is absolutely necessary to maintain the integrity of an android device, especially if physical control of that device is lost. I just wanted to see if anyone had managed to do so on a Nexus 5X with a custom ROM to regain the security features provided by a locked bootloader and secure android's encryption scheme.
Click to expand...
Click to collapse
Unless your Asus has an open source bootloader (which very few devices do), there is no way you can boot a non stock kernel with a locked bootloader. I also think you are confusing locking bootloader with Android verity, which are 2 different things. Verity, as part of Android, kicks in after OEM bootloader verification. While you can do whatever you want with verity, you can't touch a closed source bootloader, which means you can't get to that OEM certificate. And while you can replace verity certificate with your 'alternative signing certificate', the same will have absolutely no effect on bootloader verfication.
There is one other possibility which is used in several devices: you can have stock kernel working with custom roms by way of hijacking one of hardware initiation scripts and have it open a separate ramdisk that is compatible with a custom rom. That's how my old Xperia ION with unlockable bootloader can run CM roms.
In other words, there are only 3 possibilities to have custom roms work with locked bootloaders: 1. Have an OEM certificate; 2. Open source bootloader; and 3. Second ramdisk compatible with custom roms. There is no other way.
So, if none of the above three applies to your Asus, then your locking procedure has not resulted in a locked bootloader, which also happens...
Also, locked bootloader does not provide any additional security. It only cares about boot and recovery partitions and has no effect on System. So, if a thief gets your device, all he has to do is flash it in flash mode with OEM official software to wipe everything clean, even if your boot loader cannot be unlocked. If the thief is after your data (regardless of encryption), locked bootloader doesn't help in any way. If government adversaries are after you, locked bootloader is no help either: they have data acquisition software that includes most if not all OEM's certificates.
optimumpro said:
Unless your Asus has an open source bootloader (which very few devices do), there is no way you can boot a non stock kernel with a locked bootloader. I also think you are confusing locking bootloader with Android verity, which are 2 different things. Verity, as part of Android, kicks in after OEM bootloader verification. While you can do whatever you want with verity, you can't touch a closed source bootloader, which means you can't get to that OEM certificate. And while you can replace verity certificate with your 'alternative signing certificate', the same will have absolutely no effect on bootloader verfication.
There is one other possibility which is used in several devices: you can have stock kernel working with custom roms by way of hijacking one of hardware initiation scripts and have it open a separate ramdisk that is compatible with a custom rom. That's how my old Xperia ION with unlockable bootloader can run CM roms.
In other words, there are only 3 possibilities to have custom roms work with locked bootloaders: 1. Have an OEM certificate; 2. Open source bootloader; and 3. Second ramdisk compatible with custom roms. There is no other way.
So, if none of the above three applies to your Asus, then your locking procedure has not resulted in a locked bootloader, which also happens...
Also, locked bootloader does not provide any additional security. It only cares about boot and recovery partitions and has no effect on System. So, if a thief gets your device, all he has to do is flash it in flash mode with OEM official software to wipe everything clean, even if your boot loader cannot be unlocked. If the thief is after your data (regardless of encryption), locked bootloader doesn't help in any way. If government adversaries are after you, locked bootloader is no help either: they have data acquisition software that includes most if not all OEM's certificates.
Click to expand...
Click to collapse
The Asus device is a Gen 1 Nexus 7, I don't believe the bootloader is open source as I'm always flashing the stock boot.img when I wipe and re-load it.
I am able to lock the bootloader after I'm complete with re-loading from fastboot. The locked bootloader does protect the device from some attacks where, as I mentioned on the first page of this thread, where an attacker can flash a modified recovery partition to the device and use it to dump the key-schedule from RAM in order to gain the key and decrypt an encrypted data partition.
You're also correct that the system partition isn't protected by the encryption which allows another exploit, as I mentioned on the first page.
In the case of a thief who is after the device, I'd agree it's of little to no use as they can simply unlock it, wipe and make it their own. However if they're also after your data they can use an exploit if the bootloader is unlocked to steal the key from RAM and decrypt your data partition. The likelihood of such an attacker is probably fairly small though.
I would seriously doubt that governments have the ability to unlock any encryption that is available. If reading the news has shown anything the government pays out a lot of money for zero day exploits in order to find ways to attack people's devices and take information. The more of these methods of attack that are removed from devices the more secure the encryption that they use becomes from attackers that would exploit the same attacks that governments do. The government also raised all of those problems with apple when there was an iPhone they could not get into and likely some type of exploit was utilized in order to bypass security features and brute force the pin-code which was probably too simple.
Attacking the encryption directly simply wouldn't be an option for anyone, attackers are always trying to find ways to steal the key or bypass security features and brute force simple keys to decrypt data.
A locked bootloader prevents an adversary from stealing an encryption key from RAM by installing a modified recovery partition, this secures data in your encrypted data partition in the event your phone is lost. So it absolutely does help protect the device. This was proven in the documents I posted on the first page of this thread.
Here's a diagram showing the boot flow of android's secure boot verity:
https://source.android.com/security/verifiedboot/verified-boot.html
It should be noted that android has the capability to boot into a yellow boot state, with a non-OEM key, will display that key's fingerprint and continue the boot process.
I can understand though, I suppose you can't change the bootloader's OEM key without the bootloader being open source which makes it a no-go, I just don't know enough about how to make android utilize a non-OEM certificate.
It does state in the verified boot process though that:
In Class B implementations, it is possible for the user to flash software signed with other keys when the device is UNLOCKED. If the device is then LOCKED and verification using the OEM key fails, the bootloader tries verification using the certificate embedded in the partition signature. However, using a partition signed with anything other than the OEM key results in a notification or a warning, as described below.
The notification or warning described below was the yellow boot state which is what I had thought to get to with a custom ROM. I think in Nougat with it strictly enforcing that possibility at all may be gone.
Here's another thread discussing it a bit:
http://www.xda-developers.com/a-look-at-marshmallow-root-verity-complications/
My Nexus 7 probably works just fine with modifications and a locked bootloader because verity was not implemented until Marshmallow and I have never proceeded past Lollipop on my Nexus 7 since I need a modified kernel for it as its used in a in-car install.
So Pre-Marshmallow, unlocked bootloader, modifying and re-locking the bootloader not an issue, Marshmallow and beyond it's a problem.
Beakfire said:
The Asus device is a Gen 1 Nexus 7, I don't believe the bootloader is open source as I'm always flashing the stock boot.img when I wipe and re-load it.
I am able to lock the bootloader after I'm complete with re-loading from fastboot. The locked bootloader does protect the device from some attacks where, as I mentioned on the first page of this thread, where an attacker can flash a modified recovery partition to the device and use it to dump the key-schedule from RAM in order to gain the key and decrypt an encrypted data partition.
You're also correct that the system partition isn't protected by the encryption which allows another exploit, as I mentioned on the first page.
In the case of a thief who is after the device, I'd agree it's of little to no use as they can simply unlock it, wipe and make it their own. However if they're also after your data they can use an exploit if the bootloader is unlocked to steal the key from RAM and decrypt your data partition. The likelihood of such an attacker is probably fairly small though.
I would seriously doubt that governments have the ability to unlock any encryption that is available. If reading the news has shown anything the government pays out a lot of money for zero day exploits in order to find ways to attack people's devices and take information. The more of these methods of attack that are removed from devices the more secure the encryption that they use becomes from attackers that would exploit the same attacks that governments do. The government also raised all of those problems with apple when there was an iPhone they could not get into and likely some type of exploit was utilized in order to bypass security features and brute force the pin-code which was probably too simple.
Attacking the encryption directly simply wouldn't be an option for anyone, attackers are always trying to find ways to steal the key or bypass security features and brute force simple keys to decrypt data.
A locked bootloader prevents an adversary from stealing an encryption key from RAM by installing a modified recovery partition, this secures data in your encrypted data partition in the event your phone is lost. So it absolutely does help protect the device. This was proven in the documents I posted on the first page of this thread.
Here's a diagram showing the boot flow of android's secure boot verity:
https://source.android.com/security/verifiedboot/verified-boot.html
It should be noted that android has the capability to boot into a yellow boot state, with a non-OEM key, will display that key's fingerprint and continue the boot process.
I can understand though, I suppose you can't change the bootloader's OEM key without the bootloader being open source which makes it a no-go, I just don't know enough about how to make android utilize a non-OEM certificate.
It does state in the verified boot process though that:
In Class B implementations, it is possible for the user to flash software signed with other keys when the device is UNLOCKED. If the device is then LOCKED and verification using the OEM key fails, the bootloader tries verification using the certificate embedded in the partition signature. However, using a partition signed with anything other than the OEM key results in a notification or a warning, as described below.
The notification or warning described below was the yellow boot state which is what I had thought to get to with a custom ROM. I think in Nougat with it strictly enforcing that possibility at all may be gone.
Here's another thread discussing it a bit:
http://www.xda-developers.com/a-look-at-marshmallow-root-verity-complications/
My Nexus 7 probably works just fine with modifications and a locked bootloader because verity was not implemented until Marshmallow and I have never proceeded past Lollipop on my Nexus 7 since I need a modified kernel for it as its used in a in-car install.
So Pre-Marshmallow, unlocked bootloader, modifying and re-locking the bootloader not an issue, Marshmallow and beyond it's a problem.
Click to expand...
Click to collapse
With all due respect, but you are mistaken regarding boot states you referenced. Google have no access to OEM bootloader certificate. And under no circumstances it can boot a device that failed OEM certification. All it can do is read the state: verfied or not.
Regarding your Asus. There is no way you can boot a non stock kernel on a locked bootloader. If you can, then your bootloader is not locked and you can flash whatever you want. See if you can get to fastboot on your locked bootloader. If you can, it is not locked. If you can't, you are NOT using a modified kernel. There is no third option.
Locked bootloader security: if your phone is turned off and data encrypted, no one can get to your data even if they fastboot whatever they want. The key wouldn't get into ram until data is decrypted. If your phone is on and it gets into your adversary's hands, he doesn't need to flash anything: he can get encryption key from ram on a live device.
I am not saying the government can break encryption, but that their image acquisition software has OEM certificates I know for a fact, which means they can boot modified images signed with OEM certificates, which defeats bootloader locking...
Edit: the yellow state and the fact that the embedded key is NOT the OEM key indiates that bootloader is unlocked, so you get a yellow light telling you that you or someone else had unlocked your bootloader and modified kernel/recovery; then it waits and if there is no action from you, it boots. Useless.... It only protects somewhat against an over-the-air attack on your system: stagefreight et all. Also useless, because if someone needs to attack you, they can do that via baseband. This is one of Google's "innovations" which gives user a sense of security only...
Ok guys here is a guide for unlock/s-off/root etc while keeping your radio working, as well as getting your radio working -> http://forum.xda-developers.com/htc-10/how-to/guide-root-optionally-s-off-radio-t3373025
This week accidentally (for real, we planned on waiting until we had this PSA published first but goof'd on our build configuration, so it went live early) release SunShine for the HTC 10.
This PSA is need due to how HTC is tying in the keys for userdata encryption on newer devices and firmware. Modern device are encrypted by default, if you set a password or not. This is mostly seamless to those who don't use a password.
The way HTC encrypts the key for user data is to more or less mash up the bootloader lock status, the s-on/s-off status, and the password (for those without a password it is something like "default_password") together. Then the encrypt/decrypt the key.
What this means if you change the lock status, or the s-on/s-off status the phone can no longer decrypt your data, forcing you to wipe the device.
This will happen when you lock the device, unlock the device (which also wipes so who cares), go s-on, or go s-off. This does not matter if you use htcdev.com, SunShine, a new generation javacard, fastboot to go s-on/lock, or manually relock the device. They will all cause this to happen.
To fix this:
On stock recovery:
Do a factory reset
On TWRP:
Enter any password (doesnt matter what)
Then go to advanced, and do a format of userdata (factory reset from twrp will not fix this it must be a format).
So again, if you go s-on/s-off/lock/unlock/whatever and the phone magically is "encrypted" or "wont decrypt" or just won't work right, FORMAT userdata.
Happy Hacking
jcase said:
This week accidentally (for real, we planned on waiting until we had this PSA published first but goof'd on our build configuration, so it went live early) release SunShine for the HTC 10.
This PSA is need due to how HTC is tying in the keys for userdata encryption on newer devices and firmware. Modern device are encrypted by default, if you set a password or not. This is mostly seamless to those who don't use a password.
The way HTC encrypts the key for user data is to more or less mash up the bootloader lock status, the s-on/s-off status, and the password (for those without a password it is something like "default_password") together. Then the encrypt/decrypt the key.
What this means if you change the lock status, or the s-on/s-off status the phone can no longer decrypt your data, forcing you to wipe the device.
This will happen when you lock the device, unlock the device (which also wipes so who cares), go s-on, or go s-off. This does not matter if you use htcdev.com, SunShine, a new generation javacard, fastboot to go s-on/lock, or manually relock the device. They will all cause this to happen.
To fix this:
On stock recovery:
Do a factory reset
On TWRP:
Enter any password (doesnt matter what)
Then go to advanced, and do a format of userdata (factory reset from twrp will not fix this it must be a format).
So again, if you go s-on/s-off/lock/unlock/whatever and the phone magically is "encrypted" or "wont decrypt" or just won't work right, FORMAT userdata.
Happy Hacking
Click to expand...
Click to collapse
Wow. Awesome. Thanks man. Looking forward to getting the device!
jcase said:
This week accidentally (for real, we planned on waiting until we had this PSA published first but goof'd on our build configuration, so it went live early) release SunShine for the HTC 10.
This PSA is need due to how HTC is tying in the keys for userdata encryption on newer devices and firmware. Modern device are encrypted by default, if you set a password or not. This is mostly seamless to those who don't use a password.
The way HTC encrypts the key for user data is to more or less mash up the bootloader lock status, the s-on/s-off status, and the password (for those without a password it is something like "default_password") together. Then the encrypt/decrypt the key.
What this means if you change the lock status, or the s-on/s-off status the phone can no longer decrypt your data, forcing you to wipe the device.
This will happen when you lock the device, unlock the device (which also wipes so who cares), go s-on, or go s-off. This does not matter if you use htcdev.com, SunShine, a new generation javacard, fastboot to go s-on/lock, or manually relock the device. They will all cause this to happen.
To fix this:
On stock recovery:
Do a factory reset
On TWRP:
Enter any password (doesnt matter what)
Then go to advanced, and do a format of userdata (factory reset from twrp will not fix this it must be a format).
So again, if you go s-on/s-off/lock/unlock/whatever and the phone magically is "encrypted" or "wont decrypt" or just won't work right, FORMAT userdata.
Happy Hacking
Click to expand...
Click to collapse
Thanks
Sent from my HTC One M8 using XDA-Developers mobile app
@jcase, @beaups - Excelent job!!!!!!!
--
wysłane z HTCOne (m9) przez Tapatalk v5.8.0
Excuse my ignorance, but does this mean there is a way to root and s-off a verizon HTC 10?
klarthur said:
Excuse my ignorance, but does this mean there is a way to root and s-off a verizon HTC 10?
Click to expand...
Click to collapse
That's what I'd like to know too but sunshine site says no Verizon yet
Ndaoud360 said:
That's what I'd like to know too but sunshine site says no Verizon yet
Click to expand...
Click to collapse
Dang, that stinks. Hopefully it will soon. I went with the HTC 10 over S7 Edge specifically because I thought it would be rooted... I hope I didn't make a mistake
Sent from my LGLS990 using XDA Free mobile app
I think you can root, but there is no support (yet) for S-off.
Stephen said:
I think you can root, but there is no support (yet) for S-off.
Click to expand...
Click to collapse
Really? I hope so... I wasn't able to find anything about rooting the Verizon HTC 10 yet though... Anyone know of something?
jcase said:
This will happen when you lock the device, unlock the device (which also wipes so who cares)
Click to expand...
Click to collapse
Is it still possible to lock/unlock by editing the pg1fs partition once s-off (adding null over the HTCU flag)? If yes, do you know if this will cause the same decryption problem as using "fastboot flash unlocktoken / fastboot oem lock" ?
My Threads
klarthur said:
Really? I hope so... I wasn't able to find anything about rooting the Verizon HTC 10 yet though... Anyone know of something?
Click to expand...
Click to collapse
All I know is that you may be able to unlock bootloader if vzw doesn't lock it for us. Then root should be obtainable via normal methods. I just hope s-off comes soon. I get my 10 on Thursday if vzw is correct with their dates.
Ndaoud360 said:
All I know is that you may be able to unlock bootloader if vzw doesn't lock it for us. Then root should be obtainable via normal methods. I just hope s-off comes soon. I get my 10 on Thursday if vzw is correct with their dates.
Click to expand...
Click to collapse
Doesn't Verizon normally lock bootloaders though? And if they did lock it... what then?
klarthur said:
Doesn't Verizon normally lock bootloaders though? And if they did lock it... what then?
Click to expand...
Click to collapse
You try unlocking with htcdev website but if that fails. IDK let the professional devs here try to do something to get it unlocked for everyone it think that is how all this works
alray said:
Is it still possible to lock/unlock by editing the pg1fs partition once s-off (adding null over the HTCU flag)? If yes, do you know if this will cause the same decryption problem as using "fastboot flash unlocktoken / fastboot oem lock" ?
Click to expand...
Click to collapse
My advice is, and has always been, don't mess with pg1fs or pg2fs, particularly on some newer HTCs.
klarthur said:
Excuse my ignorance, but does this mean there is a way to root and s-off a verizon HTC 10?
Click to expand...
Click to collapse
Not yet, havent had a chance to play with one
What would happen if I tried to s-off a Verizon variant regardless of wheather it's supported or not?
TickleMeHomo69 said:
What would happen if I tried to s-off a Verizon variant regardless of wheather it's supported or not?
Click to expand...
Click to collapse
Brick?
TickleMeHomo69 said:
What would happen if I tried to s-off a Verizon variant regardless of wheather it's supported or not?
Click to expand...
Click to collapse
If you are talking about sunshine then it wont detect your phone and will say cannot obtain root or unlock bootloader. Then you can't continue...
TickleMeHomo69 said:
What would happen if I tried to s-off a Verizon variant regardless of wheather it's supported or not?
Click to expand...
Click to collapse
For sunshine, it will complain about being unable to get root
For javacard and xtc clip (Currently as of this post) it will complain about wrong version
jcase said:
For sunshine, it will complain about being unable to get root
For javacard and xtc clip (Currently as of this post) it will complain about wrong version
Click to expand...
Click to collapse
Do you know what's different about the Verizon branded version of this phone? Just that they still won't unlock the bootloader? Word is that the unlocked version works with Verizon, so I assumed the hardware was similar or the same. I didn't think it was still like previous devices where the CMDA iterations were completely different from the GSM ones.
Ok so i have read many posts on XDA about bricked nexus 5x's and many others, sometimes the main probelm is the oem isnt unlocked. I myself have a Nexus 5x that is completely stock no custom recovery no root no nothing, i just update the phone, right now on Nougat 7.0 sep security update.
So my question is, should i check the OEM unlocking in the settings ? i will never install any recovery or root but i think by reading the posts, it seems like its a major problem if this is not checked, should i check it just to be safe ?
U_Midrar said:
Ok so i have read many posts on XDA about bricked nexus 5x's and many others, sometimes the main probelm is the oem isnt unlocked. I myself have a Nexus 5x that is completely stock no custom recovery no root no nothing, i just update the phone, right now on Nougat 7.0 sep security update.
So my question is, should i check the OEM unlocking in the settings ? i will never install any recovery or root but i think by reading the posts, it seems like its a major problem if this is not checked, should i check it just to be safe ?
Click to expand...
Click to collapse
If you have issues in your current state they will most likely be hardware related and unfixable via software. But even locked you can completely reinstall the OS via sideloading an OTA or using the TOT method.
Enabling OEM unlock disables Factory Reset Protection (FRP). FRP is a security feature that prevents a stolen device from being activated. There is allot of info about it online if you wish to learn more.
So you need to decide if you want FRP or the ability to flash the factory images.
Sent from my XT1650 using Tapatalk
PiousInquisitor said:
If you have issues in your current state they will most likely be hardware related and unfixable via software. But even locked you can completely reinstall the OS via sideloading an OTA or using the TOT method.
Enabling OEM unlock disables Factory Reset Protection (FRP). FRP is a security feature that prevents a stolen device from being activated. There is allot of info about it online if you wish to learn more.
So you need to decide if you want FRP or the ability to flash the factory images.
Click to expand...
Click to collapse
ok thx dude for the reply, nah i dont care about the FRP. so flashing factory images is easier right ? rather than sideloading or whatever this TOT method is...., and do most mobiles have a oem locked or unlocked ?
U_Midrar said:
ok thx dude for the reply, nah i dont care about the FRP. so flashing factory images is easier right ? rather than sideloading or whatever this TOT method is...., and do most mobiles have a oem locked or unlocked ?
Click to expand...
Click to collapse
Sure, flashing the factory images is probably slightly easier than the other methods. Note that in your case you would need to actually unlock the bootloader to flash the images. With those added steps it's probably faster to sideload.
The Allow OEM unlock toggle has been around since LP I think. An pretty sure it's in phones that shipped with LP. It didn't automagically mean that the phones bootloader can be unlocked though. It should stop disable FRP though.
Sent from my XT1650 using Tapatalk
Yes, most, I think all OEMs leave the possibility to unlock the bootloader.
By default the bootloader is locked on most OEMs (Sony, Samsung, HTC, Motorola, even Nexus devices).
For Nexus devices it's a simple one liner to unlock/lock the bootloader which will also trigger a data wipe but. On Nexus devices it doesn't void your warranty.
For most other OEMs phones you have to follow some steps and usually get some kind of code in order to unlock the bootloader the first time. This will void your warranty!
If you don't know whether or not you should unlock/lock the bootloader, the answer is: NO!
It seems you're not modifying your phones software (Custom Kernel, Custom Rom, Root etc) and you seem to have no intention doing so. So it's not needed and even less "secure" than with locked bootloader. If you do, you should know that you have to unlock the bootloader in order to change the phones software.
Why would you want to unlock the bootloader when the only reason to do so is to modify the software and you do not plan to do this?
On a stock nexus there is no need to unlock the bootloader, you can even reflash your phone with locked bootloader with the stock software image.
creambyemute said:
Yes, most, I think all OEMs leave the possibility to unlock the bootloader.
By default the bootloader is locked on most OEMs (Sony, Samsung, HTC, Motorola, even Nexus devices).
For Nexus devices it's a simple one liner to unlock/lock the bootloader which will also trigger a data wipe but. On Nexus devices it doesn't void your warranty.
For most other OEMs phones you have to follow some steps and usually get some kind of code in order to unlock the bootloader the first time. This will void your warranty!
If you don't know whether or not you should unlock/lock the bootloader, the answer is: NO!
It seems you're not modifying your phones software (Custom Kernel, Custom Rom, Root etc) and you seem to have no intention doing so. So it's not needed and even less "secure" than with locked bootloader. If you do, you should know that you have to unlock the bootloader in order to change the phones software.
Why would you want to unlock the bootloader when the only reason to do so is to modify the software and you do not plan to do this?
On a stock nexus there is no need to unlock the bootloader, you can even reflash your phone with locked bootloader with the stock software image.
Click to expand...
Click to collapse
yo dude thx for the reply, as i said in my first post, i saw some bricked nexus 5x (they didnt mod anything i think) that couldnt be repaired cause he had the option unchecked about OEM, that is why i was asking for like a safety precaution that if something goes wrong it would be okay cause oem could be unlocked then... what do u say now ? (and yea im not gonna ever mod anything in the phone, learned fom my last phone which i somehow bricked and a man fixed it for for 5$ )
U_Midrar said:
yo dude thx for the reply, as i said in my first post, i saw some bricked nexus 5x (they didnt mod anything i think) that couldnt be repaired cause he had the option unchecked about OEM, that is why i was asking for like a safety precaution that if something goes wrong it would be okay cause oem could be unlocked then... what do u say now ? (and yea im not gonna ever mod anything in the phone, learned fom my last phone which i somehow bricked and a man fixed it for for 5$ )
Click to expand...
Click to collapse
That catch is if if you checked OEM unloking and chose to not perform oem unlock command now.
When something did went wrong afterward, you are able to perform oem unlock but it will wipe your data.
There is no point for doing it.
HebeGuess said:
That catch is if if you checked OEM unloking and chose to not perform oem unlock command now.
When something did went wrong afterward, you are able to perform oem unlock but it will wipe your data.
There is no point for doing it.
Click to expand...
Click to collapse
so i shouldnt do it like just leave it be ?
F IT I DID IT
i just read this site and also got to know a bootloop can occur with OTA update so yea i have done it.
Site: http://android.wonderhowto.com/news...ting-before-modding-anything-android-0167840/
I'm not a developer, just an enthusiast. Trying to understand if having an unlocked bootloader causes my device to be vulnerable to fastboot attacks? Or is my devices data still encrypted as long as i have a password? I know booting into my twrp recovery requires my password before decryption.. but can't they just fastboot boot a twrp image and gain access to my data somehow? or no? Can someone with knowledge explain?
If they have your phone in their hand yes it is a risk. They have access to all it's contents.
How hard is it to relock your bootloader? My bootloader is unlocked and my phone was rooted (i seem to have lost my root somehow maybe through an update). I am considering relocking my bootloader so that I can try Android Pay. Is this possible and is there a tutorial?
TolaSkamp said:
How hard is it to relock your bootloader? My bootloader is unlocked and my phone was rooted (i seem to have lost my root somehow maybe through an update). I am considering relocking my bootloader so that I can try Android Pay. Is this possible and is there a tutorial?
Click to expand...
Click to collapse
Of course there are tutorials, tons of them. One quick note, you should flash the latest factory image while you are unlocked to make sure everything is fully stock. No reason to save the data, just use flash-all, since relocking will wipe it all anyway. You could also just flash a kernel such as Elemental to access Android Pay.
bobby janow said:
Of course there are tutorials, tons of them. One quick note, you should flash the latest factory image while you are unlocked to make sure everything is fully stock. No reason to save the data, just use flash-all, since relocking will wipe it all anyway. You could also just flash a kernel such as Elemental to access Android Pay.
Click to expand...
Click to collapse
Thanks for the reply. I will probably just flash the Elemental kernel and leave the bootloader unlocked, thanks. I seem to have lost my root, would I need to be rooted. I really rather not have to wipe all my data.
TolaSkamp said:
Thanks for the reply. I will probably just flash the Elemental kernel and leave the bootloader unlocked, thanks. I seem to have lost my root, would I need to be rooted. I really rather not have to wipe all my data.
Click to expand...
Click to collapse
No need to be rooted. Just boot to twrp and flash the kernel. AP with then work I believe. Try it out, I'm locked so I can't say for sure but on my 5x it works.
Doesn't Android Device Manager (or something there of) have some protection against lost/stolen phones. I recall reading that once you have your Google account sync'ed to the phone, you will need your Google account password to restart the phone even after a factory reset.
robchow said:
Doesn't Android Device Manager (or something there of) have some protection against lost/stolen phones. I recall reading that once you have your Google account sync'ed to the phone, you will need your Google account password to restart the phone even after a factory reset.
Click to expand...
Click to collapse
This is easily bypassed. It will keep the honest people out, but with minimal effort someone could get past it.
Sent from my Pixel XL using Tapatalk
Here is the Android feature I was referring to about needing Google account's password:
Factory Reset Protection (FRP)
https://support.google.com/pixelphone/answer/6172890?hl=en
Am I correct that this statement "If you have Developer options turned on, you can also turn off device protection from your device's Settings app Settings. Tap Developer options and then OEM Unlocking" relates to bootloader unlock? As such, if unlocked bootloader then this FRP isn't active? Can FRP be turned on with unlocked bootloader?
superchilpil said:
This is easily bypassed. It will keep the honest people out, but with minimal effort someone could get past it.
Click to expand...
Click to collapse
Are you suggesting that FRP is easily bypassed?
If you have no plans to root the phone is there any reason to unlock the bootloader?
It would probably break Safety net and Android pay. BUT if you're unlocked, you have ability to flash factory images. That could be beneficial something goes really bad and your device won't boot up. You're also less secure with it unlocked.
Sent from my marlin using XDA Labs
You can always lock and unlock the bootloader when you want.
I would say you should at least have the option checked on in the Developer settings.
So just in case something happened and you can't fully boot the phone. you can still get into it and unlock the bootloader and do what you need to do.
This happened to a friend of mine where something happened and couldn't fully boot and couldn't unlock bootloader cause the option was never checked.
I don't believe the unlock option stays enabled after it boots up.
I would argue why WOULDN'T you unlock the bootloader? Regardless of rooting, an unlocked bootloader is a safety net for when things go south. Phone decides to bootloop tomorrow? No big deal, flash the latest images via fastboot and start from scratch.
Sure there's the counter argument of the phone being much less secure and vulnerable in the hands of a person who is tech savvy and stole/found your device. I'm not worried about my phone being stolen so I ALWAYS unlock my bootloader.
Pain-N-Panic said:
I would argue why WOULDN'T you unlock the bootloader? Regardless of rooting, an unlocked bootloader is a safety net for when things go south. Phone decides to bootloop tomorrow? No big deal, flash the latest images via fastboot and start from scratch.
Sure there's the counter argument of the phone being much less secure and vulnerable in the hands of a person who is tech savvy and stole/found your device. I'm not worried about my phone being stolen so I ALWAYS unlock my bootloader.
Click to expand...
Click to collapse
or just flash the full OTA image without an unlocked bootloader.
mngdew said:
You can always lock and unlock the bootloader when you want.
Click to expand...
Click to collapse
Does re-locking the bootloader wipe the phone?
foosion said:
Does re-locking the bootloader wipe the phone?
Click to expand...
Click to collapse
Yes, it does. That's why you should unlock or lock the bootloader when flashing factory images.
mngdew said:
Yes, it does.
Click to expand...
Click to collapse
Thanks
mngdew said:
That's why you should unlock or lock the bootloader when flashing factory images.
Click to expand...
Click to collapse
I don't understand what you mean by this.
You have to unlock the bootloader to flash a factory image and you can eliminate the w flag so that flashing the factory image won't wipe the phone.
uicnren said:
or just flash the full OTA image without an unlocked bootloader.
Click to expand...
Click to collapse
Very true. If the phone goes into booploop due to a bad zip or whatever other reason you have a bricked device with no options to recover.
It's healthy for me to unlock my Bootloader ASAP on XDA!
Unlocking the bootloader was always the very first thing I did when I got a new phone. However, I use Android Pay all the time, and Google seems very determined to break AP for unlocked bootloaders with every new patch. Sure, someone usually finds a way to get it working again, but that sometimes takes time, and I simply use AP too much to deal with it. As long as AP won't work officially with an unlocked bootloader, mine stays locked unless I'm flashing an image, and even then, gets locked right after. Luckily, OTAs are posted by Google now, often at the same time as the Factory Images, so it hasn't really been an issue for me.
akenis said:
It would probably break Safety net and Android pay. BUT if you're unlocked, you have ability to flash factory images. That could be beneficial something goes really bad and your device won't boot up. You're also less secure with it unlocked.
Sent from my marlin using XDA Labs
Click to expand...
Click to collapse
Thank you what actually is compromised when phone is unlocked?
uicnren said:
or just flash the full OTA image without an unlocked bootloader.
Click to expand...
Click to collapse
How can you flash with a locked bootloader?
painfree said:
Thank you what actually is compromised when phone is unlocked?
Click to expand...
Click to collapse
Data?
https://www.google.com/amp/s/www.ho...unlocking-your-android-phones-bootloader/amp/
Sent from my marlin using XDA Labs
painfree said:
If you have no plans to root the phone is there any reason to unlock the bootloader?
Click to expand...
Click to collapse
If you ever contemplate going onto the Verizon network, when you first boot up after placing VZN sim into the phone,
the ability to ever unlock again is eliminated. You could relock it, but it will have the Unlock option in Developer
Option greyed out forever after that. I would unlock it maybe because of Verizon thing, but also to be able to flash factory a image in case I ever mess up the phone.
michaelbsheldon said:
If you ever contemplate going onto the Verizon network, when you first boot up after placing VZN sim into the phone,
the ability to ever unlock again is eliminated. You could relock it, but it will have the Unlock option in Developer
Option greyed out forever after that. I would unlock it maybe because of Verizon thing, but also to be able to flash factory a image in case I ever mess up the phone.
Click to expand...
Click to collapse
As long as you have the Google version it should never grey out on you at least that's how it was with the first pixels. I have Verizon I've never had it grey out.
jt3 said:
Unlocking the bootloader was always the very first thing I did when I got a new phone. However, I use Android Pay all the time, and Google seems very determined to break AP for unlocked bootloaders with every new patch. Sure, someone usually finds a way to get it working again, but that sometimes takes time, and I simply use AP too much to deal with it. As long as AP won't work officially with an unlocked bootloader, mine stays locked unless I'm flashing an image, and even then, gets locked right after. Luckily, OTAs are posted by Google now, often at the same time as the Factory Images, so it hasn't really been an issue for me.
Click to expand...
Click to collapse
This. Android Pay is pretty convenient and I always told myself I didn't need it compared to unlock+root. Wish Google would allow AP with unlocked bootloader but I can understand why they don't from a security standpoint.
Sent from my Pixel 2 XL using Tapatalk
foosion said:
Thanks
I don't understand what you mean by this.
You have to unlock the bootloader to flash a factory image and you can eliminate the w flag so that flashing the factory image won't wipe the phone.
Click to expand...
Click to collapse
When you unlock the bootloader, phone is wiped automatically.