yashsingh1/xdaforums huggingface dataset:
[Magisk] HippoMan:
Actually, that is perfectly fit for my own daily use, and I doubt that I'm the only person who has this preference.

I want to be able to turn permissive mode on and off as part of my own ROM usage, depending upon the tasks I want to perform and the software I wish to run. In the past, I was able to do this in one or more ROMs, and there was nothing half-baked about my user experience.

I'm willing to take the associated risks, and I don't want to be paternally "protected" against those things against my will. Again, I'm sure I'm not the only Android user who feels this way.
[Magisk] pndwal:
What about debloated stock?... Plenty of guides for that... PW
[Magisk] pndwal:
But it's NOT a preference! ... It's a fact!

... I know you're no noob, but you may be developing a knack for confusing issues mate! 😜

FWIW, John's technical explanation on Reddit: SELinux Permissive ROMs/Kernels are VERY BAD

Spoiler content hidden.

So you're talking about something completely different!

www.youtube.com/watch?v=K2P86C-1x3o

... That's NOT a permissive ROM!... That's likely a perfectly stable SE enforcing ROM that you choose to disable 'enhanced security' on... And that's your business...

Like the ROM discussed here, many find the simply cannot switch a permissive ROM to SE enforcing w/o breaking stuff... cos it's still half baked/not properly implemented... BUT permissive just breaks security in exchange for accessing ROM functions that simply won't work as they should...

... Bit like the builder in such a rush to list a house on the market that he hasn't fixed the doors that jam on their jambs... So he says "oh well... Who needs doors?"... And then someone buys it!... And they think "what a bargain!"... And they sleep soundly... Cos they got a bargain... Who needs doors, right? 😝

However here's something more those switching even stable enforcing ROMs to permissive might want to to consider:

https://www.xda-developers.com/permissive-selinux-dangers-exploits/

Sure you're not... Point is, You don't need a permissive ROM to do that...

And of course ROM/Kernel Devs do that all the time to test fixes (you'll appreciate @arter97's response to this

www.twitter.com/topjohnwu/status/1194574073017167877

if you know who he is...), but it's actually far more likely that switching between modes will simply work on an enforcing ROM...

Thing is, it may be fine to leave your doors open while you're home and awake... But would you be happy with no doors when you go out or Sleep? 😲 ... And really, any builder should put doors on houses he builds... unless it's for the Korowai people of West Papua... or in a gated hippie commune... PW
[Magisk] HippoMan:
Yes, I did confuse the issue. I misread the previous discussion and incorrectly came to the conclusion that it wasn't talking about SE enforcing ROMs per se, but rather, simply the ability to disable SE.

I stand corrected.

As for my actual domicile, I indeed prefer to have doors and windows that can be closed ... and I'm the one who makes the decisions as to when I open or close them.

Likewise, when it comes to my Android device, I want to be the one who can decide when to open and close the doors and windows, and I'm glad and willing to take responsibility for any adverse consequences which might ensue due to faulty judgment.

And in any case, I'm generally more similar to an outdoor camping enthusiast when it comes to my device's security.
[Magisk] pndwal:
... So you do prefer an enforcing ROM. 👍 (Of course only permissive ROMs = house sold with no doors in openings, or at least no back door; generally they simply can't run enforcing, at least without breaking important functions...)

Sure... You want a secure ROM that can be un-securred...

My case too!... But I still want a house that hasn't been trashed to return to when I'm done camping! 😜 PW
[Magisk] HippoMan:
I don't mind an enforcing ROM as long as I can turn off the enforcement whenever I want to, and as long it doesn't prevent me from doing the things I want with my device, and as long as I don't have to jump through crazy, convoluted, headache-producing hoops in order to do any of those things. My current enforcing ROM is OK in these regards.

However, I probably wouldn't mind a non-enforcing ROM, either.
[Magisk] pndwal:
Just need to understand that properly implemented ROMs, ie. enforcing, can generally be switched w/ no dramas (for those happy to take the risks)... 'non-enforcing' (permissive) ROMs are the ones you'll generally have issues with;

they're inherently buggy for starters, and either won't boot w/ enforcing or critical functions will fail... You're usually stuck with permissive (read House with no doors) I'm afraid!...

That's because they are 'experimental, insecure, half-baked and not fit for daily use' as I originally said, and they've generally been set to permissive simply to allow broken stuff to function...

There's really no other good reason for a dev to set permissive... And as experts like John are pointing out, doing this simply to release ROMs is NOT good enough... It may be considered "really bad", "LITERALLY BACKDOORING YOUR USERS!", "dubious", "just shooting at your own foot", "nuking a SIGNIFICANT portion of modern Android's security"...

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

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

🙃 PW
[Magisk] HippoMan:
Back in the Stone Age, ROMs for Android were released in SE permissive mode. At some point, that changed, and now, the default is to release the ROMs in SE enforcing mode. I never had any problems with those earlier ROMs that were released in permissive mode.

But perhaps with all the changes in Android since those antediluvian days, SE permissive ROMs might now cause failures.

As for me, running a ROM on my device in which "a SIGNIFICANT portion of modern Android's security" has been nuked actually might be a blessing. Of course, that would not be the case if, as you mention, it's not possible in such ROMs to turn SE enforcing ON when desired. In that case, I agree with you that such a ROM would not be desirable.

In other words, if a permissive ROM wouldn't let me change SE to "enforcing" when I choose to do it, then such a ROM would be a "no no" for me. Otherwise, I'm open for such a ROM.

PS: Every linux OS I've ever run on my rooted desktop machine has never had SE enabled. By "rooted", I mean that the "sudo" command and other similar facilities are readily available on my linux box. I'd be perfectly happy for my Android device to have no more built-in security than my desktop box, and for me to be the one to manage the security protocols on these systems.
[Magisk] pndwal:
Many changes/challenges... Originally no AVB or even locked bootloaders, no SafetyNet, Play Protect, Play Integrity checks either, no Widevine DRM, etc etc... An age where we could leave our houses unlocked and our grandma's would sleep on the porch all night when the weather was to hot...

... Well I think you're still refusing to register what I've been trying to tell you (although you may have gotten it subconsciously by now)...

It may be a technicality, but it's an important concept to grasp: SE permissive ROMs don't cause failures (unless by that you mean 'trip device integrity/security detections)... It's the failure of code to run w/ enforcing set that causes Devs to release ROMs set to permissive! ... and such ROMs do this simply because fixing the code either to hard, the ROM is just an amateurish port, or the Dev doesn't care...

These days all Android code is supposed to run with SE enforcing... ROMs aren't meeting protocol (defined clearly/extensively in Google CDD, VSR, VTS and CTS documents) if they don't... In fact you may no longer be able to set permissive on stock ROMs for that reason:

https://source.android.com/docs/security/features/selinux/validate#switching_to_permissive

From the above it is also evident that permissive now breaks ctsProfileMatch at least without spoofing...

So I've been trying to tell you that ability to switch should NOT be your primary concern!... While that may well be possible with some custom permissive ROMs you'll be very lucky to find a ROM set to permissive that doesn't break important functions when set to enforcing!...

Isn't having a stable, functional ROM more important,

especially when you can easily set an enforcing

(read stable, fully baked ROM with doors, oiled hinges and well aligned locks)

custom ROM to permissive

if you are bent on doing so?!!

What you want to do doesn't change the fact that custom ROM Devs should NOT be releasing permissive ROMs in the first place...

I can't sum this up better than Bob, even if you may think he's from an antediluvian era:

😜 PW
[Magisk] meric57:
Hello, concern with magisk writing in flash memory remains blocked on copyring: systeme.img.lz4.

Do you know the reason for this blocking thank you

modification of the ap for root my s10 firmware A12 G973FOXMGHWA3

solved
[Magisk] HippoMan:
Yes, that's what I meant, and you stated it more clearly than I did when you wrote, "unless by that you mean 'trip device integrity/security detections'". This clarifying distinction doesn't change my point in the least.

Yep, the fact that these times have been a-changin' (Android-wise) is why I prefer to use an older, post-diluvian-but-still-pre-cutting-edge version of Android (A11) with TWRP and with a very pleasingly antiquated version of Magisk (v23.0). And I wouldn't have minded in the least if my ROM happened to have been shipped with permissive SE. In that case, I would accomodate.

The "evolution" of Android's security model and of some of the characteristics of many Android apps and utilities is no more desirable for me than the "evolution" of a number of other trends that is currently taking place in our "modern" world.
[Magisk] meric57:
Hello, LSPosed-v1.8.6-6712-zygisk-release why is there a problem in magisk. error restarts then magisk apk jumps must reflash with odin, is it mandatory to install this module or not if it works with the main ones from magisk.
[Magisk] martyfender:
? There is a big problem with your translation.
[Magisk] huskydg:
Your question is not clear
[Magisk] J.Michael:
Explain "error restarts"

Explain "magisk apk jumps"

Explain "it works"

Use separate sentences.

You do not "flash" apk with Odin.

If Magisk app is disappearing: search carefully full app drawer -- maybe app was renamed. If app has really been uninstalled, try to post log file. (Search for @Didgeridoohan HOW-TO)
[Magisk] huskydg:
(Maybe off-topic) Now we have an app that detect bootloader unlocked :v

[Suggestion] Workaround for apps detect bootloader unlocked through hardware attestation · Issue #252 · kdrag0n/safetynet-fix

Now we have few apps that use hardware attestion to detect bootloader status no matter SafetyNet or Device Integrity pass. We have tested with few good guys on Telegram and it's only working on unl...

github.com
[Magisk] meric57:
Hello sorry about the irritation I explained myself badly as I solved for the root with magisk.

My concern comes from the LSPosed apk version 1.8.6-6712 -zygisk-release .APK when I install it via magisk module I get an error I don't know if I should install the lower version or not.

Also as it asks to restart once restart in magisk.apk no more instalation just the application, so I have to reflash with odin the 4 BL-AP files patched_magisk -CP -and home CSC to find my root.

Just to know whether to install LSPosed or not.

I hope it's clearer for sure

attempt to install LSPosed v 1.8.4 zygisk see screenshot

On the magisk interface as soon as I restart my s10 I find myself without root see screenshot
[Magisk] zgfg:
I don't know about the APK version of Zygisk-LSposed installation?

Pls provide the link where you downloaded and the file name (with extension)

Anyway, if it is really APK file then you have to install as any other APK file - by application installer, not through Magisk app

I use Zygisk LSPosed, downloaded from below, Zygisk_-_LSPosed-v1.8.6(6712).zip and that one (zip) has to be installed through the Magisk app:

Release 1.8.6 · LSPosed/LSPosed

New Xposed API proposal As Android version iterates, the original Xposed API by rovo89 reaches its limits. Now we are working on the new modern Xposed API with features of application scope managem...

github.com

Also, for Zygisk module, Zygisk must be enabled but on your screenshot it looks like not enabled.

Make sure you do not use Riru, since Riru is not compatible with Zygisk
[Magisk] meric57:
Bonjour zgfg, sur le même site que vous avez mis sur github, magisk installe également zigisk avant d'installer le module LSPosed. APK du même site.

at least as I am winrar by default is 7zip not by default, as you can see on screenshot error these when I launch the installation in magisk
[Magisk] zgfg:
I don't understand what are you doing

You are not supposed to unzip and look for the apk file - you have to install the zip file as downloaded

See the screenshots if not familiar how to install a Magisk module
[Magisk] meric57:
Good evening, solved I downloaded directly from github and installed it's good thank you
[Magisk] shakeelbirmani:
Hello All the members, I have a problem, I use banking apps here in Pakistan and one particular app i.d HBL Mobile, seems to detect root no matter what I do, I have tried all the possible solutions, of hiding magisk, zygisk everything but it seems to detect root. any solution to this would be much appreciated.
[Magisk] rseiler:
@shakeelbirmani I see the same thing with Metro Bank. No idea at this point,
[Magisk] pndwal:
What about my reply to your previous query?:

Not sure you noticed... PW
[Magisk] huskydg:
@pndwal You should say Magisk v23 is dead as only Official MagiskHide is dead 😏
[Magisk] huskydg:
Work fine, i can go into login screen
[Magisk] huskydg:
This app is also working fine
[Magisk] pndwal:
John said:

So I said:

to find out if member was using an unofficial build retaining MagiskHide like yours (but he didn't reply)...

... And Did I not conclude with John's rejoinder:

🤪 PW
[Magisk] huskydg:
If he uses official, he should have said denylist.

But if he uses official magisk v23, why did he chat here?
[Magisk] pndwal:
How would I know?...

But this is [Discussion] Magisk - The Age of Zygisk thread... That's exactly why I commented:

... Are you saying that I should have just assumed he's using Delta or other unofficial fork that adds back MagiskHide?... Well it's fairly simple... I've learned not to assume too much here...

So are you taking issue with the "MagiskHide is dead!" comment, or that I asked for clarity re. what Magisk version a member uses?... Anything else? 🤷 PW
[Magisk] 11insomnium:
Just a simple question, that was not answered in installation guide on Github:

When do I need to repatch the boot.img with magisk app? Can I use the same magisk_patched.img (patched boot.img from previous build) to gain back root after updating to newest monthly build?

Renaming magisk.apk to magisk.zip and flash it in TWRP is no longer recommended, so I don't want to use this method.
[Magisk] huskydg:
When do I need to repatch the boot.img with magisk app?

yes, after update

Can I use the same magisk_patched.img (patched boot.img from previous build) to gain back root after updating to newest monthly build?

I'm not sure and I don't recommended to do this after updating.

Renaming magisk.apk to magisk.zip and flash it in TWRP is no longer recommended, so I don't want to use this method.

Magisk has deprecated recovery install because it is not accurately detecting device information from Recovery but it is still working in some case.
[Magisk] zgfg:
You can re-patch the previously patched boot.img only if updating Magisk (in that case you could also use Direct install)

But if you upgrade ROM, you must use the new boot.img, coming with the new/updated ROM.

However, you can extract (from the ROM zip file) and patch the new boot.img before flashing the new ROM, and then flash that patched new boot.img right after you upgrade the ROM

If upgrading ROM does not wipe Data, all your modules, Magisk db with DenyList etc will remain, hence once you flash the newly patched boot.img, Magisk will continue to work

However, some old modules might not be compatible with the upgraded ROM (usually when upgrading Android) - to prevent bootloops, better disable suspicious modules before upgrading the ROM (onxe you flash its patched boot.img, in case of bootloop, you will only be able to disable the problematic modules from TWRP or by Factory resetting - in that case you loose all)
[Magisk] 11insomnium:
(y)

These were also my thoughts, because sometimes the file size of the new boot.img has changed. But what would happen if I flash the old magisk_patched.img instead?
[Magisk] zgfg:
The old boot.img (patched or not by Magisk) usually won't work with the upgraded ROM.

You can try and take your own risk to brick😁

However, you can always temporarily boot (one time) with and test does it work:

fastboot boot <IMG>

instead of permanently flashing (and potentially bricking) by:

fastboot flash boot <IMG>
[Magisk] 11insomnium:
@zgfg Is it possible to extract only the boot.img from payload.bin on windows?

The tool I use extracts all files (>6GB) which I don't need.
[Magisk] zgfg:
I use payload-dumper. You cannot select only a single img file to extract but you can kill it once it extracts what you needed
[Magisk] pndwal:
Prior images will often allow booting, but generally comms, bt, other hardware and more will have issues or be broken since the kernel resides in boot.img and usually receives many fixes/changes with major updates ...

Many users post re. comms, bt issues etc in Magisk GitHub which turn out to be the result of flashing older Magisk-patched boot images...

I put info here:

👀 PW
[Magisk] 11insomnium:
Does this also mean that it is wrong to flash the magisk_patched.img into both slots?

My device is Poco F4 with A/B partitions.

wrong ? source

fastboot flash boot_a magisk_patched.img

fastboot flash boot_b magisk_patched.img

right ?

fastboot flash boot magisk_patched.img
[Magisk] zgfg:
Are you sure that your inactive slot is bootable (on some devices and ROMs it is not)?

Eg:

fastboot --set-active=b

fastboot reboot

Keep your OTA to switch/manage active slots, flashing with

fastboot flash boot <img>

will flash to the correct (active) one

Even if the other slot is bootable, at the moment it may not be updated to the same ROM version - flashing the wrong boot img there will make it not bootable
[Magisk] 11insomnium:
You helped me a lot to understand it. Thank you so much @zgfg & @pndwal (y)

My hopefully last question: To update the ROM + keep recovery and root installed, is this the right order?

- boot into recovery

- flash new ROM.zip

- flash recovery + new magisk_patched.img again (to keep it after next boot)

- reboot to system

When I only update TWRP/Orangefox, it is also necessary to flash again magisk_patched.img afterwards, because both are in boot partition, right?
[Magisk] pndwal:
Generally you'd only flash Magisk to inactivate slot immediately after updating OS and before reboot following these instructions:

https://github.com/topjohnwu/Magisk/blob/master/docs/ota.md#devices-with-ab-partitions

for preserving Magisk thru updates... This method works for some devices, but is broken for current P6 and P7 updates ATM, so many A/B devices must flash only to current slot after updating and rebooting like A-only devices ...

I guess you could flash Magisk to inactive slot in other circumstances if not affected by recently implemented partition digest checks that prevent this from working on newer devices currently, as long as you know exactly which OS version is on that slot... It generally won't match the current slot so boot.img used will differ... Nb. When devices are new, the unused slot is not generally bootable as factory odex files for system apks are shipped on system_b

https://xdaforums.com/t/january-3-2...7-pro-cheetah-safetynet.4502805/post-87591713

Many users want to put an OS on both slots immediately for safety reasons, and in this case there may be identical systems and partitions incl. boot.img. However flashing to inactive slot can be fraught and can break updates, so why not simply swap active slots to install Magisk while slot is marked as active to have root on both slots?... Then change active slot back... PW
[Magisk] zgfg:
If you are on Xiaomi.eu (recovery) ROMs, then TWRP or OFox will be already in the boot.img, hence you will just patch and flash the Magisk

In case of stock MIUI you can install OFox upon OTA upgrading, reboot to OFox, backup your Boot partition, then reboot to (not yet rooted) System, patch the backed-up boot.emc.win, then reboot to OFox and flash it to Boot (or flash from Fastboot)

Or, OTA, then install OFox, reboot to OFox and flash Magisk directly from OFox

(Btw, your inactive slot might really be not bootable with MIUI 13+

Also, if you first patch Magisk and then install TWRP/OFox to your device with Recovery integrated to the Boot, you will loose Magisk and you will have to patch the Magisk again)
[Magisk] shoey63:
I use Payload dumper go by @osm0sis .

It's a Magisk module and you can extract specific partitions from payload.bin on device without unpacking the whole thing.

Really handy👍
[Magisk] rseiler:
Via which method (there are a million of them)? I'm just using what's worked for everything else I use, which is:

-Magisk 25.2 (Zygisk, Denylist enforced and various apps checked, and using the Hide feature) + kdrag0n's safetynet-fix 2.4.0 module + Airfrozen

Using LineageOS 20.
[Magisk] zgfg:
Does it really work satisfactory on the phone when extracting from payload.bin of 6+ GB?

That's the reason I prefer PC
[Magisk] J.Michael:
Plus, it sounds like you need Magisk installed, so you can use a Magisk module to extract a file you need to install Magisk. Possibly useful if using one phone as a workstation to install Magisk on another phone.
[Magisk] zgfg:
There is still a case when you already have Magisk prior to OTA and you want to extract boot img on the same phone before patching, upgrading the ROM and flashing the patched boot.img

Btw, in that case you could also use.ADB & Fastboot Magisk module on that 'workstation' phone, to run ADB and/or Fastboot from that phone instead of from the PC (it works fine over the two-side USB-c cable)
[Magisk] Lughnasadh:
I've seen several people say they successfully updated via "Install to Inactive Slot" method on the Pixel 6 and 7 series in the last several months, but it's still very hit or miss. A few issues concerning this matter have been opened (and closed) in the Magisk Github, but so far no one has provided logs, so until then the reasons for the hit or miss remain unknown.
[Magisk] wkn000:
Installed Magisk.zip with TWRP on LOS 20 (payton). No need to manually reinstall Magisk after any OTA since, all done automatically in background (addons.d).
[Magisk] pndwal:
That's interesting...

This was broken for Pixel 6 and 7 at least for late A12 and A13 updates due to new partition digest checking by update engine... The linked Google documentation doesn't seem to have changed... Still says:

... This new check was identified as the issue because boot.img partition digest doesn't match after Magisk flashing so dm-verity devices indicate corrupt boot image and update/slot will be marked as failed/corrupted... I believe disabling verity/verification can't help since vbmeta can't be tampered for delta updates using update engine either...

I mentioned this here:

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

The issue is still marked in GitHub as wontfix...

Do you know if Google has in fact changed/reverted their digest checks, or if this actually works w/ up-to-date releases for some?... And perhaps you could link a user's success story?... Thanks, PW