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

[antonyjr]

@WhitbyGreg, did you hear somewhere on the internet is there any way to replace recovery or bootloader partitions bypassing Android signature checks using some Qualcomm-specific flash tool?
How do you evaluate a possibility manufacturer can leave some backdoor to do signature bypass using some private tool?

You can't. The manufacturer already has a lot of backdoor in the firmware and binary blobs which are used even in LineageOS. So LineageOS only protects you to some extent but the firmware by oneplus definitely spys you.

There are even specific attacks by the government to gain full access to your phone through the SIM. And every
android device allows this.

The only way you could truly attain freedom is to use something like Librem 5 or Pine phone which is not great
for daily driver and are overpriced for the hardware they provide.

 

[antonyjr]

I believe the scope of this guide is to protect others from tampering with your custom os. Like installing a keylogger through the TWRP or Lineage recovery.

 

[WhitbyGreg]

@WhitbyGreg I reverted back to unlocked bootloader and lineage os signed builds. The vendor.img along with the locked bootloader is causing qualcom crash dumps and my wifi/modem stopped working for some reason. In the 220104 build i had no issues like this. Maybe this is because the vendor.img is modified?

Or something I did wrong. Because I built this with a 8gb ram laptop xD. I had to do a lot of hacks in linux to make
it past the build. Failed multiple times. Took me 2 days. With an amazing AMD Ryzen 4800H which has 8c/16t but is bottlenecked by the RAM.

Update 1: I freshly installed my build again and locked the bootloader. When the phone boots it shows a unique ID which I can identify that only my bulid is booting (For now, I have no enemies who can bypass that ..xD). Everything is working again. I did copy partition and other stuff this time. in which I used my signed vender image instead of the stock vendor image. I know 'Apply Update' would do this by itself. But still I also flashed vbmeta to both partition. Also some tweaks to the network settings. The wifi sometimes turns off (due to power saving?) but the IMEI and baseband is not affected and no crashes for now (I'm talking 0 day tested so I can't be sure when the errors will start showing up).

Widevine is L3 but Google Pay other such app is working without complaining. Only Whatsapp warned I'm using a custom ROM. Build the GAPPS and F-Droid (Priv. Extensions) directly into the ROM. So F-Droid works just like Google Play Store.

Yes, you need to include vendor.img in the vbmeta and sign it appropriately for the bootloader to be locked successfully. "Apply update" won't do this by itself, you have to include the vendor in the OTA file as well as part of your built.

As I recall, older devices like enchilada wipe the widevine L1 keys on bootloader unlock, newer oneplus devices don't do thise, so I have L1 working on my 8T without issue. I beleive you could have backed up the L1 keys before unlocking the bootloader, but now its too late.

Locking the bootloader isn't a silver bullet, there are apps that will still complain because of the wrong OS name/fingerprint/etc. It's just what we have to live with using a custom rom.

 

[WhitbyGreg]

@WhitbyGreg, did you hear somewhere on the internet is there any way to replace recovery or bootloader partitions bypassing Android signature checks using some Qualcomm-specific flash tool?
How do you evaluate a possibility manufacturer can leave some backdoor to do signature bypass using some private tool?

For example, booting OnePlus 8T into EDL mode

Yes, EDL mode can bypass everything, it's at a much lower level than Android or the Recovery. That's how the MSM Tool allows you to recover your device back to stock, including locked bootloader.

I've never seen anything other that the MSM Tool, and the protocol itself isn't documented, so it seems like a pretty low probability to be used in an evil maid style attack.

Practically speaking, if it's the manufacturer that you're worried about, they have simpler ways to backdoor you, like through the modem OS or any of the firmware/blob files.

 

[WhitbyGreg]

I believe the scope of this guide is to protect others from tampering with your custom os. Like installing a keylogger through the TWRP or Lineage recovery.

The scope of this guide is to show you how to relock the bootloader with LineageOS, nothing else.

 

[hasan4791]

Yes, you need to include vendor.img in the vbmeta and sign it appropriately for the bootloader to be locked successfully. "Apply update" won't do this by itself, you have to include the vendor in the OTA file as well as part of your built.

As I recall, older devices like enchilada wipe the widevine L1 keys on bootloader unlock, newer oneplus devices don't do thise, so I have L1 working on my 8T without issue. I beleive you could have backed up the L1 keys before unlocking the bootloader, but now its too late.

Locking the bootloader isn't a silver bullet, there are apps that will still complain because of the wrong OS name/fingerprint/etc. It's just what we have to live with using a custom rom.

First of all, thank you for this amazing guide. I've a follow up question regarding the L1. Basically where the L1 keys are stored? If its stored in any partition, can we not sideload though adb. If that doesn't work, why not include it in the build package itself. Would it work?

 

[WhitbyGreg]

First of all, thank you for this amazing guide. I've a follow up question regarding the L1. Basically where the L1 keys are stored? If its stored in any partition, can we not sideload though adb. If that doesn't work, why not include it in the build package itself. Would it work?

From my understanding they are stored in a partition, once you unlock the bootloader they are wiped on older oneplus devices, so you cannot recover them. One newer devices this is not the case and relocking the bootloader restores L1 functionality.

On the 8T, the keys are not wiped, so no need to include them in the build.

 

[antonyjr]

@WhitbyGreg is it safe to distribute the pkmd.bin file (which I assume is the public key)? (i.e) There is no need to keep pkmd.bin safe right? We only need to keep the files under .android-certs secure which has the private key.

 

[WhitbyGreg]

@WhitbyGreg is it safe to distribute the pkmd.bin file (which I assume is the public key)? (i.e) There is no need to keep pkmd.bin safe right? We only need to keep the files under .android-certs secure which has the private key.

Correct, the public key is... well.. public.

Even if you don't distribute it separately, it can be extracted from an OTA file.

 

[antonyjr]

Correct, the public key is... well.. public.

Even if you don't distribute it separately, it can be extracted from an OTA file.

Awesome.

In the reddit discussion on bootloader and in this thread you recommend a user build. I get that nobody can flash unsigned packages from recovery when it's a user build. But it will not prevent someone from factory resetting my phone without any form of authentication, right?

So if we are using custom rom like lineage os we give anyone the power to destroy our data anytime. I think it's not bad as getting the unencrypted data but it is still destructive which can be avoided if we used a stock rom.

So is there a way to prevent this kind of damage in custom roms?

Imagine this, You leave your OnePlus 8t just for a minute, I can quickly boot into recovery and destroy all your data. It's very likely that you lose data which you did not backup. And will take a lot of time to recovery from that damage.

 

[WhitbyGreg]

Awesome.

In the reddit discussion on bootloader and in this thread you recommend a user build. I get that nobody can flash unsigned packages from recovery when it's a user build. But it will not prevent someone from factory resetting my phone without any form of authentication, right?

So if we are using custom rom like lineage os we give anyone the power to destroy our data anytime. I think it's not bad as getting the unencrypted data but it is still destructive which can be avoided if we used a stock rom.

So is there a way to prevent this kind of damage in custom roms?

Imagine this, You leave your OnePlus 8t just for a minute, I can quickly boot into recovery and destroy all your data. It's very likely that you lose data which you did not backup. And will take a lot of time to recovery from that damage.

Most stock ROM's let you do this as well (including Oneplus), and you can do it through fastboot anyway, so removing it from recovery doesn't get you anywhere.

Let's face it, there are faster and easier ways for someone to "wipe" your phone if they have physical access to it... aka phone meet hammer.

The point of AVBv2 isn't to avoid data loss, but prevent data exfiltration and tampering.

In your example, while you might lose the data, someone else didn't get it and you definitely know someone tampered with your device.

 

[antonyjr]

Most stock ROM's let you do this as well (including Oneplus), and you can do it through fastboot anyway, so removing it from recovery doesn't get you anywhere.

Let's face it, there are faster and easier ways for someone to "wipe" your phone if they have physical access to it... aka phone meet hammer.

The point of AVBv2 isn't to avoid data loss, but prevent data exfiltration and tampering.

In your example, while you might lose the data, someone else didn't get it and you definitely know someone tampered with your device.

Thank you for the reply. I found a guide online on how to reset the phone with forgot password in recovery in oneplus stock rom, stupid me for asking the question.

 

[antonyjr]

Will this work for Lineage OS 19 (with Google's GSI ****). I really hate that, instead of mainlining the android kernel with the Linux Kernel project and standardizing everything they are keen on moving further away from Linux. But the idea seems interesting though.

But OnePlus 6 has linux mainline(v5.16.x??) support thanks to PostmarketOS folks. Sad thing is that there is no mechanism like AVB but FDE works. So there is some hope. But I think real linux os for modern android phones is going to be hard. (And not to mention driver support nightmare).

 

[WhitbyGreg]

Will this work for Lineage OS 19 (with Google's GSI ****). I really hate that, instead of mainlining the android kernel with the Linux Kernel project and standardizing everything they are keen on moving further away from Linux. But the idea seems interesting though.

But OnePlus 6 has linux mainline(v5.16.x??) support thanks to PostmarketOS folks. Sad thing is that there is no mechanism like AVB but FDE works. So there is some hope. But I think real linux os for modern android phones is going to be hard. (And not to mention driver support nightmare).

Google is working towards mainlining all of their changes, but it is a long involved process, so it won't happen anytime soon.

I haven't ported the script changes over to LineageOS 19 yet, as that's not officially released, but I will when it is.

As for GSI's, no, as GSI's by definition don't include anything but the system partitions, so you can't build a proper vbmeta image to flash to the phone so that the bootloader can check the critical partitons.

As for using a mainline kernel, yes it should work as AVBv2 is primarily in the bootloader, before the kernel starts up, from my understanding.

If you really want a mainline Linux kernel for your phone right now, you're better off going with a full Linux OS on the phone, but from what I've seen, those aren't really ready for prime time yet. Otherwise wait for Google to finish their work on moving their changes to the mainline kernel.

 

[namhoang235]

Nah, this is bone stock 18.1. Lineage doesnt do signed builds so theres occasionally little hiccups on these steps. I think it has to do with recent FCM changes tho, in the full context of it it happens with ota_from_target_packages tripping on FCM VNDK API 30 vs null. Ill post my fix

EDIT: Full stdout if interested

Linx Server - otafromtargetderps.log

bin.xs.pe

have you fixed this?