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...
I recently got a new motherboard installed to my Nexus 5X by LG due to the recent bootloop related to TWRP and Android N. My problem is that after unlocking bootloader, and doing the mandatory device wipe that comes with it, the bootloader gets reverted to locked state when I restart my device. I've tried multiple cables, USB ports, fastboot binaries, but nothing seems to make the device behave any differently. I am able to flash things in fastboot mode after unlocking the device as long as I don't restart the device. TWRP installs just fine, but obviously throws a bunch of errors because I cannot enter recovery mode without restaring (which gets the bootloader locked again). Is there any tricks I could try, or is it my NAND that is acting up as it seems to revert to previous state on power loss? As far as I can tell, the rest of the memory chip is working just fine, /sdcard does not lose any data when restarting etc. I was able to install Nougat on the device by flashing factory images.
I have not bought my device from Google and thus it is covered only by LG's limited warranty, which probably means that this is something they will not repair as unlocking the bootloader probably voids their warranty in any case. Am I just out of luck?
neree said:
I recently got a new motherboard installed to my Nexus 5X by LG due to the recent bootloop related to TWRP and Android N. My problem is that after unlocking bootloader, and doing the mandatory device wipe that comes with it, the bootloader gets reverted to locked state when I restart my device. I've tried multiple cables, USB ports, fastboot binaries, but nothing seems to make the device behave any differently. I am able to flash things in fastboot mode after unlocking the device as long as I don't restart the device. TWRP installs just fine, but obviously throws a bunch of errors because I cannot enter recovery mode without restaring (which gets the bootloader locked again). Is there any tricks I could try, or is it my NAND that is acting up as it seems to revert to previous state on power loss? As far as I can tell, the rest of the memory chip is working just fine, /sdcard does not lose any data when restarting etc. I was able to install Nougat on the device by flashing factory images.
I have not bought my device from Google and thus it is covered only by LG's limited warranty, which probably means that this is something they will not repair as unlocking the bootloader probably voids their warranty in any case. Am I just out of luck?
Click to expand...
Click to collapse
What TWRP errors are you getting? TWRP shouldn't care if your device is locked or not. It doesn't do its operations through the bootloader.
Also just as a sanity check, you enabled OEM unlocking under developer options and you did fastboot oem unlock (or equivalent) on the phone right?
sfhub said:
What TWRP errors are you getting? TWRP shouldn't care if your device is locked or not. It doesn't do its operations through the bootloader.
Also just as a sanity check, you enabled OEM unlocking under developer options and you did fastboot oem unlock (or equivalent) on the phone right?
Click to expand...
Click to collapse
For the TWRP errors I'll have to get back on when I get back home to my device. For the other part, yes I did enable the unlocking under dev options, and used fastboot flashing unlock (also tried fastboot oem unlock). They both do go through and wipe my device. The bootloader also stats that current state is unlocked after the wipe. However after restaring the device back to bootloader causes the state change back to locked.
Did you install the motherboard or did LG?
I think something didn't install correctly on your phone. There is probably somewhere on the phone where they store the persistent unlocked state of the bootloader and that isn't working.
If you are bold, you can try using LGUP and the TOT file to reinstall you phone (this is a more in-depth reinstall than just factory images)
However there is always the risk you make things worse on your phone than they currently are.
If you have 16GB then you need to install the Android N OTA afterwards to get the partition tables set correctly.
sfhub said:
Did you install the motherboard or did LG?
I think something didn't install correctly on your phone. There is probably somewhere on the phone where they store the persistent unlocked state of the bootloader and that isn't working.
If you are bold, you can try using LGUP and the TOT file to reinstall you phone (this is a more in-depth reinstall than just factory images)
However there is always the risk you make things worse on your phone than they currently are.
If you have 16GB then you need to install the Android N OTA afterwards to get the partition tables set correctly.
Click to expand...
Click to collapse
LG (or whatever company it is that does it for them here) installed the new board. I think I'll pass on doing the deeper installations for now as I'm currently trying to sell the device off to someone who wouldn't have any use to unlocked bootloader. Was just wondering if I completely missed something that might cause the device to do this so I could either use it again by myself or sell it as fully functioning Nexus device.
neree said:
I think I'll pass on doing the deeper installations for now as I'm currently trying to sell the device off to someone who wouldn't have any use to unlocked bootloader.
Click to expand...
Click to collapse
That's a good call. Actually I wouldn't mess around too much with the phone if you are going to sell it.
Just make sure you remove any pin/pattern/password from the phone and to be extra safe, remove your google account from the phone *PRIOR* to factory reset or you will run into Factory Reset Protection (FRP) where you will have to give the buyer your google account and password so they can do first install and switch to their own account.
I had a Nexus 5X with stock Android 6 software. Android Pay was working fine.
I was having a few lag issues and noticed the final Nexus factory image was available for Android 7 so I decided to unlock my bootloader and install the factory image. After I installed it, Android Pay was still working fine.
Then I received an OTA update for the monthly security hotfixes which I installed. Since doing this, Android Pay doesn't work. It says something about my phone being rooted/unlocked and that Android Pay does not support this.
Can anyone tell me why this is happening? I don't need to keep my bootloader unlocked so if locking will allow me to resolve the issue without losing data then I can do this. Can anyone guide me please?
Try flashing a kernel from The Flash or Franco.
Both have a line of code that should stop the bootloader error in safetynet
Thank you but I don't want to put on any custom stuff. I just want to go back to a stock Android 7.0 ROM that works with Android Pay. I don't need root, or an unlocked bootloader. How can I go back to stock?
You can use something like wugs nexus tool.
Although some have mentioned you can brick your device trying to lock the bootloader.
Personally I have never done it. Others might have more experience.
It may or may not be easier to lock than to use a custom kernel. YMMV.
One benefit of the kernel is increased performance on your phone.
Oh and if you lock your bootloader it will completely wipe your phone. E.g. You will lose your data.
Edit.. Root isn't needed for a kernel either
Start the device in fastboot mode again, as described above.
Execute:
fastboot flashing lock
or, for older devices, run:
fastboot oem lock
Locking bootloader will wipe the data on some devices. After locking the bootloader, if you want to flash the device again, you must run fastboot oem unlock again, which will wipe the data.
Source: https://developers.google.com/android/nexus/images
Ah okay, thanks for the info. What I should have done originally was re-lock the bootloader straight after I flashed the ROM. Unfortunately, I setup the device after flashing the ROM and kept the bootloader unlocked which is why I'm stuck right now. Okay, time to backup my stuff up and re-lock the bootloader. Thanks everyone.
Hello!
So, I've purchased a T-Mobile LG G8 ThinQ phone for use in Canada and wanted to remove the T-Mobile splash.
After reading a bit on the forums here, it seems like it'll be too complex for someone like me. (I'm lazy)
So, I uninstalled Magisk, which supposedly uninstalls root and I'm looking to relock my boot loader.
Just I'm having a hard time getting back into bootloader with the vol- and power button method, and using adb to reboot into bootloader doesn't seem to give the desired results.
The phone just reboots like normal with the unlocked bootloader warning.
Reason I wanna relock it is so that I can use Android Pay again and using Magisk Hide or the alternative would require them to give a guaranteed result.
One day it could be patched and I won't be near a PC to resolve the issue and I personally don't like carrying my wallet.
cheddarest said:
Hello!
So, I've purchased a T-Mobile LG G8 ThinQ phone for use in Canada and wanted to remove the T-Mobile splash.
After reading a bit on the forums here, it seems like it'll be too complex for someone like me. (I'm lazy)
So, I uninstalled Magisk, which supposedly uninstalls root and I'm looking to relock my boot loader.
Just I'm having a hard time getting back into bootloader with the vol- and power button method, and using adb to reboot into bootloader doesn't seem to give the desired results.
The phone just reboots like normal with the unlocked bootloader warning.
Reason I wanna relock it is so that I can use Android Pay again and using Magisk Hide or the alternative would require them to give a guaranteed result.
One day it could be patched and I won't be near a PC to resolve the issue and I personally don't like carrying my wallet.
Click to expand...
Click to collapse
I'm not an expert (or even that experienced with phone flashing), but a li'l Googling gives this result. The relevant part being:
Re-locking the bootloader​To re-lock the bootloader:
For newer devices (2015 and higher):
fastboot flashing lock
For older devices (2014 and lower):
fastboot oem lock
Note: Re-locking the bootloading on a Motorola Xoom erases all user data (including the shared USB data).
blaacksheep said:
I'm not an expert (or even that experienced with phone flashing), but a li'l Googling gives this result. The relevant part being:
Re-locking the bootloader​To re-lock the bootloader:
For newer devices (2015 and higher):
fastboot flashing lock
For older devices (2014 and lower):
fastboot oem lock
Note: Re-locking the bootloading on a Motorola Xoom erases all user data (including the shared USB data).
Click to expand...
Click to collapse
Sure, I'll try that if you can help me figure out why I can't get back into the bootloader.
You need to use QFIL to put flash back the engineering abl file to get fastboot. Then you can run the command.
armodons said:
You need to use QFIL to put flash back the engineering abl file to get fastboot. Then you can run the command.
Click to expand...
Click to collapse
Thank you! That worked, I was flashing abl_a and abl_b with the backup images to see if that did anything.
Week ago I flashed the android 14 dev, don't liked it and yesterday flashed A13 (TQ1A.230205.002) with Android Flash Tool. Today I saw that I can't add my credit card to the Google Pay. I checked in settings and found out that my bootloader unlocked but the button is unavailable.
What can I do?
If your phone was rooted, then do a factory reset. Download and install the Google Platform tools, or if adb and fastboot drivers are installed system-wide, that's fine.
Connect phone to PC in fastboot mode
Enter the first command "fastboot devices"
Then type, "fastboot flashing unlock"
Confirm on your device to lock the bootloader
That's it. If you want a detailed guide, here are the instructions on how to unlock/relock the bootloader on a Pixel phone.
wrkadung said:
If your phone was rooted, then do a factory reset. Download and install the Google Platform tools, or if adb and fastboot drivers are installed system-wide, that's fine.
Connect phone to PC in fastboot mode
Enter the first command "fastboot devices"
Then type, "fastboot flashing unlock"
Confirm on your device to lock the bootloader
That's it. If you want a detailed guide, here are the instructions on how to unlock/relock the bootloader on a Pixel phone.
Click to expand...
Click to collapse
Locking with adb will erase all my data?
max_134 said:
Locking with adb will erase all my data?
Click to expand...
Click to collapse
Yes, of course! Unlocking and relocking will erase and factory reset your phone, I use Google One to take backups.
Alternatively, you can also use the Android flash tool, and it will automatically do it for you. You just have to follow the on-screen instructions, and it will ask for your confirmation to lock the bootloader, and you also get the option to wipe data (never tried unchecking the wipe data option).
Here is the video tutorial, if you need it.
EDIT: apologies for covering much of what has already been discussed by @wrkadung, got ninja'd a bit there...
I wouldn't risk locking the bootloader via platform-tools....so many instances from all the way back from the original Pixel has had countless members hard-brick their Pixel's relocking the bootloader.
The safest way to go about it is to use the Android Flash Tool to flash both slots and relock bootloader; most hard bricks happen when it's not flashed to both slots and/or the improper factory image is used...
But the OEM unlocking being greyed out is sometimes SOP after unlocking the bootloader. It's not really anything to be concerned about. If Wallet isn't working properly, it is doubtful it is simply having the unlocked bootloader; Wallet usually doesn't work when rooted than it is the fact of an unlocked bootloader. You should try Force Stop-ing and Clear Data Wallet first. Then even "uninstall updates" and/or revert to an older version before locking the bootloader. ESPECIALLY if you don't wish to wipe the device by relocking the bootloader...
max_134 said:
Week ago I flashed the android 14 dev, don't liked it and yesterday flashed A13 (TQ1A.230205.002) with Android Flash Tool. Today I saw that I can't add my credit card to the Google Pay. I checked in settings and found out that my bootloader unlocked but the button is unavailable.
What can I do?
Click to expand...
Click to collapse
Google pay will work with an unlocked bootloader.
simplepinoi177 said:
EDIT: apologies for covering much of what has already been discussed by @wrkadung, got ninja'd a bit there...
I wouldn't risk locking the bootloader via platform-tools....so many instances from all the way back from the original Pixel has had countless members hard-brick their Pixel's relocking the bootloader.
The safest way to go about it is to use the Android Flash Tool to flash both slots and relock bootloader; most hard bricks happen when it's not flashed to both slots and/or the improper factory image is used...
But the OEM unlocking being greyed out is sometimes SOP after unlocking the bootloader. It's not really anything to be concerned about. If Wallet isn't working properly, it is doubtful it is simply having the unlocked bootloader; Wallet usually doesn't work when rooted than it is the fact of an unlocked bootloader. You should try Force Stop-ing and Clear Data Wallet first. Then even "uninstall updates" and/or revert to an older version before locking the bootloader. ESPECIALLY if you don't wish to wipe the device by relocking the bootloader...
Click to expand...
Click to collapse
Yes, definitely, a stock factory image is required. Most people directly lock the bootloader on a rooted phone using adb & fastboot commands, which results in bricking the phone.
On stock firmware, it is working perfectly. Right now I am working on a video tutorial for Pixel 7 and it worked fine without any issues, it was just bootloader unlocked device (not rooted).