• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

[GUIDE] Re-locking the bootloader on the OnePlus 8t with a self-signed build of LOS 18.1

Search This thread

WhitbyGreg

Senior Member
I collected some logcat on locked and unlocked bootloaders and found such a difference at the logcat output beginning:

On locked bootloader:
Code:
09-07 08:02:17.768  1361  1787 V FingerprintService: mDaemon was null, reconnect to fingerprint
09-07 08:02:17.770  1361  1787 V FingerprintService: Fingerprint HAL id: -5476376659343548400
09-07 08:02:17.770  1361  1361 D FingerprintService: initConfiguredStrengthInternal(15)
09-07 08:02:17.808  1361  1787 V FingerprintService: Enumerating user(0)

On unlocked bootloader:
Code:
09-07 08:02:18.264  1391  1391 D FingerprintService: initConfiguredStrengthInternal(15)
09-07 08:02:18.301  1391  1776 V FingerprintService: Enumerating user(0)

At the time when I'm trying to register fingerprint there is a lines on unlocked bootloader:
Code:
09-07 08:03:12.773  1391  1391 V FingerprintService: Acquired: 0 0
09-07 08:03:12.804  1391  1391 V FingerprintService: Cancelling enrollment
09-07 08:03:12.977  1391  1391 V FingerprintService: handleError(client=com.android.settings, error = 5)
09-07 08:03:12.978  1391  1391 V FingerprintService: Done with client: com.android.settings
09-07 08:03:13.038  1391  1391 D FingerprintService: setActiveUser(0)
09-07 08:03:13.039  1391  1391 V FingerprintService: starting client EnrollClientImpl(com.android.settings) targetUserId: 0 currentUserId: 0 cookie: 0/0

And no lines with "FingerprintService:" at all on the locked bootloader near the time I tried to register a fingerprint. Looks like the last line with it was only near the end of the system boot time.

WhitbyGreg, does it mean something to you?
Doesn't mean anything to me, doesn't look like any errors present at that point.

You can see this post on how to look for SELinux issues.
 
For fod not working, can you verify `vendor.boot.verifiedbootstate`? As locked, it should be set to true, and if so, my suspicion is not the problem unless you've applied https://github.com/dotOS-Devices/de...mmit/6fc4be42a0a2bf33e511f7b35b1d7d59aae5fe07

Relevant logic to your provided logs, if it means anything to u
 
Last edited:
  • Like
Reactions: xHasKx

xHasKx

Member
May 27, 2018
18
1
For fod not working, can you verify `vendor.boot.verifiedbootstate`? As locked, it should be set to true, and if so, my suspicion is not the problem unless you've applied https://github.com/dotOS-Devices/de...mmit/6fc4be42a0a2bf33e511f7b35b1d7d59aae5fe07

Relevant logic to your provided logs, if it means anything to u
Currently, I have an empty result of the command adb shell getprop vendor.boot.verifiedbootstate, on user build and locked bootloader.

Thanks, xstefen, I'll apply the patch from the commit you mentioned to my build setup and will try fingerprint again.
 
Last edited:

xHasKx

Member
May 27, 2018
18
1
For fod not working, can you verify `vendor.boot.verifiedbootstate`? As locked, it should be set to true, and if so, my suspicion is not the problem unless you've applied https://github.com/dotOS-Devices/de...mmit/6fc4be42a0a2bf33e511f7b35b1d7d59aae5fe07
Thank you xstefen a lot, this is fixed my fingerprint issue!
I tested values "true", "yellow" and "orange" for the "vendor.boot.fingerprintbstate" variable, and "orange" makes it work on the locked bootloader!
 
  • Like
Reactions: WhitbyGreg

WhitbyGreg

Senior Member
For fod not working, can you verify `vendor.boot.verifiedbootstate`? As locked, it should be set to true, and if so, my suspicion is not the problem unless you've applied https://github.com/dotOS-Devices/de...mmit/6fc4be42a0a2bf33e511f7b35b1d7d59aae5fe07
On my 8T, with relocked bootloader:

OnePlus8T:/ $ getprop | grep bootstate [ro.boot.verifiedbootstate]: [yellow]

Based on the patch, I assume the blob is looking for orange or true, which seems like a bug from OnePlus. It looks like they've corrected the logic for the 9/9Pro so I wonder if they're fix it on the 8t in an upcoming release or not.

@xstefen, do you think the patch could be altered to replace vendor.boot.verifiedbootstate with a static string instead of another variable?
 
true=green. Yellow is for custom key, orange is typically unlocked. So not sure what's going on here. As for modification you'd have to modify the hal, I personally only know as much as I can read from the patch so not sure https://source.android.com/security/verifiedboot/boot-flow

My device on stock OOS but unlocked:
$ getprop | grep bootstate
[ro.boot.verifiedbootstate]: [orange]
 

WhitbyGreg

Senior Member
true=green. Yellow is for custom key, orange is typically unlocked. So not sure what's going on here. As for modification you'd have to modify the hal, I personally only know as much as I can read from the patch so not sure https://source.android.com/security/verifiedboot/boot-flow
Yep, I expect mine to be yellow, relocked with custom key. I'm not talking about messing with the HAL, just to two .so files that are being patched with a replacement variable be replaced with a static string. I'll poke at them some more and see what I can find.
 
  • Like
Reactions: xstefen

optimumpro

Senior Member
Jan 18, 2013
6,741
14,215
Yep, I expect mine to be yellow, relocked with custom key. I'm not talking about messing with the HAL, just to two .so files that are being patched with a replacement variable be replaced with a static string. I'll poke at them some more and see what I can find.
Hello. I am optimumpro, the guy who inspired you to do locked bootloader on AVB-2. :)

Why not downgrade to AVB-1? Then you don't need to include Magisk or anything else. Magisk can recognize AVB-1 signed boot images and sign them after patching automatically with verity key. It could also do the same on a live device.

AVB-2 is too expensive and I am not sure that it's very useful. If your bootloader is AVB-1 signed and locked, no one can mess with partitions anyway.

I am going to try it on Oneplus 8... .
 

WhitbyGreg

Senior Member
Hello. I am optimumpro, the guy who inspired you to do locked bootloader on AVB-2. :)

Why not downgrade to AVB-1? Then you don't need to include Magisk or anything else. Magisk can recognize AVB-1 signed boot images and sign them after patching automatically with verity key. It could also do the same on a live device.

AVB-2 is too expensive and I am not sure that it's very useful. If your bootloader is AVB-1 signed and locked, no one can mess with partitions anyway.

I am going to try it on Oneplus 8... .
Hey Optimumpro, great to hear from you. :)

I'm not aware of any way to "downgrade" a device that supports AVB-2 back to the older AVB-1 style of bootloader locking like the OnePlus 5/5t supported (if that's what you mean at least).

AVB-2 has a few advantages as well, like being able to "fix" corruption to the partitions (either by accident or maliciously) as well as obviously benefiting from a newer and (hopefully) more secure design.

While AVB-1 will block changes, if an attacker could alter the partitions (through an exploit) those changes would persist across boots and even a factory reset. Where as an AVB-2 device would revet those changes on next boot.

Obviously AVB-2 support does take more effort to achieve, I wrote up a Q&A discussion post about it over on reddit for LineageOS about why you probably don't want to do it, but I think it does makes sense if you're trying to get the maximum security out of your device.

As I'm not installing GAPPS or Magisk on my device (again to maximize security for me), I don't have to worry too much about those parts of the build. It does look like @xHasKx has managed to integrate both in to the build process successfully, so it is possible.

Let me know how your attempt with the OnePlus 8 goes... I have relocking working on a OnePlus 9 and I'll be receiving a Nord N200 shortly to see if it has the custom key support as well.
 
  • Like
Reactions: xHasKx

optimumpro

Senior Member
Jan 18, 2013
6,741
14,215
Hey Optimumpro, great to hear from you. :)

I'm not aware of any way to "downgrade" a device that supports AVB-2 back to the older AVB-1 style of bootloader locking like the OnePlus 5/5t supported (if that's what you mean at least).

AVB-2 has a few advantages as well, like being able to "fix" corruption to the partitions (either by accident or maliciously) as well as obviously benefiting from a newer and (hopefully) more secure design.

While AVB-1 will block changes, if an attacker could alter the partitions (through an exploit) those changes would persist across boots and even a factory reset. Where as an AVB-2 device would revet those changes on next boot.

Obviously AVB-2 support does take more effort to achieve, I wrote up a Q&A discussion post about it over on reddit for LineageOS about why you probably don't want to do it, but I think it does makes sense if you're trying to get the maximum security out of your device.

As I'm not installing GAPPS or Magisk on my device (again to maximize security for me), I don't have to worry too much about those parts of the build. It does look like @xHasKx has managed to integrate both in to the build process successfully, so it is possible.

Let me know how your attempt with the OnePlus 8 goes... I have relocking working on a OnePlus 9 and I'll be receiving a Nord N200 shortly to see if it has the custom key support as well.
You can do the same with AVB-1. You can mark (in fstab) /system /product /system-ext and /vendor to be included into the AVB-1 scheme, and any tempering with those would be discovered.

As far as downgrading from AVB-2, I think it's just removing AVB-2 entries from your device's BoardConfig.mk/Device.mk/Common.mk and replacing them with AVB-1.

Edit: The only thing that might prevent AVB-1 from working is some entry in bootloader that would refuse to boot with AVB-2 disabled.
 
Last edited:

WhitbyGreg

Senior Member
You can do the same with AVB-1. You can mark (in fstab) /system /product /system-ext and /vendor to be included into the AVB-1 scheme, and any tempering with those would be discovered.

As far as downgrading from AVB-2, I think it's just removing AVB-2 entries from your device's BoardConfig.mk/Device.mk/Common.mk and replacing them with AVB-1.

Edit: The only thing that might prevent AVB-1 from working is some entry in bootloader that would refuse to boot with AVB-2 disabled.
While you could build LineageOS without AVB2, I don't think it would boot if you relocked the bootloader (on newer phones) as AVB2 is a mandatory requirement for devices now.

I would expect the red "corrupt OS" message to appear after relocking if AVB1 was enabled an not AVB2.

I know when I was working on getting everything setup for AVB2, if I missed anything in the config it would throw the corrupt OS message all the time when I tried to relock.

I beleive that on modern devices (aka anything that has AVB2 as mandatory), that the bootloader will refuse to load anything but AVB2 signed systems when relocked.
 

optimumpro

Senior Member
Jan 18, 2013
6,741
14,215
While you could build LineageOS without AVB2, I don't think it would boot if you relocked the bootloader (on newer phones) as AVB2 is a mandatory requirement for devices now.

I would expect the red "corrupt OS" message to appear after relocking if AVB1 was enabled an not AVB2.

I know when I was working on getting everything setup for AVB2, if I missed anything in the config it would throw the corrupt OS message all the time when I tried to relock.

I beleive that on modern devices (aka anything that has AVB2 as mandatory), that the bootloader will refuse to load anything but AVB2 signed systems when relocked.
Well. Oneplus 6 has AVB-2, nonetheless it works with AVB-1.

My problem now is that I have a verity.x509.pem key that can't be read by avb tool. Any idea on converting this to the avb-readable format?
 

WhitbyGreg

Senior Member
Well. Oneplus 6 has AVB-2, nonetheless it works with AVB-1.

My problem now is that I have a verity.x509.pem key that can't be read by avb tool. Any idea on converting this to the avb-readable format?

Assuming avb wants the private key to do the signing, you should be able to get the right format with something like:

openssl pkcs8 -in verify.pk8 -inform DER -out verity.key -nocrypt
 
  • Like
Reactions: optimumpro

azoller1

Senior Member
Aug 4, 2011
1,850
1,751
My Room
OnePlus 8T
Yes, anything that is based on AOSP should be possible for it to work with.
Nice. This seems very intriguing, thanks for the guide btw. I'm just trying to figure out the best way to backup my data and restore it after flashing and relocking the bootloader. I suppose I could initially build with magisk and then use an app to restore apps/data, then I could make a new build with an unpatched boot.img, resign with my keys, then reflash the new build so I can get rid of root and keep my data. I am assuming this would work?
 

Top Liked Posts

  • There are no posts matching your filters.
  • 1
    Also, if you disable OEM unlock, that's pretty secure, but if something goes wrong with your phone, i.e., you can't boot in recovery and system, the only way to restore the phone is flashing with MSM tool. I had it once on my Oneplus 5. I had a paranoid TWRP, with Cancel button removed. So, all of a sudden, TWRP refused to recognize my password. So, you can't press cancel to access system to do a factory reset. All right, I thought, I am just going to boot into system and enable OEM unlock. Well, no can do: the phone refused to boot into system and instead booted into TWRP with the password prompt. Bootloader locked, remote flashing is not allowed. The only option - MSM tool. I set up Windows on my virtual machine, but forget it, MSM tool can't connect to the phone no matter what I tried. So, I had to find on old laptop with Windows and then it worked... .
    Correct, once OEM unlocking is disabled, just like with OxygenOS, if something goes horribly wrong, you're using MSM to get back to stock and re-installing.

    I don't use TWRP, and build both LineageOS and Lineage Recovery in user mode. Building recvoery in user mode (and only with my certificates) also means you can't "rollback" to an older version of Lineage as it won't flash older zips.

    As I said in my reddit post, most people don't really want to do this. Too much risk, too little reward. But if you're wiling to take the risk, you do get as close to a "stock" security footprint as you can without using the OEM's OS.
    1
    Yes. Thank you.

    There is, however, something wrong with your guide. I tried to use plain test key and the pem version of the same key to no avail - red screen, when relocked.

    It only worked when I used the ruby script to extract the public key from my own rom's vbmeta partition (which is quite ridiculous, LOL).

    Google says avb tool only accepts pem format, which is not true, as it accepts plain text keys too. As I said, I tried both and the rom builds fine. Google also says to use pkmd.bin for flashing, it flashes fine, but doesn't work. Perhaps, the output should be in img format? I'll try tomorrow.

    Edit: img format makes sense, as phone partitions accept .img files.

    Edit2; Or, perhaps, it depends on OEM. Google devices accept pkmd.bin, Oneplus may only accept .img.
    I use the same pkmd.bin file on both Pixel and OnePlus files, generated as per the guide.

    I just tried regenerating it using the same command line and it generates the exact same file I use now so it looks correct to me.
    1
    I use the same pkmd.bin file on both Pixel and OnePlus files, generated as per the guide.

    I just tried regenerating it using the same command line and it generates the exact same file I use now so it looks correct to me.
    You were right. My fault. I didn't set my own key for vbmeta.img, so it was signed with default test key. The system doesn't care what key other images are signed with, it's the vbmeta signature that goes to bootloader.
    1
    Yeah, it looks like the blob is looking for vendor.boot.verifiedbootstate to be either green/true or orange and doesn't allow for yellow. Probably some kind of if statement that doesn't check for the yellow state. I can confirm that the fingerprint scanner works fine on the 9 in any state, so it probably some kind of unique library to the 8T.

    The "patch" basically swaps out vendor.boot.verifiedbootstate for a custom property that can be set to orange manually independent of vendor.boot.verifiedbootstate. The problem is that the patch does the swap blindly and without really understanding what it does it may have other impacts that aren't obvious.

    On my list of things to look at is decompling the library and seeing what's really going on, but it's low on my priority list ;)
    I'll try removing it.

    By the way, I have successfully built my rom with Magisk included. It took a few hours to set it properly. The instructions say that the call for the extendrom's download script must be put in vendorsetup.sh. But starting with Android 10, Google has removed vendorsetup. When I created one, the script would download the requested files, but wouldn't unzip and put them in the /out directory. The problem was: vendorsetup script gets executed on 'source build/envsetup.sh'. At that point, there is no device tree set yet. So, extendrom can't see 'pre-root' flags, therefore, it puts them in prebuilt directory, , which results in a compile error: 'no /out/.magisk directory exists. So, it worked only when I put the flags in extendrom's common.mk.
    1
    When Cyanogen bundled Gapps, they got a cease and desist letter from Google. Also, even if I sign Gapps.zip with the release key, system would still be modified.
    Yep, it's a risk, there are several custom ROM's that do ship GAPPS though. I completely understand (and agree with) why LineageOS doesn't ship GAPPS, both from a licensing perspective and a user choice perspective.

    I still don't understand how it is possible that user changes to system (even when they change brightness or move volume panel or a hundred of other changes) don't get to roll back.
    Because those aren't stored on the system partition, those are part of the user data or in memory. The system partition is not written to during day to day operations, and in fact on Android 11 is only mounted as read only.
  • 10
    What is this tutorial?
    This tutorial will:
    • Creating an unofficial build of LineageOS 18.1 suitable for using to re-lock the bootloader on a OnePlus 8t
    • Take you through the process of re-locking your bootloader after installing the above

    This tutorial will NOT:
    • Remove *all* warning messages during boot (the yellow "Custom OS" message will be present though the orange "Unlocked bootloader" message will not)
    • Allow you to use official builds of LineageOS 18.1 on your device with a re-locked bootloader (more details near the end of the tutorial)
    This tutorial will assume you are working on an Ubuntu 18.04 installation, if you are using Windows or another Linux distro, the commands may be different.

    Supported devices:
    The following devices have been tested and confirmed to work:
    • OnePlus 7 Pro (guacamole)
    • OnePlus 8t (kebab)
    • Pixel 4 (flame)
    Other OnePlus devices that support AVBv2 (OnePlus 6t and newer as well as most Pixel devices) and LineageOS 18.1 (see current support list over on the LineageOS download page) should work as well.

    For simplicities sake, all further references will only be to the 8t (kebab).

    Pre-requisites:
    • a mid level knowledge of terminal commands and features
    • a supported phone
    • a PC with enough CPU/RAM to build LineageOS 18.1 (recommended 8 cores, 24g of RAM)
    • a working USB cable
    • fastboot/adb installed and functional
    • LineageOS 18.1 source code downloaded
    • at least one successful build of LineageOS
    • at least one successful signing of your build with your own keys

    Misc. notes:
    • the basics of building/signing of LineageOS is outside the scope of this tutorial, refer to the LineageOS Wiki for details on how to complete these tasks
    • you'll be modifying some code in LineageOS, so if you are not comfortable using basic editing utilities as well as patch, do not proceed any further
    • the path to your LineageOS source code is going to be assumed to be ~/android/lineageos, if it is somewhere else, substitute the correct path in the tutorial
    • the path to your private certificate files is going to be assumed to be ~/android-certs, if it is somewhere else, substitute the correct path in the tutorial


    *** WARNING ****
    This process may brick your device. Do not proceed unless you are comfortable taking this risk.


    *** WARNING ****
    This process will delete all data on your phone! Do not proceed unless you have backed up your data!


    *** WARNING ****
    Make sure you have read through this entire process at least once before attempting, if you are uncomfortable with any steps include in this guide, do not continue.



    And now on with the show!

    Step 1: Basic setup

    You need a few places to store things, so create some working directories:
    Code:
    mkdir ~/android/kebab
    mkdir ~/android/kebab/patches
    mkdir ~/android/kebab/pkmd
    You also need to add "~/android/lineageos/out/host/linux-x86/bin" to your shell's profile path. Make sure to close and restart your session afterwards otherwise the signing will fail later on with a "file not found" error message (this may no longer be required).

    Step 2: Update kebab's BoardConfig.mk

    You will need to add a few parameters to the end of ~/android/lineageos/device/oneplus/kebab/BoardConfig.mk, they are:

    Code:
    BOARD_AVB_ALGORITHM := SHA256_RSA2048
    BOARD_AVB_KEY_PATH := /home/<userid>/.android-certs/releasekey.key
    Note you cannot use "~" in the path names above to signify your home directory, so give the full absolute path to make sure the files are found.

    Step 3: Update sm8250-common's BoardConfigCommon.mk

    LineageOS by default disables Android Verified Boot's partition verification, but you can enable it now as all the required parts will be in place.

    To enable partition verification do the following:

    Code:
    cd ~/android/lineageos/device/oneplus/sm8250-common
    sed -i 's/^BOARD_AVB_MAKE_VBMETA_IMAGE_ARGS += --flags 2/#BOARD_AVB_MAKE_VBMETA_IMAGE_ARGS += --flags 2/' BoardConfigCommon.mk
    sed -i 's/^BOARD_AVB_MAKE_VBMETA_IMAGE_ARGS += --set_hashtree_disabled_flag/#BOARD_AVB_MAKE_VBMETA_IMAGE_ARGS += --set_hashtree_disabled_flag/' BoardConfigCommon.mk
    sed -i 's/^BOARD_AVB_VBMETA_SYSTEM_KEY_PATH := external\/avb\/test\/data\/testkey_rsa2048.pem/BOARD_AVB_KEY_PATH := \/home\/<userid>\/.android-certs\/releasekey.key/' BoardConfigCommon.mk

    Don't forget to replace your <userid> in the third sed command above with your current logged in user id.

    Step 4: Patch the AOSP and Device Makefile

    You also need to patch the Makefile included with AOSP as it will otherwise fail during the build.

    The required patch can be found here:

    Download it and store in ~/android/kebab/patches.

    Now apply it with the following command:

    Code:
    cd ~/android/lineageos/build/core
    patch Makefile ~/android/kebab/patches/core-Makefile-fix-18.1.patch

    If you would like to know more about this patch, see the additional info at the bottom of this post.

    There is also a small addition to the device's common.mk required to enable the OEM unlock option in developers options, do this via the following commands:

    Code:
    cd ~/android/lineageos/device/oneplus/sm8250-common
    sed -i 's/^# OMX/# OEM Unlock reporting\nPRODUCT_DEFAULT_PROPERTY_OVERRIDES += \\\n    ro.oem_unlock_supported=1\n\n# OMX/' common.mk

    Step 5: Build LineageOS

    You are now ready to build:

    Code:
    cd ~/android/lineageos
    breakfast kebab
    source build/envsetup.sh
    croot
    mka target-files-package otatools

    Step 6: Sign the APKs

    You are now ready to sign the apks with sign_target_files_apks:

    Code:
    ./build/tools/releasetools/sign_target_files_apks -o -d ~/.android-certs $OUT/obj/PACKAGING/target_files_intermediates/*-target_files-*.zip signed-target_files.zip

    Step 7: Build the OTA

    Now it is time to complete the OTA package:

    Code:
    ./build/tools/releasetools/ota_from_target_files -k ~/.android-certs/releasekey --block signed-target_files.zip lineage-18.1-[date]-UNOFFICIAL-kebab-signed.zip

    Note, replace [date] with today's date in YYYYMMDD format.

    Step 8: Create pkmd.bin for your phone

    Before you can lock your phone, you have to tell it what your public key is so it knows it can trust your build.

    To do this you need to create a pkmd.bin file:

    Code:
    ~/android/lineageos/external/avb/avbtool extract_public_key --key ~/.android-certs/releasekey.key --output ~/android/kebab/pkmd/pkmd.bin

    Step 9: Flashing your LineageOS build

    It's time to flash your build to your phone. The following steps assume you have already unlocked your phone and have flashed an official version of LineageOS to it. You don't need to have flashed LineageOS yet, you could use TWRP through "fastboot boot" if you prefer. Or, if you want to use the recovery that was just created, it is located in ~/android/lineageos/out/target/product/kebab and is called recovery.img.

    • Reboot your phone in to recovery mode
    • In LineageOS Recovery return to the main menu and select "Apply update"
    • From your PC, run:
    Code:
    adb sideload ~/android/lineageos/lineage-18.1-[date]-UNOFFICIAL-kebab-signed.zip

    When the sideload is complete, reboot in to LineageOS. Make sure everything looks good with your build.

    You may also need to format your data partition at this time depending on what you had installed on your phone previously.

    Step 10: Flashing your signing key

    Now it's time to add your signing key to the Android Verified Boot process. To do so, do the following:

    • Reboot your phone in to fastboot mode
    • From your PC, run:
    Code:
    fastboot flash avb_custom_key ~/android/kebab/pkmd/pkmd.bin
    fastboot reboot bootloader
    fastboot oem lock
    • On your phone, confirm you want to re-lock and it will reboot

    Your phone will then factory reset and then reboot in to LineageOS.

    Which of course means you have to go through the first time setup wizard, so do so now.

    Step 11: Disable OEM unlock

    Congratulations! Your boot loader is now locked, but you can still unlock it again using fastboot, so it's time to disable that as well.

    • Unlock you phone and go to Settings->About phone
    • Scroll to the bottom and find "Build number"
    • Tap on it you enable the developer options
    • Go to Settings->System->Advanced->Developer options
    • Disable the "OEM unlocking" slider
    • Reboot

    Step 12: Profit!


    Other things

    • The above will build a standard USERDEBUG version of LineageOS, however this will still allow LineageOS Recovery to sideload non-signed files as well as give you root shell access through ADB. Step 3/4 above protects your system/vendor/boot/dtbo/etc. partitions, but none of the others. Likewise USERDEBUG builds will allow for rolling back to a previous builds/versions of LineageOS. To increase security and disallow both of these scenarios you may want to build a USER version of LineageOS to install. However this brings in other issues, such as flashing newer firmware from OnePlus so make sure you understand the implications of both choices. For more details on build types, see https://source.android.com/setup/develop/new-device#build-variants.
    • In the above example the releasekey from your LineageOS install has been used to sign AVB, but AVB supports other key strengths up to SHA512_RSA8192. You could create a key just for signing AVB that used different options than the default keys generated to sign LineageOS.
    • If you want to remove you signing key from your phone, you can do it by running "fastboot erase avb_custom_key".
    • The changes you made to the AOSP Makefile may conflict with future updates that you pull from LineageOS through repo sync, if you have to reset the file to get repo sync to complete successfully, you'll have to reapply the changes afterwards.

    So why can't I do this with official LineageOS builds?

    NEW: You can! See this thread for more details.

    For Android Verified Boot (AVB) to work, it must have the hash values for each of the system/vendor/boot/dtbo/etc. partitions stored in vbmeta. Official LineageOS builds for kebab do include the vendor.img in them along with everything else that is needed, however that is not true for all phones.

    There are two "issues" that stop someone from using the official kebab builds:
    • LineageOS does not provide a pkmd.bin file to flash to your phone to include the public key in your AVB process (NEW: this thread shows you how to extract the key).
    • AVB is enabled in the official LineageOS builds but does not validate the hash trees during boot which limits the protection offered.
    Ok, what messages do I see during the boot process then?

    During a boot you will of course see the standard OnePlus power up screen, followed by the yellow "custom os" message and then the standard LineageOS boot animation.

    For more details on AVB boot messages, see https://source.android.com/security/verifiedboot/boot-flow

    So what does that patch to the Makefile do?

    AOSP's default Makefile makes an assumption that when AVB is enabled, that all the img files will be available well before vbmeta.img is created. This is simply NOT true and AOSP seems to know this as well from the following comment in the Makefile:

    Code:
    # Not using INSTALLED_VBMETA_SYSTEMIMAGE_TARGET as it won't be set yet.
    ifdef BOARD_AVB_VBMETA_SYSTEM
    $(eval $(call check-and-set-avb-args,vbmeta_system))
    endif
    
    ifdef BOARD_AVB_VBMETA_VENDOR
    $(eval $(call check-and-set-avb-args,vbmeta_vendor))
    endif

    These two calls eventual evaluate to returning the path to the partitions based upon the INSTALLED_*IMAGE_TARGET variable, which isn't created until later in the build process.

    Because of this, the command to build vbmeta.img gets corrupted due to the missing make variable being empty and an invalid command line is passed to avbtool near the end of the build.

    The corruption happens due to the fact that the following line from the original Makefile:

    Code:
    --include_descriptors_from_image $(call images-for-partitions,$(1))))))

    Gets added to the avbtool call even if "$(call images-for-partitions,$(1))" turns out to be an empty string. Avbtool then throws an error message as it is expecting a parameter after the "--include_descriptors_from_image" flag that is added for the "empty" partition path.

    The fix is to call "$(call images-for-partitions,$(1))" earlier, set it to a variable and check to make sure it isn't an empty string before letting the "--include_descriptors_from_image" be added to the avbtool command line to be used later.

    This technically generates an incomplete vbmeta.img file during the build process, but since the signing process recreates it from scratch anyway; no harm, no foul.

    Thank You's
    1
    Hello,

    I did extract the proprietary blobs from payload-based.

    Do you mean I should compile LinageOS successfully first using:
    source build/envsetup.sh
    breakfast guacamole
    croot
    brunch guacamole

    before i follow the steps listed here in this guide??

    Thank You
    Check the extraction script for errors or switch to the muppets, sometimes the extraction script isn't up to date.

    In general, yes, make sure you have a version of LineageOS that compiles successfully, that way you know you have a valid base to start from.

    Pre-requisites:
    • at least one successful build of LineageOS
    • at least one successful signing of your build with your own keys
    1
    Thank You so much.

    One last question if i may, can these steps applied on LinageOS 4 MicroG using the automated build by their docker image docker-lineage-cicd ?

    Thank You
    You'd have to modify the docker image from my understanding as it includes all the source and tools required to do the build.
    1
    Hello,

    Kindly Please, Could you clarify what do you mean by ~/.android-certs/releasekey.key and ~/.android-certs/releasekey.key/ ??

    I created my own signing keys, and the output contains releasekey.pk8 and releasekey.x509.pem, that is why I'm confused.
    You might need to convert your pk8 in to plain text using openssl like so:

    openssl pkcs8 -in releasekey.pk8 -out releasekey.key
    1
    I followed every single step on this guide, and the build, signing, and generating OTA file are all successful.

    avbtool through error:

    b = 2L**32 # pylint: disable=long-suffix
    ^
    SyntaxError: invalid syntax

    So, i used your other post to extract the pubkey using the ruby script to flash the avb_custom_key.

    I flashed my OnePlus 7 Pro successfully, and it's working fine, the bootloader is locked, and OEM disabled in developer menu.


    Thank You for your guide and help.

    have a blessed life.