Magisk General Support / Discussion

Search This thread

zgfg

Senior Member
No haven't seen that one yet, but you could experiment by adding one with Magisk and see if anything respects it. 😛
I did test on my two Xiaomi phones, MIUI 12.5/A11 and MIUI 13/A12

None of them had the /etc/nsswitch.conf file, or anything similar

I created the conf file as zipped and attached (XDA does not allow conf extension attachments) and copied the conf file to:
/data/adb/modules/hosts/system/etc

After reboot, the conf file was mounted to /etc (as 'required')

Initially, the conf file defines:
hosts: files dns

Then I tested the opposite (both options are prepared in the same conf file, one must be commented out, the other un-commented):
hosts: dns files

and rebooted - but the conf file seems to be ignored, /etc/hosts file has always the precedence over DNS (ads are always blocked for me via the hosts file)

PS: Maybe if somebody with A13 (latest Pixel update) would like to test😁
 

Attachments

  • nsswitch.zip
    478 bytes · Views: 8
Last edited:
  • Like
Reactions: osm0sis

ctcx

Senior Member
Jan 16, 2013
269
84
It's ok not to be a dev or know Python, you can use the program as a user,
it would extract the boot from the image, transfer it to the phone, create the script based on the chosen file, create the patch and pull it back to your PC, and it is cross platform.
You can inspect the generated script which is bash, and understand what it is doing without necessarily knowing one bit of python.
The program is very verbose so that people can follow what is going on.

Generate a patch using the program, and let's assume this patch is not exactly what is needed and functional, let's call it a bad patch

Also generate a patch the manual way that you know works, and let's call this a good patch
Next you would compare the two, the patched boot files can be unpacked and compared.

This can be done on the phone or if you are more comfortable doing it on the PC, you can use the excellent toolkit Android Image Kitchen by @osm0sis
Even a binary diff would give you an idea of the difference.
See further below.


I don't agree with the above generalization, there's always outliers, but in general the community is very helpful, and amazingly patient even with newcomers, what is typically not tolerated is people not putting in the effort to research or even read few posts and expect all the answers to be delivered on a platter.
When a senior member who is well seasoned and knows what he/she is talking about, asks a specific question to be able to offer advise, and it is evaded, it naturally irks the person.
Almost always there is a lot of context in the questioner's mind that is not totally relayed in the post, hence why specific questions are asked and answers expected.


You're not supposed to know, but you find out with exploratory observation, testing, trial and error and of course differential analysis.
For example I didn't know about the KEEPVERITY and KEEPENFORCEENCRYPT flags when I first called boot_patch.sh, and just like you the generated patch was not good and different from a good patch.
I did a binary diff of the two (at the time I didn't even know I could unpack) and noticed those two keywords existing in the good patch, but not mine.
Read up about it, inspected the script, and asked questions to eventually figure out the right options to use to generate an identical patch.
Same with the Magisk32,
Thanks again for your whole advice.

However, still nothing of this would explain my first problem back here:
 

Elsrougy

Member
May 19, 2017
7
2
Cairo
Is there anyway to tell if an app is checking for strong integrity? I have 2 apps that stopped working after having to update them and it's because they detect root, but I would like to know if it's strong integrity so I can just give up. The apps names are Absher and Nafath.
Did you get any answer? Absher, Nafath & SNB (Bank) all not working now
 

Nergal di Cuthah

Senior Member
Sep 20, 2013
2,111
1,156
Google Pixel 6 Pro
Did you get any answer? Absher, Nafath & SNB (Bank) all not working now


That was from a while ago (many magisk canaries). So lets start with basics.
What device
What android version
What other mods do you have
What version of magisk (canary stable beta and number)
What version of usnf are you running
What's in your deny list

All of that will make finding what is being seen by the apps easier . It is HIGHLY UNLIKLY that it is belching on strong integrity nobody to date uses that one, and if, by slight chance they are -which they're not - then the only remedy is to unroot and relock your bootloader and turn off oem debug.
 
Last edited:
  • Like
Reactions: ipdev

pndwal

Senior Member
Finally installed Magisk on an ocean (Moto) device with LOS 20.0. With Zygisk active, universal safetynet module, and adding the infamous banking app to deny list, app finally let run instead of complaining "device cannot be trusted, exit".

But there were big problems, which I describe in 2 separate posts.

First, trying "fastboot boot magisk_patched.img" did not work at all.
Fastboot output:
fastboot FAILED (remote: '') # yes, [B]nothing[/B] inside the simple quotes...
Bootloader logs:
incomplete boot image downloaded

I tried with su in PC console, "--set-active=b" just to be sure (albeit it's always slot b, and it already was), different platform-tools versions... NOTHING.

Why is this?
Fastboot temp booting images doesn't work on all devices... Did you try flashing? PW
 

badabing2003

Recognized Contributor
Sep 17, 2012
2,287
3,200
However, still nothing of this would explain my first problem back here:

My answer has not changed :)
Inspect the boot file you generated and see how it differs from the expected patched boot file.

incomplete boot image downloaded
This should be a clue.
 

pndwal

Senior Member
Is there anyway to tell if an app is checking for strong integrity? I have 2 apps that stopped working after having to update them and it's because they detect root, but I would like to know if it's strong integrity so I can just give up. The apps names are Absher and Nafath.
Did you get any answer? Absher, Nafath & SNB (Bank) all not working now
Check app prerequisites and see if it can run with Android 7 or earlier... If it can they're not enforcing strongIntegrity...

Test if app can run on any unmodded (stock, locked) device launched with Android 7 or earlier (can be running later stock Android) or any later device known to have broken keymaster implementation (eg. many OnePlus devices)... If it can they're not enforcing strongIntegrity...

Nb. It is conceivable that an app requiring strongIntegrity might not check for this on certain (whitelisted) devices. However if this behaviour did exist the App would really be compromising the strongIntegrity attestation itself since there should be no way to bypass a failing verdict... Implementing such behaviour would allow any device to bypass the verdict simply by spoofing the device properties of any whitelisted device, rendering strongIntegrity really no better than deviceIntegrity...

👀 PW
 
Last edited:

olik2000

Member
Sep 26, 2014
29
15
That was from a while ago (many magisk canaries). So lets start with basics.
What device
What android version
What other mods do you have
What version of magisk (canary stable beta and number)
What version of usnf are you running
What's in your deny list

All of that will make finding what is being seen by the apps easier . It is HIGHLY UNLIKLY that it is belching on strong integrity nobody to date uses that one, and if, by slight chance they are -which they're not - then the only remedy is to unroot and relock your bootloader and turn off oem debug.
Moto edge 30 ultra
Android 12
I have magisk alpha 25210 + latest lsposed
I have shamiko and all apps that don't require root added to denylist + google services and store
I use unsf 2.4.0 mod 1.1
I also have hide my applist
snb used to work but stopped after a recent update
 

Attachments

  • Screenshot_20230321-001837_1.png
    Screenshot_20230321-001837_1.png
    137.1 KB · Views: 53
  • Screenshot_20230321-001929_1.png
    Screenshot_20230321-001929_1.png
    45.7 KB · Views: 53
  • Like
Reactions: ipdev

Nergal di Cuthah

Senior Member
Sep 20, 2013
2,111
1,156
Google Pixel 6 Pro
Moto edge 30 ultra
Android 12
I have magisk alpha 25210 + latest lsposed
I have shamiko and all apps that don't require root added to denylist + google services and store
I use unsf 2.4.0 mod 1.1
I also have hide my applist
snb used to work but stopped after a recent update
Magisk 25210 is flawed, no mods are enabled or can run. Switch to 25209 or stable. Don't forget to roll back your boot.img too.
Usnf mod 1.1 was flawed did not kick in soon enough switch to 2.4.0 mod 1.2

Then try and see if apps still are blocked
 

zgfg

Senior Member
Magisk 25210 is flawed, no mods are enabled or can run. Switch to 25209 or stable. Don't forget to roll back your boot.img too.
Usnf mod 1.1 was flawed did not kick in soon enough switch to 2.4.0 mod 1.2

Then try and see if apps still are blocked
He mentioned Magisk Alpha 25210..Not sure do we have active Alpha users who know the up-to-date situation there, bugs and fixes in the recent Alpha releases, etc
 

Nergal di Cuthah

Senior Member
Sep 20, 2013
2,111
1,156
Google Pixel 6 Pro
He mentioned Magisk Alpha 25210..Not sure do we have active Alpha users who know the up-to-date situation there, bugs and fixes in the recent Alpha releases, etc
Oops i read alpha as canary and forgot that there are forks (poorly named imho) alpha and delta. Figured since this is the general thread they were using the general magisk, at my likely mistake.
 
  • Like
Reactions: ipdev

ctcx

Senior Member
Jan 16, 2013
269
84
My answer has not changed :)
Inspect the boot file you generated and see how it differs from the expected patched boot file.

incomplete boot image downloaded
This should be a clue.
Probably you forgot that I did mention that I tried with ALL the imgs: the bad patch, the good one, and even the original unpatched one. All of them gave that result.
 
  • Like
Reactions: ipdev

badabing2003

Recognized Contributor
Sep 17, 2012
2,287
3,200
Probably you forgot that I did mention that I tried with ALL the imgs: the bad patch, the good one, and even the original unpatched one. All of them gave that result.
Yes, I didn't realize that, so basically what you're saying you have a flashing issue, no matter what you try to flash, it does not work, even stock?

Then what @pndwal suggested is the most plausible reason.
 
  • Like
Reactions: ipdev and pndwal

Elsrougy

Member
May 19, 2017
7
2
Cairo
That was from a while ago (many magisk canaries). So lets start with basics.
What device
What android version
What other mods do you have
What version of magisk (canary stable beta and number)
What version of usnf are you running
What's in your deny list

All of that will make finding what is being seen by the apps easier . It is HIGHLY UNLIKLY that it is belching on strong integrity nobody to date uses that one, and if, by slight chance they are -which they're not - then the only remedy is to unroot and relock your bootloader and turn off oem debug.
-Device: OnePlus 8 Pro
-Android Version: stock OOS 11
-Other mods: for magisk modules I disabled them all and tried but no luck, also using HMA (in the log it doesn't seem they check tho) and shamiko (tried with & without)
- Magisk version: stable 25200
- USNF: 1.2 (I tried Kdrag0n & Displax mod 1.2
- Deny list: play services, store, Android service library, android setup, device health survices, support component, package installer and a bunch of apps that need root hidden to work. I know I added a lot of unecessary apps to the list but I did that when I got fedup with those apps before

I don't believe they are checking for strong integrity but it seems like there's nothing working with them right now. Worth noting that few months ago they had an update and they were not working with denylist and shamiko fixed the problem. Also from play store info absher supports (android 5.0 and up), while SNB & Nafath supports 8.0 and up
 

Elsrougy

Member
May 19, 2017
7
2
Cairo
Check app prerequisites and see if it can run with Android 7 or earlier... If it can they're not enforcing strongIntegrity...

Test if app can run on any unmodded (stock, locked) device launched with Android 7 or earlier (can be running later stock Android) or any later device known to have broken keymaster implementation (eg. many OnePlus devices)... If it can they're not enforcing strongIntegrity...

Nb. It is conceivable that an app requiring strongIntegrity might not check for this on certain (whitelisted) devices. However if this behaviour did exist the App would really be compromising the strongIntegrity attestation itself since there should be no way to bypass a failing verdict... Implementing such behaviour would allow any device to bypass the verdict simply by spoofing the device properties of any whitelisted device, rendering strongIntegrity really no better than deviceIntegrity...

👀 PW
From play store info "absher" supports (android 5.0 and up), while "SNB" & "Nafath" supports 8.0 and up
I know it is highly unlikely that they are checking for strong integrity but because I tried alot to make them work with no luck I am starting to think of the extreme cases they may use
I do not have a device running android 7 or earlier to check on them unfortunately but my device is oneplus 8 pro stock OOS11
 

pndwal

Senior Member
Yes, I didn't realize that, so basically what you're saying you have a flashing issue, no matter what you try to flash, it does not work, even stock?

Then what @pndwal suggested is the most plausible reason.
Praps not a flashing issue... Not sure if flashing was actually tried... I said:
Fastboot temp booting images doesn't work on all devices... Did you try flashing? PW
Probably you forgot that I did mention that I tried with ALL the imgs: the bad patch, the good one, and even the original unpatched one. All of them gave that result.
... Sorry, I only saw the reference to temp booting magisk-patched image also, per:
Finally installed Magisk on an ocean (Moto) device with LOS 20.0. With Zygisk active, universal safetynet module, and adding the infamous banking app to deny list, app finally let run instead of complaining "device cannot be trusted, exit".

But there were big problems, which I describe in 2 separate posts.

First, trying "fastboot boot magisk_patched.img" did not work at all.
Fastboot output:
fastboot FAILED (remote: '') # yes, [B]nothing[/B] inside the simple quotes...
Bootloader logs:
incomplete boot image downloaded

I tried with su in PC console, "--set-active=b" just to be sure (albeit it's always slot b, and it already was), different platform-tools versions... NOTHING.

Why is this?
... If by "I tried with ALL the imgs: the bad patch, the good one, and even the original unpatched one. All of them gave that result" you mean with fastboot boot xxx.img then you should try flashing... 😉 PW
 

ctcx

Senior Member
Jan 16, 2013
269
84
With Magisk installed, in order to make banking app work I had to:
enable Zygisk, install universal safetynet fix module, and also enable deny list and add banking app to it (I thought this last one was no longer needed...)

Infamous banking app finally ran and began registration stuff. But the app is unable to scan the needed qr code: the "screen" is just complete black instead of the camera looking for qr code.

Do you think this could be related to Magisk further settings, or is it purely app's fault?

Thanks.

(I read that, supposedly, there were 3rd-party qr code apps which were able to scan the qr code and open it with another installed app, which supposedly could work for cases like this. Do you know something about this?)
 

Top Liked Posts

  • 1
    What you describe has a good chance of working. When it doesn't work, you will have a good chance of recovering by flashing the unmodified "new" ROM, and continuing as you used to.
    He's talking about OTA, you can't modify OTA, it will fail AVB.
    1
    He said "no OTA updates for me. So I download them from the Google site", which I took to mean he downloaded a full ROM.

    I don't understand your reference to "AVB". If he can flash a patched boot image after the system is updated, and if he does indeed have a full ROM corresponding to an updated system, why couldn't the first flash of the updated system be with the boot image patched? (Unless this is one of those systems where Magisk cannot do a complete job of patching unless it is currently running on the target system.)
    J Michael,
    My bad, I did in fact mean I download the OTA and flash that because Google knows my phone is rooted or bootloader unlocked or something else, but never pushes updates to my phone. But I am certainly not an expert in all this, I am assuming badabing2003 is referring to a signature check or somesuch failing if I replace the boot image in the OTA zip with the magisk_patched one.

    I do appreciate your input, thanks! I'm learning...
  • 8
    The angry sir answered with something I already had learned (again, my fault as always...)

    And worse, as mentioned in the link, that's NOT it at all. Even other users such as zgfg pointed out this very fact.

    ...I'll take it as direct consequence of my very being. Devs are clearly unwilling to help.
    Thanks everyone else for all your advises. At least the other flags were able to be figured out.
    Before this spins out of control. 🙃

    ---

    Most here would just read past (skip) your post if they can not help or give a constructive response.
    or they are short of time and can not give your question the proper attention it needs.

    Instead they might give a quick answer to the question, even if you do not understand the (your own) question. 😉

    ---

    No one is angry.
    We all learn and ask questions.
    If anyone gets angry at you (or any one) for asking question, we will report them to the xda mods. 🪓

    Cheers. :cowboy:
    8
    Hello!
    How do you know?
    You must be an expert or something

    Nigerian-Meme.jpg 😜 PW
    8
    The angry sir answered with something I already had learned (again, my fault as always...)

    And worse, as mentioned in the link, that's NOT it at all. Even other users such as zgfg pointed out this very fact.

    ...I'll take it as direct consequence of my very being. Devs are clearly unwilling to help.
    Thanks everyone else for all your advises. At least the other flags were able to be figured out.

    I'm not angry, please don't characterize me as such. I'm not currently following this thread, nor whatever journey/rabbithole you're on/in, but I'm doing pop-ins to help when I'm called, if I can help, as I always do. 🙂

    But that is where "Ramdisk Yes" comes from:


    check_boot_ramdisk populates the RAMDISKEXIST shell Boolean, which becomes the Java/Kotlin Info.ramdisk Boolean, which become the translated app strings Ramdisk Yes/No:


    Edit:

    P.S. AIK will tell you very clearly when there's no ramdisk inside a boot.img:


    But that's neither here nor there for how Magisk makes that assumption, as you can see. 👍
    7
    If the "issue" is that you have not yet been able to reproduce the Magisk manager app's "Ramdisk: Yes/No":

    Did you try a "wrapper" for the shell script function you found? At the time you reported several script fragments, there was talk of needing to call other functions first to set up environment variables.

    Look up the "echo" command. There is a form that causes the shell to echo all lines as they are executed. Do this, redirect output to a log file, and you can crawl through and maybe spot where it first disappoints you.

    I believe "needing to call other functions first to set up environment variables" is exactly why he is getting a different result from the app. 👍

    I could gut out all the relevant bits for him to run, but, not trying to offend here, I kind of don't see what the point of all this has been, so I don't think I can justify putting in that amount of effort when I've got my own stuff to be doing... 🫤

    Edit: One final thought. It could also be that he needs to use Magisk's busybox and busybox ash env for some of the commands like Magisk would be to get the intended output.

    I'm running into an interesting problem that I can't put my fingers on, and am open to ideas / suggestions.
    As you may already know, Magisk embeds the SHA1 of the stock boot image used to create the patch into the patched image, this is great because one can easily determine the source image that was used and validate if it is what it is supposed to be.

    And this is exactly what PF does, it extracts the SHA1 from the patched image.
    Here's the function code
    Python:
    def extract_sha1(binfile, length = 8):
        with open(binfile, 'rb') as f:
            s = f.read()
            # Find SHA1=
            pos = s.find(b'\x53\x48\x41\x31\x3D')
            # Move to that location
            if pos != -1:
                # move to 5 characters from the found position
                f.seek(pos + 5, 0)
                # read length bytes
                res = f.read(length)
                return res.decode("utf-8")

    Unlike magiskboot and Android Kitchen Tools by @osm0sis which extracts the ramdisk.cpio and performs magiskboot cpio <ramdisk.cpio> sha1 on it, PF (to keep it lightweight) it just looks for the string SHA1= directly on the patched file and then reads the next 8 hex characters and converts them to ascii.
    And this has worked flawlessly so far, until this.
    Basically what is happening is:
    The expected embedded SHA1 is: 40100d6b9512f6dffbb6f6b67c1b878f3bd82d18

    With the exception of the red part of the SHA1, everything matches.
    In one case 0100 part which is expected to be 30 31 30 30 hex it is instead 89 00 FB 33, and in the other case it is 72 00 FC 15

    View attachment 5902493View attachment 5902495


    I don't understand why this is happening, my first guess would be some kind of encoding, but then why now and only with this image, my other guess / fear is that perhaps the writing is not clean which would be a bug in Magisk.
    Obviously I can skip over the first few bytes and do the validation with the remaining bytes, but I'd hate to take a path like that without understanding why this is happening, who's to say that this thing can't happen on the other portions of the SHA1 string.

    If you have any ideas, I'm all ears.

    The boot.img contains the ramdisk.cpio.gz/.lz4/.lzma/.xz and while text strings may get stored as-is in a compression format, that isn't guaranteed and the compression might find something it thinks it can "optimize" for space savings. That's why `magiskboot cpio <file> sha1` is run on the uncompressed ramdisk.cpio. 🙂
    7
    As I expected in advance, problems with Magisk occurred after the OTA update of LineageOS (Pixel 6a).
    Updated from a 20.0 build to lineage-20.0-20230429-nightly-bluejay

    After the update it was necessary to flash the new boot image again. I have done that. But Magisk simply does not root. Magisk patched the downloaded LineageOS boot-image, saved it in the download folder and that was it.

    Magisk was hidden before I did OTA update.
    Simply very beautiful. All this after setting up LineageOS to my liking.
    And what can I do now except re-flash ROM?

    You might be interested in this.

    If you are using the current Magisk canary build, addon.d support was fixed.
    A few weeks ago, I tested it on my Pixel 3a and made a post in The Age of Zygisk thread.
    Post #3,128

    Since I did not install Magisk via recovery, I made a module that overlays Magisk's addon.d script into the system/addon.d directory.
    The module is not necessary after the first OTA.
    - The OTA updater will actually restore the Magisk script into system with the others.

    Magisk Survival Module - [GitHub] - Link
    Please read all of the readme if you decide to use it.
    - This only works with addon.d-v2 (A/B slot devices).

    Cheers. :cowboy:

    PS.
    I have updated my 3a using the OTA updater 4/5 times now and Magisk is retained each time.
    No need to manually patch and flash the new boot image after update.
  • 1093
    This is the place for general support and discussion regarding "Public Releases", which includes both stable and beta releases.
    All information, including troubleshoot guides and notes, are in the Announcement Thread
    156
    Hello, I haven't given much support on XDA lately. It can be resulted from
    • University started and I have limited free time. In fact, I mostly develop during midnight
    • I live in Taiwan, which has large time zone differences between my European/American contributors/testers, which usually forces me to stay up late at night to discuss/test stuffs.
    • The new version is about to come, I don't want to spend effort on supporting old releases
    The planned update is delayed again and again, to some point I think I'll shed some light about what has been happening lately, also along with some announcements.

    New Forum!
    As you might have already discovered, Magisk got its own subforum on XDA! Many thanks to all the support you gave me, and much more information/features/support is about to come!
    **For developers supporting all the devices that are not using standard Android boot format, feel free to create threads in this section (actually, PLEASE do so) for your favorite devices after v7 is out. As I currently know, Asus devices require signing the boot image before flashing, and is model dependant; Sony devices seems to use ELF kernel that is unpatchable, or some has two ramdisks (inner + outer), both requires different workarounds; LG bootloader locked devices has to manually "BUMP" the boot image after flashing Magisk..... and there may be lots of other crazy boot image formats that haven't come up to my attention yet.
    It is impossible for me to support all these non-standard boot images, and I hope the community can collaborate to make Magisk running across all the devices. Overall, community collaboration is what XDA about :D

    The Pixel Phone
    Some of you might already know this news, that the next Pixel Phone right around the corner seems like it does not have ramdisk in boot image, which pretty much wrecked Magisk in all ways. However, it pretty much doomed root itself too. Kernel modifications is inevitable IMO, so I'll try to migrate my scripts to C programs that could possibly be included into the kernel itself. Note that I'm not familiar with linux kernel, I'm not even sure if my idea and concept is correct or not. But once the device is available, I think developers will find a way to bypass all the difficulties, and I'll do my best to learn things ;)

    Current Progress
    In the past month, I've spent quite some time learning SELinux, so that I can avoid using SuperSU's sepolicy patches. Thanks to the helps and tips from @phhusson and @Chainfire, I finally have a much clearer understanding of how SELinux works. The Magisk core parts (the scripts, boot image patches, new features, more supports) are actually done some time ago. What is causing all the delays is the Magisk Manager.
    To be completely honest, although I can code in Java without much issues, Magisk Manager is actually my first Android application, I had to reach out for assistance, and fortunately awesome developers like @DVDandroid and @digitalhigh contributed a lot, which makes the current Manager awesome.
    After the repo system and module management is mostly done, I was about to do some adjustments and release, but what we really done is decided to add another feature: auto-unroot with per-app settings. I decided to wait for it to be finished, and then do my adjustments. Due to reasons that'll be mentioned later, this feature will likely not be available for the next release (should come in future updates)

    Safety Net Disaster
    Those who are using Magisk for Safety Net bypass purposes must have known that Google recently updated the detection method of my Systemless Xposed. I still have no idea what Safety Net is detecting, so currently I cannot fix it on my side (also because I'm busy working on the next update). However, suhide developed by @Chainfire is able to hide Xposed and worked fine.
    However, only my Systemless Xposed v86.2, which is based on SuperSU's su.d, is supported using that method. v86.2 and v86.5 (latest, Magisk based) have nearly identical binaries, and the only difference is the path where the binaries are stored.
    I'm still not sure what's the real issue for it not being supported, I just hope it is not done intentionally.

    Conclusion
    Due to the fact that my Safety Net bypass is not 100% perfect now, I do not want to spend any more time waiting for auto-unroot to be polished. What I'm doing now is finishing up all the things I'd like to change in Magisk Manager (it has been a while since I last contributed to Manager, my fellow developers are doing all the heavy job), which might take a little more time, after that, packed with tons of information to be announced in Magisk Section, I'll release the long awaited update.

    Hope this lengthy post gives you the idea of the whole situation, and again thanks for all your support!!
    121
    Ah, some Chainfire bashing, I hope it is not too late for me to exercise additional villainy.

    First, let me make clear I have nothing against @topjohnwu, nor against Magisk. Magisk is an interesting project and it certainly displays @topjohnwu ingenuity and persistence. I don't doubt we will see more interesting things from his hands.

    -------------------------

    What has happened here is not all that dark and complicated, from either end. I returned from holidays, and someone pointed me at Magisk. My first thought: interesting!

    Among other things, the thread lists some issues with SuperSU, which in combination with the phrase The developer also requests users to not bug Chainfire with compatibility requests for SuperSU with Magisk from the portal article, raised my left eyebrow by nigh half an inch. The popular systemless xposed mod is apparently now based on it, and apparently it now no longer works with SuperSU, and apparently I'm not supposed to fix that, nor any of the other found issues. I found that a bit weird. So yes, I have told @topjohnwu that I was a bit surprised he was posting about issues with SuperSU without notifying me about them (I can't fix or help fix issues I'm not aware of, after all).

    He's also spreading a modified version of the SuperSU package, which is not all that uncommon, nor necessarily a problem. I have not looked into what he modified, I only ran a few quick tests on one of my devices, and found some commonly used commands run as root to be broken. I have informed him of this as well.

    It appears the tool of choice for Magisk is phh's Superuser, because of some of the mentioned issues with SuperSU. That's fine by itself, but fixing issues in that superuser by incorporating SuperSU's binaries into it is a somewhat questionable practise. After all, SuperSU is a commercial closed-source package that helps pay for my dinner, and superuser is a direct competitor. I have informed him that I was surprised he did this without asking for permission. I have expressed similar surprise on him spreading a modified version of LiveBoot (which helps pay for a snack now and then).
    @topjohnwu has also stated that Magisk's scripts are largely influenced by mine (I have not checked). Scripts based on mine are used all over the place on XDA, some people have crafted amazing things based on them, I have never made an issue of this (otherwise I would have just made them binaries). But yes, I have also stated to him that I don't think it's very nice to base something on one program, and then using that to (almost exclusively) push something directly competing with that program.

    tl;dr Towards @topjohnwu, I have:
    - expressed surprise he has issues getting Magisk to work with SuperSU, and has chosen not to inform me about those
    - expressed surprise he is using SuperSU binaries in a competing superuser without permission
    - expressed surprise he is posting a modified LiveBoot without permission
    - informed him of issues with the modified SuperSU he has posted
    - let him know I thought it wasn't very nice to be applying my scripts to benefit seemingly exclusively that same competing superuser

    To be crystal clear:
    - I have not asked for an apology
    - I have not asked for Magisk to be abandoned, neither the root hiding nor systemless module parts, and certainly not systemless xposed
    - I have not made an issue of any of this anywhere, until this post
    - I have not even specifically asked for anything to be taken down (though obviously in my opinion the other superuser package mixed with SuperSU's binaries, as well as the LiveBoot package, should go)
    - I have not reported this thread to XDA moderators for copyright violations or otherwise

    While my conversation with @topjohnwu may not win any awards for being friendly (though it may win some for brevity), I think all things considered my response has been rather mild. To be perfectly honest, until the apology post, I thought this was over with already. I think the apology post was triggered because I haven't replied to his last PM for a while - I was in the zone, it happens.

    To emphasize again, I have nothing against @topjohnwu, Magisk, or systemless xposed, and it is certainly not my goal to see any of them go. If it can be made to work together with SuperSU, great.

    I get it though: you think of something, you want to see if you can make it work, you finally get it to work, you publish it, it takes off - enthusiasm gets the better of you. Maybe in the rush some mistakes are made. That doesn't mean you have to just drop it and run. None of my stuff would make it past 0.1 if I stopped at the first big mistake :)

    Aside from said being in the zone coding, I usually regret actually responding to these sort of things the day after, which has made me hesitant to reply. Surprise me.
    76
    Thread temporarily closed so everyone sees this.

    The flood of "SafetyNet isn't working for me either!" posts are not helpful, at all. Please refrain from posting further, it will be looked into. Please do not forget that not passing SafetyNet is 100% NORMAL AND INTENDED when you have an unlocked booloader or running custom firmware. These are workarounds and they will be worked around in turn.

    The Flash
    Forum Moderator

    EDIT: Thread is reopened... I will be cleaning any SafetyNet posts for a while to keep the thread clean for real issues.
    75
    Hello everyone!

    I am aware that Google has updated Safety Net that makes Magisk itself a no go for Android Pay. In fact, I witnessed the change live while I am developing the new magiskhide, which should hide all Magisk modules and Magisk installed root.

    Google is serious about Safety Net now, clearly hunting down all possibility to run Xposed with Safety Net passed. I spend quite some time examining the new security measures last midnight, and fortunately it seems that it is possible to run Magisk and root along with Safety Net if no Xposed is running. I'm glad I removed the old root toggle at the right time lol, that is no longer feasible with the latest detection.

    So stay tuned for the next update, it will come with bug fixes, along with the new magiskhide to bypass that Safety Net.

    Google, how will a few systemless mods do any harm :p:p