Between December last year / January this year to date, we’ve received a lot of positive feedback on our Auto TWRP porter & Auto Philz porter tools for Meditek (MTK). During the early stages of development, we did hit a brick wall with a number of devices; flashing the custom recovery caused a bootloop for some while for others the device just boot up to home screen (while attempting to boot into custom recovery) only to show stock recovery mode on the next attempt.
Summary is that the custom recoveries (though ported correctly by our tools) just wouldn’t work. After a closer look, the culprit turned out to be DM_Verity.
So what is this DM_Verity?
According to android.com;
Android 4.4 and later supports verified boot through the optional device-mapper-verity (dm-verity) kernel feature, which provides transparent integrity checking of block devices. dm-verity helps prevent persistent rootkits that can hold onto root privileges and compromise devices. This feature helps Android users be sure when booting a device it is in the same state as when it was last used.
Clever malware with root privileges can hide from detection programs and otherwise mask themselves. The rooting software can do this because it is often more privileged than the detectors, enabling the software to “lie” to the detection programs.
The dm-verity feature lets you look at a block device, the underlying storage layer of the file system, and determine if it matches its expected configuration. It does this using a cryptographic hash tree. For every block (typically 4k), there is a SHA256 hash.
Because the hash values are stored in a tree of pages, only the top-level “root” hash must be trusted to verify the rest of the tree. The ability to modify any of the blocks would be equivalent to breaking the cryptographic hash. See the following diagram for a depiction of this structure.
Simply explained, it checks to ensure that the system (and recovery) partition has not been modified.
DM_Verity & Auto TWRP porter tool
In MTK Auto TWRP porter v1.2, we included DM_Verity checker. For a recovery image with verity_key in ramdisk, the tool will give a warning like:
If you see this warning then the TWRP recovery won’t work (when flashed) unless the device’s boot has already been patched.
How do I patch boot to disable verity checks?
The easiest approach is to patch stock boot.img using Maagisk. Upon flashing back the patched_boot.img, you shouldn’t have issues with DM_Verity and will also gain root in the process.
If, on the other hand, you only need a custom recovery (without root) e.g looking to flash Gapps.zip only, then send us your stock boot.img at the Hovatek Forum and we’ll be happy to manually patch it for you.
Google introduced vbmeta which is also a verity check. To bypass this check, you flash an empty vbmeta.img before attempting to flash TWRP recovery. You can download one here
How you flash vbmeta depends on your chipset. A general technique is to use fastboot (bootloader must be unlocked) using any of the commands below which works:
fastboot flash vbmeta vbmeta.img
fastboot –disable-verity flash vbmeta vbmeta.img
fastboot –disable-verity –disable-verification flash vbmeta vbmeta.img
If you’re unable to unlock bootloader then you can use a flash tool for your chipset e.g SP flash tool for MTK, Research Download for Spreadtrum and QFIL for Qualcomm