I have a Sunshine T2 Elite tablet from Tru Connect purchased new. I try charging and turning it on, and I get dm-verity corruption. I'd tried holding the power button and the volume up button to get fast boot / normal something / and the third something, but they don't do anything, and the device is stuck on "fast boot". Is this device broken? Can it be fixed?

During the boot of an unlocked device, it displays "OS Fingerprint:" with some random string. What does this string represent? Additionally, is there a way to safely change it? I know if you disable verity, 'N/A' will be displayed.

My Infinix Hot 12i on Android 11 is having this dm-verity corruption. The phone turned itself off and it can't boot. I tried to flash, but it's saying no command. Nothing is working. The phone can't come on. What do I do? And it's operating

So what I want to do is boot into my own custom ROM with a locked bootloader. I have a OnePlus 6T so it's possible, but can I have root access after I boot with a locked bootloader? If I replace my custom ROM's boot.img with a patched Magisk boot image, will it be possible to have root access after locking my BL? Also, will I be able to use TWRP and flash updates through it?

As documented here , many bootloaders will allow flashing a custom verity key to the avb_custom_key partition using fastboot. This then allows a custom chain of trust so the device will boot a custom ROM. I have a phone which has a locked bootloader so I cannot flash the avb_custom_key using fastboot. But, I do have Qualcomm EDL mode access with a firehose loader. Does anyone know if there is any way to use EDL to flash avb_custom_key? It does not show as a partition in the GPT. Google calls it a virtual partition. I don't know what that means.

I got a Chinese phone with an MTK6761 SoC, running Android 13 (has the virtual A/B partition and DM-verity/AVB enabled). I managed to unlock the bootloader and root it through Magisk and MTKClient tool running on Manjaro Linux. So far the only "issue" with that is that as I have seccfg modified, I have the annoying message at boot stating that the partitions are corrupted (because of dm-verity). In that regard, I tried disabling dm-verity through the usual methods with no luck. The problem that I am facing is as follows: I am attempting to modify the bootanimation file, which is inside the "product" virtual partition. I found that it is inside super.bin, so I unpacked it using the lpunpack commandline application with the command:

lpunpack super.bin ./Images`

Then, I found there was an image, product_a.img which has the bootanimation.zip, so I increased the allocated size by 10 MB with the following commands:

e2fsck -f product_a.img

fallocate -l 2275078144 product_a.img

resize2fs product_a.img 555439

Then, I mounted it to a folder named "product" with the following command:

sudo mount -t ext4 -o loop,rw product_a.img product

To access and modify its content I used Thunar Root and replaced the bootanimation file with my custom file. Then I unmounted the file using sudo umount product and repacked everything with the following command:

lpmake 
	--super-name super 
	--metadata-size 65536 
	--metadata-slots 2 
	--device super:5368709120 
	--group main:4504506368 
	-p "product_a:none:2275078144:main" -i "product_a=./product_a.img" 
	-p "product_b:none:0:main" -i "product_b=./product_b.img" 
	-p "system_a:none:1678229504:main" -i "system_a=./system_a.img" 
	-p "system_b:none:139591680:main" -i "system_b=./system_b.img" 
	-p "vendor_b:none:0:main" -i "vendor_b=./vendor_b.img" 
	-p "vendor_a:none:411607040:main" -i "vendor_a=./vendor_a.img" 
	-virtual-ab 
	--output ./super.img

I must say that I had to place vendor_b before vendor_a because it being a 0 byte partition made **lpmake** complain if it was the last partition. To get the actual size of each partition I used the result of "stat" command for each, and I used a metadata-size of 65536 as it was "recommended" online. Lastly, I flashed it to the phone through MTKClient:

python mtk w super super.img

The partition was written successfully and the device started correctly but I could not see any changes. So I dumped once again the super image from the phone, and I verified the changes were actually applied to the ROM, and that is when I got really confused. I also tried removing files and adding files to the partition, only to find that the device do not see the changes but they seem to be there when I dump it back tu my PC. I would really appreciate if someone could help me figure out what I am doing wrong.

SO, I have an MT6739 dveice with Android 8.1, it's not A/B seamless, and it is not TREBLE. I have used a tried and tested method to remove DM-Verity. On this device it was in the DTB, in the boot and also in the vendor partitions. I use Magisk to get me root and I have removed and installed lots of /system/apps, changed the audio, bootanimations etc on the device. I even changed the backgrounds and tweaked the Launcher. However whenever I come to change anything in /system/build.prop the device bootloops! I have tried this with Magisk DM-verity ON/OFF with no effect. I also copied back a build.prop from my PC and it worked fine again. So, something must be looking up the build.prop and checking for changes. All I have done is change the ro.product.model property to be super sure nothing in the build.prop is incorrect. I have tried with setting permissions (644, for some reason they are 600 (RW - - ) on the device so tried that too). There is a build.prop in the /vendor partition. i have heard of this checking the fingerprint of the system/build.prop, but they are different anyway on the stock ROM. I also tried just copying the build.prop from /system into here so they were identical. Fresh out of ideas!! Does anyone know what is going on here. I can literally change anything I want on the device as normal/pre-verity days except for the build.prop settings.

I tried to create a service for slot switching in Android 11. I have used the API from Bootctrl HAL to check the other slot availability and valid image in it. I have updated both the slots a and b with same image, then the service was successfully switched between different slots. With different images in slot a and slot b it is failing. After the slot switching, getting dm verity corruption and log is as below [ 4.383505] device-mapper: verity: sha1 using implementation "sha1-ce" [ 4.394599] device-mapper: verity-fec: 252:0: FEC: recursion too deep [ 4.401091] device-mapper: verity: 252:0: metadata block 542471 is corrupted [ 4.408301] kvm: exiting hardware virtualization Device is continuously rebooting after slot update. Could anyone please help me to resolve this?

my doogee s96, with the TWRP no more able to boot, probably due to the dm-verity check. I tried several things, install Magisk or patching boot.img, but I always failed. The phone starts and suddendly swicth to TWRP without launching Android. With the suggestion of @alecxs I pulled the super partition through adb and umpacked with lpunpack. The idea is to manually disable the avb/dm-verity control. Now I have product.img + system.img + vendor.img. I can open them with 7z and, for instance, i found many lines on /vendor.img/etc/fstab.mt6785 using avb: system /system ext4 ro wait,,avb=vbmeta_system,logical,first_stage_mount,avb_keys=/avb/q-gsi.avbpubkey:/avb/r-gsi.avbpubkey:/avb/s-gsi.avbpubkey vendor /vendor ext4 ro wait,,avb,logical,first_stage_mount product /product ext4 ro wait,,avb,logical,first_stage_mount or the system.img/init.rc with the line exec -- /system/bin/fsverity_init and system.img/system/bin/fsverity_init: # Enforce fsverity signature checking echo 1 > /proc/sys/fs/verity/require_signatures # Load all keys for cert in /product/etc/security/fsverity/*.der; do /system/bin/mini-keyctl padd asymmetric fsv_product .fs-verity < "$cert" || log -p e -t fsverity_init "Failed to load $cert" done # Prevent future key links to .fs-verity keyring /system/bin/mini-keyctl restrict_keyring .fs-verity || log -p e -t fsverity_init "Failed to restrict .fs-verity keyring" The question is: **Is it possible to manually edit the imgs, repack the super and adb push it to make my phone start again?** What should I do? Thank you in advance! State of the art: ----------------- from adb i pulled the superpartition from the device adb pull /dev/block/platform/bootdevice/by-name/super super.img i extracted it with lpunpack in two folders: ./otatools/bin/lpunpack --slot=0 ./super.img ./superA/ mounted and enlarged the partition + edited the fstab.mt6785 sudo mount -t ext4 -o loop,rw,noexec,noatime vendor.img /mnt/vendor sudo dd if=./vendor.img bs=1MiB of=./vendor.img conv=notrunc oflag=append count=5 #to add 5MB sudo losetup | grep vendor #get the right loop device, in my case loop25 sudo losetup -c /dev/loop25 sudo resize2fs /dev/loop25 sudo vim /mnt/vendor/etc/fstab.mt6785 #removed the avb options in vendor, system and product sudo umount /mnt/vendor Following this guide , I built a new super.new.img: $e2fsck -yf vendor.img $resize2fs -M vendor.img $e2fsck -yf vendor.img $stat -c '%n %s' * super.img 3758096384 product.img 1596944384 system.img 1128718336 vendor.img 544976896 $../otatools/bin/lpmake --metadata-size 65536 --super-name super --metadata-slots 1 --device super:3758096384 --group main:3270639616 --partition system:readonly:1128718336:main --image system=./system.img --partition vendor:readonly:544976896:main --image vendor=./vendor.img --partition product:readonly:1596944384:main --image product=./product.img --sparse --output ./super.new.img lpmake I 02-17 12:18:27 2646704 2646704 builder.cpp:1012] [liblp]Partition system will resize from 0 bytes to 1128718336 bytes lpmake I 02-17 12:18:27 2646704 2646704 builder.cpp:1012] [liblp]Partition vendor will resize from 0 bytes to 544976896 bytes lpmake I 02-17 12:18:27 2646704 2646704 builder.cpp:1012] [liblp]Partition product will resize from 0 bytes to 1596944384 bytes Invalid sparse file format at header magic Invalid sparse file format at header magic Invalid sparse file format at header magic even though the size of super.new.img is not the same of super.img (is it normal??) $stat -c '%n %s' super.new.img super.new.img **3248851200** when I flash it with adb the phone goes straight to the recovery without booting android. Please note that 3248851200 is not divisible by 512, which is a requirement of lpmake.... Any suggestion?

I have built LineageOS 17.1 for Motorola X4 / payton with unlocked bootloader with reverted commit 81cc203c06596878d2beb62ab6e07f36e278018e . The common question is how to disable dm-verity, but I want to know how to properly enable it for /system . The vendor partition is called oem on Motorola. AVB was deactivated (the device is missing *fastboot flash avb_custom_key* but has a vbmeta_a/b partition?) During build these options were set: PRODUCT_SUPPORTS_BOOT_SIGNER := true PRODUCT_SUPPORTS_VERITY := true PRODUCT_SUPPORTS_VERITY_FEC := true I checked *system.img* and *vendor.img* with verity_verifier script and the *verity_key* and it outputs VERIFIED. I flashed boot, vendor and system to the corresponding partitions. */verity_key* is inside the *boot.img*. The boot cmdline contains *androidboot.veritymode=eio* and *veritykeyid=id:47b1fe9xxxxxx*. *The boot.img* only contains recovery.fstab, verify option is set there, too. adb enable-verity is succesful for / and for /vendor. */vendor/etc/fstab.qcom* contains the verify option for system and vendor partition. The following obversations were made: - During boot I see a message "Verity mode is set to disable". What is this referring to? - Modifiying data (*touch test*) on the vendor/oem partition from Lineage Recovery results in the errors being corrected by FEC, messages shown from dmesg after next boot: > [ 3.023786] init: [libfs_mgr]Enabling dm-verity for vendor (mode 0) > [ 3.175842] device-mapper: verity-fec: 259:31: FEC 0: corrected 21 errors > [ 3.257369] device-mapper: verity-fec: 259:31: FEC 4096: corrected 17 errors > [...] The created file *test* vanishes after boot. - Modifying data on the system partition from Lineage Recovery is not corrected by FEC and no messages show up. The created file *test* is visible on the partition after next boot. - There is no difference between locked and unlocked bootloader (*fastboot flash lock*). What am I missing here?

I have One Plus 6T Android device which has a ROM of build type user. This device is rooted with Magisk and I want to disable dm-verity on this device. I have tried to run adb disable-verity but I got an error saying verity cannot be disabled/enabled - USER build Is there any way to disable this? Goal: Want to place customized sepolicy file under system_root directory. I have tried to do it with following commands:

C:\Users\GPU-Test>adb shell
OnePlus6T:/ $ su
OnePlus6T:/ # mount -o rw,remount /system_root
OnePlus6T:/ # cp /sdcard/selinux_policy_modified /system_root/sepolicy
cp: /system_root/sepolicy: Permission denied
1|OnePlus6T:/ # cp -f /sdcard/selinux_policy_modified /system_root/sepolicy
cp: /system_root/sepolicy: No such file or directory
1|OnePlus6T:/ # ^C
130|OnePlus6T:/ # exit
130|OnePlus6T:/ $ exit

C:\Users\GPU-Test>adb disable-verity
verity cannot be disabled/enabled - USER build

Also tried to disable Preserve force encryption and Preserve AVB 2.0/dm-verity checkbox but still the above commands have same result. Also on reboot these check-boxes enables again automatically.

my phone has dm verity enabled by default. I read about ways to disable it. After that, is there any way with which can i verify if dm-verity is disabled?

I am working with Android 8, Android verified boot with dm-verity, and block-based differential seamless A/B updates. To my understanding, the Android update_engine performs some validations of the received update image before it proceeds to write the target partitions. AFAIK, update_engine checks if the differential update can be installed atop the current partitions. How is this check performed? I can imagine two possibilities, but I haven't found authoritative documentation of either hypothesis: 1. The differential update package contains a linear hash of the source partition. On the device, update_enigne computes a SHA-256 hash of the entire partition on top of which the differential update is to be applied. It compares this value with the one provided as part of the update package and proceeds only if the two values agree. 2. The differential update package contains the dm-verity root hash of the Merkle-Tree used for block-wise validation with dm-verity. The update_engine compares this target root-hash with the one provided on the device in the vbmeta structure. Only if the two match, it proceeds to install the update. Is either one of these hypotheses correct, or am I missing something? Similarly, how does the update_engine validate the target partitions once they have been written? Via a linear hash, or using the root hash? Or otherwise?

I am learning about android dm-verity protection and I try to understand how does the android dm-verity uses the hash tree for validation of "single block". https://source.android.com/security/verifiedboot/dm-verity says: >Instead, dm-verity verifies blocks individually and only when each one is accessed. When read into memory, the block is hashed in parallel. The hash is then verified up the tree. And since reading the block is such an expensive operation, the latency introduced by this block-level verification is comparatively nominal. After the block is read and hashed, it is verified up the tree. But how can I verify root hash, when I have not read all the blocks?? I can verify just that part of the tree I have read, and that means I do not have to go up to root hash. I do not understand why we use a hash tree. [StackOverflow thread](https://stackoverflow.com/questions/13337364/how-are-hash-trees-useful) says that main reason for using hash trees is when the hash is computed for every block and than for the whole file again, i don't get why it is used here. So how it is actually implemented?? My assumption is that when the block is loaded to memory android just checks the particular branch and rest of values are taken from the pre-computed hash tree. But than I don't see the reason for using the tree. I would just store block hash values and after reading the block and hashing compare just the hash. Edit: Let's assume this implementation: 1. split the whole block device to the blocks of 4K size. 2. hash each particular block and concatenate hashes(create layer 0 of dm-verity) 3. store the hashes (layer 0) at the end of block device Now, when I want to verify 4K block loaded to the memory, I find the block position and compare the hash of loaded block with the stored hash. In the situation as [this](https://bitcoin.stackexchange.com/questions/50674/why-is-the-full-merkle-path-needed-to-verify-a-transaction) using a tree makes sense, because you only have Merkle root available, but in Android, we have the whole tree, so why just not use the layer 0 (implementation above) and throw away the rest. And while writing, I think I came up with an answer. Android stores the whole hash tree at the end. But the tree is not signed, only the dm-verity table(metadata) that contains the root hash. So, In my implementation, I would have to sign the whole layer 0. And that is probably wasting resources, so it's better to use the tree.

I'm just starting to explore how to customize my Samsung S7 Edge and I'm interested in moving an application over to the system partition. It's currently running Android 8.0. I've been doing a lot of research on the process before I just dive in and I feel like I have a good understanding of the process using ODIN, installing TWRP for my particular device, and using TWRP to move the installed app into the system partition. However, what I'm struggling to find detailed information on is dm-verity and if/how it would impact what I want to do. I know my device utilizes it, but the sources I'm reading boil things down to "download and install this file using ODIN" and provide a handy link to the file *without talking about the file at all* or otherwise explaining what is being changed. I struggle to find those sources trustworthy since the file details are completely unknown. I'm assuming I'll need to circumvent dm-verity in order to utilize TWRP. Is this assumption correct and, if yes, what are the detailed steps to do so?

I want to flash the Magisk ZIP while keeping dm-verity and AVB 2.0. The Magisk ZIP detects my encrypted /data partition and keeps force encryption, but always disables dm-verity and AVB 2.0 when flashed with TWRP. This leads to the inconvenience that I have to restore the "stock boot image" (with TWRP) and flash it again in Magisk Manager. It's better if dm-verity and AVB is preserved at the first flash in TWRP.