Device not booting with manual installed stock rom and locked bootloader (device corrupted)

Help Fairphone 4
1

Hello there,

I create a new topic, but my situation is in relation to this topic:
forum.fairphone com/t/device-not-booting-after-flashing-factory-image-and-locking-bootloader/82231/79

In the last year I switch from the stock fairphone 4 rom to calyxos 3.9 and locked the bootloader.
No problems are there.
But some things let me test iodeos.
So I unlock the bootloader, flash iodeos and relock it afterwards.
Now the phone says your device Is corrupted and want start.

In detail, I don’t take a look at the actually security situation between these roms.
Calyxos are installed with may 2023 security patch and iodeos is actually in april sec. patch.

Afterwards I relock the bootloader and the critical partitions, and load the stock firmware from
https://support.fairphone.com/hc/en-us/articles/4405858261777.
After flashing and locking I realized, that this stock image was not up to date…
It’s version FP4.SP21.B.048, but the actual version are FP4.SP28.B.065.
See https://support.fairphone.com/hc/en-us/articles/11351328932497.

I reflash the stock rom, iodeos, calyxos 20 times with different methods and don’t get the bootloader locked without the corrupted message.
If I am right, the only thing I can do to relock the bootloader is waiting for an actually stock image with the may security updates to flash it and reflash the custom rom I want.

Can anyone confirm that?
Or have anyone a link to the actually firmware provided it has the new security patch?

But what I don’t understand is If this depends on the securitypatches and androids rollbacksecurity, why I don’t can reflash the actually calyxos image an lock the bootloader again?

Can it be, that this rollback get a bit deeper?

Installed Calyxos before try flashing:

shipped with proprietary files : FP4.SP28.B.065.20230420
kernel patch: May 2023
software patch: May 2023

iodeos

based on proprietary files: January 2023
kernel patch: March 2023
software patch: March 2023

actual flashing.zip from calyxos - so if I remember correctly

shipped with some, not all proprietary files : FP4.SP25.B.058.20230318
kernel patch: April 2023
software patch: May 2023

madbehaviorus

2

Welcome to the community :wave:

Let me get this straight, your goal is still to end up with an iodéOS install, right?! :thinking:

Then yes, you need to wait for iodé to catch up to the CalyxOS SPL you had before. You won’t be able to lock your bootloader with the outdated stock FPOS factory images either.
CalyxOS tries to follow the FPOS releases as close as possible, so soon after a new OTA release is out it’ll get updated to that patchlevel, for security reasons and because otherwise people on the latest stock FPOS couldn’t switch over to Calyx.

Whatever you do, I hope you keep :eyes: on fastboot flashing get_unlock_ability.

1 Like
3

Thank you.

Ok, I had kept in mind, that the partition or drive, that stores the number of the security patches (index) is a part of the stock installation and can be reflashed.

I take a look at rollback_index_location field of the main vbmeta struct at verified boot 2.0 :

https://android.googlesource.com/platform/external/avb/+/master/README.md#rollback-Protection

and see the partition is named vbmeta (in A/B its vbmeta_a and vbmeta_b).
The stock_rom.zip have also the vbmeta image.
So how I can imagine that?

A bit more simplified:

vbmeta is an image that stores all root hashes from the hashtrees from the images like system vendor boot etc. and is signed with the custom_key.
But the ROLLBACK_INDEX is located in an other location. This location is a tamper-evident storage. So it can’t be manipulate from us.
Excluded the from the index info that every rom are shipped with.

I think this article describes the situation good:
https://www.xda-developers.com/xiaomi-anti-rollback-protection-brick-phone/

One sentences is important:

“There is one caveat, however. There’s no way to tell beforehand if the rollback index has been incremented due to an updated bootloader, modem, vendor, or other partitions.”

In my short search I can’t find the answers to the following questions:

  1. If I’m right, the the custom rom can “set” the rollback index so high, that it is never possible to install a new rom.
    So there are only two solutions there:
    a) all new flashed roms has the same or => index
    b) the support with special connectors / hardware can reflash / renew it? Maybe??? Than its not really a tamper-evident storage.

  2. For a patch level only exits one number.
    Independent witch image (vendor, kernel, system etc.) have the highest index, this number is set If its higher than before as rollback_index right?

4

Yes, in fact that has been a problem in the past (not to that extreme) because Calyx used to set the SPL to the actual level they shipped, which lead to people not being able to go back to stock because FPOS is always lagging behind.
That’s why they started setting it to the latest FPOS SPL, even if CalyxOS is ahead.

The problem is that according to the docs the rollback_index should actually be reset when installing a new ROM, but so far no one has been able to explain why it isn’t. FP isn’t very communicative in that regard, and the Calyx devs didn’t get an answer out of them either :roll_eyes:

Not exactly, the rollback_index used is in this case just the unix timestamp of the platform security update. It’s set in BoardConfig.mk, so you could just use a different int if you wanted, as long as you increase the number.
Here’s how it looks for CalyxOS …

BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
[…]
# Security patch level
BOOT_SECURITY_PATCH := 2023-04-05
VENDOR_SECURITY_PATCH := 2023-04-05

# Calyx
PLATFORM_SECURITY_PATCH := 2023-04-05
STOCK_SECURITY_PATCH := 2023-04-05 # Latest stock update available
PLATFORM_SECURITY_PATCH_TIMESTAMP := $(shell date -d 'TZ="GMT" $(STOCK_SECURITY_PATCH)' +%s)

… as you can see, it gets set to the stock SPL.

I wrote a bit more about it here, I’m not a dev though, beware off potential errors.

5

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.