I had to roll back to stock android from IodeOS on my FP5 for some testing, but I didn’t realize that the security patch was older (October) than currently on IodeOS (November). Thus I couldn’t relock the bootloader due to the risks of bricking the phone.
Now I’m done with my testing on stock and would like to install Iode again, but I’m afraid to relock on it either, since fastboot flashing get_unlock_ability returns a 0.
So my question is: is it safe to relock the bootloader on Iode since I didn’t lock it on stock, or should I wait for stock to be updated so I can first relock on it, and then install Iode as normal?
Reverting back to stock I had to unlock_critical, so that might bring issues, since the instructions tell you not to do that? ( ota / ota · GitLab )
My recommendation is to make sure to enable get_unlock_ability from Developer Options, make sure to not have any Google accounts registered on the phone, then flash but do not lock the bootloader at this time. Then login to the phone, make sure that Developer Options still has “Enable OEM Unlocking” enabled and that everything else is as expected. Then if all looks good, go ahead and relock using fastboot flashing lock (which will wipe your userdata again so you will need to re-setup).
Alright thanks, this sounds good. Actually the new FP update came quicker than I thought it would (today), so I should be able to relock it on stock now. But then reflashing Iode would introduce an older security patch so that might be an issue again… So I’ll consider my options haha.
For an update, I still couldn’t relock after the 7.1 update, or even after first reverting back to stock and then reinstalling Iode. I thought 7.1 would come with the same December 5th security patch as Fairphone’s stock package, but maybe that’s not right then?
OK so you are now on iodéOS, but unlocked. FYI to be safe, I would confirm that “Allow OEM Unlocking” is enabled before attempting to relock.
But then when you issue “fastboot flashing lock” it gives an error, or then is unbootable, or what happens?
The 7.1 update should include the SPL you refer to. But there are some FP4 users who still report that when they relock it will end in a boot loop until it reverts to the prior installation (due to the “A/B” partition scheme). Maybe that is what you are facing too?
No actually I chose to stay on stock for now, I don’t like to idea of walking around with the bootloader unlocked. The issue was that I got the “device is corrupt” prompt when trying to do the fastboot flashing lock.
I think I’ll just wait for 7.2 and see if that changes anything
I hear you, but personally I am still of the opinion that an unlocked bootloader only protects you from an “Evil Maid” (and even then I don’t know of any successful "evil maid’ exploits on Android):
I am genuinely open to a simple explanation of how it is a credible risk for privacy concerns… admitting that yes deep-state-level actors may have ways to trigger an exploit, but is this just due to an unlocked bootloader or more likely to something else?
But to the issue, yes I hope future builds will have this fixed. As noted, we have confirmed issues with the FP4 that may possibly be related to this:
Our developers note the following about a question of whether that above post is related to our issue of FP4 users with locked bootloaders not able to upgrade to v7.x:
yes, but the actual firmware is FP4.QREL.15.14.3… maybe there’s a problem with it too. Waiting for the new firmware FP4.SREL.15.14.4, not released on their website yet
So possibly FP is rolling out firmware updates across the line to address some issues. When they do they will be incorporated in our next builds following their release.
Right, I’m not that knowledgeable about this stuff and have actually been wondering what kinds of exploit scenarios an unlocked bootloader opens up. Been mainly going with the common sentiment that it’s risky.
But thanks again, I’ll keep waiting for the updates!
Things could have changed, but last time I checked, anyone with physical access to a phone with an unlocked bootloader can use the USB to install malware that can bypass all security. When you enter your PIN after such a compromise, all your data can be leaked to the attacker.
If I connect a USB cable to my smartphone, I need to type my PIN before I can set to “data transfer”. So without my PIN there is no possibility to install any malware.
What you describe is what an “evil maid attack” is, but I don’t know of such an ability to install in this way on Android. The system is read-only, if it is replaced it will not boot due to signature mismatches. The writable userdata partition is encrypted until user unlocks it. So where can they install such malware?
Sorry I didn’t explain correctly and certainly what I have written previously is misleading. I had been thinking at the time during various dirty flash swaps between systems that have failed to boot for for me it was because even though the device was unlocked, it still possibly had some ability to detect the underlying system had changed and then prevent the ability to decrypt. But that was late night triple thinking something and the last two layers of thinking were not formed correctly. So I don’t know why it is needed sometimes to “Factory Reset” if a dirty flash fails to boot, but I have seen that (for seemingly unrelated reasons).
However, I was also under the impression that since the OTA process is able to perform a build signature verification and not allow the install if new new update has a different signature, that we would also be able to inspect if a current running system had a tampered with base, so that possibly from recovery or fastboot we could inspect the current system to see if it matches what we expect from upstream. But that isn’t the case (more late night over thinking going on: are you detecting a trend? The answer is no over thinking past a certain time for me but how do we enforce that? )
In summary, you are correct if physical access to your device by a malicious actor is suspected then to be certain you won’t be the next (or first ) victim of an evil maid you would need to reflash the device before you would login to it and thus decrypt userdata.
So in summary, a locked bootloader doesn’t better protect the data itself (this is the same as if it had an unlocked bootloader), but its does prevent booting if the system is changed out from under you, effectively “confirming an evil maid visited” We won’t know if the evail maid paid a visit if it doesn’t have a locked bootloader.
Sorry again to be spreading misinformation previously.
I do personally remain unworried that any evil maids will be visiting me but to each their own
Thanks for the help!
So I don’t know why it is needed sometimes to “Factory Reset” if a dirty flash fails to boot, but I have seen that (for seemingly unrelated reasons).