[ROM][Official][Nightly] LineageOS 16.0 for OnePlus 3/3T

[Deleted member 4405529]

@trachyte:

You last posting is one of the most interessting readings for a long time!

I'm stiil using 5.0.8 bootloader and keymaster (for details see https://xdaforums.com/oneplus-3t/how-to/guide-cope-9-0-3-5-0-8-firmware-barrier-t3941164). You still need a clean encryption footer with plain 9.0.x bootloader and keymaster.

That being said: if you can't find a way to migrate a 5.0.x footer to a 9.0.x compatible one, you can reset the footer to it's former 5.0.x state and access your userdata partition with 5.0.x fw or the modded 9.0.x fw from tje thtead mentioned above.

I'm crossing fingers, you'll find a way to transparently migrate a 5.0.x footer to a 9.0.x footer and vice versa.

I'm really impressed by your findings!
@All: @trachyte still needs a footer from an encrypted 9.0.x fw!!!!

 

[Deleted member 4405529]

So here we go @nvertigo67: If you want to work on the updater, I want to help you. Just tell me what to do.

It's not the updater it's twrp. Cutrently no logs are needed. Hopefully the next twrp build will have it fixed. Thanx for your offer.

 

[jakito]

Ok, more from my research into the 'Password correct but data is corrupt' error.

1) I verified that CRYPT_DATA_CORRUPT was set in the crypto footer flags. The flags were actually 0x00001008. 0x00000008 is CRYPT_DATA_CORRUPT. 0x00001000 has no meaning here so I don't know why that was set.

2) I cleared CRYPT_DATA_CORRUPT in the flags, rebooted into the system, and as expected Android asked for the password again. It fails with the same error, and sets CRYPT_DATA_CORRUPT in the flags so that subsequent boots don't even ask for the password and go straight to the error message.

3) Clearing the 0x00001000 in the flags made no difference. In fact Android also adds the 0x00001000 back into the flags when it shows the error message. I can't find any place in AOSP that sets this, which is strange, but I don't think it makes a material difference.

The underlying reason the decryption fails appears to be that the keymaster_blob in the crypto footer is incorrect. The evidence for this:

1) All other fields of the crypto footer are the correct size and in the correct format. keymaster_blob, however, is shorter than it should be and is mostly zeros. The zeroed area is where data such as the IV and HMAC should be.

2) When attempting to decrypt in TWRP, the error returned is -33 aka INVALID_KEY_BLOB.

Next steps:

It would be really helpful if I had known-good crypto footers that I could compare to. If you have a working phone with an encrypted userdata partition and would be willing to send me the crypto footer (last 16KiB of userdata partition), here is the command to run in recovery:

    adb shell
    p=`basename \`readlink /dev/block/by-name/userdata\``; s=`grep "$p\$" /proc/partitions | awk '{ print $3 }'`; o=`expr \( "$s" \* 1024 \) - 16384`
    dd if=/dev/block/by-name/userdata of=/tmp/crypto_footer skip="$o" bs=1

    adb pull /tmp/crypto_footer crypto_footer

And then upload crypto_footer somewhere I can grab it. You'll know you have the right data when the first bytes are C4 B1 B5 D0 or similar.

Having the crypto footer means I would have a slight head start in cracking your device if I had access to it, but is of no use without the device, so use your own judgement about your security situation before sending it.

Once I'm able to compare my crypto footer to known-good ones, I will be able to see exactly what is wrong with the keymaster blob. And from there I'll be able to see if the affected areas can be recreated or if there's no way to recover it.

Here's a crypto footer from a working 9.0.x firmware OP3.

Edit: changed the crypto footer name to make it more understandable

 

[trachyte]

@trachyte:
I'm stiil using 5.0.8 bootloader and keymaster (for details see https://xdaforums.com/oneplus-3t/how-to/guide-cope-9-0-3-5-0-8-firmware-barrier-t3941164). You still need a clean encryption footer with plain 9.0.x bootloader and keymaster.

This is getting stranger. Your keymaster_blob is exactly like mine. A full qcom keymaster blob is:

struct  qcom_km_key_blob {
  uint32_t magic_num;
  uint32_t version_num;
  uint8_t  modulus[KM_KEY_SIZE_MAX];
  uint32_t modulus_size;
  uint8_t  public_exponent[KM_KEY_SIZE_MAX];
  uint32_t public_exponent_size;
  uint8_t  iv[KM_IV_LENGTH];
  uint8_t  encrypted_private_exponent[KM_KEY_SIZE_MAX];
  uint32_t encrypted_private_exponent_size;
  uint8_t  hmac[KM_HMAC_LENGTH];
};

We have these in the correct format:

  uint32_t magic_num;
  uint32_t version_num;
  uint8_t  modulus[KM_KEY_SIZE_MAX];
  uint32_t modulus_size;

Except the magic_num is supposed to be 0x4B4D4B42 (in Android 8.0 and 9.0). Our magic_num is 0x4B4D4B44. I can find zero references to that magic number anywhere online. The 42 -> 44 change suggests somebody incremented the magic number twice. We're two versions ahead? It also doesn't make sense that they would increment the magic number because it's supposed to be "KMKB" for "Key Master Key Blob" and now it's "KMKD". There's also a perfectly good version_num field they could have incremented instead.

The 512 bytes for public_exponent has 414 bytes of data and the remainder are zeros. public_exponent_size and the rest of the fields are all zeros. Then the keymaster_blob_size follows and is 1187. The keymaster_blob_size is supposed to be 2048, and the beginning of 1187 is exactly 2048 bytes from the magic number. And 1187 doesn't correspond to the end of the data or anything, it just points to a spot amongst the zeros.

I think it's a small miracle your phone still boots :laugh:

I'd really like to see clean 5.0.x and 9.0.x crypto footers. Or any crypto footers from Android 8 or 9, doesn't have to be from OxygenOS firmware (although probably not from Samsung since they do things somewhat differently). This is all leading to me flashing 5.0.x and experimenting with that, but I'd like as much information as I can before I do that.

---------- Post added at 12:16 PM ---------- Previous post was at 12:07 PM ----------

Here's a crypto footer from a working 9.0.x firmware OP3.

Thanks. Was this phone upgraded from 5.0.x or was it a clean 9.0.x install?

Edit: Hmm, XDA made my reply an edit. That was intended for @jakito

 

[jakito]

Thanks. Was this phone upgraded from 5.0.x or was it a clean 9.0.x install?

Edit: Hmm, XDA made my reply an edit. That was intended for @jakito

It was a clean install. I upgraded but it messed up the phone so much I just got annoyed and formated everything, changing from ext4 to f2fs and back to ext4... hope this helps you

Edit: And didn't restore anything btw. I just installed everything from the PlayStore and the LOS was also a clean install. Sorry for the misunderstanding.

 

[Deleted member 4405529]

I think it's a small miracle your phone still boots :laugh:

Thanx God my device doesn't know that...

I'd really like to see clean 5.0.x and 9.0.x crypto footers.

The footer, I've posted was generated with twrp 3.2.1-0 (old non unified version), fs is f2fs, initial encryption was done with nlos-15.1. I've clean flashed 16.0. I've dirty flashed builds after the native oneplus blobs switch with modded fw.

 

[noisy_lightning]

Hi, it's been a while since I ran LOS on my OP3. The main reason I went back last time was the camera quality vs stock was so much worse, and despite weeks or trying I was unable to find solutions to fixing it.

How do we fare now in comparison to stock on photos, have OP released the source code yet for the camera?

Sent from my ONEPLUS A3003 using Tapatalk

 

[jakito]

Hi, it's been a while since I ran LOS on my OP3. The main reason I went back last time was the camera quality vs stock was so much worse, and despite weeks or trying I was unable to find solutions to fixing it.

How do we fare now in comparison to stock on photos, have OP released the source code yet for the camera?

I use the gcam mod. Can't really talk about the native camera, but the gcam is superb.

Edit: And I believe is better then the OOS native one.

 

[Notor1ouS-]

I'm on Firmware / Modem 9.0.4.
can i update to 9.0.5 on the latest LineageOS build or will i get problems?

 

[Deleted member 4405529]

I'm on Firmware / Modem 9.0.4.
can i update to 9.0.5 on the latest LineageOS build or will i get problems?

No, go ahead. The problem is crossing the 5.0.x-9.0.x (or vice versa) border. There are no 9.0.x-9.0.x+n borders.

 

[mottenkiller]

And then upload crypto_footer somewhere I can grab it.

Here is mine.

My recent phone history:
- Stock 9.0.5 (encrypted)
- format /data + wipe /system
- LOS 16 / encrypted today

 

[S4turno]

Hi, it's been a while since I ran LOS on my OP3. The main reason I went back last time was the camera quality vs stock was so much worse, and despite weeks or trying I was unable to find solutions to fixing it.

How do we fare now in comparison to stock on photos, have OP released the source code yet for the camera?

Sent from my ONEPLUS A3003 using Tapatalk

Quality on custom ROMs will always be worse than stock, but even stock is crap compared to what you can get with a modded Google Camera app: https://xdaforums.com/oneplus-3/how-to/modded-google-camera-hdr-60fps-video-t3658552

The one from Urnyx05 works out of the box. Only slow motion is broken.

 

[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.

 

[felagund]

Hi, it's been a while since I ran LOS on my OP3. The main reason I went back last time was the camera quality vs stock was so much worse, and despite weeks or trying I was unable to find solutions to fixing it.

How do we fare now in comparison to stock on photos, have OP released the source code yet for the camera?

Last time I went to OxygenOS it was also due to camera performance and Sultan stopping development and having to go clean flash anyways. Stock camera was faster and better than foss camera. However when I tried the gcam ports it was night and day and actually I was having problems swapping the stock for gcam in all lockscreen+gestures so LineageOS was better for lots of reasons and customizing camera shortcuts instead of forcing the stock cam was a major positive.

So you can give it a go and use a recent good quality gcam port.
You will still have lower speed of starting and using the cam but at least no painting effect like on stock and overall good quality and lots of options.

I recently broke my back camera glass and sensor and can't do comparison photos to show.

 

[trachyte]

Ok, results from my continued testing. The news isn't great but at least it's damn interesting.

9.0.5 firmware with LOS 16.0-2019042(8? 9?): Does not produce the same keymaster_blob
5.0.8 firmware with LOS 14.1-20170727: Does not produce the same keymaster_blob

In both cases I did a (wipe, clean flash of LOS, go through setup process and enable encryption) x 2, and compared the resulting keymaster_blob's in the crypto footers. They were different every time.

The exact setup for the 5.0.8 test was: Stable5.0.8 Firmware+Modem_OnePlus3T.zip + lineage-14.1-20170727-nightly-oneplus3-signed.zip + twrp-3.3.0-1-oneplus3.img. I chose these because they are from or near 06/2017 when my phone was initially encrypted (not 2016 as I had previously thought). For good measure I copied over my latest userdata (the one it would be nice to recover), and tried to decrypt that. No luck. It wouldn't even recognize that the password was correct: both recovery and system always failed with 'Invalid password'.

Ok, so I'm not able to generate the same signing key. What's left? Let's do a 5.0.8 -> 9.0.5 upgrade again, this time keeping meticulous track of what changes so we can nail down what exactly goes wrong during the process. This is where it gets interesting.

Before: Stable5.0.8 Firmware+Modem_OnePlus3T.zip + lineage-16.0-20190501-nightly-oneplus3-signed.zip + twrp-3.3.0-1-oneplus3.img
After: Stable9.0.5 Firmware+Modem_OnePlus 3T.zip + same OS and TWRP as before. Only the firmware was flashed, using TWRP.

After each step below I saved the crypto footer and the first 10MB of userdata to see if there were any changes. The steps taken immediately after flashing the firmware and their results:

1. Reboot to system, don't enter password, reboot to recovery: Results:

• CRYPTO_DATA_CORRUPT not set
• Crypto footer has not changed
• First 10MB did change (~4K out of 10MB, mostly in a few large chunks but also small changes)

2. Enter correct password in recovery:

• CRYPTO_DATA_CORRUPT not set
• Crypto footer has not changed
• First 10MB has not changed
• Recovery returns -33 aka INVALID_KEY_BLOB

3. Boot into system, enter correct password, get 'Password is correct but data is corrupt' error message, reboot into recovery:

• CRYPTO_DATA_CORRUPT is set
• First 10MB has not changed
• Crypto footer has changed:
  • CRYPTO_DATA_CORRUPT is set
  • 0x90e - 0x92b has changed completely (This is just the SHA256 sum of the crypto footer. A single byte changed when CRYPTO_DATA_CORRUPT was set, therefore the SHA256 sum changed too.)

Conclusions:

1. My theories regarding the crypto footer / keymaster_blob being modified during the firmware upgrade were completely wrong. The crypto footer is not modified except for CRYPTO_DATA_CORRUPT being set, which doesn't effect the underlying crypto at all.

2. Also the HW module signing key is probably not changed. Or at least there's no evidence to suggest it is. If it was changed then keymaster_blob should have been changed too, and it wasn't.

3. It was the userdata that was changed.

4. The process outlined in my last post for (post 5.0.x -> 9.0.x, after reflashing 5.0.8 firmware) is mostly correct, just with the userdata being changed instead of the keymaster_blob.

• IK2 is generated correctly
• IK2 is used to decrypt the encrypted master key correctly
• The correct master key is passed to dm-crypt to set up /dev/block/dm-0. This works even though the userdata is incorrect. dm-0 can be read from, but it returns nonsense data because dm-crypt is combining the correct master key with incorrect data.
• Mounting /data fails because dm-0 is not ext4

Let me reiterate that point number 3 since it's the big discovery here:

The userdata was modified.

Not only was the userdata modified, it was modified even before a password was entered. userdata had not been mounted and there was zero chance it could have been modified correctly. Whatever software modified it had no business writing to userdata. It was doing so completely blindly with no idea of what userdata contained. This was a massive f*ck up and shows complete disregard for users' data. In any situation when you're going to blindly overwrite userdata, the user should be prompted for confirmation.

What's next?

1. I'm going to do more 5.0.8 -> 9.0.5 firmware upgrades. For these I'll:

• Check more precisely exactly when the userdata is modified in order to narrow down which software actually makes the changes, and when
• Save more than 10MB in order to see how extensive the modifications are
• Restore the 5.0.8 userdata after it is modified, to see if 9.0.5 keeps modifying it every boot

2. I'll be comparing the changes from the first upgrade to the new upgrades to see if the changes to the userdata are the same each time.

3. Based on the above, try to figure out what the userdata modifications actually are. It's possible it's something like a quick format that might only affect the initial data, or otherwise be limited in such a way that most of the userdata is still intact and recoverable.

 

[Deleted member 4405529]

@trachyte:

Thank you very much for all the effort you put in testing and documenting!!!

Just some thoughts:

Keep in mind that oneplus stated that only locked bootloaders can be transparently updated. I still think all the update trouble is no bug (though oneplus stated to @dianlujitao they wil "fix" it), but intended. Modifying data on first boot no matter if the passphrase was given "smells" more like intention...

I'm pretty sure the keymaster partition plays in here, too.

 

[dogmatism]

Anyone's touchscreen stopped working after flashing the 3rd or 4th July release? It works immediately after reboot but once the phone goes to sleep the touchscreen stops working - buttons and finger print reader keep working.

change the default kernel. I have seemed to overcome this bug, by flashing latest madkernel

 

[trachyte]

"I will have no comment until the investigation is complete."

-- A Very Smart Person​

Previous test:

• Upgraded firmware 5.0.8 -> 9.0.5
• Rebooted to recovery
• Results:
  • 4K of first 10MiB of userdata was modified
  • I was not expecting userdata to be modified so I wasn't tracking precisely what the conditions were during the flash or checking precisely when the modifications occurred. But the sequence was: flash 9.0.5, immediately reboot to recovery and discover that userdata had been modified.
  • So, obviously it was the firmware that made the changes.
  • Caught you, firmware!

Now let's replicate that result and narrow down exactly when the userdata is modified and exactly how it is modified. All of the Upgrade Tests below start with: Wipe, Format, Flash 5.0.8 firmware, reboot to system, do initial setup and enable encryption, reboot to recovery. All tests were done with LOS 16.0-20190501 and TWRP 3.3.0-1. This time I checked the first 500MiB of userdata, and also 500MiB of data starting exactly 20GiB into userdata. I also checked the crypto footer, but there were no changes to it in any of the tests besides setting CRYPTO_DATA_CORRUPT and updating the SHA256 sum.

Upgrade Test 1

• Flash 9.0.5 firmware (and do not reboot)
  • No changes
• Let recovery sit for 15 minutes
  • No changes
• Reboot into recovery
  • No changes
• Click around in recovery UI but don't change anything
  • No changes
• Reboot to recovery
  • No changes
• Do literally 55 other steps (reboots to recovery, reboots to system, enter correct/incorrect passwords, hard power off, and more) to give every opportunity for something to modify the userdata
  • No changes
• Thoughts
  • That's strange, but I must have done something differently in this test. I'm sure another test will be able to replicate the original results.

Upgrade Test 2

• Flash 9.0.5 firmware (and do not reboot)
  • No changes
• Reboot into system, don't enter password, reboot to recovery
  • No changes
• 4 more various steps
  • No changes
• Thoughts
  • Ut oh, that's twice in a row. Did I cry wolf about userdata being modified? Hmm, I wonder if I had userdata mounted to /data in recovery during my original test.

Upgrade Test 3

• Mount /data in recovery, flash firmware 9.0.5, reboot to system, don't enter password, reboot to recovery
  • First 500MiB: ~500 bytes changed
  • Middle 500MiB: ~130 bytes changed
• Thoughts
  • Aha! /data needs to be mounted during the flash in order for userdata to be modified. The firmware probably isn't aware of userdata unless it's mounted during the flash. Doesn't quite make sense but the test data doesn't lie. The modifications are a lot smaller than my original test but both the first 500MiB and middle 500MiB changes take place on well-known boundaries. The first changes to both are exactly 1024 bytes in. Clearly the firmware is doing a quick reformat of some type. Let's do this same test again just to make sure /data being mounted is what makes the difference.

Special Test 3.5

• Purpose
  • This was a quick test while resetting to 5.0.8. I was worried that since /data was mounted during the install, and therefore underwent unmounting during the reboot after flashing, it may have had data written to it as part of the unmounting process (update last time used, etc.).
• Mount /data in recovery, flash 5.0.8 firmware
  • No changes
• umount /data
  • No changes
• Reboot to recovery
  • No changes
• Thoughts
  
  • This test shows that unmounting /data doesn't cause any modifications to userdata. Good!

Upgrade Test 4

• Same as Test 3: Mount /data in recovery, flash firmware 9.0.5, reboot to system, don't enter password, reboot to recovery
  • First 500MiB: ~670 bytes changed
  • Middle 500MiB: ~130 bytes changed
• Thoughts
  • Yep, clearly /data being mounted during the flash is what is causing the firmware to modify userdata.

Special Test 5

• Purpose
  • Check if the firmware will modify the userdata on every boot, or only the first boot
• Restore first 500MiB and middle 500MiB to their original 5.0.8 states.
• Reboot to recovery
  • No changes
• Reboot to system, reboot to recovery
  • No changes
• Enter incorrect password, correct password into recovery
  • No changes
• Reboot to system, enter incorrect password
  • Get 'Password is correct but data is corrupt' error
• Reboot to recovery
  • No changes
• Clear CRYPTO_DATA_CORRUPT flag
• Thoughts
  • The firmware isn't modifying the userdata on every boot. Whatever is occurring is only happening on the first boot.

Special Test 6

• Purpose
  • Let's make absolutely sure unmounting /data doesn't cause any modifications to userdata. I mean, what if there are some pending changes and the kernel doesn't write them until some time after the unmounting? The modifications to userdata do occur at locations like 1024, which is where the ext4 superblock starts. Instead of a quick format these could just be normal bookkeeping writes to the superblock during the unmounting. I better check everything to be super positive that there are no pending changes waiting to be written.
• Flash 9.0.5 firmware over itself
• umount /data
• sync
• Confirm that /proc/sys/vm/dirty_bytes = 0
• Confirm that column 9 of /sys/block/sda15/stat is 0
• Confirm that column 9 of /sys/block/dm-0/stat is 0
• Confirm that Dirty and Writeback in /proc/meminfo are 0Kb
• Reboot to recovery
  • No changes
• Reboot to system, reboot to recovery
  • No changes
• Thoughts
  • Great, unmounting /data doesn't cause any writes. Super confirmed. I actually did this test twice to be certain.

Special Test 7

• Purpose
  • Wait, I unmounted /data, but the dm-crypt device (/dev/block/dm-0) still existed. What if removing that caused writes to userdata? Unlikely but let's check anyway.
• Cross-compile static dmsetup for ARM (goodbye five hours of my life), push to phone
• Reboot to recovery, mount /data
• umount /data /sdcard
  • No changes
• sync
• Wait a minute
• Make sure there are absolutely no pending writes (/proc/meminfo, etc.)
• dmsetup ls
  • userdata (253:0)
• dmsetup table
  • userdata: 0 112477112 req-crypt
• dmsetup remove userdata
• dmsetup ls
  • No devices found
• Result of removing dm-crypt device
  • First 500MiB: ~144 bytes changed (exactly the same areas as changes in previous tests)
• Thoughts
  • Crap. It wasn't the firmware doing a quick format, it was just the unmounting of /data and subsequent removal of dm-0 causing the superblock to be written to.

So there you go. After all of this testing I've eliminated a lot of possible causes and established one essential fact:

The crypto footer and userdata are not modified during the upgrade

There were multiple tests in this latest round where there were no changes to the crypto footer or userdata but the decryption failed in the same manner it always has.

This is good for me because it means the bit-for-bit copy of userdata I made after upgrading is actually correct. The correct keymaster_blob, encrypted master key, and the data should all be there. It must be the HW module not signing the IK correctly that is causing the decryption to fail. So something is happening to the HW module or KeyMaster or TrustZone that isn't reversed by simply downgrading the firmware back to 5.0.8.

What's next?

1. Test 5.0.8 -> 9.0.5 -> 5.0.8 in one TWRP session, see if decryption still works in that session, and after rebooting.
2. Install the 9.0.5 firmware, but only flash one image at a time, in order to narrow down which image causes the issue.
3. Once the offending image is identified, reverse engineer it to see what calls it's making to the HW module.

I'm going to do 1. I might do 2 and/or 3, not sure yet.

The cause might have something to do with Version Binding (https://source.android.com/security/keystore/version-binding), although the keymaster_blob should have been updated if the key was updated. And for various other reasons, despite version binding looking like a prime candidate, I'm leaning toward it not being the cause.

Edit: @nvertigo67's modified firmware is using 5.0.8 emmc_appsboot.mbn and keymaster.bin, so the 9.0.5 version of one of those is responsible, keymaster.bin being the obvious suspect as @nvertigo67 has previously pointed out in this thread.

 

[rohan164]

this post keeping me away to flash LOS on 3t. is it safe to flash?
@trachyte

 

[trachyte]

this post keeping me away to flash LOS on 3t. is it safe to flash?
@trachyte

There's no problem flashing LOS itself on the 3T. The conditions that cause data loss are: upgrading 5.0.x -> 9.0.x firmware, with an unlocked bootloader, and encrypted userdata. If you avoid that situation you should be fine (but make a backup of course). If you can't avoid that situation then you can use @nvertigo67's modded firmware.