System Verity Checks
Thanks to the investigation of @nkk71first off, sorry @jollywhitefoot that word just doesnt work well with me, i know what it means, how it's used (harmless), it just hits a nerve
My Final Conclusion
As I have suspected it's the
[ro.boot.veritymode]: [enforcing] --> good
vs
[ro.boot.veritymode]: [logging] --> BAD, and will result with the
"There was an unexpected error and the file system may be corrupted. Please contact HTC support for further assistance."
encryption has nothing to do with it by the way.
So here's a breakdown of what happens during a normal boot.
1) aboot starts, "does stuff"
2) then hands over to boot.img for further processing
3) which should eventually end up with a booting the ROM
This is what a normal (verity=enforcing) would look like:
Code:aboot part: ... [510] read_device_info_mmc:read device info from mmc [520] htc_read_device_info: verity_mode = enforcing .... kernel/boot.img part: ... ...
How to break it (DO NOT DO THIS): have your boot.img use verified boot (ie verity checking on a modified system partition, by having the "verify" flag in fstab), since system won't pass the check, this will happen:
Code:aboot is still OK: ... [500] read_device_info_mmc:read device info from mmc [510] htc_read_device_info: verity_mode = enforcing ... BUT once it hits the kernel/boot.img .... [ 2.737990] c0 466 fs_mgr: Enabling dm-verity for system (mode 1) [ 2.801811] c1 53 device-mapper: verity: verity_verify_io:io_real_digest=a48df664 io_want_digest=a43baac3 [ 2.801826] c1 53 device-mapper: verity: 259:30: data block 0 is corrupted [ 2.802645] c1 53 device-mapper: verity: verity_verify_io:io_real_digest=5c67cc54 io_want_digest=5864f2b1 [ 2.802659] c1 53 device-mapper: verity: 259:30: data block 1 is corrupted [ 2.808372] c0 6 device-mapper: verity: verity_verify_io:io_real_digest=2a70e9c0 io_want_digest=7bafd223 [ 2.808386] c0 6 device-mapper: verity: 259:30: data block 243 is corrupted [ 2.826504] c1 53 device-mapper: verity: verity_verify_io:io_real_digest=6dff1798 io_want_digest=b40f453c [ 2.826520] c1 53 device-mapper: verity: 259:30: data block 950780 is corrupted
unfortunately no matter what you restore in TWRP, any following bootup will already be set to "logging" from aboot (because one or several partitions have been "flagged",
so the kernel/boot.img verification won't matter any more
Code:... [530] read_device_info_mmc:read device info from mmc [540] htc_read_device_info: verity_mode = logging ....
this will be passed on to kernel/boot.img and then to the ROM, which the Updater will now consider a corrupt emmc
How to fix: (you tell me)
i've had limited success, in restoring back to "enforcing" instead of "logging", on occasion (no RUU yet), and nothing "conclusive"
and given the amount of [low level] partitions that are now messed up, i have no further info
so yay.... i'm about as close to bricking as possible for the moment
Data Encryption and Data Signal
Short Story:Decrypting the DATA partition will break signal
Full Story:
I was testing out data decryption one day and did some tests. Soon I found out that my phone cannot receive any signal.
At first, I thought it was caused by Xposed, so I restore system and boot, flash SuperSU to patch the boot image. The result is still the same, no signal.
Then I thought it might be SuperSU, so I manually modified the fstab of the ramdisk, the signal is still broken.
Before doubting the hardware might be broken, I restored everything back to stock (include forceencrypt boot), and it everything works!!
I've done the tests above several times, just in case I missed anything. The results are always the same: once the data is decrypted, the signal won't work.
Conclusion:
Don't try to decrypt your data until people found out the reasons.
Last edited:
