Session 26 — 2026-03-27i

Field	Value
Date	2026-03-27
Phase	03b — TWRP
Duration	~1.5 h

dm-crypt IV Root Cause

Crypto footer at offset 0x24 of the last 16 KB of userdata:

00000020  00 00 00 00 61 65 73 2d  78 74 73 00 00 00 00 00  |....aes-xts.....|

crypto_type_name = "aes-xts" — Qualcomm HW FDE. TWRP’s create_crypto_blk_dev() passes this verbatim to DmTargetCrypt. Kernel dm-crypt requires cipher-chainmode-ivmode format. "aes-xts" has no IV mode → "IV mechanism required".

Fix: Patch cryptfs.cpp to append -plain64: "aes-xts" → "aes-xts-plain64". Applied in v3.4. Hypothesis: ICE hardware XTS uses sector-number tweaks equivalent to plain64. If ICE uses a different IV scheme, decryption will produce garbage (read-only, no data corruption).

ICE Hardware Confirmed

• ICE driver: c0c8000.sdcc1ice (bound to eMMC)
• QCE: /dev/qce at 1de0000.qcedev
• Vendor libs: libcryptfshwcommon.so (exports set_ice_param, set_hw_device_encryption_key)
• Kernel has req-crypt dm target but TWRP’s CONFIG_HW_DISK_ENCRYPTION path is compiled out (requires libcryptfs_hw)

TWRP v3.4

Contains: dm-crypt plain64 fix + health HAL service in init.rc + VINTF manifest + monochrome theme + A2 waveform. Built and flashed. Not yet tested in TWRP — Android showed unexpected FDE password prompt after EDL reset; user factory-resetting to restore.

Possible cause of FDE prompt: session 24’s failed decrypt attempts incremented failed_decrypt_count in crypto footer (put_crypt_ftr_and_key called on error path). Consider guarding against footer writes on IV-related failures.