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.
Would there be a way to do one-click-root on the Motorola Moto G5 (XT1672) or another way that is easy and does not do a factory reset? Thanks!
vanhead said:
Would there be a way to do one-click-root on the Motorola Moto G5 (XT1672) or another way that is easy and does not do a factory reset? Thanks!
Click to expand...
Click to collapse
I really don't know how this is going from root very well, but as I understand it, you need to unlock the bootloader of the device (which requires a factory reset). If you already have the bootloader unlocked, try KingRoot, The truth is the only root of a click that I know, I have not really tried it on this device, but on an old phone, and it worked fine. The only problem I have had and I do not know if it is the fault of the device or KingRoot, and is that when I try to uninstall an application which I gave it the root permissions, the phone restarts, to uninstall an application I had to deny it permissions and then I could uninstall it, I repeat, I do not know if it is a problem that only happens to me
Postdata: Sorry for my english
vanhead said:
Would there be a way to do one-click-root on the Motorola Moto G5 (XT1672) or another way that is easy and does not do a factory reset? Thanks!
Click to expand...
Click to collapse
Rooting the phone does not require a factory reset but unlocking the bootloader does
So if you haven't unlocked the bootloader you will have to factory reset it during the process
If the bootloader is already unlocked you do not need to factory reset your device again in order to root it
Magisk should be the only way you should root your device - do not use other methods like kingroot as this has bloat and is not systemless (meaning it alters the system partition)
You need to root with magisk in order to maintain the system partition in its original state in order to pass basic integrity & to be able to pass cts profile (may need a magisk module) and to hide the fact you are rooted from apps that will not work if your device is rooted
TheFixItMan said:
Rooting the phone does not require a factory reset but unlocking the bootloader does
So if you haven't unlocked the bootloader you will have to factory reset it during the process
If the bootloader is already unlocked you do not need to factory reset your device again in order to root it
Magisk should be the only way you should root your device - do not use other methods like kingroot as this has bloat and is not systemless (meaning it alters the system partition)
You need to root with magisk in order to maintain the system partition in its original state in order to pass basic integrity & to be able to pass cts profile (may need a magisk module) and to hide the fact you are rooted from apps that will not work if your device is rooted
Click to expand...
Click to collapse
Thank you for your help. I tried several One-click-root, none worked, so I researched, they only work on android 7.
Could you tell me if it is possible to Downgrade from Android 8.1 to 7 without unlocking the bootloader? All the videos I find, the bootloaders are already unlocked.
vanhead said:
Thank you for your help. I tried several One-click-root, none worked, so I researched, they only work on android 7.
Could you tell me if it is possible to Downgrade from Android 8.1 to 7 without unlocking the bootloader? All the videos I find, the bootloaders are already unlocked.
Click to expand...
Click to collapse
As mentioned before - you cannot root a device without unlocking the bootloader!
Why do you want a one click root? They are buggy & full of bloatware
Magisk should be the only method you should be using to root a device - either flashing through twrp or by patching the kernel and flashing the patched image through fastboot
What ever method you choose you need an unlocked bootloader to root!
Why would you want to downgrade? You can flash all parts of a firmware image except gpt & bootloader but again you might need an unlocked bootloader to do this but I don't see the point
TheFixItMan said:
As mentioned before - you cannot root a device without unlocking the bootloader!
Why do you want a one click root? They are buggy & full of bloatware
Magisk should be the only method you should be using to root a device - either flashing through twrp or by patching the kernel and flashing the patched image through fastboot
What ever method you choose you need an unlocked bootloader to root!
Why would you want to downgrade? You can flash all parts of a firmware image except gpt & bootloader but again you might need an unlocked bootloader to do this but I don't see the point
Click to expand...
Click to collapse
In fact, since i need to unlock the bootloader to root, for now, it wouldn't be a good option for me.
But there are apps that I really need and that don't work correctly on Android versions above Nougat, if I could get Downgrade without losing data, that would help me immensely for now.
Is there a possibility that I can downgrade to android 7 with the locked bootloader ? What can go wrong? Brick?
vanhead said:
In fact, since i need to unlock the bootloader to root, for now, it wouldn't be a good option for me.
But there are apps that I really need and that don't work correctly on Android versions above Nougat, if I could get Downgrade without losing data, that would help me immensely for now.
Is there a possibility that I can downgrade to android 7 with the locked bootloader ? What can go wrong? Brick?
Click to expand...
Click to collapse
You would have to format data - it would bootloop otherwise and I've already said. Flash all parts of firmware except gpt and bootloader however it may not flash as your bootloader is not unlocked
If the flashing goes wrong and your bootloader is not unlocked you will not be able to recover the device without taking it to a repair shop
My advice just don't bother - if you want to mod your phone unlock the bootloader!
And what app doesn't work above nougat?