You may call it as a tweak, a hack, or a mod but the underlying concept of using one of these files is to avoid bootloop after flashing a custom recovery and gaining root with Magisk. Enter dm-verity disabler tool! Many Mi Fans also call it the “Lazy Flasher“. This file is basically a universal mod to hack boot image with dm-verity enabled. You may end up in a bootloop state or with a broken device if you flashed TWRP and granted it to allow system modification.
In a normal situation, you will have to install a kernel that has dm-verity disabled in the fstab and hence you can bypass the dm-verity’s boot prevention. Instead of installing a custom kernel through baking a custom boot image, this LazyFlasher or Universal DM-Verity Disabler will save your time much by dynamically modify ramdisks and inject kernel binaries into the current boot image. It takes away the pain of building a custom boot image. Many thanks for its developers for that.
The explanation above may sound geeky. Novice users can simply understand following logic: flashing TWRP and swiping to allow system modification on many recent MIUI devices will trigger a security mechanism that prevents the device to boot properly. Therefore, some good developers have managed to create a hack to fix the situation. This helps many novice users from “cooking” a custom boot image.
There are two popular hacks with similar abilities out there: LazyFlasher and Universal DM-Verity Disabler.
LazyFlasher
Developed by jcadduono, a member of XDA forum, Lazy Flasher has gained its name in many Mi Fans around the globe. It easy-to-remember name helps it gain its popularity. This hack supports many devices powered with arm (armv7), arm64 (aarch64), x86 (i386), x86_64 (amd64), mips, and mips64 CPU architectures including those produced by Qualcomm and MediaTek.
The only downside is its incompatibility with TWRP built based on Android 4.3 or earlier. Check all of its features out below:
- ChromeOS support (ChromeOS test-key signing and recognition)
- MediaTek device support (MTK headers)
- SELinux policy injection support via sepolicy-inject
- Includes an optional bbe tool for applying binary patches
- Supports dtb.img replacement (place it in the root folder named “dtb.img”)
- Scans fstab and partition locations for the boot partition optionally allows a preset location
- Supports Gzip, LZ4, Bzip2, and LZO ramdisks. Support for LZMA and XZ is a work in progress
- Supports arm (armv7), arm64 (aarch64), x86 (i386), x86_64 (amd64), mips, and mips64 architectures
- Intelligently installs kernel modules by copying the previous layout of /system/lib/modules and creating symlinks
- A process that executes a sorted list of scripts for making the desired modifications (separate from the framework)
- Example scripts to disable dm-verity or forced encryption during the install process (010-no-force-encrypt, 015-no-dm-verity)
- Handily unpacks, decompresses, applies changes, compresses, and repacks boot images quickly and safely
- Creates modprobe supported /lib/modules aliases if kernel modules are included in the installer (030-kernel-modules)
- Installs new files to the ramdisk and sets their permissions automatically based on file type from ramdisk-patch (020-patch-ramdisk)
- Unnecessary architectures and tools can be removed to save space
- Many useful functions and variables included in the patch.d environment to simplify modification/patching scripts (patch.d-env)
Download LazyFlasher
No Verity Opt Encrypt: The minimal version of the LazyFlasher framework.
Disables Verity, Forceencrypt, and/or Disc Quota
Heavily based on previous work by topjohnwu and jcadduono
AnyKernel3 — Flashable Zip Template for Kernel Releases with Ramdisk Modifications
by osm0sis @ xda-developers
"AnyKernel is a template for an update.zip that can apply any kernel to any ROM, regardless of ramdisk." — Koush
AnyKernel3 pushes the format even further by allowing kernel developers to modify the underlying ramdisk for kernel feature support easily using a number of included command methods along with properties and variables.
A working script based on Galaxy Nexus (tuna) is included for reference.
do.devicecheck=1 specified requires at least device.name1 to be present. This should match ro.product.device or ro.build.product for your device. There is support for as many device.name# properties as needed. You may remove any empty ones that aren’t being used.
do.modules=1 will push the contents of the module directory to the same location relative to root (/) and apply 644 permissions.
do.cleanup=0 will keep the zip from removing it’s working directory in /tmp/anykernel (by default) — this can be useful if trying to debug in adb shell whether the patches worked correctly.
do.cleanuponabort=0 will keep the zip from removing it’s working directory in /tmp/anykernel (by default) in case of installation abort.
supported.versions= will match against ro.build.version.release from the current ROM’s build.prop. It can be set to a list or range. As a list of one or more entries, e.g. 7.1.2 or 8.1.0, 9 it will look for exact matches, as a range, e.g. 7.1.2 — 9 it will check to make sure the current version falls within those limits. Whitespace optional, and supplied version values should be in the same number format they are in the build.prop value for that Android version.
block=auto instead of a direct block filepath enables detection of the device boot partition for use with broad, device non-specific zips. Also accepts specifically boot or recovery .
is_slot_device=1 enables detection of the suffix for the active boot partition on slot-based devices and will add this to the end of the supplied block= path. Also accepts auto for use with broad, device non-specific zips.
ramdisk_compression=auto allows automatically repacking the ramdisk with the format detected during unpack. Changing auto to gz , lzo , lzma , xz , bz2 , lz4 , or lz4-l (for lz4 legacy) instead forces the repack as that format, and using cpio or none will (attempt to) force the repack as uncompressed.
slot_select=active|inactive may be added to allow specifying the target slot. If omitted the default remains active .
"if search string" is the string it looks for to decide whether it needs to add the tweak or not, so generally something to indicate the tweak already exists. "cmdline entry name" behaves somewhat like this as a match check for the name of the cmdline entry to be changed/added by the patch_cmdline function, followed by the full entry to replace it. "prop name" also serves as a match check in patch_prop for a property in the given prop file, but is only the prop name as the prop value is specified separately.
Similarly, "line match string" and "line replace string" are the search strings that locate where the modification needs to be made for those commands, "begin search string" and "end search string" are both required to select the first and last lines of the script block to be replaced for replace_section, and "mount match name" and "fs match type" are both required to narrow the patch_fstab command down to the correct entry.
"scope" may be specified as "global" to force all instances of the string targeted by replace_string to be replaced. Omitted or set to anything else and it will perform the default first-match replacement.
"before|after" requires you simply specify "before" or "after" for the placement of the inserted line, in relation to "line match string".
"block|mount|fstype|options|flags" requires you specify which part (listed in order) of the fstab entry you want to check and alter.
dump_boot and write_boot are the default method of unpacking/repacking, but for more granular control, or omitting ramdisk changes entirely ("OG AK" mode), these can be separated into split_boot; unpack_ramdisk and repack_ramdisk; flash_boot respectively. flash_dtbo can be used to flash a dtbo image. It is automatically included in write_boot but can be called separately if using "OG AK" mode or creating a dtbo only zip.
Multi-partition zips can be created by removing the ramdisk and patch folders from the zip and including instead "-files" folders named for the partition (without slot suffix), e.g. boot-files + recovery-files, or kernel-files + ramdisk-files (on some Treble devices). These then contain zImage, and ramdisk, patch, etc. subfolders for each partition. To setup for the next partition, simply set block= (without slot suffix) and ramdisk_compression= for the new target partition and use the reset_ak command.
Similarly, multi-slot zips can be created with the normal zip layout for the active (current) slot, then resetting for the inactive slot by setting block= (without slot suffix) again, slot_select=inactive and ramdisk_compression= for the target slot and using the reset_ak keep command, which will retain the patch and any added ramdisk files for the next slot.
backup_file may be used for testing to ensure ramdisk changes are made correctly, transparency for the end-user, or in a ramdisk-only "mod" zip. In the latter case restore_file could also be used to create a "restore" zip to undo the changes, but should be used with caution since the underlying patched files could be changed with ROM/kernel updates.
You may also use ui_print "
" to write messages back to the recovery during the modification process, abort "
" to abort with optional message, and file_getprop " " "
" and contains " " " " to simplify string testing logic you might want in your script.
The AK3 repo includes current ARM builds of magiskboot , magiskpolicy and busybox by default to keep the basic package small. Builds for other architectures and optional binaries (see below) are available from the latest Magisk zip, or my latest AIK-mobile and FlashIt packages, respectively, here:
Optional supported binaries which may be placed in /tools to enable built-in expanded functionality are as follows:
- mkbootfs — for broken recoveries, or, booted flash support for a script/app via bind mount to /tmp (deprecated/use with caution)
- flash_erase , nanddump , nandwrite — MTD block device support for devices where the dd command is not sufficient
- dumpimage , mkimage — DENX U-Boot uImage format support
- mboot — Intel OSIP Android image format support
- unpackelf , mkbootimg — Sony ELF kernel.elf format support, repacking as AOSP standard boot.img for unlocked bootloaders
- elftool (with unpackelf ) — Sony ELF kernel.elf format support, repacking as ELF for older Sony devices
- mkmtkhdr (with unpackelf ) — MTK device boot image section headers support for Sony devices
- futility + chromeos test keys directory — Google ChromeOS signature support
- BootSignature_Android.jar + avb keys directory — Google Android Verified Boot (AVB) signature support
- rkcrc — Rockchip KRNL ramdisk image support
Place Image.gz-dtb in the root (separate dt, dtb or recovery_dtbo, and/or dtbo should also go here for devices that require custom ones, each will fallback to the original if not included)
Place any required ramdisk files in /ramdisk and modules in /modules (with the full path like /modules/system/lib/modules)
Place any required patch files (generally partial files which go with commands) in /patch
Modify the anykernel.sh to add your kernel’s name, boot partition location, permissions for added ramdisk files, and use methods for any required ramdisk modifications (optionally, also place banner and/or version files in the root to have these displayed during flash)
zip -r9 UPDATE-AnyKernel3.zip * -x .git README.md *placeholder
If supporting a recovery that forces zip signature verification (like Cyanogen Recovery) then you will need to also sign your zip using the method I describe here:
Not required, but any tweaks you can’t hardcode into the source (best practice) should be added with an additional init.tweaks.rc or bootscript.sh to minimize the necessary ramdisk changes.
It is also extremely important to note that for the broadest AK3 compatibility it is always better to modify a ramdisk file rather than replace it.
If running into trouble when flashing an AK3 zip, the suffix -debugging may be added to the zip’s filename to enable creation of a debug .tgz of /tmp for later examination while booted or on desktop.
Android Treble enabled devices will have force encryption enabled and also DM Verity check enabled.
DM verity does not allow an Android system to boot if the system integrity has changed or in simple words, if some of the system partitions are changed such as: boot, recovery, system partition etc.
In order to flash a TWRP recovery by replacing the stock recovery you need to disable DM verity and disable force encryption.
This zip file is TWRP flashable which disables the Force Encryption on Android phone with Treble enabled.
Click on the Download button below to start the download.