search

ADeadTrousers / twrp_device_Unihertz_Atom_LXL

Common device tree for the Unihertz Atom L and XL
Apache License 2.0
7 stars 3 forks source link

Decryption of /data in TWRP messes up password recognition on LOS #4

Closed ADeadTrousers closed 3 years ago

ADeadTrousers commented 3 years ago

Right after providing my pattern in TWRP /data got decrypted but also LOS wasn't able to decrypt any more. My pattern always gets rejected. As far as I can tell /mnt/vendor/persists/t6 gets changed somehow. Here trustkernel seems to store a hashkey of some sort for the proper password/pattern recognition. If it's not matching then the password gets rejected. But somehow TWRP is able to use that key for decryption anyway (maybe some kind of "upgrade" path?) while LOS doesn't. At least I hope it's that trivial. If it's the other way round and it is in fact messing up the user keys in /data/system_de/user/0/spblob I'm pretty much screwed. Means I won't get decryption to work properly.

ADeadTrousers commented 3 years ago

It looks like my quick fix is holding: 27a152cad2a5013d14016d281e49e53ac0acbf33 With this on every boot into TWRP the files inside /mnt/vendor/persist/t6 get copied into /mnt/vendor/persist/t6_twrp which is used by teed to do the authorisation.