The unlocked bootloader problem on a rooted FP3. What exactly is happening?

I have an FP3 which is rooted and I update the OS using the procedure documented here: https://www.thecustomdroid.com/install-ota-update-rooted-android-device-guide/

If I attempt to lock the bootloader I get a message saying the phone has been corrupted. I like to understand what is going on so I have a few questions:

  1. Has the phone really been corrupted or is it just that checking software thinks it has? If not then is there anything simple I can do about it?
  2. Does the same thing happen with all A/B phones or is it specific to the FP3?
  3. Are there any other operating systems for an A/B phone that do not provide a native way of rooting but for which this does not happen?

Finally I would like to say that I think there should be some native way of rooting the phone. I realize it’s not for all users (don’t say not for mums and dads because I’m 72 and a grandad and none of my kids would ever dream of rooting a phone) but it should be possible, not necessarily easy, to root it.

Before I had this phone I had an FP2 running Fairphone-Open and it was dead easy to root. I was quite disappointed that I got less functionality running an FP3 with /e/-os.

Regain your privacy! Adopt /e/ the unGoogled mobile OS and online servicesphone

I don’t use root anymore so probably my knowledge isn’t too deep on that matter.

But from the link you provided I see this part

The second method was introduced when Google first released the Google Pixel devices in 2016. These devices came with dual A/B partition system to support seamless updates and removed the recovery partition from the devices completely. So, the first method failed rigorously. This new method involves patching the stock boot image using Magisk and then flashing the patched boot image via Fastboot.

I guess the bold-face part explains why the phone has been corrupted. From what I understood, that’s exactly the thing a locked bootloader protects from.

One thing that made all this easier on the FP2 was that its bootloader wasn’t locked/lockable.

1 Like

Yes, I see that, but I suspect that the supposed check for corruption involves little more than checking a fingerprint, something like sha256. But whatever it does, using the word ‘corrupted’ is misleading; ‘changed’ would be better. I’m all for security but it seems absurd that the user can’t change the lock. It’s a bit like locking all your tools in the garden shed and throwing the key away ‘for security’.

But I suspect that, in reality, the user can change the lock. The key must be stored on the device itself and if you have the device in your hands with root access there must be some way of changing it. I’m not sure how much added security this actually gives against the people who really matter to me. If I go to China and the authorities want to ‘examine’ my phone, they may well have got this all figured out.

Of course the real answer is to allow routing at the operating system level itself. You can then have the checks that locking the bootloader gives and they will add whatever added security they add.

My own attitude is that I want, at least in principle, complete control over any device I use. Nannyware that won’t let me do things because it thinks I haven’t wiped my nose properly may be well meaning and may offer some protection, but who is to say that it, itself, has not been patched?

I don’t intend to comment on your expectations/requirements, but I think I have something to add on the technical aspect.

I have no idea about your technical background, so maybe all I write is already known to you, but from those sentences I’d assume you got something wrong (or I didn’t catch your meaning 100%).

First of all I doubt that checking for corruption can be done by a simple sha256 checksum. For that the bootloader would have to know all checksums for all future update images. I’m pretty sure that’s impossible mathematically.

Then about “the” key. If “the” key would be stored on the phone I’d assume the whole concept wouldn’t make much sense.
To be sure, I don’t know implementation details, but if at all, I’d assume the verification works with public/private keys. Then, the public key is used by the bootloader to check that the image (or its checksum) was signed with the corresponding private key. Using the public key extracted from the bootloader (if that’s what you meant to say?) wouldn’t help.

I could imagine that the bootloader could be set up in a way so that a user can add their own public key in order to verify images signed with the user’s private key (maybe that’s what you wanted?). But I’m not aware that the FP3 is set up like this (IIRC that’s only the case for Google Pixel phones, but here my knowledge isn’t really firm).

Maybe that’s what you meant all along. Just wanted to make sure our understanding matches.

1 Like

I do tend to be a bit sloppy at times.

As an aside, I can remember quite vividly going to a lecture on public/private keys way back in the early 70’s. I guess it must have been a fairly new idea then. The reason I remember it so well is that I had a colleague who had a scholarship from the US Navy to do research into the generation of large prime numbers for his doctorate. We all thought the US Navy must be crazy but half way through the lecture it dawned on me why they had done it.