"OEM unlock" Disabled - Githubissues

alengh commented 5 years ago

Any help with OEM unlock Disabled ? The Build is signed and did the mistake of re-lock the bootloader :(

Because i did signe the Build i am no longer able to (ADB Sideload) to update with OTA or Stock zip

Is there any other way to flash another buil or the factory one ?

Thx in advance

alengh commented 5 years ago

Finally Got the solution. Hope it will Help Others :

I did notice on the Device that there was a Guest User account but i had no way to remove it.

No need to be on internet or so on

To do so i managed to :

1 - Wipe (factory reset) : Setting / System / Advanced / Reset options / Erase all data (Factory reset) => (Find the entry according to your Built / Android version)

2- Boot in Safe mode (Turn off the device / Hold the power on button till Google screen then release and hold pressed the volum down button until the device finish booting.

3- Go to setting / System / Advanced / Multiple users

4- tap on Guest, then on "Menu" the [...] on top right of the window

5- "Delete Guest User from this device" and confirm

6- Ones again Setting / System / Advanced / Reset options / Erase all data (Factory reset)

7- Your Device will reboot and at this time hold pressed the volum down button until the device finish booting (this time it will take longer to finish booting) . (that will boot the device in safe mode).

8- Enable Developer mode

9 - Goto Developer options and you are done (The OEM unlock option is back and you can enable or disable it)

anestisb commented 5 years ago

I don't understand why you had to go this long way instead of simply opening the Developer Options and OEM unlock again. Anyways, I'm labelling this as a question and closing.

alengh commented 5 years ago

Hi @anestisb Thank you for your answer .
The OEM unlock was disabled (Gray and not active) due to signed custom build and boutloader locked with Fastboot. (there was no way to unlock again without my steps).

anestisb commented 5 years ago

But if you flash your self-signed AVB key (fastboot flash avb_custom_key) you have full control over the bootloader locking state. Did you skipped that step?

Btw which device & OS version are you using?

To the best of my knowledge only with Pixel 2 & Pixel 3 that support AVB 2.0 you can re-lock (yellow state) with a self-signed key. For Pixel if you lock with self-signed you cannot boot kernel (boot.img) and device should failover to the second slot (or lose the device if both slots flashed with non-official images) and still be able to re-unlock via the normal path. The path you describe above seems very bizarre and I cannot relate it to the expected AVB flows.

alengh commented 5 years ago

It is a "Google store" Pixel (Sailfish Android P 9) , and yes i confirm did lock with self-signed (no more orange state but yellow state) . kernel boot perfectly , both slots flashed with images of self_signed build, the built run perfectly .

thestinger commented 5 years ago

You can lock the bootloader with a custom build on 1st generation Pixels. It figures out the public key at runtime from the boot image, shows the fingerprint and enforces that it doesn't change indirectly by binding the TEE functionality like the keystore and disk encryption to it.

thestinger commented 5 years ago

I don't know why OEM unlocking would be grayed out though. The recovery steps don't make any sense.

alengh commented 5 years ago

I don't know why OEM unlocking would be grayed out though.

That's what i experienced !

The recovery steps don't make any sense.

You may be right but that's what rescued my device ;-)

anestisb commented 5 years ago

You can lock the bootloader with a custom build on 1st generation Pixels. It figures out the public key at runtime from the boot image, shows the fingerprint and enforces that it doesn't change indirectly by binding the TEE functionality like the keystore and disk encryption to it.

Interesting, since this translates to a light violation of secure boot. Let's keep out of the equation for the time being the Keymaster RoT diversifier hash (sha256(sha256(pkey_e + pkey_m) + unlock state)) that is sent from SBL to TZ app to bind the FBE keys.

AFAIK Pixel's SBL is based on QC's LK. The boot_linux_from_mmc() exec flows that are verifying and loading the boot.img are invoking verify_signed_bootimg if device.is_unlocked (as read from RPMB) is false. verify_signed_bootimg should then use a hardcoded pub key (certBuffer in certificate.c) to verify boot.img signature appended at the end of the partition. Since SBL is verified from QC's trusted boot, the pub key is trusted and can then verify boot.img from which init's fs_mgr verifies the verity key for system & vendor.

When device's bootloader is unlocked, the verify_signed_bootimg flows that are wrapped from device.is_unlocked (which is now true) are never invoked, thus allowing the device to boot with self-signed images which verify themselves (pub-key extracted from image - see boot_verify_image() calls).

Now if a self-signed image is allowed to boot with a locked bootloader it means that Pixel's SBL deviates from the upstream LK design (and what Android docs imply about secure boot). The only logical design that I can think of without violating the secure boot principles is that the last known pub_key used before locking the bootloader is saved in RPMB and used to verify the following images. Otherwise, how the SBL will recognise a legit unlocked-locked self-signed image vs a rogue boot.img (e.g. flashed via chip-off)? I get there is always the Keymaster FBE key release fail-safe to protect userdata, but still doubt that Google will enable these secure boot flows.

I think it's time for a bindiff between an upstream MSM8996 LK build and Pixel's SBL.

alengh commented 5 years ago

Right now i am at work but as soon as i am at home i will send/attach logs of the device

thestinger commented 5 years ago

@anestisb It's how it was originally documented as working. The documentation at https://source.android.com/security/verifiedboot/boot-flow was updated for AVB. The flow chart originally showed that if verification with the hard-wired key failed, it would fall back to using the embedded key and showing the yellow boot state warning if the device supported it. I talked about the weakness of this and lack of direct enforcement of the key on Twitter in the past. AVB is a major improvement over how it worked previously where it relied entirely on indirect enforcement via the TEE or the user noticing the appearance of a warning (for stock) or change of displayed fingerprint.

The displayed fingerprint has also never been long enough to be meaningful on the release of devices. I've reported this for each device they've released, and they've acknowledged the issue each time and even done work to address it before the problem recurs with the release of the next device. The documentation even currently recommends "For the hex-number, use the first 8 digits of the sha256 of the libavb representation of the public key used for verification, for example f7a24de1.". There have also been bugs in the calculation on the fingerprint before AVB was introduced. I'm not sure if they ever got around to fixing it on 1st generation Pixels.

anestisb commented 5 years ago

I remember reading on Twitter about the second part, although totally missed the first. Wow, that was unexpected.

vamsirocks commented 5 years ago

You can lock the bootloader with a custom build on 1st generation Pixels. It figures out the public key at runtime from the boot image, shows the fingerprint and enforces that it doesn't change indirectly by binding the TEE functionality like the keystore and disk encryption to it.

@anestisb It's how it was originally documented as working. The documentation at https://source.android.com/security/verifiedboot/boot-flow was updated for AVB. The flow chart originally showed that if verification with the hard-wired key failed, it would fall back to using the embedded key and showing the yellow boot state warning if the device supported it. I talked about the weakness of this and lack of direct enforcement of the key on Twitter in the past. AVB is a major improvement over how it worked previously where it relied entirely on indirect enforcement via the TEE or the user noticing the appearance of a warning (for stock) or change of displayed fingerprint.

The displayed fingerprint has also never been long enough to be meaningful on the release of devices. I've reported this for each device they've released, and they've acknowledged the issue each time and even done work to address it before the problem recurs with the release of the next device. The documentation even currently recommends "For the hex-number, use the first 8 digits of the sha256 of the libavb representation of the public key used for verification, for example f7a24de1.". There have also been bugs in the calculation on the fingerprint before AVB was introduced. I'm not sure if they ever got around to fixing it on 1st generation Pixels.

Hi first of all thank you for your detailed answer. It really helpful to me. I had also faced the issue of bootloader unlocking issue on my pixel 2 xl device and source code i had used is android-8.1.0 r28 and build id OPM4.171019.016.B1.

So based on above answer I got idea that since not flashing custom generated avb key i am unable unlock the boot loader , oem ulock is grayed out in developer options.

Please kindly help me how this avb_custom_key playing key roll in verified boot. Even not flashing this key also i had got yellow screen warning and device booting perfectly in locked state, even if i am changing only this avb custom key also its booting perfectly in yellow screen . i am unable to understand what it ensuring .

thestinger commented 5 years ago

I don't understand what you're saying. It sounds like you have your device unlocked in the orange state, without verified boot enabled. You'll need to be clearer about what you've done and what question you're asking. I can't read your mind.

vamsirocks commented 5 years ago

I don't understand what you're saying. It sounds like you have your device unlocked in the orange state, without verified boot enabled. You'll need to be clearer about what you've done and what question you're asking. I can't read your mind.

Let me explain in detail I had downloaded the source code of android version android-8.1.0 r28 with build id OPM4.171019.016.B1. I build my entire source code for taimen ( pixel 2 xl ) and flashed the device and locked the bootloader and later I am unable to unlock my device (bootloader). I went to developer options but OEM unlocks get grayed out.

My First question But before locking the bootloader i had never executed this step ( fastboot flash avb_custom_key). Here my question since I had not executed this step is I am unable to unlock my bootloader?

My second question which is nowhere related to the context of my first question : I had observed that device is booting in yellow screen warning in the locked state, even I had flashed a different avb_custom_key( pkmd.bin) which is not part of my build process. I mean pkmd.bin not generated from the key which is used in build process so what is the significance of avb_custom_key in the boot process and why even I had flashed different key which is not part of build process why it's successfully getting booting with yellow screen warning in the locked state ?

I had used below commands

avbtool extract_public_key --key key.pem --output pkmd.bin fastboot flash avb_custom_key pkmd.bin

Please help me in understanding .

thestinger commented 5 years ago

I seriously doubt that you locked the bootloader. It wouldn't work if you never flashed an AVB key and the fact that the OEM unlocking toggle is grayed out confirms that, because you can't toggle it when the bootloader is unlocked. I think you're confusing the orange state with the yellow state. You further confirm that by saying you can't unlock (since it already appears to be unlocked) and mentioning that you are still able to flash which can only be done when unlocked.

alengh commented 5 years ago

I seriously doubt that you locked the bootloader. It wouldn't work if you never flashed an AVB key and the fact that the OEM unlocking toggle is grayed out confirms that, because you can't toggle it when the bootloader is unlocked. I think you're confusing the orange state with the yellow state. You further confirm that by saying you can't unlock (since it already appears to be unlocked) and mentioning that you are still able to flash which can only be done when unlocked.

@thestinger Did you ever tryed it by your side ?

I already said that me too had locked my bootloader after flashing only a build without flashing AVB !

It works, the build works, the stat is Yellow after locking the bootloader and the device steel works with the new build.

You further confirm that by saying you can't unlock (since it already appears to be unlocked) and mentioning that you are still able to flash which can only be done when unlocked.

By my side the "OEM unlocking" toggled grayed with "Disabled" state. (Was "Enabled" befor i "fastboot lock").

But you are right : Was not able to re-flash anything and fastboot was rejected since the bootloader was locked.

thestinger commented 5 years ago

@alengh You said you have a first generation Pixel, where AVB does not exist. Obviously the AVB custom key does not need to be flashed there... it needs to be flashed on 2nd and 3rd generation Pixels where AVB was introduced as the new verified boot implementation. I already explained how it worked in past generations (Nexus 5X, Nexus 6P, Pixel, Pixel XL) above:

I don't see why you're muddying the waters in a much different conversation about the Pixel 2...

thestinger commented 5 years ago

What @vamsirocks is claiming is that they've found an exploitable vulnerability in the verified boot implementation simply by trying to use it, and their description of what's happening does not make sense. They have a 2nd generation Pixel with AVB, not a first generation Pixel without it. They claim they've locked the bootloader without flashing an AVB custom key and that it boots / works, but also say that they can still flash images. I think it's fairly clear that they simply haven't locked the bootloader, or maybe used lock_critical rather than lock on an older version of the firmware where that existed. It also explains why this option is grayed out for them. I doubt it's the same issue as you. It's not at all the problem you're describing. I think they're just misunderstanding the current state of their device.

Sure, it's possible they found a way to completely break it, but it's far more likely they haven't locked it considering how they're describing the situation and what they've done.

vamsirocks commented 5 years ago

I seriously doubt that you locked the bootloader. It wouldn't work if you never flashed an AVB key and the fact that the OEM unlocking toggle is grayed out confirms that, because you can't toggle it when the bootloader is unlocked. I think you're confusing the orange state with the yellow state. You further confirm that by saying you can't unlock (since it already appears to be unlocked) and mentioning that you are still able to flash which can only be done when unlocked.

I am in yellow warning screen only and I am also unable to unlock the bootloader that is what I mentioned in my first question .

Second question is an individual question : what I had observed is I flashed my custom build without flashing avb key , but still device booting how. Then what is the significance of avb key

thestinger commented 5 years ago

I am in yellow warning screen only and I am also unable to unlock the bootloader that is what I mentioned in my first question .

In all likelihood it's the orange state.

Second question is an individual question : what I had observed is I flashed my custom build without flashing avb key , but still device booting how. Then what is the significance of avb key

It isn't needed when verified boot isn't enabled.

vamsirocks commented 5 years ago

What @vamsirocks is claiming is that they've found an exploitable vulnerability in the verified boot implementation simply by trying to use it, and their description of what's happening does not make sense. They have a 2nd generation Pixel with AVB, not a first generation Pixel without it. They claim they've locked the bootloader without flashing an AVB custom key and that it boots / works, but also say that they can still flash images. I think it's fairly clear that they simply haven't locked the bootloader, or maybe used lock_critical rather than lock on an older version of the firmware where that existed. It also explains why this option is grayed out for them. I doubt it's the same issue as you. It's not at all the problem you're describing. I think they're just misunderstanding the current state of their device.

Sure, it's possible they found a way to completely break it, but it's far more likely they haven't locked it considering how they're describing the situation and what they've done.

I am in yellow warning screen only and I am also unable to unlock the bootloader that is what I mentioned in my first question .

In all likelihood it's the orange state.

Second question is an individual question : what I had observed is I flashed my custom build without flashing avb key , but still device booting how. Then what is the significance of avb key

It isn't needed when verified boot isn't enabled.

I am in locked bootloader state with yellow screen it doesn't mean verified boot?

thestinger commented 5 years ago

No, since if everything you are claiming is true, it means your device isn't functioning correctly and verified boot isn't working. It would mean you've discovered a serious vulnerability. I don't think that's the case but rather you are misunderstanding or incorrectly remembering the process you've done and the state of the device.

vamsirocks commented 5 years ago

I am also unable to unlock the bootloader since my oem unlock grayed out. As per your response I had understood since I had not flashed avb key I am unable to unlock. May be your right I will verify.

Since I had not flashed avb to unlock I generated an ota build with framework customisation which successfully made my device again unlockable. This is how I sorted out my bootloader unlock issues

thestinger commented 5 years ago

I am also unable to unlock the bootloader since my oem unlock grayed out.

The toggle in the OS does not unlock the bootloader. It enables / disables unlocking the bootloader via fastboot. It does not lock or unlock the bootloader itself.

So, to go back to what you said:

But before locking the bootloader i had never executed this step ( fastboot flash avb_custom_key).

You say you never flashed avb_custom_key before locking the bootloader.

I had observed that device is booting in yellow screen warning in the locked state, even I had flashed a different avb_custom_key( pkmd.bin) which is not part of my build process. I mean pkmd.bin not generated from the key which is used in build process

You follow that up by saying you flashed a different one, which would only be possible if the bootloader was unlocking. It's not possible to flash or format partitions via fastboot with a locked bootloader.

Along with the fact that verified boot is clearly not being enforced, since you don't have the right AVB custom key flashed, this shows that you don't have the bootloader locked.

thestinger commented 5 years ago

Since I had not flashed avb to unlock

I don't know what that means. If you had locked the bootloader with a non-stock OS without flashing the correct AVB custom key, it would fail the boot verification process and wouldn't proceed to booting.

What procedure did you use to try to lock the bootloader, and what makes you think it was locked? Take a picture of the verified boot screen that you see on boot and post it.

vamsirocks commented 5 years ago

I am also unable to unlock the bootloader since my oem unlock grayed out.

The toggle in the OS does not unlock the bootloader. It enables / disables unlocking the bootloader via fastboot. It does not lock or unlock the bootloader itself.

So, to go back to what you said:

But before locking the bootloader i had never executed this step ( fastboot flash avb_custom_key).

You say you never flashed avb_custom_key before locking the bootloader.

I had observed that device is booting in yellow screen warning in the locked state, even I had flashed a different avb_custom_key( pkmd.bin) which is not part of my build process. I mean pkmd.bin not generated from the key which is used in build process

You follow that up by saying you flashed a different one, which would only be possible if the bootloader was unlocking. It's not possible to flash or format partitions via fastboot with a locked bootloader.

Along with the fact that verified boot is clearly not being enforced, since you don't have the right AVB custom key flashed, this shows that you don't have the bootloader locked.

That is my second question both are different I will also agree we can't flag avb key in locked state. In that previous comment I also mentioned the second question is different no where related to my first question context

thestinger commented 5 years ago

That is my second question both are different I will also agree we can't flag avb key in locked state. In that previous comment I also mentioned the second question is different no where related to my first question context

It isn't different. If you flashed an AVB custom key, that doesn't simply go away when you flash a new OS including flashing the stock factory images. If you ever flashed an AVB custom key, it's still present unless you explicitly went through the process of removing it.

thestinger commented 5 years ago

Post the output of fastboot getvar all from fastboot mode and a picture of the verified boot screen shown on boot.

vamsirocks commented 5 years ago

Thank you, tomorrow I will do once I reach office with full details for sure.

vamsirocks commented 5 years ago

That is my second question both are different I will also agree we can't flag avb key in locked state. In that previous comment I also mentioned the second question is different no where related to my first question context

It isn't different. If you flashed an AVB custom key, that doesn't simply go away when you flash a new OS including flashing the stock factory images. If you ever flashed an AVB custom key, it's still present unless you explicitly went through the process of removing it.

You are right explicitly there is fastboot command to erase the tamper evident storage. I did erase too and reflashed with different key not part of my build process.

vamsirocks commented 5 years ago

Here is the command I used to erase fastboot erase avb_custom_key

vamsirocks commented 5 years ago

Hi friend as you said this time i flashed the avb_custom_key before locking the bootloader as you said using below command i did

avbtool extract_public_key --key external/avb/test/data/testkey_rsa4096.pem --output pkmd.bin fastboot flash avb_custom_key pkmd.bin

But this time too there is a problem in the unlocking of the bootloader .

@anestisb your quote " But if you flash your self-signed AVB key (fastboot flash avb_custom_key) you have full control over the bootloader locking state. Did you skipped that step?

Btw which device & OS version are you using? "

I had flashed AVB key but still unable to unllock the booltoader why ?

Still OEM unlocking grayed out why ?

I am currently using pixel 2 xl device and source code i had used is android-8.1.0 r28 and build id OPM4.171019.016.B1 and i had generated a user build.

As you requested fastboot getvar all and i am getting yellow screen warning too

(bootloader) keep_efs:no (bootloader) is_oem_unlocked:yes (bootloader) have_oem_lock_id:yes (bootloader) avb_stored_rollback_indexes: (bootloader) avb_user_settable_key_set:yes (bootloader) avb_version:1.0.0 (bootloader) hw-color:VB (bootloader) hw-variant:GA00125-IN (bootloader) hw-revision:rev_10 (bootloader) cid:00000000 (bootloader) erase-block-size:0x1000 (bootloader) logical-block-size:0x1000 (bootloader) unlocked:no (bootloader) off-mode-charge:1 (bootloader) battery-soc-ok:yes (bootloader) battery-voltage:4210 (bootloader) version-laf:1.0.3 (bootloader) version-baseband:g8998-00202-1803121407 (bootloader) version-bootloader:TMZ12bb (bootloader) version-abl:TMZ12bb (bootloader) version-aes:TMZ12bb (bootloader) version-cmnlib:TMZ12bb (bootloader) version-cmnlib64:TMZ12bb (bootloader) version-devcfg:TMZ12bb (bootloader) version-hyp:TMZ12bb (bootloader) version-keymaster:TMZ12bb (bootloader) version-pmic:TMZ12bb (bootloader) version-rpm:TMZ12bb (bootloader) version-xbl:TMZ12bb (bootloader) variant:MSM UFS (bootloader) partition-type:laf_b:raw (bootloader) partition-size:laf_b: 0x3000000 (bootloader) partition-type:laf_a:raw (bootloader) partition-size:laf_a: 0x3000000 (bootloader) partition-type:dtbo_b:raw (bootloader) partition-size:dtbo_b: 0x800000 (bootloader) partition-type:dtbo_a:raw (bootloader) partition-size:dtbo_a: 0x800000 (bootloader) partition-type:boot_b:raw (bootloader) partition-size:boot_b: 0x2800000 (bootloader) partition-type:boot_a:raw (bootloader) partition-size:boot_a: 0x2800000 (bootloader) partition-type:vendor_b:ext4 (bootloader) partition-size:vendor_b: 0x1F400000 (bootloader) partition-type:vendor_a:ext4 (bootloader) partition-size:vendor_a: 0x1F400000 (bootloader) partition-type:persist:ext4 (bootloader) partition-size:persist: 0x2000000 (bootloader) partition-type:userdata:ext4 (bootloader) partition-size:userdata: 0xD423FB000 (bootloader) partition-type:system_b:ext4 (bootloader) partition-size:system_b: 0xA0000000 (bootloader) partition-type:system_a:ext4 (bootloader) partition-size:system_a: 0xA0000000 (bootloader) has-slot:laf:yes (bootloader) has-slot:bootloader:yes (bootloader) has-slot:vendor:yes (bootloader) has-slot:dtbo:yes (bootloader) has-slot:vbmeta:yes (bootloader) has-slot:cmnlib64:yes (bootloader) has-slot:cmnlib:yes (bootloader) has-slot:keymaster:yes (bootloader) has-slot:devcfg:yes (bootloader) has-slot:hyp:yes (bootloader) has-slot:pmic:yes (bootloader) has-slot:abl:yes (bootloader) has-slot:rpm:yes (bootloader) has-slot:tz:yes (bootloader) has-slot:xbl:yes (bootloader) has-slot:radio:yes (bootloader) has-slot:modem:yes (bootloader) has-slot:system:yes (bootloader) current-slot:b (bootloader) has-slot:boot:yes (bootloader) slot-retry-count:b:6 (bootloader) slot-unbootable:b:no (bootloader) slot-successful:b:yes (bootloader) slot-retry-count:a:7 (bootloader) slot-unbootable:a:no (bootloader) slot-successful:a:no (bootloader) slot-count:2 (bootloader) slot-suffixes:a,b, (bootloader) secure:yes (bootloader) serialno:807KPPB2010136 (bootloader) product:taimen (bootloader) max-download-size:0x20000000 (bootloader) kernel:uefi (bootloader) qem:0 all: finished. total time: 0.004s

So now what i did to unlock my bootloader is .

I generated a ota update with these changes in framework

Identity the file AOSP_Root/frameworks/base/services/core/java/com/ android/server/oemlock/VendorLock.java Identify the below mentioned line in above mentioned file path return allowedByCarrier[0]; replace above line with below mentioned line return true; Identity the file AOSP_Root/frameworks/base/core/java/android/service/ oemlock/OemLockManager.java Identify the below mentioned line in above mentioned file path return mService.isOemUnlockAllowedByCarrier(); replace above line with below mentioned line

mService.isOemUnlockAllowedByCarrier();
return true;

Identity the file AOSP_Root/frameworks/base/services/core/java/com/ android/server/PersistentDataBlockService.java Identify the below men- tioned line in above mentioned file path

if (ActivityManager.isUserAMonkey()) {
return;
}
enforceOemUnlockWritePermission();
enforceIsAdmin();
if (enabled) {
// Do not allow oem unlock to be enabled if it’s disallowed by a user rest
enforceUserRestriction(UserManager.DISALLOW_OEM_UNLOCK);
enforceUserRestriction(UserManager.DISALLOW_FACTORY_RESET);
}

comment above lines

These changes are enough to unlock bootloader . After making above changes build ota update and sideload it which will resolve the bootloader unlocking issue.

This is how i am able to unlock the bootloader .

I also know colours for your info I am not miss understanding orange colour as yellow . you are not able to listen what i am saying

Next time i will show even flashing wrong avb key still how device booting successfully . Give some time i will come up with details soon. .