Can't unlock EOM anymore, because FRP is not flashed (I've been told)

[anon73588713]

@rik

@anon73588713 thanks for the explanations, I am appreciating this challenge more. But I am still not sure how under normal operation a user with a new install of iodé would have get_unlock_ability ever set to 0. Yes, it may be put to 0 when the factory image was installed as you note, but then the bootloader would need to be unlocked before installing iodé and thus the value should be 1 at all times when installing iodé correct?

Installing factory images doesn’t lock the bootloader, the install script doesn’t perform that step. They just dump you in a newly installed system, with get_unlock_ability set to 0 and expect you to reboot yourself and lock it. Which is wildly more unsafe then just locking it before the first boot, at which point get_unlock_ability would still be at 1. If you flash factory images with an outdated SPL and follow the official instructions, then that’s a brick. I’ve told them for years to fix it…

A user could just flash factory images without locking the bootloader, run it for months (adding a Google account in the process), and then flash iodé. The bootloader is already unlocked, I don’t need get_unlock_ability, you can’t even enable the OEM unlocking switch on stock if the bootloader is unlocked, it’s greyed out.

For that user to start the iodé installation at 1, they’d need to either flash factory images again without booting them after installation (requires modifying the install script or catching the reboot in time), or fake a locked bootloader with Magisk, which makes the OEM unlocking switch available again.

(Or they could run the complete stock installation, including taking the risk to lock the bootloader themself, to then immediately unlock it again, and only after that start the iodé installation, I wouldn’t…)

@rik

So in this case, I guess the manual running of lock_critical after install is what then set it to 0?

No, get_unlock_ability was already at 0 at this point, fastboot flashing lock_critical happened after the first boot, and that’s what reset it.

I’ll try to write a test case that hopefully makes this reproducible, starting point is a FP4 with a locked bootloader:

1. Enable OEM unlocking in the developer options, get_unlock_ability changes to 1
2. Run fastboot flashing unlock and fastboot flashing unlock_critical, still at 1
3. Install the factory images, get_unlock_ability is at 1 during installation, changes to 0 when we reach Android userland
4. (Run fastboot flashing lock_critical) I would skip that part, checking that fastboot flashing get_unlock_ability returns 0 should be enough for this test and is safer
5. Set up a Google account on the phone, which primes factory reset protection
6. Our bootloader is still unlocked so we directly start the iodé installer, don’t lock the bootloader in the end and don’t let the installer finish, just stay on that prompt
7. Open a terminal and check get_unlock_ability while the installer is still running, then finish the installation (without locking!) and check it again after first boot
8. Try enabling OEM unlocking and see if it crashes
9. Optionally (in case it crashes) repeat the previous step while running adb logcat -c && adb logcat *:E > logcat.txt and look for FRP in the output

The most interesting part is the value of get_unlock_ability in step 7. If my theory is correct then it should stay at 0.
If it’s 1 before the first iodé boot we have to look for a different cause for the reset, could be FRP getting triggered, I’m not sure.

I would run that test myself, I already have iodé on my FP4, but I don’t have the time to set up my phone again from scratch the next few days (realistically not before the end of the year tbh)