[OnePlus 3 & 3T Cross Device Development] trachyte:
Thanks for the crypto footers. I'd still like to see a clean 5.0.x one, but I'll have one myself soon once I reset my device.

My thinking thus far is:

1) There is nothing wrong with the crypto footer post 5.0.x -> 9.0.x, except the keymaster_blob may have been overwritten (see below).

2) There's (probably) nothing wrong with the data on the userdata disk.

3) The correct process for mounting userdata should be (summarized):

Generate Intermediate Key (IK) using user-supplied password and crypto footer fields

Call the HW module to sign the IK and create IK2

Use IK2 to decrypt the encrypted master key stored in the crypto footer

Set up dm device by supplying decrypted master key to dm-crypt

Mount dm device on /data

4) The actual process post 5.0.x -> 9.0.x:

The whole process gets short-circuited because the new keymaster or TrustZone firmware doesn't work with the 5.0.x crypto footer and/or keys stored on the HW module. Exactly why and why locked vs. unlocked bootloader matters I don't know. At some point the keymaster tells the HW module to generate a new signing key (I have not verified this) and maybe the keymaster_blob in the crypto footer is overwritten too.

The error pathway checks that the IK generated from the user's password matches the one stored in the crypto footer fields. It does, so it sets the CRYPT_DATA_CORRUPT flag and shows the 'Password is correct but data is corrupt' error message

5) The actual process post 5.0.x -> 9.0.x, after reflashing 5.0.8 firmware:

Generate Intermediate Key (IK) using user-supplied password and crypto footer fields

Call the HW module to sign the IK and create IK2

The HW module signs the IK using a different key than it used when encryption was first set up on the phone, thus returning a different IK2

Use IK2 to decrypt the encrypted master key stored in the crypto footer (this works even though IK2 is wrong -- the "decrypted master key" is not correct though)

Set up dm device by supplying incorrect decrypted master key to dm-crypt (this also works. /dev/block/dm-0 is created and can be read from. It returns nonsense data though because it's using the incorrect master key to decrypt the data)

Try to mount dm device on /data, but fail because the data is not ext4

The error pathway checks that the IK generated from the user's password matches the one stored in the crypto footer fields. It does, so it sets the CRYPT_DATA_CORRUPT flag and shows the 'Password is correct but data is corrupt' error message

TL;DR: 9.0.x probably overwrites the signing key stored in HW and maybe the keymaster_blob stored in the crypto footer.

So in order to fix this and decrypt your userdata, the original signing key (and thus keymaster_blob) is needed. Now this seems impossible, right? Surely the HW module generates a random key every time it is asked to create a new key, right? I would have thought so but apparently that is not the case. According to security researchers the same version of the same TrustZone application, asking to create a key using the same parameters, will result in the same key being generated. This is because the core Secure Hardware Key (SHK) is baked into the hardware and never changes, and new keys are derived from the SHK, not randomly. This article explains that: https://bits-please.blogspot.com/2016/06/extracting-qualcomms-keymaster-keys.html.

And to make it complicated, there's a chance newer KeyMaster versions fixed the "vulnerability" of constant key derivation and actually generate random keys. But what matters is when your original signing key was generated. If it was generated 2016/2017 then you should be able to regenerate it using older firmware from that time. I have no idea if it was ever fixed in KeyMaster or when, only that the in linked article KeyMaster had not been fixed as of 03/2017. In order to determine if it was ever fixed, one would need to examine the latest KeyMaster binary and check if the KDF used has changed or not. I encrypted my device in 2016, so I haven't checked that.

Next steps:

I'm going to wipe my device using 5.0.8 multiple times and see if the keymaster_blob is the same each time. If not, I'll try downgrading to older firmware from 2016 and trying again.