yashsingh1/xdaforums huggingface dataset:
[Magisk] V0latyle:
No...EAS = End of Active Service. It was my last day in the military, I had been on terminal leave for more than a month, and after 9 years in the military I didn't particularly care about adhering to grooming standards while I went to pick up my DD-214. For some reason the CO wanted to do an exit interview, and was rather offended that I hadn't taken the time to shave.
[Magisk] mrjuniork:
I could not agree more, though "any" should probably be explained more thoroughly (see below)

OT post counter: 0

OT posts left: 3

OT post counter (Magisk related): 1

OT posts left (Magisk related): 2

:geek:
[Magisk] noni2724:
thanks for amazing help guys. after some research i just turned off tap jack and i was able to install it.
[Magisk] pndwal:
But I disagree I'm afraid... The comment infers mods here are making exceptions, and that wouldn't be fair...

I have had OT removed by mods, and now make every effort to keep on topic... I also endeavour not to post trivia on its own, so if I do you'll notice that it's just an aside (in relation to the Magisk content)... I'm actually more carefutl than XDA staff themselves!... Just look at posts above. 😜

If my posts are not removed I hope it's because they're topical...

I don't think OT rules are intended to make XDA dull and sterile either... They're to prevent threads being hijacked for other purposes. And we see mods themselves joking / having fun with this without hijacking the topic...

I think mods allow all of us such latitude as long as we don't abuse it, and I try hard to keep my 'prolific' offerings informative, here giving General Support to Magisk users and furthering Discussion about its workings, functions etc...

If other users discuss aspects I'd never use or encounter, or even kid around / mention trivia here I have no issue with it if it's broadly in the spirit of Magisk General Support / Discussion, and I don't think mods generally do either because it takes the Dull out of XDA and is healthy for all of us...

Mods may be more proactive where OPs have specific wishes, but will generally act to prevent abuses and not show favouritism.

... Actually, I helped a mod here buy a small private island earlier this year; I thought I'd paid royally to spam and abuse him legitimately, but let me tell you I was SCAMMED! - no refunds!

https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-86673615

So anyone else who thinks they can get a special dispensation to violate rules here is a Fearless Daring Hothead Fool!

https://xdaforums.com/t/fvp-forum-violation-passes-now-available.4424853/post-86670993

Did I mention Magisk?... almost forgot! 😬 😁 P
[Magisk] pndwal:
It was pretty much the first search result (thanks Google!)... not as fun as others but. 😜

Wow... Fun times 'n discipline... Coulda bin a close shave I guess...

... Happy to interview you here regardless of your hair styles!

Oh dear, my OT count is rising...

Long Live Magisk Root! 😀 PW
[Magisk] V0latyle:
Thanks for the debug app tip. I'm on Stable 25.2 now, BASIC and DEVICE integrity both passing.

Oh, I forgot...People keep asking me why disabling verification and verity was necessary when flashing /vbmeta on the Pixel series prior to Magisk 23016. My understanding is Magisk didn't properly handle Boot Image Header v4, introduced with Android 12. The same thing is necessary when using most custom kernels - one must reflash /vbmeta with the arguments --disable-verity --disable-verification

A bit of background:

Prior to 23016, Magisk patched Android 12 boot images would not start. Bootloader would report failed to load/verify boot image. We found a workaround by disabling verity and verification. The odd thing is, if verity/verification had not been disabled before (normal flash of vbmeta) and data was not clean, system would bootloop into Rescue Party: Can't load Android system. Your data may be corrupt. To proceed, the user had to either perform a factory reset, or reflash an unpatched boot image (as well as /vbmeta without the arguments)

Any insight on this? Am I correct in this assessment, or can someone explain a little better why we needed to do this, and why it's still necessary with some custom kernels?
[Magisk] pndwal:
This fix in 23015?:

https://github.com/topjohnwu/Magisk/commit/632971af15de952f04356e138ab81654add6e10b

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

https://github.com/topjohnwu/Magisk/pull/5028

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 have been in vbmeta partition(s)...

Since recent magiskinit injection refactoring in 25.0+, AVB flags and keys / vbmeta have been left intact by default as stripping these is not needed for magiskinit injection by patching the original init... This means that custom kernels that require AVB stripping could no longer rely on Magisk to do this by default. PW
[Magisk] V0latyle:
So what would kernel developers need to change so this wouldn't be necessary? Custom vbmeta images containing AVB keys that match the kernel?

It's rather confusing because we all thought that unlocking the bootloader essentially disabled AVB, but it seems some checks are still performed?
[Magisk] pndwal:
@capntrips managed to get Kirisakura 2.4.0 (for Pixel 6 devices) to boot on SP2A.220405.004 with verity enabled using Magisk 24310 back in May by appending a hashtree footer to the vendor_dlkm image with:

avbtool add_hashtree_footer --image vendor_dlkm.img --partition_size 56066048 --partition_name vendor_dlkm --hash_algorithm sha256 --salt 51193cce3e801498112752099b294f47c816f97e383bf193c2397c49b51c5f3b --output_vbmeta_image temp.img --do_not_append_vbmeta_image

https://github.com/topjohnwu/Magisk/issues/5777#issuecomment-1126691707

I don't know if @Freak07 has found a better fix or used/improved on this method for his Kirisakura kernels since then... You or other Pixel users here may know. 😉 PW
[Magisk] V0latyle:
I've personally never used anything other than the stock kernel
[Magisk] capntrips:
Unlocking the bootloader allows hash errors, but fstab still defines a hashtree that fails to mount for custom kernels without a patched hashtree descriptor when verity or verification aren't disabled. The workaround above developed into Hashtree Patcher, which has been integrated with AK3, which Kirisakura and many other kernels use for installation.
[Magisk] V0latyle:
Makes sense, thank you for the explanation
[Magisk] badabing2003:
Here's an interesting observation, am not sure if it is good.

I was on Magisk Canary 25203

The Manager (which was not hidden) told me that there was an update to 25205, I decided to go for it.

then of course Magisk itself needed to be upgraded from 25203 to 25205

I chose direct install then rebooted.

Out of curiosity I wanted to see what changed on the boot.

So I dumped by boot partition (active slot being b)

adb shell "su -c 'dd if=/dev/block/bootdevice/by-name/boot_b of=/sdcard/Download/boot_b.img'"

Pulled it and did a binary diff to the previously created patched file with 25203

100% binary match.

Is that expected, if yes what exactly was changed that did not necessitate changes in the boot image? just Magisk Manager changes?

UPDATE:

Apologies for the false ALARM, my active slot was a not b

All is good with slot a
[Magisk] zgfg:
When you perform Direct Install (or just Patch), it prints the Magisk Target version number, was that 25203 or 25205

Also, upon you reboot, does Magisk app shows Magisk version 25203 or 25205

You can also execute with su:

magisk -c

It will print the Magisk version

And make sure that _b is really your active slot:

getprop ro.boot.slot_suffix
[Magisk] badabing2003:
My bad,

Active slot is a not b, I need new set of glasses :(

Apologies for the false alarm.
[Magisk] pndwal:
AVB is not disabled; it simply no longer supplies a verified green state... PW
[Magisk] J.Michael:
If you speak English, "unlocking the bootloader" means "the bootloader is unlocked and will no longer impose any restrictions on what it will load and boot".

If you speak Samsung, "unlocking the bootloader" means "we check a box that said the bootloader is unlocked, then we refuse to boot anything of which we do not approve." At least, if you have the misfortune to update your bootloader past version 3.
[Magisk] pndwal:
... At least they reversed decision that left cameras completely disabled w/ unlocked bootloader (because these are now used as elements for biometrics, eg iris scans, facial recognition, QR codes etc, with security implications)!... Or am I wrong?... 🤔 PW
[Magisk] Freak07:
The method that's described in the first quoted post is currently used on the pixel 6 devices, since magisk no longer removes all the avb checks from fstab. (all thanks to @capntrips for his work!)

For completeness sake:

There's another option I don't use on pixels, but another GKI device. Vendor_boot contains the ramdisk, the ramdisk contains the fstab now.

I can manually edit the ramdisk, strip the fstab of avb for vendor_dlkm and just ship that in the kernel.zip (as kernel.zips for a full GKI kernel include, zImage, dtbo, vendor_boot and vendor_dlkm).
[Magisk] 73sydney:
Yes thankfully that was kyboshed, i was especially focused on that because that was happening literally as i got this S20+ 5G (second hand) last year, and i have never owned an unrooted device (and never will)

On a side note...

Nice to see @Freak07 here, i got him beat on at least one aspect, i been a freak since 71 ...
[Magisk] V0latyle:
I only have one Samsung device, and it's a fairly low end tablet, but it does seem like everything works more or less like it should, even using LineageOS.

Samsung is perhaps one of the most obstinate OEMs in that they refuse to follow the AOSP model. Samsung devices still have a discrete recovery and no A/B slots so they're not capable of seamless OTA updates.
[Magisk] pndwal:
I believe in Android 13 launch version devices ramdisk is in vendor_boot (moved out of boot) for new GKI compatibility; are these the other devices you mean?

Magisk has made a number of changes to cope with A13 and GKI changes...

issue

Magisk rooted boot img result in error while booting on android 13 beta 2 #5819

that required disabling vbmeta verity was mentioned by John:

https://twitter.com/i/web/status/1525034917670756353

and fixed by

Extract vbmeta from footer …

Do not scan manually, extract properly from footer like libavb

For the latest Android 13 launch version devices w/ ramdisk in vendor_boot, Magisk will now manually add basic ramdisk to boot.img when patching for Magisk init injection:

Support GKIs without ramdisk

Notes:

I'm wondering whether you can preempt Magisk's boot ramdisk/cpio creation and use your own custom init to bypass the need for patching vendor_boot/fstab?... - I'm not clear on the need for that so I may be way off, especially if this method of Magiskinit injection doesn't already address the booting issues peculiar to your Kernel... If it does, a similar method could be useful pre Magisk installation... 🤔 PW
[Magisk] zgfg:
Btw, in the Magisk Alpha TG release thread vvb2060 (?) suggested (as translated):

>> For Pixel7 devices, please patch init_boot.img and flash the partition with the same name.
[Magisk] pndwal:
Correct... Except bootloader may also be reporting yellow or red states depending on user modifications...

Doubt this...

That's the point of hardware based keys used in the attestation and a hardware root of trust which contains these keys used for cryptographic functions and enables the secure boot process. It is inherently trusted, and secure by design.

Arm TrustZone technology provides the starting point to establish a hardware root of trust based on PSA guidelines. TrustZone technology within Cortex-A based application processors is commonly used to run trusted boot and trusted OS to create a Trusted Execution Environment (TEE), the use of which includes the protection of authentication mechanisms, cryptography, mobile device management, payment, key material, and digital rights management (DRM).

Verified Boot strives to ensure all executed code comes from a trusted source (usually device OEMs), rather than from an attacker or corruption. It establishes a full chain of trust, starting from a hardware-protected root of trust to the bootloader, to the boot partition and other verified partitions including system, vendor, and optionally oem partitions. During device boot up, each stage verifies the integrity and authenticity of the next stage before handing over execution.

VB from A4.4) typically starts with a read-only portion of the device firmware which loads code and executes it only after cryptographically verifying that the code is authentic and doesn't have any known security flaws...

In Android Verified Boot introduced w/ A8 (AVB is enhanced VB, or VB 2.0) the central data structure used in is the VBMeta struct. This data structure contains a number of descriptors (and other metadata) and all of this data is cryptographically signed. Descriptors are used for image hashes, image hashtree metadata, and so-called chained partitions. A simple example is the following:

where the vbmeta partition holds the hash for the boot partition in a hash descriptor. For the system and vendor partitions a hashtree follows the filesystem data and the vbmeta partition holds the root hash, salt, and offset of the hashtree in hashtree descriptors. Because the VBMeta struct in the vbmeta partition is cryptographically signed, the boot loader can check the signature and verify it was made by the owner of key0 (by e.g. embedding the public part of key0) and thereby trust the hashes used for boot, system, and vendor.

Tamper-evident storage must be used for stored rollback indexes, keys used for verification, device state (whether the device is LOCKED or UNLOCKED)

- https://source.android.com/docs/security/features/verifiedboot

- https://www.arm.com/technologies/trustzone-for-cortex-a

- https://android.googlesource.com/platform/external/avb/+/master/README.md

🤠 PW
[Magisk] V0latyle:
I am familiar with Verified Boot (dm-verity for example). I'm trying to better understand exactly how having the bootloader unlocked interferes with hardware integrity. So far, if I understand correctly, we've established the following with an unlocked bootloader:

Verified Boot still functions

Trusty still works (albeit probably isn't trustworthy anymore because software integrity cannot be guaranteed)

Keystore is still available

So these still function, and the only difference (I assume) is that bootloader is not in GREEN state, so how does this prevent hardware integrity? Assuming we could somehow mask or disguise the bootloader state itself, what else would indicate that software integrity cannot be guaranteed?

I promise I'm not trying to go around in circles on this...I'm just trying to find a relatively simple answer so that I accurately understand exactly why this is the case.

As far as Verified Boot goes...It would seem that exactly what is checked, and to what degree, is changed by unlocking the bootloader. For example: The only thing necessary to attain root on Pixel devices (or any other device using a similar partition layout) is patching the boot image. Vbmeta is not patched or changed, so a patched boot image hash would not match the signature stored in /vbmeta, yet the device still boots (aside from the prior problems we had with the image header and fstab), which means that the entire boot image isn't being checked. Or am I wrong in my assumption that /boot is checked against /vbmeta? We've established that the kernel itself is not modified - only ramdisk - but this is still contained in the boot image.
[Magisk] Zibri:
Hmm.. for testing I did this:

1) flashed original stock rom.

2) modified boot.img with two patches to allow me to gain root privileges.

3) did NOT flash anything, not even the modified boot.img.

Then booted my boot.img manually with fastboot boot myboot.img.

I also set in the image all props to nomarl locked props.

Now, when I run the attestation or play integrity api I still get only BASIC attestation.

If I set momentarily selinux to permissive and run the attestation again I gett all red.

If I reset selinux to enforcing I get BASIC.

An interesting read:

https://www.sstic.org/media/SSTIC2022/SSTIC-actes/droidguard_a_deep_dive_into_safetynet/SSTIC2022-Article-droidguard_a_deep_dive_into_safetynet-thomas.pdf

In other words:

as far as I understood, "the.apk" makes a number of checks and searches specifically for magisk, su and many more things.

But in MY system, which is the stock untouched rom, there are no modifications.

I wonder what changes when booting manually from fastboot.

(So I could hide that)

P.S.

For who is intersted I can tell you the original boot patches to be able to get full privileges in adb shell. I won't post it publicly, because...you know... the cat is reading us :D
[Magisk] zgfg:
It's not "APK" but the Play Integrity (PI) API built into the Google Play Services

You flashed from Fastboot - hence you DO HAVE modifications, you had to UNLOCK your BOOTLOADER and that's exactly one thing the PI API (and its predecessor SafetyNet) looks for

There are threads here on XDA:

- For Google Pay/Wallet

- Magisk module USNF (how to trick SN and PI)

and everything about PI and SN APIs were already discussed there in details, with links to the Google's official documentation how the APIs work, what they looks for, how they deliver verdicts are and how to trick them (and what cannot be tricked)

Otherwise, you don't only go back to stock ROM, Kernel, and Recovery you MUST also relock your Bootloader

And PI API (or its predecessor SN) does not look for su - it doesn't need. If you installed su/root, you must have had your BL unlocked and you must have had to modify (Boot partition also counts in, it's not limited to the pure System partition) your stock firmware - that's what Google looks for:

- unlocked Bootloader

- unmodified and certified stock firmware
[Magisk] Zibri:
Clearly you did not read the document I attached."the.apk" is an invisible application google play services (gms) downloads and executes to check the status of the device.

The guy wrote a document reversing everything.

About me:

my system is fully unmodified and certified stock firmware

the ONLY thing is the unlocked bootloader.

BUT I booted a different boot image and I put back the properties so that the status is green and everything looks fine.

I was not asking a newbie question as you thought.

I am just trying to have a minimal (next to zero) impact on the system and then try to cover the only track I left (the unlocked bootloader).

Please read the whole PDF I linked before answering next time.

Regards.
[Magisk] HippoMan:
I've been a freak since '52 ... and I always welcome youngster freaks into the freak ranks.
[Magisk] zgfg:
Fine. I did read the Google's original SafetyNet and Play Integrity APIs. I suggest you to read the official documentation as well:

Overview of the Play Integrity API | Google Play | Android Developers

developer.android.com

Because, that is actually the bible, not how me, you, or that guy who wrote your PDF interprets things

Unlocked Bootloader might be for somebody/you, but it is absolutely of NOT MINIMAL impact for Google - with the unlocked BL (and without spoofing it by Magisk and USNF), YOU CANNOT PASS DEVICE_INTEGRITY.

Fullstop

---

And if I misunderstood you, then sorry.

Even, if it makes you happy, no problem - you know things better, I'm just a foul and everything what I wrote above is wrong

Good Bye, I'm sorry but I'm not interested in this further discussion (hence I will no more answer).

I should not had answer you in the first place, it would have been better for you and me👍
[Magisk] m0han:
and i was thinking 73

wow! been to woodstock?
[Magisk] V0latyle:
As has been pointed out, since your bootloader is unlocked, HKA will always fail, meaning STRONG_INTEGRITY will always be unavailable, and without modification, DEVICE_INTEGRITY isn't either. This has been discussed ad nauseum - the simple fact that the bootloader is unlocked, even if everything else is untouched and OEM, means your device will not pass.
[Magisk] V0latyle:
So while it does appear that this package does exist:

it would appear that the assertion that this app specifically searches for Magisk is not true. I disabled DenyList, rebooted, and ran Play Integrity Checker (I have the modded USNF module):

While I don't doubt that other apps may specifically search for Magisk, I don't believe GMS does...
[Magisk] onimorza:
Thanks for this, but unfortunately it doesn't seem to hide it (anymore?) from Momo.

Same for @huskydg 's Magisk module Hide Userdebug which probably does about the same as it also sets the prop to stopped.

When I call the prop in terminal by getprop, the prop is indeed stopped, so both above techniques do their job, but Momo still detects USB debugging for both so maybe checks something else besides init.svc.adbd ?

Yes, I know, Momo will always detect something, but I'm a perfectionist and persistently keep trying :D
[Magisk] 73sydney:
You Sir, will surely send yourself slowly mad entertaining momos quirks and foibles. i removed it and freed up my OCD to concentrate on other things, like "did i leave the gas on?" every time i leave the house...which is quite something as i dont have a gas connection...
[Magisk] Qavra:
Hi, i would like to know why, whenever i install magisk (no matter if its a manual installation or with orange fox recovery) if i flash a zip or if i install a module, my phone (after rebooting) will work for a few minutes, then freezes for a minute or so and reboot, on loop. The only solution for this issue is to do a clean flash of my rom.. what can cause this ? And how can i prevent it ? the kernel's and recovery's logs are attached to this reply, as it might help troubleshooting that issue. (and no, changing kernel does not help in my case)
[Magisk] zgfg:
Phone, Android version, ROM.

What do you mean by manual installation.

Did you previously had Magisk and some modules and upgraded ROM

You provided no info whatsoever - how do you think anybody can help you?!
[Magisk] Prof_Shekhar:
I have recently run into an issue with my banking app after its recent update, wherein it is supposed to tie my banking app with my current device (running Lineage OS 19.1 with Magisk 25.2 and Zygisk -Hide my app list enabled for this banking app). Now every time I try and access this app, it causes the OS to crash immediately after displaying the app splash screen. No error message is being displayed.

This particular banking app is also on Magisk deny list and has been working on this device without any issues for the past one year.

I am unable to figure out if this issue is caused due to the app detecting the root or the custom ROM.

Device is able to pass all safety net checks.