yashsingh1/xdaforums huggingface dataset:
[Magisk] Spaceoid:
Aaah, okay, ty! I misunderstood the Release tab on Github.

While trying to get the official OTA, I restored the original Manager (had it under a renamed package), then hid it again under a different package name, which caused a soft-crash of my phone. Everything seems normal now again, though. I assume it was only some crashing Magisk module or a package name conflict... Or could I have destroyed my Magisk installation now? I never changed the Manager name twice in so fast succession before...
[Magisk] zgfg:
Magisk app (former Manager) shows everything: do you have Magisk installed and which version, as well as which version of Magisk app you have - btw, you should have both the same versions
[Magisk] pndwal:
Right track, but:

Stub .apk (currently version 31) is actually a separate app called per Update Channel / hosted JSON file when online.

Here's JSON for latest beta release. Note links for

- "magisk" versionCode: 25000 app-release.apk,

- "note" Magisk/releases/25000.md, and

- "stub" versionCode: 31stub-release.apk.

{
"magisk": {
"version": "25.0",
"versionCode": "25000",
"link": "https://cdn.jsdelivr.net/gh/topjohnwu/magisk-files@25.0/app-release.apk",
"note": "https://topjohnwu.github.io/Magisk/releases/25000.md"
},
"stub": {
"versionCode": "31",
"link": "https://cdn.jsdelivr.net/gh/topjohnwu/magisk-files@25.0/stub-release.apk"
}
}

Also, the stub .apk is simply installed... Magisk daemon has generally called the stub .apk and then populated it's app data w/ Magisk binary ( or 'injected' binary data as you put it) in the case you mention (ie. whenMagisk does not detect a Magisk Manager app) and when taking 'Hide the Magisk app' function...

John originally said:

... Magisk simply uses the (empty) stub to 'hide itself'...

- https://topjohnwu.github.io/Magisk/faq.html#q-after-i-hidden-the-magisk-app-the-app-icon-is-broken

- https://topjohnwu.github.io/Magisk/releases/20100.html

Nb. In the past, the stub was always called from GitHub host and required network connection to succeed, then vvb2060 introduced:

• [App] Use the local version when you can't download the stub, now it can be used completely offline

in her Alpha builds. This was merged in TJW Magisk after 23.0... TJW had said earlier that since the famous 'Manager --> App' release v22.0 "the Magisk app (renamed from Magisk Manager) includes everything it needs within the APK itself, making installation a 100% offline process."

https://topjohnwu.github.io/Magisk/releases/22000.html

This was not totally accurate at the time as this change didn't include the stub .apk, but that has been included now with vv's commit making it truely "a 100% offline process"... At least it worked this way for a while when network connections were disabled, but I've found recently that 'Hide the Magisk app' has again failed w/o network connection. 🤔

No... Daemon will call/set up stub .apk (completely different .apk, only 27kb for release, 45kb for debug), completely uninstall full app and load all the full app's binary into stub app's data during extra setup... This results in a tiny (approx 100KB App size) pseudo 'Magisk' app, obfuscated w/ random package name and custom app name chosen by user, but Total Storage size of around 13.5MB (release build binary) which is similar to the App size or the replaced full 'Magisk' app...

Final comment:

It's worth noting that neither Google nor John seem to regard hiding (obfuscating) Magisk App as akin to attempts to "spoof/alter/manipulate any non-Magisk related signals or traces to circumvent any device state detection", now precluded in Magisk... Seems this is legitimate subterfuge as apps should not be employing such means of detection in any case... (Ie. Google has rules preventing both modder abuse, and proprietary app abuses)...

In the words of Momo's Scan Info notes (vvb2060, RikkaW):

😛 PW
[Magisk] pigbedleg:
can't do simple search for sepolicy.rule in github code repo search button for study how to manually inject se policy once and for all going system root by exploit no need to fool banking apps for fraud here
[Magisk] pndwal:
May need some Magisk Tools... This help?:

https://topjohnwu.github.io/Magisk/tools.html#magiskpolicy 😛 PW
[Magisk] meric57:
Hello, following zgfg and pndwal posts that talk about stable and beta I followed their advice. So I put in the beta settings magisk app goes to 25.00, just magisk remains 23.4 above with updating in front.

The concern if I update on restart I am blocked on loop logo, so I restart in TRWP recovery mode and restore my backup to restart normally.

The best to stay in beta or I have to take the AP that I modify it with magisk and that I take the boot.img that I flash with magisk or TRWP.
[Magisk] zgfg:
If you only updated Magisk (not ROM) and if it causes bootloop, it's maybe something specific to the phone, maybe pndwal knows more

Generally, it's your choice/decision would you settle for Stable (and wait untill v25 Stable will be released) or use your phone for testing v25 in Canary/Beta

If you take Debug version, you can report your issue (with Debug logs) to Magisk GitHub, to help/speed-up resolving the problem

Personally I never install Beta:

- For reporting issues (issues should be reported only to GitHub), you need to use Debug version

- Debug releases equal to Canary releases, however Debug provide logs needed for reporting the issue to GitHub

- Canary (and Debug) are frequently updated, while Beta is updated rarely (usually Beta comes once before releasing Stable).

Eg, if current Beta causes a bootloop with your device, there is a higher chance that fix will be provided sooner through the next Canary/Debug release

This is about my experience with how Beta/Canary releases (and my opinion about Beta - I never use Beta but only Canary and if I have problems with the new Canary I downgrade both Magisk app and Magisk itself to the previous Canary version)

However, we are all here just users and only TJW 'knows' when the next Canary, Beta or Stable will be released, and when the known issues might be fixed
[Magisk] meric57:
hi zgfg, as you can see on the capture message from the top in beta it gives this and on stable it gives this. So I stay on stable just at version 25 official, as long as I am rooted.
[Magisk] huskydg:
Attach your installation logs, dmesg when you get bootloop. Moreover please report this problem to github
[Magisk] pigbedleg:
Do you really have to patch the binary? Doesn't SElinux have a encoded config file for policy?; You use an SElinux configurator to manage. I was looking for a config file to inject. Relevant reply though, keep it up!
[Magisk] DiamondJohn:
The SE Policy adjustments through magisk are done using text files, with the contents as linked above. Or using a shell script (again a text file), also explained in the link.
[Magisk] pigbedleg:
ohh so you want the encoded config removed is why you instruct to replace selinux. I have to exploit the running system in this project using another disparate. selinux is the forseen obsticle after exploit and I need the command line tool to write a config for su. how to unpack Magisk Tools for my CLI?
[Magisk] pigbedleg:
How to get the Magisk Tools? I looked on github and do not see the assets. I have the app installed. I need the tools because I look into installing superuser into the system. In order to boot a patched ramdisk I take it I would need a laptop to run fastboot unlock bootloader and also have the unlock code and the original boot.img because the whole proprietary idea is to boot signed images which match the locked bootloader, and maybe also verity (verity would be good if it were did right). Furthering with a need for select flash software and specific undocumented USB cables. This is something which would require much work and equipment most cell phone stores are not equipped for or you trust an in the wild copy of a boot.img sometimes found on MegaDrive. Sometimes before you'd even get a factory boot.img you may have bricked a phone. Going forward with an exploit method I need the tools to modify the selinux policy. Magisk Tools including su will be needed outside of a boot.img ramdisk patch. If needed is there some generic ramdisk which I can patch, mount, and copy Magisk Tools from?
[Magisk] pigbedleg:
To keep it from spiraling out on a tangent I reposted my refocused general discussion here: https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-87038197
[Magisk] pigbedleg:
My app reads Latest 24.3 though 25.0 installed are you usung a beta ?
[Magisk] DiamondJohn:
You lost me 😵‍💫 especially when you said that I "want the encode config removed" Huh?I want nothing, i am saying its all already there.

The binary to modify the SE Policy rules (ie magisk) is included in a standard Magisk install. It will be available on your device, you do not need to extract it from the ramdisk. run which magisk to confirm your installation for yourself.

If you have another app that needs to modify an SEPolicy while it is running, simply execute a root shell from your app to issue the command, as explained in the above linked post. There may be a neater way built into the libsu, but I havent needed such, and therefore haven't checked for myself.

PS: I dont use the beta, I use stable.
[Magisk] pigbedleg:
no yeah if I get root shell I need the policy tool. As I recall some selinux policy require encoded config and maybe the configurator is not installed such would be the proper way to do selinux as got in fedora -So the policy cannot simply be changed during runtime as will be with a plaintext configuration.
[Magisk] pndwal:
Think this links back here...

I can confirm re. Magisk Tools:

- magiskboot /* binary */

runs fine for me w/ su from terminal with full path, /data/adb/magisk/magiskboot using Canary 25001...

- magiskpolicy /* binary */

- supolicy -> magiskpolicy

- magisk /* binary */

- resetprop -> magisk

- su -> magisk

binaries and applets all run fine w/o full path...

Guess you could copy the tools from /data/adb/magisk/ in magisk-rooted system for use in system with different su, but whether this will work in practice / practical application is beyond me... PW
[Magisk] pndwal:
Lost me too... 😁

Isn't this magiskpolicy binary, not magisk binary?... Seems we can call both compatible supolicy and magiskpolicy... PW
[Magisk] pndwal:
So you set Update Channel to Stable after updating App to Beta... App is correctly showing latest Stable per your setting, and won't prompt you to Update App until next Stable build is pushed...

meric57 has changed Update Channel and updated App to Beta. He hasn't hidden app and hasn't taken Direct Update (or Select and Patch a File) yet, so he currently has original Stable Magisk (mask) binaries installed but later package w/ Beta binaries loaded for pending Magisk Installation (patching, Direct installation)... He's therefore seeing the Magisk Update notification (which will now update from Stable to Beta). PW
[Magisk] BillGoss:
magiskpolicy and supolicy are both symlinks to magiskinit

su and resetprop are symlinks to magisk
[Magisk] meric57:
Hello pigbedleg, I tested beta and stable the result and in the 2 screenshots.

As said zgfg and pndwal this version is not official yet my installation magisk 23.4 official, if I put beta the application is updated my steps magisk which remains official 23.4 I still have rooting therefore I am waiting for magisk 25.0 official
[Magisk] pndwal:
...OK...

🤔 I was going by this:

https://topjohnwu.github.io/Magisk/tools.html#magiskpolicy

... Seems to me supolicy is actually a 'symlink' to magiskpolicy tool/binary (nothing to do with magiskinit), or as John states:

https://topjohnwu.github.io/Magisk/tools.html#magiskpolicy

... however

is correct...

magiskpolicy is also a distinct binary on my system, and magiskinit exists separately:

😬 PW
[Magisk] pndwal:
All these are actually 'official' TJW builds... I think you are really waiting for official public Stable 25.x instead of official public Beta 25.0...

Nb. Even w/ recent Stable Magisk you have Beta Zygisk... With new Beta Magisk we now have Stable Zygisk! 😁

... Some may have waited on Stable 23.0 for Stable Magisk incl. Stable Zygisk, but they'll be playing catch-up soon... Others have gotten used to Beta Zygisk in combination with various Magisk iterations... Still others have just blindly fumbled with these shiny new things and probably enjoyed it / learned alot!... I think I have... 😛 PW
[Magisk] BillGoss:
It seems that things have changed with v25.

I'm still on 24.3
[Magisk] zgfg:
From my v25:

:/ $ magisk -c
cacf8736:MAGISK:R (25001)
:/ $
:/ $ which magisk
/system/bin/magisk
:/ $
:/ $ su
:/ # cd /system/bin
:/system/bin #
:/system/bin # ls -la | grep magisk
-rwxr-xr-x 1 root root 232120 1972-08-16 05:04 magisk
-rwxr-xr-x 1 root root 304296 1972-08-16 05:04 magiskpolicy
lrwxrwxrwx 1 root root 8 1972-08-16 05:04 resetprop -> ./magisk
lrwxrwxrwx 1 root root 8 1972-08-16 05:04 su -> ./magisk
lrwxrwxrwx 1 root root 14 1972-08-16 05:04 supolicy -> ./magiskpolicy
[Magisk] pndwal:
Ah yes... Much has changed...

FWIW, these changes are due to this:

Introduce new sepolicy injection mechanism …

. In the current implementation, Magisk will either have to recreate all early mount implementation (for legacy SAR and rootfs devices) or delegate early mount to first stage init (for 2SI devices) to access required partitions for loading sepolicy. It then has to recreate the split sepolicy loading implementation in-house, apply patches, then dump the compiled + patched policies into monolithic format somewhere. Finally, it patches the original init to force it to load the sepolicy file we just created.

. With the increasing complexity involved in early mount and split sepolicy (there is even APEX module involved in the future!), it is about time to rethink Magisk's sepolicy strategy as rebuilding init's functionality is not scalable and easy to maintain.

. In this commit, instead of building sepolicy ourselves, we mock selinuxfs with FIFO files connected to a pre-init daemon, waiting for the actual init process to directly write the sepolicy file into MagiskInit. We then patch the file and load it into the kernel. Some FIFO tricks has to be used to hijack the original init process's control flow and prevent race conditions, details are directly in the comments in code.

. At the moment, only system-as-root (read-only root) support is added.

Support for legacy rootfs devices will come with a follow up commit.

topjohnwu committed on 16 Mar

Changes here:

Make magiskinit not magiskpolicy -

topjohnwu committed on 17 Mar

Use standalone magiskpolicy -

topjohnwu committed on 17 Mar

Tools doc updated here:

Update tools.md …

. magiskpolicy is no longer an applet of magiskinit

canyie authored and topjohnwu committed on 14 Apr

👀 PW
[Magisk] DiamondJohn:
Im pretty sure it is. I just checked my device

root@sunfish:/ # magiskpolicy
MagiskPolicy - SELinux Policy Patch Tool

Usage: magiskpolicy [--options...] [policy statements...]

Options:
--help show help message for policy statements
--load FILE load monolithic sepolicy from FILE
--load-split load from precompiled sepolicy or compile
split cil policies
--compile-split compile split cil policies
--save FILE dump monolithic sepolicy to FILE
--live immediately load sepolicy into the kernel
--magisk apply built-in Magisk sepolicy rules
--apply FILE apply rules from FILE, read and parsed
line by line as policy statements
(multiple --apply are allowed)

If neither --load, --load-split, nor --compile-split is specified,
it will load from current live policies (/sys/fs/selinux/policy)

root@sunfish:/ # which magiskpolicy
/system/bin/magiskpolicy

Its currently used to set the SELinux allows for Viper.

I am running stable 24.3, but @zgfg has just posted it for what I would guess is a newer version. https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-87038837

And its referenced in the Magisk page linked above.
[Magisk] pigbedleg:
did you try putting your Canary down a mineshaft?
[Magisk] pndwal:
Actually, binary/tool is now magiskpolicy

In 24.3 it was magiskinit, not magisk

Please see

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

and

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

above... 👍 PW
[Magisk] pigbedleg:
it is interesting and complex as topjohnwu has said he doesn't even know the details wonder if anybody does or who topjohnwu supposes knows since he did not exclude everybody and he says it is a substantial update. If you look at my post you see the complexity of even installing it if you have two Hong Kong Knights at your door you can put something together. selinux was developed by NSA and looks pretty good dunno if Amall really wants to ride with a broken selinux here in 2022 you finally have the capacity to secure the seventh layer for long time apps like PGP which is about what is at the boot layer now or some similar keying, critical stuff. Id really enjoy running it do you have any HK Knights available for reenforcment.
[Magisk] DiamondJohn:
Not sure what you are trying to tell me, as the above post I made is directly from a shell command, on a device running v24.3, where magisk and magiskpolicy give the output I posted. ie they are both present and work. And is what is used in my working modules
[Magisk] zgfg:
Not Canary but something else went down:
[Magisk] pndwal:
Never... Just keep feeding it normal seed...

So just for fun, re

... Re. exploit method John did put this a while back (nb. this doc is now obsolete):

https://github.com/topjohnwu/Magisk...79f3f6847965f4bd5119d/docs/deploy.md#exploits

Nb. scripts/emulator.sh became scripts/avd_magisk.sh on Jan 20...

... just a lead... in case it's relevant... So hope your hardy bird helps you pull this off... Still won't survive noxious gases any more than Canary... as long as you don't die trying... 😜 PW
[Magisk] pigbedleg:
not sure 25 is official because my app reads latest is 23.4 and wouldn't you expect a 24 maybe it was a substance

maybe zigfreed is posting a custom unofficial magisk

are you guys using x86 android? yeah I already asked for a generic ramdisk image to patch with gentoo I would do a makeramdisk in a kernel config. but if you dont do a holy grail and monitor the binaries

where to get lab grade hyrulonic acid for zigfreed?
[Magisk] pndwal:
guessing 24.3

Sorry, still can't see where you call magisk binary here...

Yup, always needed magiskpolicy.

Just saying that magiskpolicy in 24.3 was an applet of magiskinit binary (and so was supolicy), not an applet of magisk binary...

Further, now in 25.0/25001, magiskpolicy is no longer an applet, but a new 4th binary...

Hope it's clear! 😛 PW
[Magisk] DiamondJohn:
Yep, typo. Literally got a new keyboard a few hours ago. I have been using the previous one around 10 years. This one may go back. Corrected it in my post.

The quoted text I put displays that clearly. Its run from the root of the device, so is clearly in the path. I then made a call to which ummm....which that shows where it is running the binary from. I dont know how I could make it clearer. My assumption is that Magisk is mounting a magiskpolicy on boot to /system/bin/magiskpolicy; as shown by the which

I only run the stable 24.3 so at this stage I know nada (or care much about) canary. I also assumed the other dev was asking about stable. ie build his code to a fixed working target.

On a side, what is your distinction between "applet" and "binary"?
[Magisk] pndwal:
I'm not a dev; just assuming John's terminology is correct (... probably best to adopt his anyway so we're all on the same page. 😛)

This re. recent (incl. 24.3) tool, replaced going forward:

showing magiskpolicy as an applet of magiskinit

And this re. magiskpolicy tool now, since new sepolicy injection (24302+)

showing magiskpolicy as a new additional binary w/ supolicy as an applet...

As mentioned, I just posted about this change:

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

👍 PW
[Magisk] Timmmy001:
Monthly update Android 12 does not work - Hint needed

Android 12 / Build SP2A.220505.002

Magisk 24.3 (24300)

I have already rooted my Pixel6 Pro.

The first time I could not install the monthly update, because I had forgotten the first time to install the vbmeta including options.

With the follow-up attempt including data reset, I then followed the instructions from Magisk more conscientiously.

Now with the June update I wanted to install this as before according to the instructions.

Patching June Factory boot image with app

Boot in to fastboot-mode

flashing magisk-boot image

flashing vbmeta image with options

reboot ("G" with green/white progress bar at startup)

"fastboot.exe" flash boot "magisk_patched-24300_twvOE.img"
Sending 'boot_b' (65536 KB) OKAY [ 1.767s]
Writing 'boot_b' OKAY [ 0.107s]
Finished. Total time: 1.898s

"fastboot.exe" flash vbmeta --disable-verity --disable-verification vbmeta.img
Rewriting vbmeta struct at offset: 0
Sending 'vbmeta_b' (8 KB) OKAY [ 0.001s]
Writing 'vbmeta_b' OKAY [ 0.036s]
Finished. Total time: 0.051s

Result:

I'm still at the May security level....

(At least no boot loop or data reset).

Tried 4 times.

Does anyone have a hint where my error could be?
[Magisk] zgfg:
Follow-up to the discussion on applets between @DiamondJohn and @pndwal:

>> On a side, what is your distinction between "applet" and "binary"?

magisk is binary and su or resetprop its applets

Applets are symlinked:

lrwxrwxrwx su -> ./magisk

lrwxrwxrwx resetprop -> ./magisk

Executing:

magisk

(from Terminal) provides different result than executing:

su

However, executing su equals to executing:

magisk su

Similarly, executing:

resetprop --help

equals to executing:

magisk resetprop --help

Ie, magisk binary checks the arguments. If the first argument is su (or resetprop) it behaves accordingly

Similarly, busybox and toybox are binaries providing tens of applets each (some are even common to both)

Eg, whoami or which (applets) are symlinked to toybox (binary). And executing:

whoami

equals to executing:

toybox whoami

Or, executing:

which --help

equals to executing:

toybox which --help

Etc.

Some toybox applets come preinstalled with Android. To install the full set of toybox applets, install the module:

GitHub - Magisk-Modules-Alt-Repo/ToyBox-Ext: Systemless Magisk module for ARMv7 or higher, to install (additional) ToyBox applets

Systemless Magisk module for ARMv7 or higher, to install (additional) ToyBox applets - GitHub - Magisk-Modules-Alt-Repo/ToyBox-Ext: Systemless Magisk module for ARMv7 or higher, to install (additi...

github.com

Similarly, for busybox, install either the NDK module from @osm0sis:

GitHub - Magisk-Modules-Repo/busybox-ndk: busybox-ndk

busybox-ndk. Contribute to Magisk-Modules-Repo/busybox-ndk development by creating an account on GitHub.

github.com

or alternatively:

GitHub - Magisk-Modules-Alt-Repo/BuiltIn-BusyBox: Systemless Magisk module that installs and symlinks BusyBox with its applets to the Magisk built-in busybox binary

Systemless Magisk module that installs and symlinks BusyBox with its applets to the Magisk built-in busybox binary - Magisk-Modules-Alt-Repo/BuiltIn-BusyBox

github.com

In this context, applets don't need to be symlinked to binaries but without, typing command lines would require more strokes, like:

magisk su

toybox whoami

etc

(Sorry for advertising the two modules, it was not intended)
[Magisk] pndwal:
Well you don't mention taking OTA or flashing ROM... Have you done this?... or are you just updating boot.img (ie. kernel and ramdisk)...

Of course Magisk instructions are to restore all partitions with stock images, take OTA, then flash new magisk-patched boot image...

Here are instructions for seamless updates (recently fixed) for A/B devices:

https://github.com/topjohnwu/Magisk/blob/master/docs/ota.md... PW
[Magisk] pndwal:
Difference here is that magiskpolicy was formerly an applet of magiskinit (but not of magisk binary), but now (going forward) it's a binary in its own right... PW