FORUMS
Remove All Ads from XDA

Universal DM-Verity, ForceEncrypt, Disk Quota Disablers [10/20/2019]

3,654 posts
Thanks Meter: 5,673
 
Post Reply Email Thread
27th July 2019, 12:32 AM |#541  
OP Senior Member
Thanks Meter: 5,673
 
More
Quote:
Originally Posted by sga999

Still no luck. I'm attaching recoveryd.log, which is after flashing your disable...zip. Also, I'm attaching recoverym.log after flashing Magisk zip.

Looks like I'll need to read the magisk docs more on .magisk files. Zip worked fine but magisk then removed the .magisk file from ramdisk and made a new one :/
Magisk also segfaulted - don't know what's up there
27th July 2019, 06:22 AM |#542  
Senior Member
Thanks Meter: 110
 
More
Quote:
Originally Posted by Zackptg5

Looks like I'll need to read the magisk docs more on .magisk files. Zip worked fine but magisk then removed the .magisk file from ramdisk and made a new one :/
Magisk also segfaulted - don't know what's up there

I've been looking at the scripts for Magisk. It looks like get_flags invokes getvar for variables FORCEENCRYPT and FORCEVERITY (and more). gevar contains this line: VALUE=`grep_prop $VARNAME /sbin/.magisk/config /data/.magisk /cache/.magisk`

But only /data/.magisk seems "accessible" when installing Magisk during TWRP, so it seems like your zip file MUST place the .magisk file in /data in order for the subsequent Magisk install to see the overrides.

I haven't looked closely enough yet at your anykernel.sh. But there are some copies at line 167 that should copy from config to /data/.magisk, etc. But for some reason, those must not be happening for my device/rom. I'll keep learning more, but I thought this might give you a hint about what's going on.

EDIT: Just for a test, I added a line to copy the .magisk file at about line 165.
Added this: cp -f $home/config /data/.magisk
Before this elif [ "$ROOT" != "SuperSU" ]; then

It appears to work, but I haven't tested it much. You will probably want to add more lines, making it more like lines 167-172.

Things I don't know:
1. What is $home? Is it /sbin/.magisk?
2. It seemed like I couldn't access /sbin/.magisk/config and /cache/.magisk in TWRP, only /data/.magisk. See 2a. below. However, I know a config file was written there, so it must be accessible. I'm confused!.
3. In TWRP file manager or terminal, I can't see files/folders starting with a dot. Why is that?

2a. When I say files are not accessible, here's why I say that. While in TWRP, in adb shell, I issue:
sed -n /KEEPVERITY=/p /sbin/.magisk/config /data/.magisk /cache/.magisk

Here is the output from that. Only the middle one, /data/.magisk works.
sed: /sbin/.magisk/config: No such file or directory
KEEPVERITY=false
sed: /cache/.magisk: No such file or directory
27th July 2019, 03:42 PM |#543  
OP Senior Member
Thanks Meter: 5,673
 
More
Quote:
Originally Posted by sga999

I've been looking at the scripts for Magisk. It looks like get_flags invokes getvar for variables FORCEENCRYPT and FORCEVERITY (and more). gevar contains this line: VALUE=`grep_prop $VARNAME /sbin/.magisk/config /data/.magisk /cache/.magisk`

But only /data/.magisk seems "accessible" when installing Magisk during TWRP, so it seems like your zip file MUST place the .magisk file in /data in order for the subsequent Magisk install to see the overrides.

I haven't looked closely enough yet at your anykernel.sh. But there are some copies at line 167 that should copy from config to /data/.magisk, etc. But for some reason, those must not be happening for my device/rom. I'll keep learning more, but I thought this might give you a hint about what's going on.

EDIT: Just for a test, I added a line to copy the .magisk file at about line 165.
Added this: cp -f $home/config /data/.magisk
Before this elif [ "$ROOT" != "SuperSU" ]; then

It appears to work, but I haven't tested it much. You will probably want to add more lines, making it more like lines 167-172.

Things I don't know:
1. What is $home? Is it /sbin/.magisk?
2. It seemed like I couldn't access /sbin/.magisk/config and /cache/.magisk in TWRP, only /data/.magisk. See 2a. below. However, I know a config file was written there, so it must be accessible. I'm confused!.
3. In TWRP file manager or terminal, I can't see files/folders starting with a dot. Why is that?

2a. When I say files are not accessible, here's why I say that. While in TWRP, in adb shell, I issue:
sed -n /KEEPVERITY=/p /sbin/.magisk/config /data/.magisk /cache/.magisk

Here is the output from that. Only the middle one, /data/.magisk works.
sed: /sbin/.magisk/config: No such file or directory
KEEPVERITY=false
sed: /cache/.magisk: No such file or directory

Ya, I get where I messed up. So:
the .backup/.magisk file is mounted to /sbin/.magisk/config during boot so that's only accessible during bootmode (this is what I overlooked)
So I'll place it in data/.magisk but I'll still attempt to extract it from .backup since that's the one that magisk itself uses and has some extra vars (SHA1 and RECOVERYMODE)

$home is set at the top of update-binary of installer, it's just equal to the working directory (/tmp/anykernel)

any file or folder with a '.' in front of it is hidden

not all devices have a /cache partition but in that case, /cache should be a symlink to /data/cache
27th July 2019, 03:52 PM |#544  
OP Senior Member
Thanks Meter: 5,673
 
More
@sga999 Got a new test build here that'll always create the data or cache/.magisk file in addition to ramdisk one.

I'll need to look into supersu but at least with magisk, order of flashing no longer matters - you can flash magisk before or after this zip. It's actually preferred to flash magisk before this zip now
The Following 4 Users Say Thank You to Zackptg5 For This Useful Post: [ View ] Gift Zackptg5 Ad-Free
27th July 2019, 10:10 PM |#545  
Senior Member
Thanks Meter: 110
 
More
Quote:
Originally Posted by Zackptg5

@sga999 Got a new test build here that'll always create the data or cache/.magisk file in addition to ramdisk one.

I'll need to look into supersu but at least with magisk, order of flashing no longer matters - you can flash magisk before or after this zip. It's actually preferred to flash magisk before this zip now

Thanks, with minimal testing so far, this looks good.

About accessing files while in TWRP, thanks for explaining why I could not see /sbin/.magisk (or config). In my system, /cache is a symlink to /data/cache. But after flashing your zip, there is no .magisk file there. I am able to copy a .magisk file there myself, and the 'sed' command will work with /data/cache/.magisk, but not without /data in front. So it seems like Magisk could change its getvar() list of files to accommodate this, but that's another story! (Since /data/.magisk does work in the 'sed', that's good enough). Anyway, I thought I'd let you know that your zip does not seem to be putting .magisk in cache. Maybe because /data/cache is required for my system?

As you mentioned, I do see SHA1 in the config or .magisk file if your zip is flashed last (I do not see RECOVERYMODE). SHA1 does not appear when yours is flashed first. My preference is to have yours first because when Magisk is first, it shows that it is keeping dm-verity and forceencrypt. (I do know that that is not what will actually occur, but I'd rather not see that). Also, I had liked the idea that your zip was passing the .magisk file on to Magisk. So other than SHA1 not being there, is there any other reason that I should not flash your zip first?
27th July 2019, 10:13 PM |#546  
OP Senior Member
Thanks Meter: 5,673
 
More
Quote:
Originally Posted by sga999

Thanks, with minimal testing so far, this looks good.

About accessing files while in TWRP, thanks for explaining why I could not see /sbin/.magisk (or config). In my system, /cache is a symlink to /data/cache. But after flashing your zip, there is no .magisk file there. I am able to copy a .magisk file there myself, and the 'sed' command will work with /data/cache/.magisk, but not without /data in front. So it seems like Magisk could change its getvar() list of files to accommodate this, but that's another story! (Since /data/.magisk does work in the 'sed', that's good enough). Anyway, I thought I'd let you know that your zip does not seem to be putting .magisk in cache. Maybe because /data/cache is required for my system?

As you mentioned, I do see SHA1 in the config or .magisk file if your zip is flashed last (I do not see RECOVERYMODE). SHA1 does not appear when yours is flashed first. My preference is to have yours first because when Magisk is first, it shows that it is keeping dm-verity and forceencrypt. (I do know that that is not what will actually occur, but I'd rather not see that). Also, I had liked the idea that your zip was passing the .magisk file on to Magisk. So other than SHA1 not being there, is there any other reason that I should not flash your zip first?

So the zip will only create .magisk in cache if data isn't writable for some reason so in your case, it should be /data/.magisk (and in most other cases as well) - cache is more of a last resort kind of thing
The SHA1 is created by magisk itself and magisk only places that into the ramdisk copy (sbin) so everything you're seeing is expected. Seems like I finally got it right this time lol
27th July 2019, 10:22 PM |#547  
Senior Member
Thanks Meter: 110
 
More
Quote:
Originally Posted by Zackptg5

So the zip will only create .magisk in cache if data isn't writable for some reason so in your case, it should be /data/.magisk (and in most other cases as well) - cache is more of a last resort kind of thing
The SHA1 is created by magisk itself and magisk only places that into the ramdisk copy (sbin) so everything you're seeing is expected. Seems like I finally got it right this time lol

Since you said it was preferred to flash Magisk first, I was just wondering what the reasons are. Was it only a concern only for supersu?
27th July 2019, 10:46 PM |#548  
OP Senior Member
Thanks Meter: 5,673
 
More
Quote:
Originally Posted by sga999

Since you said it was preferred to flash Magisk first, I was just wondering what the reasons are. Was it only a concern only for supersu?

This is a new thing for magisk only. So magisk will create the .backup/.magisk file in ramdisk replacing what's already there. Then flash this zip and it'll modify it.

I was concerned originally that magisk did some extra stuff to remove that this zip didn't but I got that all figured out now
The Following User Says Thank You to Zackptg5 For This Useful Post: [ View ] Gift Zackptg5 Ad-Free
2nd August 2019, 09:59 AM |#549  
Senior Member
Thanks Meter: 40
 
More
Hi, does the newest trial version works with encrypted Official MIUI ROM?

I tried the zip in the OP on my Redmi Note 7 Pro and when the phone rebooted, there was an error msg saying 'the system has been destroyed', I had to dirty flash the ROM to fixed it.

My RN7 pro came encrypted by default and the TWRP can decrypt and mount the data partition just fine.

I'm trying to use your zip to prevent MIUI ROM replacing TWRP with stock recovery.

Thx.
3rd August 2019, 12:35 AM |#550  
OP Senior Member
Thanks Meter: 5,673
 
More
The new stable is finally here! It's the same as the last test build I posted. I updated the flashing instructions in the OP so be sure to check it out. Only change is:
Root should be flashed before this zip now due to how .magisk/.supersu files work. Flashing root after instead will still work fine too but .magisk file in ramdisk that magisk creates may not be correct
The Following 4 Users Say Thank You to Zackptg5 For This Useful Post: [ View ] Gift Zackptg5 Ad-Free
3rd August 2019, 12:39 AM |#551  
OP Senior Member
Thanks Meter: 5,673
 
More
Quote:
Originally Posted by ne0t

Hi, does the newest trial version works with encrypted Official MIUI ROM?

I tried the zip in the OP on my Redmi Note 7 Pro and when the phone rebooted, there was an error msg saying 'the system has been destroyed', I had to dirty flash the ROM to fixed it.

My RN7 pro came encrypted by default and the TWRP can decrypt and mount the data partition just fine.

I'm trying to use your zip to prevent MIUI ROM replacing TWRP with stock recovery.

Thx.

I have no idea, never messed with miui. Is your bootloader unlocked? Did you format data as described in the OP before flashing anything?
If all you want to is to prevent twrp from being overwritten, you can just delete /system/bin/install-recovery.sh

The only thing this zip could potentially change in system would be any fstabs in vendor/etc if the device doesn't have a separate vendor partition
Post Reply Subscribe to Thread

Tags
dm-verity disabler, force encryption disabler

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes