[Moto Z Guides, News, & Discussion] gm.outside:
Hi,

I was away from Android modding for quite a while (since 4.4) and it turned out that lots have changed since then. I got a new phone (Moto Z Play XT1653-02) and decided to play a bit with it. After reading the forums I found that there is not enough explanation on how the modern security model works.

I am a big fan of SELinux in the enforced mode (as long as you know how to configure and tweak the policy to your specific needs) and I don't need root on the phone itself, but I need the ability to apply changes to the /system hierarchy.

OK, I downloaded TWRP image + MultiScript-MZP-V2 zip. Looked inside the zip file (I would recommend to understand what you are going to side load before commiting to anything) and I did not like a bit the way that zip was operating on the device.

Long story short, I had 2 requirements:

1. to have root access to the device when I am at home - this can be accomplished with any TWRP (other custom recoveries) using `fastboot boot <recovery>.img`

2. to be able to change stuff on the /system filesystem (as a test I was copying /system/media/bootanimation.zip to /tmp and then back and that was rendering the phone unbootable)

I searched the web and found that the modern Android systems are kind of locked with so-called "verifiable boot". There are multiple parts of that solution, but we are interested in the removing the verification of the /system filesystem.

The check is built in to the kernel and cannot be disabled with a kernel command line parameter. However, looking into the documentation to the "verifiable boot" implementation I found that the trigger to do the verification is the "verify" flag set inside the fstab file.

Thanks to the author of the MultiScript-MZP-V2 archive I had all the tools at hand on the device to test my theory, so I `dd`'ed the boot partition into a file, unpacked the resulting boot.img file, unpacked the ramdisk, removed the "verify" flag from /fstab.qcom, repacked the ramdisk back, rebuild the boot.img file, and `dd`'ed it back to the boot partition.

Once I did that, I rebooted the phone to confirm that it is still bootable -- it was. The next step was to boot into the TWRP and replace something on the /system filesystem - I prepared a custom bootanimation.zip file for this (so I could easily see the result :) ). I booted into the TWRP, mounted /system in read/write and did `cat /tmp/my_boot_animation.zip > /system/media/bootanimation.zip` (the reason for the redirect is that I did not have SELinux tools and wanted to preserve the original SELinux context of the bootanimation.zip file).

After the reboot I saw my custom boot logo and the boot sequence, which confirmed that the theory worked as expected. So, now I have the original kernel from the manufacturer (I do not trust kernels sourced from the net and it is either the one I got from upstream or the one I built myself), have the ability to modify the /system filesystem as I see fit, and do not introduce unnecessary risk of running escalated applications on my phone.

P.S. I struggled with the bootanimation.zip a bit, but in the end I found that the keypoint is to ensure that the zip file is a container for files (i.e. zip with no compression at all - `zip -0 bootanimation.zip file1 file2 ...`)