Related
Oneplus has released the Stable and Beta OREO Oxygen OS for Oneplus 3T and 3.
This thread is only for OOS Oreo. For disabling Dm-Verity and force Encryption in PIE OOS ROMs refer to my thread here: https://forum.xda-developers.com/oneplus-3t/how-to/dm-verity-disable-oxygen-os-t3922324. For disabling Dm-Verity and force Encryption in NOUGAT OOS ROMs refer to my thread here: https://forum.xda-developers.com/oneplus-3t/how-to/rom-dm-verity-force-encryption-disabled-t3618232[/I]
Disclaimer: I am not responsible for any damage or data loss that happens to your device on embarking this procedure...
THE DETAILS....
There has been some modifications that i came across after unpacking and verifying the packages..
After extracting the ramdisk to my surprise there was no fstab file and hence no fstab entries that could be modified to disable Dm-Verity and Force encryption...
After tweaking a little i found that indeed the file fstab does exist but its not in the ramdisk but in an other location..
So i disabled the Dm-Verity and Force encryption entries in the fstab file in the new location and made a flashable zip file which will replace the original fstab file.
As @rk2612 pointed out the fact that indeed the system entries are hashed out in the fstab file and the kernel takes care of the system loading procedure in OREO, I have been working on it. Indeed it is true. After unpacking the boot image into kernel, ramdisk and device tree blobs (dtbs), I came accross 12 entries in the dtb that reference directly to mount the system after triggering the DM-Verity flag. So I patched the dtb binary to clear off the DM-Verity flags and repacked the Boot images. Moreover, in OREO as long as DM-Verity is triggered, any changes made to the system are reverted back once you boot to system which has been clearly stated with the help of posts from @BillGoss.
The other fact is that regarding force encryption, it indeed is taken care of only in the fstab.
So in a nut shell, to disable DM-Verity you will need to flash the patched Boot Images and to disable force encryption you will have to flash the force encryption disabler zip - The links of which are provided below. Do refer to the correct procedure explained in datail before attempting to do anything...
For all those who need an in-depth reading of the nature of patching the fstab in dtb file and my work you can refer here:
https://forum.xda-developers.com/showpost.php?p=74326761&postcount=3
THIS METHOD WILL WORK FOR BOTH ONEPLUS 3 T AND ONEPLUS 3...
TESTED AND WORKING TILL ONEPLUS 3/3T STABLE OOS 5.0.8 / ONEPLUS 3T BETA 30 / ONEPLUS 3 BETA 39..
FOR THOSE WHO HAVE ALREADY TRIGGERED DM-VERITY ON OOS OREO FOLLOW THE STEPS IN POST 2 IN THIS THREAD TO GET RID OF DM-VERITY BEFORE PROCEEDING...
Nothing has been changed....
It is 100% stock boot image except that the DM-Verity Flag has been patched...
Links:
For ONEPLUS 3T
STABLE OOS Boot Images
Patched Boot Image Stable OOS 5.0.8
http://www.mediafire.com/file/xcsiuizziw6xckq/boot-patched-5.0.8-OP3T.img/file
Patched Boot Image Stable OOS 5.0.7
http://www.mediafire.com/file/ckn0012znn8kw8c/boot-patched-5.0.7-OP3T.img/file
Patched Boot Image Stable OOS 5.0.6
http://www.mediafire.com/file/ma4plv5vtom4ih1/boot-patched-5.0.6-OP3T.img/file
Patched Boot Image Stable OOS 5.0.5
http://www.mediafire.com/file/adxxd99bgswez8d/boot-patched-5.0.5-OP3T.img/file
Patched Boot Image Stable OOS 5.0.4
http://www.mediafire.com/file/c8ftkmwqebmrer3/boot-patched-5.0.4-OP3T.img
Patched Boot Image Stable OOS 5.0.3
http://www.mediafire.com/file/z1kut18fycm2k57/boot-patched-5.0.3-OP3T.img/file
Patched Boot Image Stable OOS 5.0.2
http://www.mediafire.com/file/hu6n544a8yhpmma/boot-patched-5.0.2-OP3T.img
Patched Boot Image Stable OOS 5.0.1
http://www.mediafire.com/file/cjxs6plcngqc5g6/boot-patched-5.0.1-OP3T.img
Patched Boot Image Stable OOS 5.0
http://www.mediafire.com/file/dxxgn7i49sxbca1/boot-patched-5.0-OP3T.img
BETA OOS Boot Images
Patched Boot Image OOS Beta 30
http://www.mediafire.com/file/b3fu93f15zd576c/boot-patched-Beta30-OP3T.img/file
Patched Boot Image OOS Beta 29
http://www.mediafire.com/file/w80wj3lql256td3/boot-patched-Beta29-OP3T.img/file
Patched Boot Image OOS Beta 28
http://www.mediafire.com/file/k3fj0u71t85jo8q/boot-patched-Beta28-OP3T.img/file
Patched Boot Image OOS Beta 27
http://www.mediafire.com/file/d1m6awl8oda5087/boot-patched-Beta27-OP3T.img
Patched Boot Image OOS Beta 26
http://www.mediafire.com/file/6c832j5y5hwk68t/boot-patched-Beta26-OP3T.img
Patched Boot Image OOS Beta 25
http://www.mediafire.com/file/6h1h1cammycdu9f/boot-patched-Beta25-OP3T.img
Patched Boot Image OOS Beta 24
http://www.mediafire.com/file/s8q750qedda5c2n/boot-patched-Beta24-OP3T.img
Patched Boot Image OOS Beta 23
http://www.mediafire.com/file/a9r6o20qc865bij/boot-patched-Beta23-OP3T.img
Patched Boot Image OOS Beta 22
http://www.mediafire.com/file/kk5llc6s43kr2bb/boot-patched-Beta22-OP3T.img
Patched Boot Image OOS Beta 21
http://www.mediafire.com/file/di3nm7ci7fn1u6i/boot-patched-Beta21-OP3T.img
Patched Boot Image OOS Beta 20
http://www.mediafire.com/file/woow4q1enart2tf/boot-patched-Beta20-OP3T.img
Patched Boot Image OOS Beta 19
http://www.mediafire.com/file/vqud6vy7k61stzt/boot-patched-Beta19-OP3T.img
For OnePlus 3
STABLE OOS Boot Images
Patched Boot Image Stable OOS 5.0.8
http://www.mediafire.com/file/6i5yblsbx7rdiba/boot-patched-5.0.8-OP3.img/file
Patched Boot Image Stable OOS 5.0.7
http://www.mediafire.com/file/1xo7e9qr521s9z9/boot-patched-5.0.7-OP3.img/file
Patched Boot Image Stable OOS 5.0.6
http://www.mediafire.com/file/98nyyirwfy2mo9e/boot-patched-5.0.6-OP3.img/file
Patched Boot Image Stable OOS 5.0.5
http://www.mediafire.com/file/12bhw4bo48lrp8o/boot-patched-5.0.5-OP3.img/file
Patched Boot Image Stable OOS 5.0.4
http://www.mediafire.com/file/io7hqnwoiy0i9v5/boot-patched-5.0.4-OP3.img/file
Patched Boot Image Stable OOS 5.0.3
http://www.mediafire.com/file/vdeq5iox0700rou/boot-patched-5.0.3-OP3.img/file
Patched Boot Image Stable OOS 5.0.1
http://www.mediafire.com/file/e1ae6d7ae45571r/boot-patched-5.0.1-OP3.img
Patched Boot Image Stable OOS 5.0
http://www.mediafire.com/file/a69c69gw6gkj860/boot-patched-5.0-OP3.img
BETA OOS Boot Images
Patched Boot Image OOS Beta 39
http://www.mediafire.com/file/3rc3t0zc543oqf7/boot-patched-Beta39-OP3.img/file
Patched Boot Image OOS Beta 38
http://www.mediafire.com/file/6ef5szt65605woh/boot-patched-Beta38-OP3.img/file
Patched Boot Image OOS Beta 37
http://www.mediafire.com/file/856w586ctt39rg8/boot-patched-Beta37-OP3.img/file
Patched Boot Image OOS Beta 36
http://www.mediafire.com/file/2l6mj266z15vbbq/boot-patched-Beta36-OP3.img
Patched Boot Image OOS Beta 35
http://www.mediafire.com/file/cguelk95o3klcki/boot-patched-Beta35-OP3.img
Patched Boot Image OOS Beta 34
http://www.mediafire.com/file/r1sd37135f3d90u/boot-patched-Beta34-OP3.img
Patched Boot Image OOS Beta 33
http://www.mediafire.com/file/vmey23ggvafw2ps/boot-patched-Beta33-OP3.img
Patched Boot Image OOS Beta 32
http://www.mediafire.com/file/7m6gxldmenen2qs/boot-patched-Beta32-OP3.img
Patched Boot Image OOS Beta 31
http://www.mediafire.com/file/2150f2hnaclc1zk/boot-patched-Beta31-OP3.img
Patched Boot Image OOS Beta 30
http://www.mediafire.com/file/5x1bcyxzihscdj3/boot-patched-Beta30-OP3.img
Patched Boot Image OOS Beta 29
http://www.mediafire.com/file/v1cm7ddtmr6tnam/boot-patched-Beta29-OP3.img
Patched Boot Image OOS Beta 28
http://www.mediafire.com/file/1afm13h8ax9d3r0/boot-patched-Beta28-OP3.img
STEPS: This is applicable only to people who have their data currently ENCRYPTED and needs the procedure only for NOT TRIGGERING DM-VERITY
USAGE FOR STOCK OOS:
1. Flash the downloaded boot-patched.img file corresponding to the Model and OOS version in TWRP immediately after flashing the Stock ROM zip in TWRP before doing anything (even before restarting or applying any patches, root, kernels, etc.)
2. Restart back to TWRP Recovery.
3. Done.
4. Now do whatever you want like usual.. Flash root, kernel, mods or anything as usual
5. You dont have to worry about triggering DM-Verity again and any changes made to system via TWRP will not be reverted back..
The 2 Prodeures given below: This is applicable only to those people who needs the procedure for getting rid of FORCE ENCRYPTION AND PREVENT TRIGGERING DM-VERITY
PROCEDURE 1: This is applicable only to people who have their data currently NOT ENCRYPTED AND KEEP IT DECRYPTED
First of all Backup your data preferably to and usb otg or a PC for later restore. You may lose your data from your phone following this procedure...
1. Format SYSTEM, DALVIK, CACHE and then only Flash the Full Rom Oreo Beta OOS zip file in TWRP.
2. DON'T REBOOT
3. Flash the downloaded boot-patched.img file corresponding to the Model and OOS version in TWRP immediately after flashing the Stock ROM zip.
4. DON'T REBOOT TO SYSTEM
5. REBOOT TO TWRP.
6. In TWRP, MOUNT SYSTEM, GO TO ADVANCED > TERMINAL and Type "df system"(without quotes) and enter. The details of the system partition will be shown. Look at the Use% and Free Space. Make sure you have atleast 100MB free space in System before you go to the next step. If you don't have enough free space then mount system in TWRP, go to file manager and free some space in system by deleting some unwanted apps (in system/app folder like duo, google drive, hangouts,etc. which you can later reinstall via google play as it is not mandatory for them to run as system apps)...If there is low space on your system partition that fstab file flashing fails resulting in blank fstab file and you will end up in bootloop.
7. Once you have confirmed that you have atleast 100MB of free space left in system partition. REBOOT BACK TO TWRP.
8. Flash "Force Encryption Disabler For OOS Oreo v2.zip" in TWRP. (No need to mount system. The v2 zip file does it automatically)
9. Flash SuperSuSR5 / Magisk 15.3+
10. Done.
11. Reboot to System.
NB:f you have bootloop go back to TWRP by keep holding the power button to power off and powering on and rebooting to TWRP via the volume buttons, mount system, go to file manager and free some space in system by deleting some unwanted apps (in system/app folder like duo, google drive, hangouts,etc. which you can later reinstall via google play as it is not mandatory for them to run as system apps) and reflash the disabler zip and reboot..It is due to low space on your system partition that fstab file flashing fails resulting in blank fstab file. But if you followed Steps 6 and 7 carefully you wont end up here.
PROCEDURE 2: This is applicable only to people who have their data currently ENCRYPTED AND NEEDS TO GET IT DECRYPTED and PREVENT TRIGGERING DM-VERITY
First of all Backup your data preferably to and usb otg or a PC for later restore. You will lose your data from your phone following this procedure...
1. Go to Bootloader...
2. Connect to your PC..Type "fastboot format userdata" without quotes and press enter. (You will lose your data, do back up if you need something.)
3. Don't reboot to system...Using volume buttons select boot to recovery and Reboot to TWRP.....(Very Important)
4. Flash the downloaded boot-patched.img file corresponding to the Model and OOS version in TWRP immediately after flashing the Stock ROM zip.
5. DON'T REBOOT TO SYSTEM
6. REBOOT TO TWRP
7. In TWRP, MOUNT SYSTEM, GO TO ADVANCED > TERMINAL and Type "df system"(without quotes) and enter. The details of the system partition will be shown. Look at the Use% and Free Space. Make sure you have atleast 100MB free space in System before you go to the next step. If you don't have enough free space then mount system in TWRP, go to file manager and free some space in system by deleting some unwanted apps (in system/app folder like duo, google drive, hangouts,etc. which you can later reinstall via google play as it is not mandatory for them to run as system apps)...If there is low space on your system partition that fstab file flashing fails resulting in blank fstab file and you will end up in bootloop.
8. Once you have confirmed that you have atleast 100MB of free space left in system partition. REBOOT BACK TO TWRP.
9. Flash "Force Encryption Disabler For OOS Oreo v2.zip" in TWRP. (No need to mount system. The v2 zip file does it automatically)
10. Flash SuperSuSR5 / Magisk 15.3+
11. Done.
12. Reboot to System.
NB: If you have bootloop go back to TWRP by keep holding the power button to power off and powering on and rebooting to TWRP via the volume buttons, mount system, go to file manager and free some space in system by deleting some unwanted apps (in system/app folder like duo, google drive, hangouts,etc. which you can later reinstall via google play as it is not mandatory for them to run as system apps) and reflash the disabler zip and reboot..It is due to low space on your system partition that fstab file flashing fails resulting in blank fstab file. But if you followed Steps 7 and 8 carefully you won't end up here.
Rooting:
For Rooting use only SuperSu 2.82 SR5 or Magisk 14.3 or above seems to work for root...
FAQs:
Q: Is the boot.img file altered in anyway?
A: As mentioned above its 100% stock boot image except that the DM-Verity Flag has been patched in the device tree blobs (dtb)...
Q: My phone is already encrypted, will I lose encryption on flashing the zip?
A: No. It only disables force encryption. That means if you have already disabled encryption in your phone it will prevent the phone from getting encrypted when you flash a stock OOS ROM..
Q: I happen to lose TWRP and revert to stock recovery every time I update OOS, I happen to lose changes made to system via TWRP or lose data/apps accidentally while updating OOS...Can this be corrected by using this method?
A: Definitely. Follow the steps correctly. Each time while updating the OOS, after flashing the Full OOS ROM.zip, immediately flash the patched boot.img of the corresponding OOS given in this thread and then restart back to TWRP recovery. Done. You will never lose TWRP again..
Q: I am Rooting my phone using Magisk/Supersu then why do i need this?
A: Its optional.. If you are rooting phone using Magisk/Supersu it patches the stock boot.img. But in case you have problems flashing Magisk/Supersu after flashing the STOCK ROM zip this can come in handy or as an insurance policy just flash this patched boot.img before doing anything. But is very helpful to those people out there who doesn't root their phone but has unlocked their phone or installed TWRP for other purposes..
Q: How to flash the patched boot.img in TWRP?
A: Default flash option is for zip files in TWRP. Select the flash image option in TWRP. Then select the downloaded patched boot.img file and among from the partition option (boot, recovery and system) select the boot option and then flash it.
Q: What is "-Xn" seen after the OOS Version in the settings menu?
A: That's just my signature -Xn that I had put there to make sure that you have correctly done the procedure and the boot image that is currently in use is my patched boot image and to ensure you that you are 100% safe from DM verity...
Q: Where to find downloads and queries regarding the Stock OOS ROM and Beta OOS?
A: @Siddk007 has been maintaining Stock and Beta OOS threads were you can find relevant information.
Hope you find it useful...
Will update this OP as newer OOS versions come....
Thanks,
@rk2612 -- For pointing out the presence of DM-Verity checks in dtbs...
@BillGoss -- For testing out the patched boot images and providing useful posts mentioning that DM-Verity triggering reverts changes made to system...
@akhilnarang -- For helping tackle the weirdness of fstab decryption....as he pointed out the fact of clearing the system of free space to get it done...
HIT THANKS IF I HELPED YOU. IT DOESN'T COST YOU ANYTHING, BUT IT MEANS A LOT TO ME...
AND IF YOU DO APPRECIATE MY WORK DONATIONS ARE ALWAYS WELCOME...
THIS IS FOR PEOPLE WHO HAVE TRIGGERED DM-VERITY AND NEEDS TO GET RID OF THE DM-VERITY MESSAGE PERMANENTLY ON OOS OPEN BETA OREO ROMs. CONFIRMED WORKING EVEN IN THE LATEST OOS OREO STABLE 5.0.8/ BETA 30/BETA 39...
THIS IS FOR ONEPLUS 3T AND FOR ONEPLUS 3 but be careful in using the correct files corresponding to the OOS version and your MODEL
READ ALL THE STEPS AND DOWNLOAD ALL REQUIRED FILES BEFORE PROCEEDING. FOLLOW THE STEPS EXACTLY AND 100% THE DM-VERITY MESSAGE WILL BE GONE WITHOUT ANY DATA LOSS OR ANY OTHER HARM!!!
Prerequisite : Install ADB for windows from here: [url]https://forum.xda-developers.com/showthread.php?t=2588979[/URL]
1)
Download 4.0.2 Firmware for Oneplus 3T from here: [url]http://www.mediafire.com/file/cx568em66025p5b/4.0.2_firmware_OnePlus_3T.zip[/URL]
Download 4.0.2 Firmware for Oneplus 3 from here: [url]http://www.mediafire.com/file/8tt5x4xxy4m488t/4.0.2_firmware_OnePlus3.zip[/URL]
2) Flash the downloaded 4.0.2 firmware OnePlus 3.zip or 4.0.2 firmware OnePlus 3T.zip file in TWRP.
3) DONT REBOOT TO SYSTEM. REBOOT TO BOOTLOADER FROM OPTION IN TWRP.
4) Connect your phone to the pc
5) Press windows button + X
6) Open Command prompt
7) Type "fastboot oem disable_dm_verity" without quotes and press enter
8) Type "fastboot oem enable_dm_verity" without quotes and press enter
9) DONT REBOOT TO SYSTEM. REBOOT TO TWRP RECOVERY.
10)
In case of Oneplus3T, Flash the required firmware files for Stable or Open Beta OREO OOS corresponding to your current OOS (current OOS is the version of OOS which you are using now on your phone) in TWRP from this post: https://forum.xda-developers.com/oneplus-3t/how-to/firmware-beta-10-t3631166(Courtesy: @kamilmirza)
In case of Oneplus3, Flash the required firmware files for Stable or Open Beta OREO OOS corresponding to your current OOS (current OOS is the version of OREO OOS which you are using now on your phone) in TWRP from this post: [url]https://forum.xda-developers.com/oneplus-3/how-to/radio-modem-collection-flashable-zips-t3468628[/URL] (Courtesy: @jamal2367)
11) DONT REBOOT!!!!
12) VERY IMPORTANT: WITHOUT REBOOTING, Flash the downloaded boot-patched.img file corresponding to the OOS version and phone model(either stable or beta) in TWRP from post 1...
13) Reboot..The DM-verity message is gone forever...
VERY IMPORTANT:
1. If you need to keep your phone un-encrypted flash Force Encryption Disabler For OOS Oreo.zip immediately after step 12 and then only reboot.
2.If you are attempting this method on a a CUSTOM ROM then after Step 12 flash the full CUSTOM ROM zip file + latest gapps again without doing any sort of wipes in TWRP immediately and then only reboot....
Enjoy!!!
FAQs...
Q: Will I lose any data after I do these steps?
A: Never. There will be no data loss or any untoward effects of the procedure. Your data and phone will be in the exact same state as it was a before except for the fact that the damn dirty Dm-Verity message will be gone forever!!!
Q: Will this work on CUSTOM ROMs?
A: Of course. It has been tested to be perfectly working on even CUSTOM ROMs. Just follow the instructions in this post carefully where specific steps for CUSTOM ROMs are mentioned.
HIT THANKS IF I HELPED YOU. IT DOESN'T COST YOU ANYTHING, BUT IT MEANS A LOT TO ME...
Knowledge is always good and Xda is the best place to share it.. So here it is...
This is important for those interested in depth reading and for those who casually use xda to just download and use stuff because it gonna affect you all...
It all begins with the boot.img file which is located inside the Oxygen OS ROM zip file. The Boot image file can be practically for learning purpose be broken down to ramdisk, kernel and dtb(device tree blob) files.
The importance of all this is that from Oreo onwards Oneplus just shifted the fstab entry(in which the code triggering dm-verity is located) into the dtb file rather than in the ramdisk which becomes a little hard to edit rather than while being in the ramdisk.
So the essential steps being unpacking dtb file from the boot image, then editing the code triggering the dm-verity in the dtb file and then repacking the dtb into the boot image file again. Seems simple but its rather difficult...
The dtb file extracted from the boot image file in fact can be further split into 13 dtb dumps, 12 of which having an fstab entry that triggers dm-verity and each has to patched individually and then combined to a single dtb file and then repacked to the boot image....
So what is important is...
The original code in dtb file by Oneplus in the boot image file after decompiling and analysing by the dtc(device tree compiler) is :
Code:
fstab {
compatible = "android,fstab";
system {
compatible = "android,system";
dev = "/dev/block/platform/soc/624000.ufshc/by-name/system";
type = "ext4";
mnt_flags = "ro,barrier=1,discard";
fsmgr_flags = "wait,verify";
status = "ok";
};
};
The line fsmgr_flags = "wait,verify"; should be changed to fsmgr_flags = "wait" to avoid triggering dm verity.
So lets see...
What Magisk does... After analysing the patched boot image by magisk 14.5, 14.6 and 15.0 the Fstab entry in the dtb file looks like this:
Code:
fstab {
compatible = "android,fstab";
system {
compatible = "android,system";
dev = "/dev/block/platform/soc/624000.ufshc/by-name/system";
type = "ext4";
mnt_flags = "ro,barrier=1,discard";
fsmgr_flags = <0x77616974 0x0 0x0>;
status = "ok";
};
};
The problem is that magisk searches for the hex code for --->,verify and then replaces it with zero bytes....that efficiently disables the dm verity check in fs tab but the line fsmgr_flags = <0x77616974 0x0 0x0>; makes no sense...but when you translate the hex:77616974 to ASCII it becomes "wait". But whether this has any impilcations on the system or performance. I just simply dont know....
And I just couldn't analyse the dtb file produced by Magisk 15.1 as it fails to patch the dtb file in the boot image completely...just giving an error as Segmentation fault...This is well noticed as you cannot see the line stating that patching fstab in dtb file is conspicuously absent when you flash Magisk 15.1.. and hence Magisk 15.1 fails to clear the dm verity flag in the boot image...This can be ascertained by many who reported that they triggered dm verity today as they flashed Magisk 15.1 after flashing the ROM zip file in the Open Beta thread for oneplus 3T on XDA. But many didn't notice it as they just flashed Magisk 15/14.6 and then upgraded Magisk to 15.1 as the earlier versions as stated above took care of dm verity...
I have to say Magisk is one of the wonders in modern day android era and the statements i have given above is just observations and are really not meant to degrade or hurt the dev or anyone associated with magisk. @topjohnwu will already be knowing the issue as he is one hell of a developer and will definitely be correcting it...
Coming to SuperSu..This is what SuperSu does after patching the dtb file...
Code:
fstab {
compatible = "android,fstab";
system {
fsmgr_flags = "wait";
mnt_flags = "ro,barrier=1,discard";
type = "ext4";
dev = "/dev/block/platform/soc/624000.ufshc/by-name/system";
};
Now here the line fsmgr_flags = "wait"; is good but the line --->status = "ok"; is completely missing as SuperSu appends the line after the word "wait" in the fstab...And now whether this has any implications too whther I really dont know butit too does the job of removing dm-verity triggering...
Post a tiring study through all this I finally managed to patch the Oneplus boot image to as good as possible. I manually unpacked the boot image to dtb. The split the combined dtb to individual dtbs and the removed the line of code manually and the repacked the whole thing again to the original Boot image.
The dtb file in My Patched boot image looks like this after analysing with dtc.. And achieves the desired result...and perfectly avoids triggering dm-verity without causing any untoward effects in the fstab section in dtb file.
Code:
fstab {
compatible = "android,fstab";
system {
compatible = "android,system";
dev = "/dev/block/platform/soc/624000.ufshc/by-name/system";
type = "ext4";
mnt_flags = "ro,barrier=1,discard";
fsmgr_flags = "wait";
status = "ok";
};
Now the real question,
What will happen if you flash my patched boot image and then ,
---> When you flash Magisk after flashing my patched boot image it does nothing because it fails to identify the hex code for ",verify" as there is no such word/hex code in my boot.img file so it doesn't change anything to the fstab section in the dtb file in my patched boot image and so there no untoward effects in the code...
--->When you flash SuperSu, but, it still appends the line after "wait" in the dtb file in my patched boot image too and results in removal of the line status = "ok";.
Earlier Boot images posted in the OP, I too patched the hexcodes using a hex editor in the binary dtb file resulting in results in fstab section of dtb file like Magisk...
Now on I will manually patch each boot image file to produce the fstab file with no other alterations done in the dtb file so that there will never be any problems after flashing the patched boot images....
@Xennet that was quick, thanks. However i have already flashed and booted OB 16. can i still flash?
Of Course..
No problems in that...
Did you trigger Dm Verity and is your phone encrypted?
Xennet said:
Of Course..
No problems in that...
Did you trigger Dm Verity and is your phone encrypted?
Click to expand...
Click to collapse
i successfully rooted OB 16 without trigerring DM Verity and yes phone is encryptyed
Siddk007 said:
i successfully rooted OB 16 without trigerring DM Verity and yes phone is encryptyed
Click to expand...
Click to collapse
No problems still you can flash...
Thanks !
Too late for me brothers, I've fallen, I triggered dm verity and now my phone partition was wiped and it won't let me install a ROM.
Still have access to fastboot and adb tho. (Restore not working due to the dm-verity)
I'll try to flash this and play around, hopefully it will resolve my issue.
Thanks for helping everyone anyway
EDIT : Ok so I think it allowed me to restore an old old old backup so probably props to you for giving my brick a second chance.
It stills shows me the "dm-verity not enforced" message when booting up tho.
And TWRP still won't let me install a ROM. Even the officiel beta
I get an error 7 saying my build.pro ro.product.series is " " instead of "OnePlus 3T" but I checked it's OnePlus 3T...
If I remove the update script part about checking my series it just fails to update system image.
This update really ****ed up my phone because of the dm-verity when I tried to flash TWRP and Magisk (I had no issue before and was full stock)
Can anyone help ?
I triggered dm verity with oreo rom but I went and installed backup PA Nougat as I didnt like the OOS Oreo, can I still flash this zip on nougat to disable dm verity or is it only for oreo?
Isus <3 said:
I triggered dm verity with oreo rom but I went and installed backup PA Nougat as I didnt like the OOS Oreo, can I still flash this zip on nougat to disable dm verity or is it only for oreo?
Click to expand...
Click to collapse
This is only for Oreo
For Nougat go to my thread here..
https://forum.xda-developers.com/oneplus-3t/how-to/rom-dm-verity-force-encryption-disabled-t3618232
Hinoy said:
Too late for me brothers, I've fallen, I triggered dm verity and now my phone partition was wiped and it won't let me install a ROM.
Still have access to fastboot and adb tho. (Restore not working due to the dm-verity)
I'll try to flash this and play around, hopefully it will resolve my issue.
Thanks for helping everyone anyway
EDIT : Ok so I think it allowed me to restore an old old old backup so probably props to you for giving my brick a second chance.
It stills shows me the "dm-verity not enforced" message when booting up tho.
And TWRP still won't let me install a ROM. Even the officiel beta
I get an error 7 saying my build.pro ro.product.series is " " instead of "OnePlus 3T" but I checked it's OnePlus 3T...
If I remove the update script part about checking my series it just fails to update system image.
This update really ****ed up my phone because of the dm-verity when I tried to flash TWRP and Magisk (I had no issue before and was full stock)
Can anyone help ?
Click to expand...
Click to collapse
Install nougat ROM OOS 4.5.0 STABLE and remove DM verity by following instructions from my thread here...
https://forum.xda-developers.com/oneplus-3t/how-to/rom-dm-verity-force-encryption-disabled-t3618232
Then after removing DM verity if needed you can reflash Oreo beta zip after removing the first line in updater script and then immediately flashing the DM verity and force encryption disabled zip from this thread...
Can anyone confirm it works? (disabling forced encryption)
I had changed the flag in fstab manually (forceencrypt to encryptable), and I still got encrypted.
akhilnarang said:
Can anyone confirm it works? (disabling forced encryption)
I had changed the flag in fstab manually (forceencrypt to encryptable), and I still got encrypted.
Click to expand...
Click to collapse
At least for me I couldn't get it to not be encrypted. I've tried for a few hours and had no luck.
akhilnarang said:
Can anyone confirm it works? (disabling forced encryption)
I had changed the flag in fstab manually (forceencrypt to encryptable), and I still got encrypted.
Click to expand...
Click to collapse
Nope it does not. Mine started the encryption process as well.
[EDIT] correction; it does seem to work. Because the first boot took really long and the device ran hot, just like the first time when I did have encryption, I thought it was the case this time as well. Although I had to reflash the TWRP-recovery (it was replaced by stock) but it did not tell me /data was encrypted, so I think we're good!
Thank you Xennet!
Mr_Q said:
Nope it does not. Mine started the encryption process as well.
[EDIT] correction; it does seem to work. Because the first boot took really long and the device ran hot, just like the first time when I did have encryption, I thought it was the case this time as well. Although I had to reflash the TWRP-recovery (it was replaced by stock) but it did not tell me /data was encrypted, so I think we're good!
Thank you Xennet!
Click to expand...
Click to collapse
Hope you will not lose twrp if you had rebooted back to twrp before rebooting to system..
Can you confirm that the phone is not encrypted...
See the encryption status in settings, security..
Xennet said:
Hope you will not lose twrp if you had rebooted back to twrp before rebooting to system..
Can you confirm that the phone is not encrypted...
See the encryption status in settings, security..
Click to expand...
Click to collapse
I did boot TWRP -> TWRP, it become stock after I did a normal boot.
But the sad news is, it does state it's encrypted..
So I thought encryption always required a PIN or Pattern when accessing the phone and/or Recovery, am I wrong?
Mr_Q said:
I did boot TWRP -> TWRP, it become stock after I did a normal boot.
But the sad news is, it does state it's encrypted..
So I thought encryption always required a PIN or Pattern when accessing the phone and/or Recovery, am I wrong?
Click to expand...
Click to collapse
Just sent you a PM..
Check it...
Mr_Q said:
I did boot TWRP -> TWRP, it become stock after I did a normal boot.
But the sad news is, it does state it's encrypted..
So I thought encryption always required a PIN or Pattern when accessing the phone and/or Recovery, am I wrong?
Click to expand...
Click to collapse
Yup but that's right...
To access an encrypted phone data you need a pin in TWRP
Can you check in TWRP again and are you able to see your data and copy and move around files..
Xennet said:
Yup but that's right...
To access an encrypted phone data you need a pin in TWRP
Can you check in TWRP again and are you able to see your data and copy and move around files..
Click to expand...
Click to collapse
Yes I can, but I did notice something interesting in the logs of TWRP:
Data successfully decrypted, new block device: '/dev/block/dm-0'
Updating partition details...
... done
Succesfully decrypted with default password.
So yes it's encrypted, but I don't have to enter any password...
Mr_Q said:
Yes I can, but I did notice something interesting in the logs of TWRP:
Data successfully decrypted, new block device: '/dev/block/dm-0'
Updating partition details...
... done
Succesfully decrypted with default password.
So yes it's encrypted, but I don't have to enter any password...
Click to expand...
Click to collapse
You have not triggered DM verity I suppose??
So my zip file does protect from triggering DM verity but not force encryption that's weird...
Did you use any root methods..?
I'm rooted using Magisk and I'm using ElementalX kernel, I do not have TWRP installed as I want to get OTAs... my question is, can I re-ecrypt my data without losing Magisk? I remember TWRP having problems decrypting the partition when I first tried to install Magisk/EX so, in case I lose Magisk, can I reinstall Magisk/EX in TWRP or Fashfire once I re-encrypt my device? (i.e. can TWRP decrypt "user encrypted" data partitions? and/or can Magisk run from an encrypted data partition?)
jhonyrod said:
I'm rooted using Magisk and I'm using ElementalX kernel, I do not have TWRP installed as I want to get OTAs... my question is, can I re-ecrypt my data without losing Magisk? I remember TWRP having problems decrypting the partition when I first tried to install Magisk/EX so, in case I lose Magisk, can I reinstall Magisk/EX in TWRP or Fashfire once I re-encrypt my device? (i.e. can TWRP decrypt "user encrypted" data partitions? and/or can Magisk run from an encrypted data partition?)
Click to expand...
Click to collapse
You have a premise incorrect here... If you are not 100% stock, you CANNOT take an OTA, even if you have stock recovery... you have modified the kernel, ramdisk image (Magisk), and likely the system partition (if not, why did you bother to root?), so OTA updates will FAIL. Even with FlashFire they are less there is less than a 50% success rate with this device when rooted.
Although I haven't tried in a long time, TWRP should handle encryption fine, as long as you know the password/PIN... I can't speak for ElementalX specifically, but it is a mainline kernel so I think it should be fine.
The point is that once you have unlocked the bootloader, your device security is pretty much zero... that is kind of a given, encryption helps safeguard your private information, but unlocked bootloader negates FRP and anyone could just fastboot TWRP, wipe and enjoy using your device. This is one of the reasons (of several) that I have stopped unlocking the bootloader and rooting anymore.
My question was mainly about Magisk and TWRP working with encrypted partitions.
About the security, I'm aware of the implications and I just want to keep my data safe, which is more important than the device itself.
As for the device modifications, AFAIK ElementalX uses the ramdisk just as Magisk does, it doesn't write anything to the kernel partition, also, I haven't modified /system at all; all possible modifications I've done have been through Magisk modules and Xposed (which I installed systemlessly of course). The main reason I rooted is indeed Xposed so I can use stuff like NeoPowerMenu, Whatsapp Extensions, ActivityForceNewTask, etc.
Given the fact that I've only modified the ramdisk so far, are you sure that I can't accept OTAs? (I know they'll break my current setup, but it should be easy to fix)
jhonyrod said:
My question was mainly about Magisk and TWRP working with encrypted partitions.
About the security, I'm aware of the implications and I just want to keep my data safe, which is more important than the device itself.
As for the device modifications, AFAIK ElementalX uses the ramdisk just as Magisk does, it doesn't write anything to the kernel partition, also, I haven't modified /system at all; all possible modifications I've done have been through Magisk modules and Xposed (which I installed systemlessly of course). The main reason I rooted is indeed Xposed so I can use stuff like NeoPowerMenu, Whatsapp Extensions, ActivityForceNewTask, etc.
Given the fact that I've only modified the ramdisk so far, are you sure that I can't accept OTAs? (I know they'll break my current setup, but it should be easy to fix)
Click to expand...
Click to collapse
Positive... 99% sure they will fail. And although Xposed may be installed systemless, it's modules still modify /system.
Tools needed: boot.img extractor. I recommend the one created by osm0sis from this thread:
https://forum.xda-developers.com/sho....php?t=2073775
The first method was developed by osm0sis and removes magisk and all modules.
1. Unpack magisk_patched.img
2. Unzip overlay.dremove1.zip and place overlay.d folder in ramdisk folder.
3. Repack IMG
4. fastboot boot image-new.img created by repacking 8mg
This method is an offshoot of osm0sis version but boots core-only mode. Afterwards, remove the .disable-magisk file from the /cache folder for modules to work. Dot files are hidden files so if your root explorer can't see hidden files, run the "Remove disable_magisk" bat file in ADB.
1. Same as above but use the overlay.dcoreonly1.zip
For both methods you must be rooted for it to work. These are not cure all's for all bootloops.
Remove .disable_magisk bat file
https://www.androidfilehost.com/?fid=4349826312261684994
****************************************
Here is a fastboot bootable image to boot you into Magisk core-only mode in case you bootloop due to flashing a bad module and TWRP is not enough.
Once in fastboot:
fastboot boot image-newpixel3a.img
You will boot with root but modules disabled. After you remove the offending module you will need to go to /cache folder and delete the .disable_magisk file before your modules will work.
fastboot boot image-newpixel3aRemove.img
This one should remove magisk and all modules, then reboot and magisk should reinstall itself (ask to install necessary binaries). This is what osm0sis uses to recover from failed flashes. See this post:
https://forum.xda-developers.com/pi...odules-disabler-booting-magisk-t3976625/page2
Images are in this common folder. Pick the appropriate image for your phone.
6-4-20
https://www.androidfilehost.com/?w=files&flid=313291
oh my gosh would you believe i desperately needed this on tuesday and, after several hours spent trying unsuccessfully to get magisk manager for recovery working, ended up reflashing and starting again from scratch! crazy timing. anyway thanks for this, will definitely come in handy as i am too stupid to learn from my mistakes, ever.
c_tho said:
oh my gosh would you believe i desperately needed this on tuesday and, after several hours spent trying unsuccessfully to get magisk manager for recovery working, ended up reflashing and starting again from scratch! crazy timing. anyway thanks for this, will definitely come in handy as i am too stupid to learn from my mistakes, ever.
Click to expand...
Click to collapse
Relatable. I've had to hard wipe twice as I'm not used to this a/b stuff without TWRP lol. I've learnt my lesson though and finally granted shell root access, so assuming the phone boots past the bootloader I can use adb to fix up my magisk install.
Sent from my Google Pixel 3a XL using XDA Labs
Thank you! I've been running the stock kernel for the past several days because of a borked Magisk module. I couldn't fix the problem through TWRP since I'm on Android 10. This boot image allowed me to get back root without wiping. So thanks again!
Do you mind explaining how you made the image? I saw on the Magisk website that such a thing was possible but was unable to actually find details on how to create a core only image.
benji said:
Thank you! I've been running the stock kernel for the past several days because of a borked Magisk module. I couldn't fix the problem through TWRP since I'm on Android 10. This boot image allowed me to get back root without wiping. So thanks again!
Do you mind explaining how you made the image? I saw on the Magisk website that such a thing was possible but was unable to actually find details on how to create a core only image.
Click to expand...
Click to collapse
You have to build your own copy of magisk from GitHub.
Clone magisk
Go to native/jni/core folder and edit the boot stages.cpp file in notepad++ like this:
Approx line 667
If (access(DISABLEFILE, F_ok) ==0)
Change == to !=
Now build magisk as per instructions on GitHub
One you have built it and there were no errors go to native/out/armeb-v7a folder and get a copy of the magiskini64 file.
Unpack a copy of your magisk_patched.img.
In the ramdisk folder replace the init file with the .magiskini64 file (rename to init)
Repack your magisk_patched.img
The results are a patched IMG that will boot core only mode.
I definitely need to make sure I have this handy. A few questions, if you don't mind.
1. I would assume one should make a new version everytime they update to the latest security patch, correct? For example, I should not use a patched boot.ing from the December patch if I'm on the January, patch, correct?
2. Do your instructions assume that someone already put a .disable_magisk file in /cache, or does the boot.img itself do that job?
Bramton1 said:
I definitely need to make sure I have this handy. A few questions, if you don't mind.
1. I would assume one should make a new version everytime they update to the latest security patch, correct? For example, I should not use a patched boot.ing from the December patch if I'm on the January, patch, correct?
2. Do your instructions assume that someone already put a .disable_magisk file in /cache, or does the boot.img itself do that job?
Click to expand...
Click to collapse
To update boot would be best but you are just booting the image, not flashing. The old method required building a modded version of Magisk. The new method you just unpack the magisk_patched.img and drop in the overlay folder.
The boot image installs the .disable_magisk file for you.
March boot fix images uploaded.
Thank god for this one. I almost did a fullwipe because I couldn't get Magisk to work after flashing the March factory image in order to update. Turns out I forgot to remove your center clock/battery icon gone module. I didn't expect it to be the culprit, but it seems it was. Regardless, I'm back to working root after days of trying to find a fix
Is it possible to fastboot boot (not flash) the modified boot image for disabling modules and then install Magisk via Magisk Manager?
cucumbersmell said:
Is it possible to fastboot boot (not flash) the modified boot image for disabling modules and then install Magisk via Magisk Manager?
Click to expand...
Click to collapse
You should be able to boot with the modified image, but you don't "install" Magisk then - Magisk is already installed, just you booted with all the modules disabled
Just open Magisk Manager, go to Modules and mark to remove the module(s) causing bootloop.
Pay also attention to remove
.disable-magisk file from /cache
as described in OP post #1
Then reboot with your proper Magisk patched image (no more Core Only) and if you have removed the module in the previous step, this time you should be booted to Magisk with no bootloop and with your other modules re-enabled again
zgfg said:
You should be able to boot with the modified image, but you don't "install" Magisk then - Magisk is already installed, just you booted with all the modules disabled
Just open Magisk Manager, go to Modules and mark to remove the module(s) causing bootloop.
Pay also attention to remove
.disable-magisk file from /cache
as described in OP post #1
Then reboot with your proper Magisk patched image (no more Core Only) and if you have removed the module in the previous step, this time you should be booted to Magisk with no bootloop and with your other modules re-enabled again
Click to expand...
Click to collapse
I used Tulsadiver's core-only boot.img for the OP7T to root the phone by fastboot booting it and then using Magisk Manager to install to the active and inactive slots. Was hoping the boot.img for the 3a would work similarly. Was nice and simple and saved the time of having to download and patch the boot.img.
cucumbersmell said:
I used Tulsadiver's core-only boot.img for the OP7T to root the phone by fastboot booting it and then using Magisk Manager to install to the active and inactive slots. Was hoping the boot.img for the 3a would work similarly. Was nice and simple and saved the time of having to download and patch the boot.img.
Click to expand...
Click to collapse
It is based off of a magisk_patched.img so you might be able to use it like that. You would need to remove the .disable_magisk file from the cache folder though. This is a little different than the one I helped out with on the 7T forum.
cucumbersmell said:
I used Tulsadiver's core-only boot.img for the OP7T to root the phone by fastboot booting it and then using Magisk Manager to install to the active and inactive slots. Was hoping the boot.img for the 3a would work similarly. Was nice and simple and saved the time of having to download and patch the boot.img.
Click to expand...
Click to collapse
Edit: Sorry, seems I just missed the thread ?
I am trying to re-root my SM-T380 after updating to Pie and am following the latest process per [TWRP 3.2.1-1] [ROOT] Tab A SM-T380/T385 - 10/02/2018 but am running into some issues with steps 3 & 4.:
Boot to TWRP
Format the Data partition (not wipe) using the FORMAT DATA button under Wipe options
Install the memory decryption patch
Assume this is the file found in Ashyx's siganture Samsung encryption disable patch but I can't find any mirrors when trying to download it. Is this the right file for the memory decryption patch?
Install the modified kernel
The file for the SM-T380 found in this post appears to be for the T380DXU3CSI5 but the current stock image is T380DXU3CSL2 for the latest firmware installation (Jan 2020 security patch). I assume a new kernel is needed for this latest version. Is that the case? Also, the file is in tar format but need in zip format to flash in TWRP. Is it as simple as repackaging the tar into a zip file instead?
Install Magisk
Thanks for the help!
I will write out what I just got to work with the latest update of Android Pie for the Samsung Galaxy Tab A T380 running T380DXU3CSL2, security patch January 2020. I have tried all of the methods on the main TWRP/Root thread (which is now closed) and only had success with one.
To clarify, yes - using the patched boot.img from ashyx that was made from T380DXU3CSI5 WILL work with T380DXU3CSL2 (latest as of time of writing) just fine. Make sure to flash Stock first and OEM Unlock.
Ashyx does give some files still needed in his/her first post on the main TWRP thread, but the boot image and the DM-verity are buried within a 66 page thread. Out of respect for ashyx's wishes I will not direct link to files. Get TWRP from the first post here. The patched boot image and DM verity no encrypt get from the guide here by user zfk110. Pg. 65 of the TWRP thread. The guide itself did not work for me though. Just grab the files.
So, files you will need:
>twrp_3.2.3-1_sm-t380_oo_4119.tar (TWRP)
>T380DXU3CSI5_patched_boot_111119.tar (boot.img inside the .tar)
>Latest Magisk version here
>Tab_A_2017_Pie_forced+encryption_disabler-1.zip (no-verity-no-encrypt)
Not only have I found RMM Bypass unnecessary, but in my many trials I think maybe it was causing an issue for me. Perhaps someone much smarter than I can explain, but there is no setting in build.prop to need it - I did check.
TWRP/Root:
>Flash TWRP with Odin with "Auto Reboot" setting turned off: (file: twrp_3.2.3-1_sm-t380_oo_4119.tar in AP slot)
>Boot straight to TWRP (home + vol down + power to get out of download mode then as soon as the screen flashes swap to home + vol up + power),
>In TWRP main menu press "Wipe" and the "Format Data", type "yes" to proceed.
>Reboot to TWRP by going back to main menu of TWRP, select "Reboot" then "Recovery"
>Install boot.img to your boot partition from your external SD card in TWRP (there is a YT video how to do this within TWRP if you need help, just Google it. The file you need is: T380DXU3CSI5_patched_boot_111119.tar then extract boot.img from that for TWRP (use ZArchiver or a program that will unzip .tar). It MUST be in .img to install it with the TWRP "Image" button. TWRP won't even read that the .tar is there, and I don't recommend Odin for this)
>Install Magisk from your external SD card (I used the latest, 20.4 just fine)
>Install the DM-Verity Forced Encryption Patch from your external SD card (file: Tab_A_2017_Pie_forced+encryption_disabler-1.zip)
>Wipe Cache and Dalvik
>Reboot to System
Notes:
Boot image must be first before flashing the others. I tried it after Magisk et.al as with a number of people's directions and several other configurations in addition both in TWRP and with Odin (and the other boot image as well on the thread: t380_boot_pp.img - no luck on XSA for me at least) and it caused a bootloop every time. I don't know why. The smart guys are on the TWRP thread but it's closed (and confusing). I just try things.
To the other OP question here - use the later version of the DM-verity patch - the original one (no-verity-no-encrypt_ashyx) you are referring to is a different size and structure (I have it archived) so it is probably necessary to use the Tab_A_2017_Pie_forced+encryption_disabler-1.zip. It's on pg.65 on zfk110's guide that I linked above (though again, the guide itself did not work for me).
Edit: I know someone could find this method out from the big thread but I know what it is like to feel newby and get confused and want to give up. And the number of different methods and files on that dang thread was a bit maddening honestly and frequently in direct conflict with each other.
Thank you for the guide Winston Churchill, I tried following it for my device Samsung Tab A T380 (build T380DXU3CTH4) but I am stuck at installing Magisk. The patched boot.img is installed successfully but when I go to the system and Magisk does not appear so I have to install it manually with Magisk.apk file. Then when I check the status it says "Installed N/A, Ramdisk Yes, A/B No, SAR No" and root is not active.
I really appreciate any help on this!!
Many thanks Winston Churchill, this worked for me after many failed efforts using other methods and procedures.
Just one or two cautions, as I had to go through the process twice -- because the first time I got locked out with an "unauthorized" firmware notice on the first reboot. I'm not sure if it was because I did not flash the RMM Bypass the first time, or I didn't make sure my OEM Unlock was showing after flashing TWRP, etc. At any rate, I ended up with the RMM Prenormal state.
So I started over . . .
- Odin-flashed my Pie version 3CSI5 one more time
- Setup, went through the time and software update thing to get OEM Unlock to show, and enabled USB Debugging
- Odin-flashed twrp_3.2.3-1_sm-t380_oo_4119.tar
- In TWRP, ran Format Data, rebooted recovery and Formatted again (this has been necessary or advised for other Samsung devices in the past, so I did it here too)
- Then flashed in TWRP:
--- (1) boot.img
--- (2) Magisk 20.4
--- (3) Tab_A_2017_Pie_forced+encryption_disabler-1.zip
--- (4) RMM-State_Bypass_Mesa_v2.zip.
- Wiped Dalvik and Cache
- Rebooted to system
- Made sure OEM Unlock showed and USB Debugging was enabled
- Installed Magisk Manager 7.5.1
- Opened Magisk Manager and made sure Magisk was installed (sometimes it takes a reboot to see Magisk, and sometimes I've actually had to go back into TWRP and reflash it).
All good. So I installed my usual root-needed apps, Speed Software Root explorer, Titanium Backup, Adaway and Power Toggles. All are now rooted and working (including Titanium Backup!!!) and my Android Pie appears to be very stable. Soooo . . . quickly back to TWRP to run a Backup in case something breaks!
I have never had so much trouble rooting any Android device before. The T380 is a nice size and very nice weight, but man oh man . . . I was beginning to wonder if I would ever get it rooted. I can't tell you how much I appreciate (finally) finding this thread and specifically your post.
Moondroid said:
Many thanks Winston Churchill, this worked for me after many failed efforts using other methods and procedures.
Just one or two cautions, as I had to go through the process twice -- because the first time I got locked out with an "unauthorized" firmware notice on the first reboot. I'm not sure if it was because I did not flash the RMM Bypass the first time, or I didn't make sure my OEM Unlock was showing after flashing TWRP, etc. At any rate, I ended up with the RMM Prenormal state.
So I started over . . .
- Odin-flashed my Pie version 3CSI5 one more time
- Setup, went through the time and software update thing to get OEM Unlock to show, and enabled USB Debugging
- Odin-flashed twrp_3.2.3-1_sm-t380_oo_4119.tar
- In TWRP, ran Format Data, rebooted recovery and Formatted again (this has been necessary or advised for other Samsung devices in the past, so I did it here too)
- Then flashed in TWRP:
--- (1) boot.img
--- (2) Magisk 20.4
--- (3) Tab_A_2017_Pie_forced+encryption_disabler-1.zip
--- (4) RMM-State_Bypass_Mesa_v2.zip.
- Wiped Dalvik and Cache
- Rebooted to system
- Made sure OEM Unlock showed and USB Debugging was enabled
- Installed Magisk Manager 7.5.1
- Opened Magisk Manager and made sure Magisk was installed (sometimes it takes a reboot to see Magisk, and sometimes I've actually had to go back into TWRP and reflash it).
All good. So I installed my usual root-needed apps, Speed Software Root explorer, Titanium Backup, Adaway and Power Toggles. All are now rooted and working (including Titanium Backup!!!) and my Android Pie appears to be very stable. Soooo . . . quickly back to TWRP to run a Backup in case something breaks!
I have never had so much trouble rooting any Android device before. The T380 is a nice size and very nice weight, but man oh man . . . I was beginning to wonder if I would ever get it rooted. I can't tell you how much I appreciate (finally) finding this thread and specifically your post.
Click to expand...
Click to collapse
So many conflicting instructions - Why exactly are people flashing this modified boot image and then magisk? Correct me if Im wrong, but isnt that what installing magisk DOES (patches the boot image) when you rename the magisk apk to a zip and install in TWRP? I only FINALLY got this working after I ignored the patched boot.img step completely and simply - flash twrp in odin, reboot rocovery, format data, reboot recovery, flash magisk, disable verity whatever, reboot system..
Dick_Stickitinski said:
So many conflicting instructions . . .
. . . isnt that what installing magisk DOES (patches the boot image) when you rename the magisk apk to a zip and install in TWRP? . . .
Click to expand...
Click to collapse
Magisk patches boot.img for Root access. Sometimes there are also other reasons for flashing a boot.img. I'm not an Android coder so I can't explain every reason why flashing boot.img might be necessary in this case.
. . . "rename the magisk apk to a zip" . . . you renamed a Magisk Manager apk to "zip" for flashing in TWRP? How did that work?
At any rate, my method worked for me and yours (however you actually did it) worked for you. I can say for sure that Android itself can be quirky, for example, my recent experiences with a Galaxy S9 on Pie where, after reflashing the exact same build 5-6 times -- because trying to set a security PIN for some screwy reason kept crashing the system (?!!) -- from one reflash to the next I got different app-disabling experiences. For example, a few built-in apps (like google movies etc) showed the option to Uninstall instead of the expected Disable. The same generic reason why an S8 G950U on Pie v8 can be rooted successfully using @jrkruse's Extreme Syndicate method, and other S8 G950s on Pie v8 will brick. Quirky? Weird, I don't know, can't explain, I just go with the flow as it flows and count my blessings when it works.
Moondroid said:
. . . "rename the magisk apk to a zip" . . . you renamed a Magisk Manager apk to "zip" for flashing in TWRP? How did that work?
Click to expand...
Click to collapse
Yeah, you can rename the APK to zip & flash it in TWRP
The Magisk Manager APK can now be flashed from within TWRP
Magisk is now distributed as part of the Manager APK, meaning you no longer need to flash a separate ZIP file from a custom recovery.
www.xda-developers.com
However, I spoke too soon... I got it to stop bootlooping and actually got it to boot into system, and magisk manager is installed, but still not rooted. When flashing magisk in recovery again (or even extracting the boot.img & patching it in magisk manager, it recognizes it as a magisk-patched boot.img, but it's still not rooted. This tablet is frustrating the hell out of me, I'm about to say the hell with it & toss it.
Dick_Stickitinski said:
Yeah, you can rename the APK to zip & flash it in TWRP
The Magisk Manager APK can now be flashed from within TWRP
Magisk is now distributed as part of the Manager APK, meaning you no longer need to flash a separate ZIP file from a custom recovery.
www.xda-developers.com
Click to expand...
Click to collapse
As of January last year, okay. On older phones/tabs I almost always go with older Magisk versions that were more current with the older device's firmware.
Dick_Stickitinski said:
However, I spoke too soon... I got it to stop bootlooping and actually got it to boot into system, and magisk manager is installed, but still not rooted. When flashing magisk in recovery again (or even extracting the boot.img & patching it in magisk manager, it recognizes it as a magisk-patched boot.img, but it's still not rooted. This tablet is frustrating the hell out of me, I'm about to say the hell with it & toss it.
Click to expand...
Click to collapse
Just a suggestion, maybe try using an older Magisk. I flashed Magisk v20.4 in TWRP and Magisk Manager v7.5.1 after booting to system. Older Magisk (zip and Manager) can be found on topjohnwu's GitHub.
Note, doing it this way, I always have to reboot one more time to see Magisk fully installed and working.
Is there any way to have this phone rooted with encryption working? I would use Lineage, but it doesn't support VoLTE. I'm aware that TWRP will very likely never work again once the phone is encrypted, but that just means that I would have to flash everything I need before encrypting.
I'm on AO 20h ROM currently. My idea was (after making sure I never need TWRP again)
1. Flash stock 20h kernel zip without dm-verity and forced encryption disabled
2. Flash stock 20h boot.img (not sure if this step is necessary)
3. Reboot into system
Does this have the possibility of working? If not, what do I need to do to make this work?
Also, where can I find the stock kernel and boot.img?
I attempted to just flash the boot.img I extracted from the 20h kdz. This didn't work, because when I rebooted it just brought me to fastboot every time.
Edit: Second attempt was to extract the 20h kdz to get both the boot.img and the system.bin files. Then I patched the boot.img with Magisk Manager on my other phone, and moved it back to the sd card. To get the system.img from the 52 binary files, I used the KDZ Extractor which has an option to merge system files into an image. My plan was to flash from TWRP the system.img and then the patched boot.img, but when I went to install the system image, I got a warning message that the image was too big. It shows as 6GB on my computer, and the system partition is 5.4GB.
The only other idea I had in mind was to flash the 20h kdz, but interrupt the installation before it boots for the first time and "encrypts", then go into fastboot and flash the modified boot.img, but this seems excessively risky.
Edit Again: I DID IT!
And I'm not even locked out from using TWRP! Though I'm stuck on Nougat - 10p - with the method I used.
1. Patch extracted 10p boot image with Magisk app
2. Flash 10p with LGUP
3. Flash TWRP to recovery with Lafsploit, reboot to recovery
4. Factory reset from TWRP
5. While still in TWRP, flash the patched boot.img from 1.
Now my next goal is to deodex and try to get signature spoofing working so I can use MicroG. I've tried the Smali Patcher, which appeared to work, but it gets stuck on the T-Mobile splash screen. Same thing happens when I try to install Xposed with any method.
Hi there Pineapple!
Not too many people do care about H918 anymore. I am just like you trying to get something done, so reading everything I can find. I will point out the things I've learned already, but do remember I am not a dev, nor a senior member, not even a very experienced one.
So, above you were saying :
1. Flash stock 20h kernel zip without dm-verity and forced encryption disabled
2. Flash stock 20h boot.img (not sure if this step is necessary)
Well, the "boot.img" contains the Kernel and the Ram Disk, or at least this is what I've read in Android Internals - Jonathan Levin [1st Ed] free on his site. So, now it should be clear that if you'd do 2, it will overwrite 1.
About Encryption and Root:
ENCRYPTION:
Encrypt your phone before rooting, -> root, -> apply ROM. Not the other way around! Tested on Android 4-6.
Once you root or install various ROMs you lose the ability to encrypt your device.
You will have either hanging, rebooting, or the animation stalling
Discussed: http://forum.xda-developers.com/showthread.php?t=2791587 and
http://androidforums.com/threads/how-to-encrypt-a-rooted-device.866968/
Un-root if already rooted. Encrypt. Re-root.
If you Root with SuperSu, you have to manually kick start SuperSU when rooting after the encryption is in effect
Also see about issues with TWRP and Encryption in some devices
(Unable to decrypt the data partition on boot due to bug in TWRP)
(yep, H918, and it seems to be happening on stock ROMs as opposed to AOSP)
not sure if on H918 it is related or not to TWRP bug
Secure Boot (aka dm-verity) also complicates persistent rooting. <- look like you already took measures here
Xposed:
Xposed now also exists as a MAGISK MODULE, so no longer DETECTED if installed thru MAGISK <-try this
Had some issues with Android 7 (Nougat) but most were fixed. <-maybe try different version?
De-Odex
Why? Are you going to be theming your apps? AFAIK,
ODEX = (pre) Optimized Dalvik Exe file format (compressed, not fully compiled yet), separate from .apk
android apps are stored in .apk packages, not as easy nor fast to run as if already Odex-ed
De-Odexing just means having your apps on ROM sort of "collected" back to ".apk". You need that where you want to have an easy access to app resources, i.e. for theming.
QUESTIONS:
1. Could you, please, post the versions of all the components you've used? Like TWRP, Magisk..
2. So, microG doesn't work on rooted stock Nougat on H918? (Damn, I wanted to de-google)
Descent2 said:
So, above you were saying :
1. Flash stock 20h kernel zip without dm-verity and forced encryption disabled
2. Flash stock 20h boot.img (not sure if this step is necessary)
Well, the "boot.img" contains the Kernel and the Ram Disk, or at least this is what I've read in Android Internals - Jonathan Levin [1st Ed] free on his site. So, now it should be clear that if you'd do 2, it will overwrite 1.
About Encryption and Root:
ENCRYPTION:
Encrypt your phone before rooting, -> root, -> apply ROM. Not the other way around! Tested on Android 4-6.
Once you root or install various ROMs you lose the ability to encrypt your device.
You will have either hanging, rebooting, or the animation stalling
Discussed: http://forum.xda-developers.com/showthread.php?t=2791587 and
http://androidforums.com/threads/how-to-encrypt-a-rooted-device.866968/
Un-root if already rooted. Encrypt. Re-root.
If you Root with SuperSu, you have to manually kick start SuperSU when rooting after the encryption is in effect
Also see about issues with TWRP and Encryption in some devices
(Unable to decrypt the data partition on boot due to bug in TWRP)
(yep, H918, and it seems to be happening on stock ROMs as opposed to AOSP)
not sure if on H918 it is related or not to TWRP bug
Secure Boot (aka dm-verity) also complicates persistent rooting. <- look like you already took measures here
Click to expand...
Click to collapse
Yes, while doing this I did learn that the boot image contains the kernel. Looking back, that statement seems silly now that I know that. You are correct about encrypting before root. I did boot into the ROM and did the initial setup, then went back to TWRP (which thankfully had no error decrypting) to flash Magisk via the patched boot image. I did get rid of secure boot too, but I don't know if it was necessary in this case.
Descent2 said:
Xposed:
Xposed now also exists as a MAGISK MODULE, so no longer DETECTED if installed thru MAGISK <-try this
Had some issues with Android 7 (Nougat) but most were fixed. <-maybe try different version?
Click to expand...
Click to collapse
I tried three different ways of installing Xposed. First was through the Magisk Module, but this just made me get stuck on the T-Mobile screen. Had to remove the module from TWRP. Second was "systemlessly" as described here: https://magiskroot.net/install-systemless-xposed-framework-nougat/ . This had the same result. Third was by using only the Xposed Installer 3.1.5 apk, which didn't seem to do anything at all.
Descent2 said:
De-Odex
Why? Are you going to be theming your apps?
Click to expand...
Click to collapse
Deodexing the ROM is necessary to add signature spoofing, which is necessary to install MicroG, so it can pretend to be the real Google Play Services. Usually in the past I've done this with the Nanodroid patcher https://nanolx.org/nanolx/nanodroid but it didn't work here, which was odd because it did work on the Alpha Omega Oreo ROM (which didn't have working encryption).
Descent2 said:
QUESTIONS:
1. Could you, please, post the versions of all the components you've used? Like TWRP, Magisk..
2. So, microG doesn't work on rooted stock Nougat on H918? (Damn, I wanted to de-google)
Click to expand...
Click to collapse
1. The TWRP that's on the laf partition is the one that FWUL 2.7 installed. The TWRP that's on my recovery is 3.5.2_9-0-h918.img. This is the latest official release. To unpack the boot image from the stock kdz, I used LG Firmware Extract 1.2.6.1. I moved the boot image onto another phone which had the latest Magisk Manager app on it (23.0) to patch it with Magisk.
2. Not so far it hasn't. I've deleted everything Google with System App Uninstaller, /d/gapps, and adb. So I'm going without Google Services or MicroG for now. I'd like to change that though, since MicroG makes it far more livable.
So, you have the same end goal as I do - privacy. Have you considered buying the de-googled phone from Brax?
Honestly, this never ending enigma with H918 has me wondering if I should just do that. I mean, I don't sweat some learning and work, but now that the V20 forum is basically dead....
Descent2 said:
Have you considered buying the de-googled phone from Brax?
Honestly, this never ending enigma with H918 has me wondering if I should just do that. I mean, I don't sweat some learning and work, but now that the V20 forum is basically dead....
Click to expand...
Click to collapse
That reminds me of the people on ebay who try to sell 12 year old Thinkpads for 3-4x what they're worth just because they flashed coreboot on them. Except it's way easier to install a custom ROM on a Pixel than it is to flash coreboot. The Pixels are also very different phones than the V20 - no removable battery, ir blaster, 3.5mm jack, good DAC - but if you want the most private and secure smartphone, a Pixel with GrapheneOS (not Lineage) is what you want. Flash it yourself, it's way easier to do it to Pixels than LG's.
Same here.
May-be not that crazy, 3-4 times, but yeah, he sells Google Pixel 4 XL 128 GB with lineage for over $700 where that same phone is $380 on Swappa, lol. It's not as drastic as you memory of e-bay, but it is twice the worth, still.
But then again, considering how much Rob is doing for the community to propagate the awareness, may-be this isn't all that high of a price. Some busy people won't even blink at his prices, but would never invest this much time to decipher everything. Sadly, I, myself is a sucker for the know how, instead of focusing on making money.
You are right in that I did pick this phone as "last phone with removable battery" myself. I actually do remove the battery from time to time when I don't want to be tracked, and drop the phone in the steel covered glove compartment, where no weaker field communication can ever reach it.
Hey, thank you so much for the version numbers, if I decide to go that way, I'll use those exact ones! (So far, do not want to cross into ARB1, but it seems that the lafsploit only works with 10p...)
You know, the Patcher is also available from NanoDroid installed as a Magisk module. Their (Nano) description here:
GitHub - Nanolx/NanoDroid: [MIRROR] See https://gitlab.com/Nanolx/NanoDroid for main repository
[MIRROR] See https://gitlab.com/Nanolx/NanoDroid for main repository - GitHub - Nanolx/NanoDroid: [MIRROR] See https://gitlab.com/Nanolx/NanoDroid for main repository
github.com
states that NanoDroid includes:
on-device framework-patcher for microG support (signature spoofing), with automatic de-odexing up to Android 8.1
Is that the method you tried?
Nanolx says that his patcher patches the sig spoofing support into one of the three locations: Magisk NanoDroid module, Magisk itself and /system. When you were using the patcher, did you see any of these choices?
Also, do you know that the dev of Magisk now works for Google? Now, I know that absolute majority of people would not see anything weird here, but I do, cause I don't trust Google, and thus want to de-google my phone. Specifically, a small conflict of interest while working for google and developing a software that supposed to oversee and support the escape from that same Google by de-googling the phone. Some stockholders might find this quite funny and demand that something is done about this.
I would try older Magisk. I know from other threads, that on 10p, some of the versions of Magisk that did work were: 16.0, 21.0, 21.4 ...
Descent2 said:
You know, the Patcher is also available from NanoDroid installed as a Magisk module. Their (Nano) description here:
GitHub - Nanolx/NanoDroid: [MIRROR] See https://gitlab.com/Nanolx/NanoDroid for main repository
[MIRROR] See https://gitlab.com/Nanolx/NanoDroid for main repository - GitHub - Nanolx/NanoDroid: [MIRROR] See https://gitlab.com/Nanolx/NanoDroid for main repository
github.com
states that NanoDroid includes:
on-device framework-patcher for microG support (signature spoofing), with automatic de-odexing up to Android 8.1
Is that the method you tried?
Nanolx says that his patcher patches the sig spoofing support into one of the three locations: Magisk NanoDroid module, Magisk itself and /system. When you were using the patcher, did you see any of these choices?
Also, do you know that the dev of Magisk now works for Google? Now, I know that absolute majority of people would not see anything weird here, but I do, cause I don't trust Google, and thus want to de-google my phone. Specifically, a small conflict of interest while working for google and developing a software that supposed to oversee and support the escape from that same Google by de-googling the phone. Some stockholders might find this quite funny and demand that something is done about this.
I would try older Magisk. I know from other threads, that on 10p, some of the versions of Magisk that did work were: 16.0, 21.0, 21.4 ...
Click to expand...
Click to collapse
As long as Magisk itself is FOSS and hasn't been proven to be spyware, I'll trust it. The later versions actually have gotten better about privacy, since it now doesn't require internet. And the goal of the Magisk project isn't to de-google your phone. It can aid in de-googling, because you can uninstall system apps, but Magisk is just to gain root.
As for how I tried to use the patcher, I tried from TWRP, which gave me the error "failed to mount /system unsupported a/b device," and then if I tried to flash it from Magisk Manager it gave the error "failed to deodex services.jar"
When you say you tried to flash it from TWRP / Magisk Manager, it is not clear to me if you understand that Nano Patcher is also available as a Magisk module, and if you have tried to add that Magisk nano module or used the Patcher by itself as provided by NanoDroid in a stand alone installer. Since I haven't used Magisk yet myself, I do not know if has the flashing capability and that is what you referred to, or if that meant you added the module. Like I said, still learning here.
I do understand that Magisk is only a systemless root , not a patcher or microG.
The H918 is not an A/B device. Not on Nougat nor Oreo in any case. Obviously, you know that.
So, your device is being misidentified as a much newer device.
I think that if you had tried a version of Magisk or the Patcher that is not YET aware of A/B devices, then possibly such mis-identification would not happen.
Of course the fact that it happens thru TWRP, gives Magisk somewhat an alibi.
I still think it is worth trying. May-be older Patcher first, then with older Magisk.
I keep holding Magisk in my attention because without it doing its job correctly, you could not take the next step, the one that isn't working.
Finally, Try some of these: https://download.lineage.microg.org/h918/ ROMs, they already have signature spoofing handled. I would think an older one might work, as I saw several threads mentioning that the later versions of LOS don't run well on H918.
Also, here is thread you might want to read and post your situation into:
[MODULE/SYSTEM] NanoDroid 23.1.2.20210117 (microG, pseudo-debloat, F-Droid + apps)
NanoDroid NanoDroid is a installer for various OpenSource related things, most noticably microG and F-Droid. It supports direct /system installation, both devices with or without A/B partition scheme, aswell as Magisk Mode (module) installation...
forum.xda-developers.com
That thread discusses NanoDroid used as a Magisk Module, and there are few users experiencing a similar situation (with different errors) and some advices.
Descent2 said:
When you say you tried to flash it from TWRP / Magisk Manager, it is not clear to me if you understand that Nano Patcher is also available as a Magisk module, and if you have tried to add that Magisk nano module or used the Patcher by itself as provided by NanoDroid in a stand alone installer. Since I haven't used Magisk yet myself, I do not know if has the flashing capability and that is what you referred to, or if that meant you added the module. Like I said, still learning here.
Click to expand...
Click to collapse
I'm taking the nanodroid patcher zip from their website and attempting to flash in TWRP, which I've successfully done before on other phones. I also tried using the same zip and installing it as a module in Magisk. I don't think there's a separate file meant specifically for use as a Magisk module. I believe the a/b error in TWRP has something to do with the fact that when I'm in TWRP and I go into the "Mount" menu and select System, the check box only remains ticked for about 5 seconds, then it automatically unmounts again. No idea what the problem is there. I suspect if that weren't an issue, I'd get the same exact error that I get when trying to use the patcher with Magisk.
As for LineageOS for MicroG, that's what I was using before going back to stock, and it was great. But it's sadly unusable as a phone because of the lack of VoLTE. If not for that, this could easily be my "forever phone" with the huge battery.
I'm also now having a strange issue where many system functions (recents, settings menus, autorotate, second screen, statusbar) are running unusably slow, while any other app runs perfectly fine. I have to do more testing to figure out what this is, though. Edit: stuck at T-Mobile logo again. Gonna try to do all this with stock Oreo.
Oops, I am sorry, I forgot, you have said that in your first post that you already tried LOS, man. So, we are stuck? It gets stuck on T-Mobile splash, meaning this is a bootloop, or rather a bootfreeze. I think your other issues must be related to this issue that is preventing you from patching for signature spoofing.
I've been reading up trying to find what is going on with your phone, and I stumbled against this:
You simply swipe the bar to allow TWRP to make modifications to your /system partition. Swiping on this particular screen, you are giving TWRP permission to mount your /system partition as R/W (Read & Write) as opposed to the default of /system being mounted as R/O (Read Only). However, please beware and know what you are doing. If you so much as mount /system as R/W via TWRP, regardless if you actually make changes, a kernel secured with dm-verity (device mapping verification) will prevent your device from booting into the Android OS. Never mount /system as R/W without first verifying whether your kernel has dm-verity enabled. If dm-verity or AVB 2.0 (Android Verified Boot) is enabled, flashing a systemless root script like Magisk 16.0 will patch dm-verity to disabled, as well as disable force encryption in the fstab.
You said you disabled the secure boot. This is aka dm-verity .
Now in your case, you are using the encryption, which needs dm-crypt to be active, correct? These two are related because they both are managed by a DM - device mapper.
When you said you have disabled the secure boot (dm-verity), do you mean that you have maybe chose some options when patching the boot.img with Magisk ? Or did you do it thru some other method?
I keep seeing references to "No Verity Opt Encrypt" without a good explanation of what it is or how to use it or when to use it. I am curious if you have applied that or not, and if you did, where did you read about it.
So, my current thinking is that if you actually failed to disable the dm-verity, this should take you to the bootloop or freeze. May-be DM failed to separate the two and kept both enabled?
The fact that you have touched the /system as r/w according to green above, should trip the dm-verity to bootloop you, if dm-verity is somehow still enabled.
I still do not understand though, why you are receiving a failure to patch.
Also, you have mentioned that you have used a "Smali Patcher". Knowing nothing about nothing, I of course assumed you meant to type "Small Patcher" , i.e. some patcher. Now cleaning up the details I looked it up. Oops. It is actually a real thing. It supposed to examine your system in step 1, and generate a Magisk module, and in step 2, you add that module to Magisk and check it as enabled. I just want to confirm that this is exactly what you have done and this brought you to T-mobile splash screen.
I actually may try LOS for microG, what version did you have that was great?
Because from what I was reading the LOS for 918 has many issues (no 5G tether, no 2nd screen, no WiFi call, etc)
Descent2 said:
Oops, I am sorry, I forgot, you have said that in your first post that you already tried LOS, man. So, we are stuck? It gets stuck on T-Mobile splash, meaning this is a bootloop, or rather a bootfreeze. I think your other issues must be related to this issue that is preventing you from patching for signature spoofing.
I've been reading up trying to find what is going on with your phone, and I stumbled against this:
You simply swipe the bar to allow TWRP to make modifications to your /system partition. Swiping on this particular screen, you are giving TWRP permission to mount your /system partition as R/W (Read & Write) as opposed to the default of /system being mounted as R/O (Read Only). However, please beware and know what you are doing. If you so much as mount /system as R/W via TWRP, regardless if you actually make changes, a kernel secured with dm-verity (device mapping verification) will prevent your device from booting into the Android OS. Never mount /system as R/W without first verifying whether your kernel has dm-verity enabled. If dm-verity or AVB 2.0 (Android Verified Boot) is enabled, flashing a systemless root script like Magisk 16.0 will patch dm-verity to disabled, as well as disable force encryption in the fstab.
You said you disabled the secure boot. This is aka dm-verity .
Now in your case, you are using the encryption, which needs dm-crypt to be active, correct? These two are related because they both are managed by a DM - device mapper.
When you said you have disabled the secure boot (dm-verity), do you mean that you have maybe chose some options when patching the boot.img with Magisk ? Or did you do it thru some other method?
I keep seeing references to "No Verity Opt Encrypt" without a good explanation of what it is or how to use it or when to use it. I am curious if you have applied that or not, and if you did, where did you read about it.
So, my current thinking is that if you actually failed to disable the dm-verity, this should take you to the bootloop or freeze. May-be DM failed to separate the two and kept both enabled?
The fact that you have touched the /system as r/w according to green above, should trip the dm-verity to bootloop you, if dm-verity is somehow still enabled.
I still do not understand though, why you are receiving a failure to patch.
Also, you have mentioned that you have used a "Smali Patcher". Knowing nothing about nothing, I of course assumed you meant to type "Small Patcher" , i.e. some patcher. Now cleaning up the details I looked it up. Oops. It is actually a real thing. It supposed to examine your system in step 1, and generate a Magisk module, and in step 2, you add that module to Magisk and check it as enabled. I just want to confirm that this is exactly what you have done and this brought you to T-mobile splash screen.
I actually may try LOS for microG, what version did you have that was great?
Because from what I was reading the LOS for 918 has many issues (no 5G tether, no 2nd screen, no WiFi call, etc)
Click to expand...
Click to collapse
The "No Verity Opt Encrypt" is a file that disables verity and forced encryption. If you rename the zip, though, you can make it only disable verity or only disable forced encryption. I did flash it with no-dm-verity, but from what you found it looks like Magisk does this for us so it's probably not necessary.
The fact that it bootlooped isn't due to me mounting it. I did that several times before without bootlooping. The issue I had with it was that it automatically unmounted /system after a few seconds, which is why I believe I can't deodex from TWRP.
For the Smali patcher, I don't remember how I attempted to use it. So far my attempts to root and encrypt stock Oreo haven't gotten very far, so I'm going to try this again.
I just used the latest version. I don't use 5G tether so I wouldn't know. The 2nd screen "works" but it just extends the main screen, making the cameras into a notch type thing. I can live without wifi calling, but lte calling won't work, which is, again, the only thing keeping me from using Lineage MicroG.
DUH !
I can't believe sometimes how dumb I actually am. Of course, it says right in the name of the file: "No Verity + Optional Encryption" ! [slamming my forehead into the table] I swear I read it thousand times, but for some reason it did not make any sense to me. I knew it does something about this subject, but I never took it literally!
Thank you for letting me know.
It is cool how the arguments are sent by renaming the patch instead of using the optional parameters. I like that. Magisk does that as well. You flash Magisk.zip and it installs Magisk. You rename it to unistall.zip and flash that, and it uninstalls Magisk.
Please, keep posting if anything changes. If I read something that makes me think I've picked up the scent again, I will let you know. For now I don't know what else to read.
PineappleMousepad said:
I've deleted everything Google with System App Uninstaller, /d/gapps, and adb.
Click to expand...
Click to collapse
You uninstalled Android Device Bridge? I am curious as to why? I mean, yeah, it's Google, but it's most likely harmless, and very useful. Does it call home or something? At some level the entire Android is Google. Yeah it comes from HA, but Google pays. And money talks. I am curious why.
Anyway, I might have found something , I am not sure, but it looks interesting:
So, I am reading this:
Internal Details
The Magic Mask for Android
topjohnwu.github.io
It says:
Paths in /data
Some binaries and files should be stored on non-volatile storages in /data. In order to prevent detection, everything has to be stored somewhere safe and undetectable in /data. The folder /data/adb was chosen...
Click to expand...
Click to collapse
Did removing ADB, somehow messed up the /data/adb folder, and then that messed up Magisk? Is this why some of the operations you have attempted have failed? Like you'd install a module and it would be like you didn't even do anything?
I didn't remove adb. I debloated using System App Uninstaller. For some things that didn't work I used /d/gapps. For other things that didn't work I used adb.
Been messing around with Oreo the past couple days.
I *can* get stock Oreo to work with root and even MicroG - everything works great. Except it refuses to encrypt. The option is there in the menu to "Encrypt Phone". The battery was above 80% and plugged in, I tap the button, and it just takes me to the T-Mobile splash screen and quickly to the lock screen. I know MicroG isn't causing it, since it has this issue with or without MicroG. I get the same result whether I installed 20h from a TWRP flashable zip or if I installed 20h from the kdz with the kdz writer tool https://forum.xda-developers.com/t/tool-kdz-writer.3649818/. It isn't an issue with the recovery partition, as I left that stock and just use TWRP from LAF.
The less ideal option for Oreo at the moment is to have it completely stock from LGUP and just debloat with adb. This means no root or MicroG, but those are the least of the issues. It looks like if you uninstall Google Play Services without also installing MicroG, you get constant error messages saying "Messages has stopped working." No problem, just remove the messages app and use QKSMS, right? Well removing Messages breaks Contacts, which is also the dialer. Removing the dialer and contacts, replacing them with Simple Dialer and Simple Contacts works, but then you get the constant error message "LG IMS has stopped working." Removing LG IMS gets rid of the error messages but, predictably, breaks VoLTE.
Edit: It may not have been Google Play Services that broke the Messages app.
Quick reaction. You are likely right. It probably wasn't the removal of GPS that broke Messaging. There are so many different fixes for that error on the net (which you probably have already mostly tried), that it suggests many different causes for the error.
But, interesting how all that stuff is chained. Almost looks as if intended that way. Don't deny them saying a good bye to google outright, just make it an incredibly deep rabbit hole.
This comes to mind: try "freezing" messaging or anything lower on this chain, in hopes that it is the uninstall that removes some shared dependency and that they haven't thought of you trying to freeze them. I know you wouldn't care all that much if the chain didn't end with VoLTE.