yashsingh1/xdaforums huggingface dataset:
[Magisk] badabing2003:
Thanks for the suggestion, but that didn't help, not that I was very hopeful, mainly because the problem is on the phone and not in the communication between the phone and the PC, all adb commands work, even Reboot to bootloader from Magisk on the phone (no PC involved) reboots back to system.
[Magisk] pndwal:
To be clear, guessing you mean revoke and reset.(?)... PW
[Magisk] badabing2003:
I updated my original post with:
[Magisk] ctcx:
@badabing2003 @osm0sis :

I finally did more test, and the first thing: I was a double idiot, sorry again...

On Magisk 25.2 (25200), it DOES use the PATCHVBMETAFLAG, and it threw different images -SHA-256 wise- with or without the flag.

However, on Moto ocean and LOS 20 there's something "funny" that I still cannot totally understand: there's no vbmeta.img or the like within ROM's zip itself, but there ARE vbmeta_{a,b} inside /dev/block/by-name when checking with adb shell...

So due to this app UI always patches with PATCHVBMETAFLAG=false

Another thing I tried again was patching the PixelFlasher way: through script, just like already tested. But this time I tried adding a line to boot_patch.sh beforehand:

Magisk/scripts/boot_patch.sh at master · topjohnwu/Magisk

The Magic Mask for Android. Contribute to topjohnwu/Magisk development by creating an account on GitHub.

github.com

Right under commented line "# Flags:" I added "get_flags", and right next echoing the flags values.

With this, I ran the script this time without manually exporting any flags beforehand.

Result: identical image to the one patched with app UI.

Also, displayed values of the flags all coincided with what I had manually set in the previous tests.

So I think I confirmed it: would be good idea to make that small change to script, albeit making it run the get_flags function only when running "manually" from command line, and not when running through app UI like normal.

I think this could even help PixelFlasher to increase compatibility with devices even more?

Thanks again.
[Magisk] pndwal:
I have no real experience with alternative use of util_functions.sh script etc, but re. need for vbmeta patching, and new instructions in Installation Instruction page, the major changes were:

Disabling verification and verity had been necessary on many Pixel devices as Magisk didn't properly handle Boot Image Header v4 introduced with Android 12, but this was fixed in 23015:

Properly support v4 image headers

topjohnwu committed on Nov 22, 2021

This fix in 23017 also addressed A12 compatibility (A12 had failed to pass the vbmeta verification of the bootloader after modifying the unlocked boot partition.):

Support PATCHVBMETAFLAG env variable

vvb2060 authored and topjohnwu committed on Jan 12, 2022

... but Magisk still stripped avb_key and avb flags for 2SI devices (ie. running A10+ unless launched with A9) till 24.3 in order to patch fstab. [My understanding is that since A9/AVB 2.0, these keys/flags have been in new seperate vbmeta partition(s)... Always??]...

This changed with major magiskinit injection refactoring in 24302+, ie:

Use /data as tmpfs mount point in 2SI setup …

Design credit to @yujincheng08 Close #5146. Fix #5491, fix #3752 Previously, Magisk changes the mount point from /system to /system_root by patching fstab to prevent the original init from changing root. The reason why we want to prevent the original init from switching the root directory is because it will then be read-only, making patching and injecting magiskinit into the boot chain difficult. This commit (ab)uses the fact that the /data folder will never be part of early mount (because it is handled very late in the boot by vold), so that we can use it as the mount point of tmpfs to store files. Some advantages of this method: - No need to switch root manually - No need to modify fstab, which significantly improves compatibility e.g. avoid hacks for weird devices like those using oplus.fstab, and avoid hacking init to bypass fstab in device trees - Supports skip_mount.cfg - Support DSU

topjohnwu committed on Mar 13, 2022

Current method:

Previous method:

Details doc

Now AVB flags and keys / vbmeta are left intact by default as stripping these is not needed with new original-init patching for magiskinit injection.

This means that custom kernels that require AVB stripping can no longer rely on Magisk to do this by default... Solutions for kernels like Kirisakura have since been found [see https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-87562127 and https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-87562165 ] but this is one case where the now optional patching of a separate vbmeta partition [command:

fastboot flash vbmeta --disable-verity --disable-verification vbmeta.img (note that it may wipe your data)] may be needed/useful. There will be others...

👀 PW
[Magisk] badabing2003:
There is no need to make a change to the original script.

I did a test, wrote this simple wrapper script: pf_root.sh

. ./util_functions.sh
get_flags
echo SYSTEM_ROOT=$SYSTEM_ROOT
echo KEEPVERITY=$KEEPVERITY
echo KEEPFORCEENCRYPT=$KEEPFORCEENCRYPT
echo RECOVERYMODE=$RECOVERYMODE

if [ $1 ]
then
echo "Creating a patch ..."
./magiskboot cleanup
./boot_patch.sh $1
fi

Which basically sources the util_functions and calls the get_flags, and displays the flags, optionally if a boot file is passed, it patches it.

I ran the script on 3 different devices.

Here's the output

marlin:/data/adb/magisk # ./pf_root.sh
- System-as-root, keep dm/avb-verity
- Encrypted data, keep forceencrypt
- No vbmeta partition, patch vbmeta in boot image
SYSTEM_ROOT=
KEEPVERITY=true
KEEPFORCEENCRYPT=true
RECOVERYMODE=false

redfin:/data/adb/magisk # ./pf_root.sh
- System-as-root, keep dm/avb-verity
- Encrypted data, keep forceencrypt
SYSTEM_ROOT=
KEEPVERITY=true
KEEPFORCEENCRYPT=true
RECOVERYMODE=false

OnePlus5:/data/adb/magisk # ./pf_root.sh
- System-as-root, keep dm/avb-verity
- Encrypted data, keep forceencrypt
- No vbmeta partition, patch vbmeta in boot image
SYSTEM_ROOT=
KEEPVERITY=true
KEEPFORCEENCRYPT=true
RECOVERYMODE=false

What I fail to understand is the SYSTEM_ROOT

In util_functions, it says the get_flags() function sets the following variables:

KEEPVERITY, KEEPFORCEENCRYPT, RECOVERYMODE, PATCHVBMETAFLAG, ISENCRYPTED, VBMETAEXIST

So I don't expect SYSTEM_ROOT to be set.

# After calling this method, the following variables will be set:
# KEEPVERITY, KEEPFORCEENCRYPT, RECOVERYMODE, PATCHVBMETAFLAG,
# ISENCRYPTED, VBMETAEXIST
get_flags() {
getvar KEEPVERITY
getvar KEEPFORCEENCRYPT
getvar RECOVERYMODE
getvar PATCHVBMETAFLAG
if [ -z $KEEPVERITY ]; then
if $SYSTEM_ROOT; then
KEEPVERITY=true
ui_print "- System-as-root, keep dm/avb-verity"
else
KEEPVERITY=false
fi
fi
...

However, the code will only set the KEEPVERITY and output the line System-as-root, keep dm/avb-verity if SYSTEM_ROOT is set.

So how is it not set, and yet outputting that line.

If I create a patch without explicitly setting SYSTEM_ROOT, the patch is not identical to what the UI would produce because the SYSTEM_ROOT is not set.

This brings me back to my previous post.

With Magisk 25 SYSTEM_ROOT passing option was not available, with Magisk 26 it is, and if it is not set to True, then the patch_boot generated patches don't match UI generated ones (on modern devices).

If set, then they do.

Checking the patch_boot.sh code, the only place SYSTEM_ROOT is used is for Legacy SAR, so why does it need to be set?

I get it, as @pndwal clearly explained, that 2SI devices are SAR, but the code below (at least the comment) suggests that Kernel needs to be patched only for legacy SAR devices.

# Force kernel to load rootfs for legacy SAR devices
# skip_initramfs -> want_initramfs
$SYSTEM_ROOT && ./magiskboot hexpatch kernel \
736B69705F696E697472616D667300 \
77616E745F696E697472616D667300 \
&& PATCHEDKERNEL=true

To summarize, @ctcx your suggested approach of using get_flags is good for all the flags except SYSTEM_ROOT, questions still need to be answered about SYSTEM_ROOT.
[Magisk] pndwal:
Only taken a cursory glance here (and much is beyond me), but my guess is that this be because kernel never loads initramfs as initial rootdir for Legacy SAR; it directly mounts system, not rootfs... Android is already using rootfs as initial rootdir for both Legacy ramdisk and 2SI ramdisk SAR device types... 😬 🙃 PW
[Magisk] pndwal:
Did a bit more digging today, and it seems fairly certain that vv / Rikka are using the same Google model they used in their Key Attestation app in Momo... I don't know of banks doing this yet, but it seems Momo 4.4.1 Bootloader unlocked verdict is arrived at by extrapolating key descriptions from the extension data of key pairs available to any app...

This means (after a cursory look at it) that any app can gain strong attestation to the true boot-state of a device.

These key pairs are generated in response to a call (attestationChallenge) from an app directly, and are unrelated to calls made by the gms droidguard VM for Google API device integrity APIs in behalf of such apps...

From what I can gather, true Bootloader Lock and verification status can always be obtained from a RootOfTrust field including Verified, Unverified, SelfSigned and Failed.

Further, most manufacturers will include device identifiers in keymaster 3+ hardware, and with READ_PRECISE_PHONE_STATE permission apps can obtain a more sensitive ID attestation including serial number or IMEI...

https://source.android.com/docs/sec...des optional support,as serial number or IMEI.

Anyway, it seems it may be virtually impossible to thwart banks attempts to detect tampering of verifiable Android (boot state) if they use this, or to obtain a completely happy Momo, but we can get close... More in next post.

🤠 PW
[Magisk] ctcx:
@badabing2003 :

Thanks yet again for all your input and tests.

And yes, I knew about the lacking of info about SYSTEM_ROOT; the truth is I was testing just on 25.2 (25200) for now, because I still feel it's the most "stable" as for now. In this version, IIRC, we already discussed that SYSTEM_ROOT was seemingly not used at all, while in 26.x it was introduced.

And regarding this already "(in)famous" flag, I just tried taking another quick look at util_functions.sh -I'm not at home right now...-, and I'd think what sets the flag could be this function. So probably we'd need to borrow some things from it as well...
[Magisk] pndwal:
Ran out of patience after 2 months, and decided to test the Native Bridge based Zygisk loading POC that is Alpha (unofficial) Magisk with new Shamiko for Native Bridge injection hiding... Results look promising 😀:

Native Detector:

Memory Detector:

Momo:

Livin' by Mandiri:

😋 👍 PW
[Magisk] promeneur:
Hello

Samsung S7

lineage-19.1-20230412-UNOFFICIAL-herolte.zip

Magisk 2.6.1

installation with twrp "install" with Magisk-v26.1.zip

there is no menu button, no "safetynet " button

thanks for your help
[Magisk] badabing2003:
Yes, I saw that, and then checked, it's not called when calling get_flags() nor when running patch_boot.sh, so I'm not sure how that line is displayed, looking at the code I just don't see it, I need my rubber ducky ;)
[Magisk] badabing2003:
@ctcx This code would take care of SYSTEM_ROOT, and the generated code matches the one from UI (Except RANDOMSEED, which is expected)

But I hate the fact that I don't understand why I have to do this.

pf_root.sh

#!/system/bin/sh
. ./util_functions.sh
echo Getting flags, please be patient ...
get_flags > /data/local/tmp/pf_output.txt 2>&1
cat /data/local/tmp/pf_output.txt
if cat /data/local/tmp/pf_output.txt | grep -q "System-as-root, keep dm/avb-verity"; then
SYSTEM_ROOT=true
fi
echo
echo Flags are set to:
echo SYSTEM_ROOT=$SYSTEM_ROOT
echo KEEPVERITY=$KEEPVERITY
echo KEEPFORCEENCRYPT=$KEEPFORCEENCRYPT
echo RECOVERYMODE=$RECOVERYMODE
echo PATCHVBMETAFLAG=$PATCHVBMETAFLAG
echo ISENCRYPTED=$ISENCRYPTED
echo VBMETAEXIST=$VBMETAEXIST
export KEEPVERITY KEEPFORCEENCRYPT RECOVERYMODE PATCHVBMETAFLAG ISENCRYPTED VBMETAEXIST SYSTEM_ROOT

if [ $1 ]
then
echo "Creating a patch ..."
./magiskboot cleanup
./boot_patch.sh $1
fi
[Magisk] cruser01:
Hi guys, may I know why my bluestacks' magisk always told me to reboot when I tried to enable Zygisk? Even though I have rebooted my bluestacks many times already, but no progress
[Magisk] badabing2003:
@ctcx

You had previously asked why you needed to include magisk32 for 64 bit device.

Check the ro.zygote prop, see if it is zygote64 or icode]zygote64_32[/icode]

On Pixel 7 Pro, which is a 64 bit only device zygote64, With Magisk 25206, when you create a patch from ui, magisk32 is not included.
[Magisk] Zotac101:
Are you using a custom rom or stock rom ?

If you are using a custom rom how did you manage to hide that?
[Magisk] pndwal:
Xiaomi RN8T, A11 stock MIUI

Someone else may have a method to hide custom ROM from Momo... I haven't tried 😜 PW
[Magisk] ctcx:
Thanks sir, I'll try.

Meanwhile, regarding the everlasting SYSTEM_ROOT issue, I think I may finally have reached a conclusion.

I think the issue is in this line.

I did many more -though possibly redundant- tests, but eventually I had to search for information about Bash and shells in general.

To get right to the point, either in adb shell and/or a Linux box, try running this:

if $hell_joe; then echo yes; else echo no; fi

Seemingly, the behavior of the shell is something like, if "command" inside the "if" turns into just an empty string -an empty command-, for some reason the "if" will always take it as an exit status of 0 "success".

Though, not such if you quote the variable.

Also, another story is if the variable is being used as replacement for booleans; this is, either just "true" or "false", in which case the if works as expected.
[Magisk] gsmdb:
I've a second approach

Modify the boot_patch in stead since it lacks export the system_root flag in sections

# Flags

[ -z $KEEPVERITY ] && KEEPVERITY=false

[ -z $KEEPFORCEENCRYPT ] && KEEPFORCEENCRYPT=false

[ -z $PATCHVBMETAFLAG ] && PATCHVBMETAFLAG=false

[ -z $RECOVERYMODE ] && RECOVERYMODE=false

[ -z $SYSTEM_ROOT ] && SYSTEM_ROOT=false <--- Extra line

export KEEPVERITY

export KEEPFORCEENCRYPT

export PATCHVBMETAFLAG

export SYSTEM_ROOT <--- Extra line

# Compress to save precious ramdisk space

. . .

echo "KEEPVERITY=$KEEPVERITY" > config

echo "KEEPFORCEENCRYPT=$KEEPFORCEENCRYPT" >> config

echo "PATCHVBMETAFLAG=$PATCHVBMETAFLAG" >> config

echo "RECOVERYMODE=$RECOVERYMODE" >> config

echo "SYSTEM_ROOT=$SYSTEM_ROOT" >> config <--- Extra line
[Magisk] badabing2003:
This extra line is already in version 26, though not the others

[ -z $SYSTEM_ROOT ] && SYSTEM_ROOT=false <--- Extra line

As for the 3rd extra line, it would be moot, because the app never checks for SYSTEM_ROOT from the config file. (MagiskInstaller.kt)

val cmds = arrayOf(
"cd $installDir",
"KEEPFORCEENCRYPT=${Config.keepEnc} " +
"KEEPVERITY=${Config.keepVerity} " +
"PATCHVBMETAFLAG=${Config.patchVbmeta} " +
"RECOVERYMODE=${Config.recovery} " +
"SYSTEM_ROOT=${Info.isSAR} " +
"sh boot_patch.sh $srcBoot")

But the main point is that in the get_flags function, no matter what, it evaluates to true.

Here's a test I did to see when it would evaluate to false (never) (tried various inputes)

Which makes the code buggy.

#!/system/bin/sh
get_flags() {
if $VARIABLE; then
echo "[$VARIABLE] true"
else
echo "[$VARIABLE] true"
fi
echo
}

echo "Test: initial"
get_flags

echo "Test: unset VARIABLE"
unset VARIABLE
get_flags

echo "Test: empty string"
VARIABLE=""
get_flags

echo "Test: nothing"
VARIABLE=
get_flags

echo "Test: 0"
VARIABLE=0
get_flags

echo "Test: 1"
VARIABLE=1
get_flags

echo "Test: 0 string"
VARIABLE="0"
get_flags

echo "Test: 1 string"
VARIABLE="1"
get_flags

echo "Test: true"
VARIABLE=true
get_flags

echo "Test: false"
VARIABLE=false
get_flags

echo "Test: string true"
VARIABLE="true"
get_flags

echo "Test: string false"
VARIABLE="false"
get_flags

And here's the result.

marlin:/data/local/tmp # ./test.sh
Test: initial
[] true

Test: unset SYSTEM_ROOT
[] true

Test: empty string
[] true

Test: nothing
[] true

Test: 0
./test.sh[21]: 0: inaccessible or not found
[0] true

Test: 1
./test.sh[25]: 1: inaccessible or not found
[1] true

Test: 0 string
./test.sh[29]: 0: inaccessible or not found
[0] true

Test: 1 string
./test.sh[33]: 1: inaccessible or not found
[1] true

Test: true
[true] true

Test: false
[false] true

Test: string true
[true] true

Test: string false
[false] true

The second true after the brackets [] is the evaluation.
[Magisk] ctcx:
@badabing2003 :

In my previous post I already tried explaining what's happening with a construct like "if $no_variable; then ..."

In the shell, assuming the variable is indeed empty/non-existent, this construct will always return "true".

So if author actually intended to evaluate something with that line I mentioned in my previous post, then indeed it'd probably make the code buggy...

And the closest thing to correctly evaluate $SYSTEM_ROOT would be the mount_partitions() function, which is why I said probably we should borrow some stuff from there for additional code

By the way, in your test above, didn't you actually mean

else
echo "[$VARIABLE] false"
fi

by chance?

Thanks.
[Magisk] ctcx:
Just tried.

The device I have is "zygote64_32", so based on this indeed I have to include magisk32.

Thanks again.

So, yet another test which should be included in additional code?

And just in case, to clarify, I'm not thinking that whole 26.x releases are completely buggy; if that were the case there would be numerous complains already.

The whole thing is, I think, the app UI works just well, but the scripting way is not due to all the discussed stuff here during last days. The point would be make the scripting way to properly work as well.
[Magisk] badabing2003:
Absolutely right, I saws your post, and based on that I ran the test, but silly me, with copy and paste error, I didn't realize that I was displaying true in both cases, and was questioning the value of the test.

After fixing that, this is what I get.

Test: initial
[] true

Test: unset VARIABLE
[] true

Test: empty string
[] true

Test: nothing
[] true

Test: 0
./test5.sh[28]: 0: inaccessible or not found
[0] false

Test: 1
./test5.sh[32]: 1: inaccessible or not found
[1] false

Test: 0 string
./test5.sh[36]: 0: inaccessible or not found
[0] false

Test: 1 string
./test5.sh[40]: 1: inaccessible or not found
[1] false

Test: true
[true] true

Test: false
[false] false

Test: string true
[true] true

Test: string false
[false] false

which I think is as you stated not correct, for empty string or null, it should not return true

But changing the test to this, works

get_flags() {
if [ $VARIABLE ]; then
echo "[$VARIABLE] true"
else
echo "[$VARIABLE] false"
fi
echo
}

Test: initial
[] false

Test: unset VARIABLE
[] false

Test: empty string
[] false

Test: nothing
[] false

Test: 0
[0] true

Test: 1
[1] true

Test: 0 string
[0] true

Test: 1 string
[1] true

Test: true
[true] true

Test: false
[false] true

Test: string true
[true] true

Test: string false
[false] true

Basically, any value and it returns true, empty string or null or being unset returns false.

Yep.

I added that to PF. I think 25.2 was always adding Magisk32 (have to confirm)

I don't think it hurts to include, but we want to mimic the App.

I agree.

And the UI is actually calling patch_boot script, so we just have to get the proper flags, and the questionable one is the SYSTEM_ROOT.
[Magisk] HippoMan:
That indeed works. I just tend to prefer to let the shell tell me directly whether the variable is set and has a value, via the -n "${VARIABLE:-}" syntax, as follows:

if [ -n "${VARIABLE:-}" ]
then
echo "[${VARIABLE:-}] true"
else
echo "[${VARIABLE:-}] false"
fi
echo

I also like the more modern double-bracket syntax on the "if" statement ...

if [[ -n "${VARIABLE:-}" ]]

... although the single-bracket syntax still works fine.
[Magisk] sab009:
my tablet was rooted and I got magisk 24 installed via custom recovery method. (Custom recovery = TWRP)

after updating to magisk v.26 I could install it via custom recovery but it didn't get installed in the app and i didn't have root access.

I found out that after magisk v.26 custom recovery method isn't completed (according to release notes) and I should install it through patching the boot method.

the problem is that I can't boot the tablet into FASTBOOT mode because it's only got Odin mode ( or Download mode ).

I can't flash the .img file via Odin.

in installation instruction section, the Samsung method isn't helpful because my rom is Lineage OS and it's got boot.img file, not AP tar file.

then I decided to install magisk v.25 via custom recovery but the result was like before.

Please help me

Samsung Galaxy note 10.1 ( GT-N8000 )

Lineage OS 16.0 ( Android 9 )

Ramdisk = yes

vbmeta partition = does NOT have
[Magisk] badabing2003:
Patch the boot file from Lineage, then create a tar file boot.tar, the contents boot.img (the patched boot) should only be at the root level.

You can then use odin to flash as AP

It's possible that you might need a patched odin (not sure) so that the device does not complain, but perhaps with lineage, it shouldn't matter.

If the tablet boots to recovery instead of system, then wipe the cache partition.

PS: This is not a Magisk issue, so you might get a better mileage posting something like this in Samsung related forums.
[Magisk] sab009:
I've done two different things before.

1. first I patched boot.img in the magisk app. then I created a tar file ( converted the patched boot.img to tar file ).

uploaded the tar file in Odin ( as AP ) and started to flash the file but it stuck in the middle of the flashing.

2. first I converted the boot.img to boot.tar and then patched the tar file in the magisk app.

uploaded it in Odin and the flashing was successful but I didn't have root access in the app. ( wifi didn't work and I flashed the rom again )

in the previous versions of magisk I used to do the custom recovery method and it was Ok but after version 26 it doesn't work. is it related to magisk issues?
[Magisk] ctcx:
In the end, can something be done regarding this SYSTEM_ROOT flag?

I already tried searching and reading about the whole system-as-root (SAR) topic, but I still need far more exercise to get a grip of it in general...

Still I'm not being able to conceptually understand what it is about.

And from Magisk's point of view, what do they call "SYSTEM_ROOT"? When device is legacy SAR, or the new one? Or any of both?

Could some of the lines within mount_partitions() function inside util_functions.sh be reliable to successfully test the flag for a given device?

Wish @osm0sis could help a bit...

Thanks again.
[Magisk] osm0sis:
GitHub and Chrome have a search function...

Magisk/app/src/main/res/raw/manager.sh at master · topjohnwu/Magisk

The Magic Mask for Android. Contribute to topjohnwu/Magisk development by creating an account on GitHub.

github.com

Magisk/scripts/util_functions.sh at master · topjohnwu/Magisk

The Magic Mask for Android. Contribute to topjohnwu/Magisk development by creating an account on GitHub.

github.com
[Magisk] n.p.:
I have a rather prickly (in terms of Magisk) device (Bluboo Maya Max phone with a custom Android 6 ROM that I found on this site). The last few releases, the "Direct Install" update method simply did not work (after rebooting, Magisk still showed the old version and asked me to complete the upgrade), so I had to patch the stock boot file. This worked fine through 25.2. For 26.1, however, after flashing the patched boot image, I ended up in the longest bootloop I have every seen. After an extreme amount of time on the splash screen, the device would go through "Preparing packages" (as if I installed an OS update), and then, immediately upon finishing (several more minutes later), would immediately reboot and repeat the entire sequence over and over again. Fortunately, I had saved the boot image patched with 25.2, which (after flashing) returned the device to its previous working state.

Any ideas on fixing / troubleshooting this? Not an expert by any means, but I do have access to someone with a reasonable amount of competence in this area. :)