{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Welcome to the Magisk Release / Announcement thread!
For all up-to-date info and links, please directly check Magisk's GitHub PageInstallation
Download count of previously XDA hosted files: 25,490,945
v1: 8746 v2: 2251 v3: 3790 v4: 1220 v5: 2914
v6: 138838 v7: 119744 v8: 116796 v9: 203836 v10.2: 215176
v11.1: 573322 v11.6:438886 v12.0: 3263706
1300: 274438 1310: 1018692 1320: 403556 1330: 1844372
1350: 39188 1360: 69874 1400: 4456314
1410: 11512 1420: 112020 1437: 247988 1455: 30652
1456: 253042 1468: 85978 1500: 434572 1510: 460120
1520: 927436 1530: 218164 1531: 3143686 1540: 97368
1600: 6043710 1610: 87628 1620: 140382
Changelog
Magisk
v20.3
- [MagiskBoot] Fix lz4_legacy decompression
v20.2
- [MagiskSU] Properly handle communication between daemon and application (root request prompt)
- [MagiskInit] Fix logging in kmsg
- [MagiskBoot] Support patching dtb/dtbo partition formats
- [General] Support pre-init sepolicy patch in modules
- [Scripts] Update magisk stock image backup format
v20.1
- [MagiskSU] Support component name agnostic communication (for stub APK)
- [MagiskBoot] Set proper header_size in boot image headers (fix vbmeta error on Samsung devices)
- [MagiskHide] Scan zygote multiple times
- [MagiskInit] Support recovery images without /sbin/recovery binary. This will fix some A/B devices unable to boot to recovery after flashing Magisk
- [General] Move acct to prevent daemon being killed
- [General] Make sure "--remove-modules" will execute uninstall.sh after removal
v20.0
- [MagiskBoot] Support inject/modify mnt_point value in DTB fstab
- [MagiskBoot] Support patching QCDT
- [MagiskBoot] Support patching DTBH
- [MagiskBoot] Support patching PXA-DT
- [MagiskInit] [2SI] Support non A/B setup (Android 10)
- [MagiskHide] Fix bug that reject process names with ":"
- [MagicMount] Fix a bug that cause /product mirror not created
v19.4
- [MagiskInit] [SAR] Boot system-as-root devices with system mounted as /
- [MagiskInit] [2SI] Support 2-stage-init for A/B devices (Pixel 3 Android 10)
- [MagiskInit] [initramfs] Delay sbin overlay creation to post-fs-data
- [MagiskInit] [SARCompat] Old system-as-root implementation is deprecated, no more future changes
- [MagiskInit] Add overlay.d support for root directory overlay for new system-as-root implementation
- [MagiskSU] Unblock all signals in root shells (fix bash on Android)
- [MagicMount] Support replacing files in /product
- [MagiskHide] Support Android 10's Zygote blastula pool
- [MagiskHide] All random strings now also have random length
- [MagiskBoot] Allow no recompression for ramdisk.cpio
- [MagiskBoot] Support some weird Huawei boot images
- [General] Add new "--remove-modules" command to remove modules without root in ADB shell
- [General] Support Android 10 new APEX libraries (Project Mainline)
v19.3
- [MagiskHide] Hugely improve process monitor implementation, hopefully should no longer cause 100% CPU and daemon crashes
- [MagiskInit] Wait for partitions to be ready for early mount, should fix bootloops on a handful of devices
- [MagiskInit] Support EROFS used in EMUI 9.1
- [MagiskSU] Properly implement mount namespace isolation
- [MagiskBoot] Proper checksum calculation for header v2
v19.2
- [General] Fix uninstaller
- [General] Fix bootloops on some devices with tmpfs mounting to /data
- [MagiskInit] Add Kirin hi6250 support
- [MagiskSU] Stop claiming device focus for su logging/notify if feasible
This fix issues with users locking Magisk Manager with app lock, and prevent
video apps get messed up when an app is requesting root in the background.
v19.1
- [General] Support recovery based Magisk
- [General] Support Android Q Beta 2
- [MagiskInit] New sbin overlay setup process for better compatibility
- [MagiskInit] Allow long pressing volume up to boot to recovery in recovery mode
- [MagicMount] Use proper system_root mirror
- [MagicMount] Use self created device nodes for mirrors
- [MagicMount] Do not allow adding new files/folders in partition root folder (e.g. /system or /vendor)
v19.0
- [General] Remove usage of magisk.img
- [General] Add 64 bit magisk binary for native 64 bit support
- [General] Support A only system-as-root devices that released with Android 9.0
- [General] Support non EXT4 system and vendor partitions
- [MagiskHide] Use Zygote ptracing for monitoring new processes
- [MagiskHide] Targets are now per-application component
- [MagiskInit] Support Android Q (no logical partition support yet!)
- [MagiskPolicy] Support Android Q new split sepolicy setup
- [MagiskInit] Move sbin overlay creation from main daemon post-fs-data to early-init
- [General] Service scripts now run in parallel
- [MagiskInit] Directly inject magisk services to init.rc
- [General] Use lzma2 compressed ramdisk in extreme conditions
- [MagicMount] Clone attributes from original file if exists
- [MagiskSU] Use ACTION_REBOOT intent to workaround some OEM broadcast restrictions
- [General] Use skip_mount instead of auto_mount: from opt-in to opt-out
v18.1
- [General] Support EMUI 9.0
- [General] Support Kirin 960 devices
- [General] Support down to Android 4.2
- [General] Major code base modernization under-the-hood
v18.0
- [General] Migrate all code base to C++
- [General] Modify database natively instead of going through Magisk Manager
- [General] Deprecate path /sbin/.core, please start using /sbin/.magisk
- [General] Boot scripts are moved from <magisk_img>/.core/<stage>.d to /data/adb/<stage>.d
- [General] Remove native systemless hosts (Magisk Manager is updated with a built-in systemless hosts module)
- [General] Allow module post-fs-data.sh scripts to disable/remove modules
- [MagiskHide] Use component names instead of process names as targets
- [MagiskHide] Add procfs protection on SDK 24+ (Nougat)
- [MagiskHide] Remove the folder /.backup to prevent detection
- [MagiskHide] Hide list is now stored in database instead of raw textfile in images
- [MagiskHide] Add "--status" option to CLI
- [MagiskHide] Stop unmounting non-custom related mount points
- [MagiskSU] Add FLAG_INCLUDE_STOPPED_PACKAGES in broadcasts to force wake Magisk Manager
- [MagiskSU] Fix a bug causing SIGWINCH not properly detected
- [MagiskPolicy] Support new av rules: type_change, type_member
- [MagiskPolicy] Remove all AUDITDENY rules after patching sepolicy to log all denies for debugging
- [MagiskBoot] Properly support extra_cmdline in boot headers
- [MagiskBoot] Try to repair broken v1 boot image headers
- [MagiskBoot] Add new CPIO command: "exists"
v17.3
- [MagiskBoot] Support boot image header v1 (Pixel 3)
- [MagiskSU] No more linked lists for caching su_info
- [MagiskSU] Parse command-lines in client side and send only options to daemon
- [MagiskSU] Early ACK to prevent client freezes and early denies
- [Daemon] Prevent bootloops in situations where /data is mounted twice
- [Daemon] Prevent logcat failures when /system/bin is magic mounting, could cause MagiskHide to fail
- [Scripts] Switch hexpatch to remove Samsung Defex to a more general pattern
- [Scripts] Update data encryption detection for better custom recovery support
v17.2
- [ResetProp] Update to AOSP upstream to support serialized system properties
- [MagiskInit] Randomize Magisk service names to prevent detection (e.g. FGO)
- [MagiskSU] New communication scheme to communicate with Magisk Manager
v17.0/17.1
- [General] Bring back install to inactive slot for OTAs on A/B devices
- [Script] Remove system based root in addon.d
- [Script] Add proper addon.d-v2 for preserving Magisk on custom ROMs on A/B devices
- [Script] Enable KEEPVERITY when the device is using system_root_image
- [Script] Add hexpatch to remove Samsung defex in new Oreo kernels
- [Daemon] Support non ext4 filesystems for mirrors (system/vendor)
- [MagiskSU] Make pts sockets always run in dev_pts secontext, providing all terminal emulator root shell the same power as adb shells
- [MagiskHide] Kill all processes with same UID of the target to workaround OOS embryo optimization
- [MagiskInit] Move all sepolicy patches pre-init to prevent Pixel 2 (XL) boot service breakdown
v16.7
- [Scripts] Fix boot image patching errors on Android P (workaround the strengthened seccomp)
- [MagiskHide] Support hardlink based ns proc mnt (old kernel support)
- [Daemon] Fix permission of /dev/null after logcat commands, fix ADB on EMUI
- [Daemon] Log fatal errors only on debug builds
- [MagiskInit] Detect early mount partname from fstab in device tree
v16.6
- [General] Add wrapper script to overcome weird LD_XXX flags set in apps
- [General] Prevent bootloop when flashing Magisk after full wipe on FBE devices
- [Scripts] Support patching DTB placed in extra sections in boot images (Samsung S9/S9+)
- [Scripts] Add support for addon.d-v2 (untested)
- [Scripts] Fix custom recovery console output in addon.d
- [Scripts] Fallback to parsing sysfs for detecting block devices
- [Daemon] Check whether a valid Magisk Manager is installed on boot, if not, install stub APK embedded in magiskinit
- [Daemon] Check whether Magisk Manager is repackaged (hidden), and prevent malware from hijacking com.topjohnwu.magisk
- [Daemon] Introduce new daemon: magisklogd, a dedicated daemon to handle all logcat related monitoring
- [Daemon] Replace old invincible mode with handshake between magiskd and magisklogd, one will respwan the other if disconnected
- [Daemon] Support GSI adbd bind mounting
- [MagiskInit] Support detecting block names in upper case (Samsung)
- [MagiskBoot] Check DTB headers to prevent false detections within kernel binary
- [MagiskHide] Compare mount namespace with PPID to make sure the namespace is actually separated, fix root loss
- [MagiskSU] Simplify su_info caching system, should use less resources and computing power
- [MagiskSU] Reduce the amount of broadcasting to Magisk Manager
- [ImgTool] Separate all ext4 image related operations to a new applet called "imgtool"
- [ImgTool] Use precise free space calculation methods
- [ImgTool] Use our own set of loop devices hidden along side with sbin tmpfs overlay. This not only eliminates another possible detection method, but also fixes apps that mount OBB files as loop devices (huge thanks to dev of Pzizz for reporting this issue)
v16.4
- [Daemon] Directly check logcat command instead of detecting logd, should fix logging and MagiskHide on several Samsung devices
- [Daemon] Fix startup Magisk Manager APK installation on Android P
- [MagiskPolicy] Switch from AOSP u:r:su:s0 to u:r:magisk:s0 to prevent conflicts
- [MagiskPolicy] Remove unnecessary sepolicy rules to reduce security penalty
- [Daemon] Massive re-design /sbin tmpfs overlay and daemon start up
- [MagiskInit] Remove magiskinit_daemon, the actual magisk daemon (magiskd) shall handle everything itself
- [Daemon] Remove post-fs stage as it is very limited and also will not work on A/B devices; replaced with simple mount in post-fs-data, which will run ASAP even before the daemon is started
- [General] Remove all 64-bit binaries as there is no point in using them; all binaries are now 32-bit only.
Some weirdly implemented root apps might break (e.g. Tasker, already reported to the developer), but it is not my fault
- [resetprop] Add Protobuf encode/decode to support manipulating persist properties on Android P
- [MagiskHide] Include app sub-services as hiding targets. This might significantly increase the amount of apps that could be properly hidden
v16.3
- [General] Remove symlinks used for backwards compatibility
- [MagiskBoot] Fix a small size calculation bug
v16.2
- [General] Force use system binaries in handling ext4 images (fix module installation on Android P)
- [MagiskHide] Change property state to disable if logd is disabled
v16.1
- [MagiskBoot] Fix MTK boot image packaging
- [MagiskBoot] Add more Nook/Acclaim headers support
- [MagiskBoot] Support unpacking DTB with empty kernel image
- [MagiskBoot] Update high compression mode detection logic
- [Daemon] Support new mke2fs tool on Android P
- [resetprop] Support Android P new property context files
- [MagiskPolicy] Add new rules for Android P
v16.0
- [MagiskInit] Support non skip_initramfs devices with slot suffix (Huawei Treble)
- [MagiskPolicy] Add rules for Magisk Manager
- [Compiler] Workaround an NDK compiler bug that causes bootloops
v15.4
- [MagiskBoot] Support Samsung PXA, DHTB header images
- [MagiskBoot] Support ASUS blob images
- [MagiskBoot] Support Nook Green Loader images
- [MagiskBoot] Support pure ramdisk images
- [MagiskInit] Prevent OnePlus angela sepolicy_debug from loading
- [MagiskInit] Obfuscate Magisk socket entry to prevent detection and security
- [Daemon] Fix subfolders in /sbin shadowed by overlay
- [Daemon] Obfuscate binary names to prevent naive detections
- [Daemon] Check logd before force trying to start logcat in a loop
v15.3
- [Daemon] Fix the bug that only one script would be executed in post-fs-data.d/service.d
- [Daemon] Add MS_SILENT flag when mounting, should fix some devices that cannot mount magisk.img
- [MagiskBoot] Fix potential segmentation fault when patching ramdisk, should fix some installation failures
v15.2
- [MagiskBoot] Fix dtb verity patches, should fix dm-verity bootloops on newer devices placing fstabs in dtb
- [MagiskPolicy] Add new rules for proper Samsung support, should fix MagiskHide
- [MagiskInit] Support non skip_initramfs devices using split sepolicies (e.g. Zenfone 4 Oreo)
- [Daemon] Use specific logcat buffers, some devices does not support all log buffers
- [scripts] Update scripts to double check whether boot slot is available, some devices set a boot slot without A/B partitions
v15.1
- [MagiskBoot] Fix faulty code in ramdisk patches which causes bootloops in some config and fstab format combos
v15.0
- [Daemon] Fix the bug that Magisk cannot properly detect /data encryption state
- [Daemon] Add merging /cache/magisk.img and /data/adb/magisk_merge.img support
- [Daemon] Update to upstream libsepol to support cutting edge split policy custom ROM cil compilations
Magisk Manager
v7.5.1
- Fix toggling app components in MagiskHide screen
- Update translations
v7.5.0
- Support new MagiskSU communication method (ContentProvider)
- Fix several issues with hidden stub APK
- Support using BiometricPrompt (face unlock)
v7.4.0
- Hide Magisk Manager with stub APKs on Android 9.0+
- Allow customizing app name when hiding Magisk Manager
- Generate random keys to sign the hidden Magisk Manager to prevent signature detections
- Fix fingerprint UI infinite loop
v7.3.5
- Sort installed modules by name
- Better pre-5.0 support
- Fix potential issues when patching tar files
v7.3.4
- App is now fully written in Kotlin!
- New downloading system
- Add new "Recovery Mode" to Advanced Settings
v7.3.0/1/2
- HUGE code base modernization, thanks @diareuse!
- More sweet changes coming in the future!
- Reboot device using proper API (no more abrupt reboot)
- New floating button in Magisk logs to go to bottom
v7.2.0
- Huge UI overhaul
- More sweet changes coming in the future!
v7.1.2
- Support patching Samsung AP firmware
- Much better module downloading mechanism
v7.1.1
- Fix a bug that causes some modules using new format not showing up
v7.1.0
- Support the new module format
- Support per-application component granularity MagiskHide targets (only on v19+)
- Ask for fingerprint before deleting rules if enabled
- Fix the bug that causes repackaging to lose settings
- Several UI fixes
v7.0.0
- Major UI redesign!
- Render Markdown natively (no more buggy WebView!)
- Support down to Android 4.1 (native Magisk only support Android 4.2 though)
- Significantly improve Magisk log disply performance
- Fix post OTA scripts for A/B devices
- Reduce memory usages when verifying and signing boot image
- Drop support for Magisk lower than v18.0
v6.1.0
- Introduce new downloading methods: no longer uses buggy system Download Manager
- Introduce many new notifications for better user experience
- Add support for Magisk v18.0
- Change application name to "Manager" after hiding(repackaging) to prevent app name detection
- Add built-in systemless hosts module (access in settings)
- Auto launch the newly installed app after hiding(repackaging) and restoring Magisk Manager
- Fix bug causing incomplete module.prop in modules to have improper UI
v6.0.1
- Update to use new online module's organizing method
- When fingerprint authentication is enabled, toggling root permissions in "Superuser" section now requires fingerprint beforehand
- Fix crashes when entering MagiskHide section on some devices
- Remove support to Magisk version lower than v15.0
- Ask storage permissions before patching stock boot image
- Update dark theme CardView color
v6.0.0
- Update to latest AndroidX support library
- Fix crashes when online repos contain incomplete metadata
- Optimize BootSigner to use as little memory as possible, prevent OutOfMemoryError
- Support new communication scheme between Magisk v17.2 and Magisk Manager
- Enable excessive obfuscation to prevent APK analysis root detections (still not 100% obfuscated due to backwards compatibility with stable channel)
2016.10.04
Magisk-v7 is quite a significant update compared to v6. A lot has changed, new features are added, and improved compatibility a lot, especially in selinux issues.
Open Source!
My previous releases has some controversy due to the fact that I included closed source property with unexpected intentions. I had worked hard to create/improve open source tools, so that they can fit my own needs. Magisk is now 100% open source, including the binary it uses.
Brand New Magisk Manager
The Magisk Manager is completely a different application compared to the previous crappy app. It has now packed with features, and it is now part of the core experience of Magisk itself. New features and improvements are still planned, so stay tuned in this application's development!
Repo System, Module Management
We've been putting a lot of effort into constructing this repo system. This change is to make installing Magisk Modules a lot more easier. What I'm aiming is to make Magisk something like Xposed, an interface and a platform for developers to work on. Providing a repo system is a good step towards the goal, as it makes installing new stuffs and receiving updates super simple. I also drastically simplified the Magisk Module template. Right now, I believe anyone with basic knowledge can create their own Magisk Module easily. Changing a few values into a config file should make porting existing mods to Magisk much easier.
Safety Net
My decision to remove root management from Magisk seems to cause some debate. People might wonder why I would remove such feature that made Magisk so popular. Well, I have to emphasize again, Magisk is never meant for bypassing Safety Net. The Xposed and root bypasses are some fun projects that I'm messing with what Magisk is capable of. One of the two main reasons I dropped this feature in Magisk is
1. Xposed is no longer working with Safety Net enabled. I had tried to bypass it with some mounting tricks and process killing, but all of those are not able to fix the issue. Soon suhide is available and it is able to bypass Xposed had made me really frustrated, as I do not want to keep working on a "not complete solution".
2. On the open source side, phh is also developing his own "suhide". phh just released a test build for hiding root (link to his test build), I'm gonna take a look and include it into the Magisk version of phh root.
These two methods are much better than the one I was using. It doesn't need a toggle, it is per app basis, and many more. Also, I'm not creating a root solution, I'm creating an interface that root solutions can rely on. So I decide to give the hiding root "responsibility" to the root solutions, not managed by the interface, Magisk, itself.
Just to let all of you know, one of Magisk Manager's future feature will be a GUI to manage these two root hiding solutions. It will need some time to develop, and I also wanted to do some things in the core Magisk side to add this support natively. So please don't be pissed that I dropped the whole root management thing. It is for a bigger plan
Due to a bug in the template zip, there will be issues flashing the zip files if the path has spaces.
This commit in magisk-module-template should fix the issue.
All repos online is updated with this fix, developers please include this patch into your modules.
2016.10.19 Magisk v8
This release is aimed for bug fixes, and most importantly the ability to hide itself from Safety Net's detection.
Template Cache Module Fix
Due to a bug in the template script, if your module is a cache module, your scripts might not be executed correctly, also flashing in Magisk Manager will cause the UI to break.
This particular commit is the fix, only cache modules are needed to be updated, other modules are working fine.
Search Bar in Download Section
Magisk Manager 2.1 brings search bar to the "Downloads Section", so that it's easier to find a module once the list gets too long.
SuperSU Integration
In the previous release (v7), I decided to automatically convert SuperSU into a Magisk module while installing Magisk. In this release (v8), I make Magisk 100% compatible with SuperSU out of box, not needed to modify how SuperSU work in anyway. For v8 and future releases, Magisk will detect SuperSU patched boot image, and only add the required additional patches to the boot image.
Also, I created further integration for Magisk and SuperSU: Magisk will create a script placed in /data/custom_ramdisk_patch.sh when SuperSU detected. What this means is that the next time you upgrade SuperSU by flashing SuperSU zip in custom recovery, Magisk will automatically be injected. You can also apply OTA updates with FlashFire, and enable SuperSU injection, which will also inject Magisk on-the-go!
For users that was using v7 with SuperSU along with the Helper Module, please manually restore your boot image (should be stored in /data/stock_boot.img), and flash the latest SuperSU, then flash Magisk-v8.
Magisk Hide
This feature should've been released a few weeks ago, but university is killing me lately; overwhelming schoolwork prevents me to finalize the tool, so please pardon my absence and lack of support. But it's still better late than nothing .
In the weeks I have been inactive, Safety Net got a couple updates, each makes bypassing more of an hassle. Magisk v8 introduce "Magisk Hide", the tool to properly hide Magisk, preventing Magisk to break Safety Net features. What it can do is hide all Magisk modules' files and mounts from target processes (e.g. Safety Net), including Magisk compatible phh root maintained by myself.
It cannot hide SuperSU, it cannot hide Xposed. If you want to hide any of them, please use suhide developed by Chainfire.
It should not cause issues as I have been testing quite some while, but if you replace some files with Magisk (known: /system/etc/customize/ACC/default.xml), Google Play Service will constantly crash. Due to this fact, this feature is not enabled by default. You have to manually enable it in the settings of Magisk Manager v2.1 after you upgraded to Magisk v8, and reboot to apply the settings.
Right now, you can manage your own hide list with ways similar to suhide, no GUI:
Code:
(All commands should be run in a root shell)
# Show current list
/magisk/.core/magiskhide/list
# Add new process (the package name should work fine)
/magisk/.core/magiskhide/add <process name or package name>
# Remove a process (might need a reboot to make an effect)
/magisk/.core/magiskhide/rm <process name or package name>
The process com.google.android.gms.unstable (Safety Net) will always automatically be added to the list if Magisk Hide is enabled, so if you just want to bypass Safety Net, just enable in Magisk Manager and you're good to go.
Safety Net - The Already Lost Cat-And-Mouse Game
Keep in mind, in the latest update of Safety Net that just happened in a few hours, Google seems to step up the game, and it might got to the point that no modifications are allowed, and might be impossible to bypass.
Currently on my HTC 10, no matter what I did to the boot image, even just a repack of 100% stock boot image, Safety Net will not pass under any circumstances. On the other hand, my Nexus 9 running stock Nougat seems bypass without issues, with root and modules all enabled and working fine. The boot verification might vary from one OEM to another, HTC's implementation might just be one of the first included into Safety Net, but eventually all major OEMs' method will be included, and at that time I think any Android "mod", including custom kernels, will pretty much break Safety Net. These verification should be coded deep into the bootloader, which is not that easy to crack. So the conclusion is that I will not spend that much time bypassing Safety Net in the future.
The attachment is a screenshot about where to enable Magisk Hide in the app
Magisk MultiROM - POC
I spend some time playing with the possibility of Universal MultiROM by only using Magisk.
Surprisingly, it is not that difficult at all! Here is a small POC video demonstrating my HTC 10 dual booting stock rom and CM 13.
No other dependency is required (e.g. modified TWRP recovery, kext kernel patch etc.). You only need Magisk injected into the boot image, and along with proper settings, by swapping out the boot image, you can load any rom systemless-ly.
What this means is that all Magisk supported device can enjoy MultiROM features! What a great news for flashaholics LOL.
NOTE! The process showed in this video in far from what it will be eventually. I will make the process nice and smooth
2016.11.14 Magisk v9
This release comes with significant updates and changes, doing adjustments to pave the road for the next major update v10: the update with Multirom support!
Please spend some time reading this lengthy release note, the most important information are included in quotes, or bolded and colored in RED.
Also, many other fixes not mentioned here are listed in the changelog.
The End of Cache (post-fs) Modules
This shall be the biggest change for this update. One of Magisk's cool feature is that it can mount files before data and build.prop is loaded (post-fs). Most modules only uses this advantage to modify read-only props (e.g. DPI, fake device model etc.) without modifying build.prop, however with a new tool included in this release (will be introduced in the next section), dealing things in post-fs is not needed anymore.
Instead of having both "Cache Modules" and "Normal Modules" at the same time, confusing both developers and users, creating complexity in module management, the decision is made that "Cache Modules" are no longer supported after this update.
How about some features that require mounting in post-fs mode (known: Changing Boot Animation)? No worries, post-fs mode is still there (as Multirom will depend on this), I only removed the interface for modules.
Magisk no longer let you install cache modules, you have to manually add the files you want to replace, which is actually super easy.
You can place your new files into the corresponding location under /cache/magisk_mount, Magisk will automagiskally manage selinux contexts, permissions and the mounting for you.
For example, you want to replace /system/media/bootanimation.zip, copy your new boot animation zip to /cache/magisk_mount/system/media/bootanimation.zip with any root explorer, Magisk will mount your files in the next reboot.
Click to expand...
Click to collapse
Magisk v9 will remove all installed cache modules under /cache/magisk, which is the previous path where cache modules locate.
Further more, to push developers to upgrade their cache modules, the latest Magisk Manager (v2.5) will filter out cache modules, which means cache modules available in the Magisk repo are NOT shown under the "Download" section in Magisk Manager.
Cache Module developers please refer to the following instructions to update your current module:
Take a look at the changes in this commit (if you're famlier with git, you can just cherry pick this commit, and deal with some minor merge conflicts)
Check the "resetprop" section to understand how to change props without using a cache module, and update your modules accordingly. For example, if you want to replace the build.prop, you no longer need to enable "automount", or bind mount the file manually in your script, as nothing will load it again.; instead, you should enable post-fs-data script, and read your new build.prop file with proper commands. If you want to change certain prop values, just switch from post-fs script to post-fs-data script, and instead of calling "setprop", please call "/data/magisk/resetprop" to set your props.
Remember to remove the "cacheModule" entry or set to false in the module.prop file, or else your module will never show up in the Magisk Download section in the Magisk Manager!
New Badass Tool - resetprop
To be honest, this tool itself deserves a new thread on XDA, as it is super powerful and super cool.
"resetprop", originally named "xsetprop", was initially developed by @nkk71 to bypass the crazy tough detections for Safety Net. Developers found method to bypass the check by modifying the kernel source code, which served the need but the solution is far from perfect as it requires the source code to be available and kernel compiling.
The tool was originally made to directly modify the system prop database. With seeing the potential of this tool, I contacted @nkk71 and start collaborating together, which brings the original simple tool into a full-fledged, all-in-one prop management tool.
Here are some technical details:
System props are handled by "init", a binary located in the ramdisk which starts right after kernel is loaded. "props" are supposed to only have a single writer, and multiple reader, which means only the process "init" has the full control to the prop database. We modify the props (by calling setprop) through an interface called property_service, which will pass the request to init; property_service also handles the triggering of "events" that should be triggered by a prop change. What read-only props means is that property_service will block all requests for modifying props starting with "ro.", as those props are not allowed to be changed once set. To overcome this difficulty, we can mimic how init behaves by directly modifying the trie structured database. However we will not be able to trigger events, as we completely skipped the property_service part. This might be ideal for SN bypasses, but not applicable for Magisk, as I want to load any prop, which should trigger some events to make some changes. So we went a step further and added a feature to "delete" a system prop! As a result, by directly deleting the prop entry in the database, then send a request to property_service, property_service will accept the request and trigger events if needed.
The new tool - resetprop can modify/delete any system prop, including read-only props (prop names starting with "ro.")
You can also read a whole build.prop, overwriting all existing props. The binary will be installed to /data/magisk/resetprop.
Here are some examples for cache module developers to adapt to the new changes:
Code:
# Set any prop (with trigger)
/data/magisk/resetprop ro.sf.lcd_density 480
# Set any prop (without trigger)
/data/magisk/resetprop -n ro.crypto.state encrypted
# Delete any prop
/data/magisk/resetprop --delete magisk.version
# Read props from a prop file
/data/magisk/resetprop --file /magisk/somemod/new_build.prop
Click to expand...
Click to collapse
The tool is originally built with AOSP source, I spent some time to make it much more portable.
Here is the link to the NDK-buildable source of the resetprop used in Magisk: https://github.com/topjohnwu/resetprop
Magisk Hide - Greatly Improved
Another update to pass SN, please grab it before it expires lol
People started to panic when Google device to check boot loader / boot-verity etc. As stated in the previous section, resetprop fixes the issue easily with setting all detecting props to the valid values. However, more detection has been added. One of those is that simply adding Magisk directories into PATH will break Safety Net. Not sure if I should be glad because the word "magisk" is now officially on the tech giant's blacklist......
So in order to hide root (here I'm only referring Magisk phh superuser, as SuperSU users shall always rely on CF's suhide, not MagiskHide), I had to change the way things works.
For the new changes that are required to NOT modify PATH, the phh's superuser has to be upgraded.
Please make sure your phh superuser is upgraded to r266-2 (or any version higher).
Older version will NOT work with Magisk v9, please upgrade phh's su before upgrading.
Also, along with the new Magisk Manager v2.5, we finally had an GUI to add/remove apps from the MagiskHide list!
Click to expand...
Click to collapse
Development
I added build.sh into the main Magisk repo, you can call the script and it will guide you with help messages.
Custom version names are supported, both in Magisk and Magisk Manager (if using custom name, update will disable)
So feel free to clone the repo and develop Magisk yourself! Pull requests are appreciated!
For Magisk Manager, you can provide translations for the app, just translate the strings, create a pull request, and I'll merge it into the main app, many thanks!
Those Pixels
I stated before that the new Google Pixel devices are using a complete different partition structure, as the ramdisk is now stored along with the system partition, and a kernel modification is inevitable.
Without much surprise, our mighty developer Chainfire had released a systemless root for Pixel devices. What it does in a nutshell is bringing back the ramdisk to the boot image, and still do modifications in the ramdisk (rootfs). However it still requires 1. custom init binary 2. binary patch directly to the kernel. If I decide to use the provided closed source solution, it shall not be difficult to port Magisk to the Pixels and start all the systemless craziness, but still I need an device to test and debug. In addition, I would love to see if I can create an open source tool to achieve similar results to make Pixel (which means maybe all future devices) running Magisk.
But the huge issue is: I live in Taiwan, and there is no sign that the Pixels will be available for purchase here, well at least not possible in 2016.
I could ask my buddy studying in the US to bring me one when he comes back at the Christmas vacations (which is still quite some time from now, but still better late than nothing.....), however the problem is that Pixel XLs (the model I prefer) are currently out of stock on the online Google Store, and I will never know if ordering now will make the package show up in my friend's place in time before he comes back to Taiwan.
If anyone seeing this post has access/can purchase brand new Pixel XLs (anywhere should be OK), and possible to deliver them to Taiwan in a reasonable time and a reasonable shipping fee, please contact me and I'll be very happy.
Lastly, I just bought my new HTC 10 within a year. I'm just an university student, the money I earn from tuition could afford me the super expensive Pixel device, but any additional donation to support my open source development is highly appreciated . I'd be really happy that many people love my work!
Click to expand...
Click to collapse
Here are some news....
Lack of Support
School have been super busy lately (getting the last metro to home nearly every day...), I have little if any time to spend on Android development. Another big factor is that I'm still waiting for my laptop to be repaired.
Sorry for all the private messages sending to my inbox, I've got way too many PMs that I'm not in the mood to read through dozens and dozens of them, since a large fraction of them are simply just asking for instructions for installing Magisk on their device.
I prefer REAL issues to be opened on Github, as I check them from time to time, and I can keep track of which are not yet resolved.
Build Friendly
I added build script for Unix-like systems (Linux and macOS) and also for Windows. I tested on all three platforms and all of them are working as expected. For people interested in the latest feature added to Magisk but not included into an official release yet, feel free to build it yourself. I automated the process that even people with no experience in NDK or scripting can build it easily.
Also for people willing to report bugs, please test Magisk built against the latest commit before opening issues on Github, thanks a lot!
Magisk Module Repo?
It has been a while since I last updated the Magisk Module Repo. I know there are a few requests for adding their own modules to the repo. I'm gonna change the way for requests to be handled from the current "posting in a request thread on XDA", to most likely handled through Github. When the new way for requests is decided, I'll add the current requests at once, and close the current thread.
I really appreciate every person who is interested in making a Magisk Module and willing to share it with others, once the new method is decided, the requests should be addressed in a timely manner.
Multirom? Updates?
I've spend my extremely limited free time to fix current Magisk issues, and so far (the latest commit on Github) it has improved a lot compared with the current v9 release.
I haven't really spend much time in the multirom feature, however I found an interesting open source project: DualBootPatcher.
It exists for quite a while, and it is very impressive just like the Multirom Tasssadar created. I haven't looked into how DualBootPatcher works, so I'm not sure if it is using similar tactics method that I switch between systems in a super simple way through Magisk.
2017.1.2 Magisk V10
Happy New Year! What is a better way to celebrate 2017 than a Magisk update
Another massive update!
Official Icon
Instead of using the picture grabbed online, the official Icon for Magisk is now live!
Magisk Hide Back On Stage
This is the most awaited fix, isn't it?
The issue of losing root is haunting since day 1 of the release of Magisk Hide, although it can be temporary recovered with a reboot, it is still quite annoying. I spend a lot of time trying to identify the reason, and soon found out that the issue is caused by MagiskHide reacting "too fast". Most processes starts from Zygote, and it requires a small period of time to isolate the mount namespace apart from Zygote. When MagiskHide reacts too quickly, it will unmount all mounts in the Zygote namespace, which literally means that all processes will lose the mounts (including root).
After adding checks and retries before switching namespaces, it leads to another issue: MagiskHide reacting "too slow". When critical files like framework is Magic Mounted, and the unmounting doesn't happen in time, it will break the SafetyNet checking process (Google Play Service FC), and can never recover until a reboot (or full restart of Google Play Service). I added tons of safety precautions (I won't go into the details here, it will be another few hundred of words), and I can "almost" eliminate all possible breakages.
Due to the fact that Magisk Hide DOES NOT hijack app_process (Zygote), it can only react passively, so there is a limitation to the effectiveness.
The best practice is to NOT add a lot of apps in the blacklist of MagiskHide (managed in Magisk Manager), so that the MagiskHide daemon has the time to react.
Personally I only hide SafetyNet (the preset), and it passes all excessive tests without any issue. However my tester still managed to break it a few times when adding 6 additional apps, and having 10+ accounts syncing at the background all the time. So I guess it is good for most users lol
Magic Mount With No Limits
I'm glad to announce that starting from this update, Magic Mount can do ANYTHING! Thanks to the new mirror implementation and some workarounds in the algorithm, it can now handle adding files to /system root (and /vendor root if separate partition). Also thanks to the new MagiskHide, all mounting combinations can pass SafetyNet!
Magisk Powered Custom ROM: One Click to Custom ROM, Another Click You're Back to Stock
I am a member of an HTC custom ROM developer team - Team Venom, and without too much effort, The world's first Magisk Powered Custom ROMhttp://venomroms.com/worlds-first-100-percent-magisk-rom/ was born!
The advantage over traditional full packaged custom rom is that we ROM developers no longer need to port carrier features (Wi-Fi calling, VOLTE etc.) to our ROMs. Users can install Magisk on their stock devices, load the Custom ROM module, reboot and BOOM all done, along with 100% fully working carrier features. Also, it is just cool to load a custom ROM fully systemless, isn't it!
Developers in the HTC 10 community soon realized the "power of Magisk", and currently trying to push out more and more Magisk Custom ROM Modules.
I hope all developers feel the excitement, and port all stock modified custom ROM to be implemented with Magisk!
For ROM developers interested, please check the link and download the zip to get an idea how to create your own Magisk Custom ROM Module!
Magisk Can Now Root Your Device
I decided to fork the phh Superuser and start doing modifications. From Magisk v10 and after, Magisk will root your device with the bundled root if
a. No root installed b. Root that isn't Systemless SuperSU or older Magisk phh versions installed
Right now you still have to install the phh Superuser application, however the root management should move to Magisk Manager soon, please stay tuned.
Currently it is nearly the same as official phh root with only a few tweaks, but I might add more in the future.
Magisk Manager Now On Play Store
It seems that some already found out that Magisk Manager is now available on Play Store! All future updates will be pushed through Play Store.
Download links will still be posted here, since there are still places where Play Store isn't available.
Documentations Updated, Module Template Updated, New Repo Requests
The documentations here on XDA is pretty outdated, I updated them with more info to assist developers and users to create their own modules.
Module template is updated for an addition option to load a prop file.
Repo requests are also updated, please check out the new instructions!
Sorry guys, in v10 (and the v10.1 if you're fast), when updating within the Magisk Manager, my scripts didn't handle the phh upgrading correctly.
For those got stuck with no root, please flash the latest phh zip downloaded in this thread in custom recovery (or Magisk Manager, because it is the only app that have root access).
Sorry for the inconvenience, please forgive me lol, I'm only one man!
2017.1.11
Magisk Manager v3.1
I'm still dealing with my finals (got an exam tomorrow, and 3 more projects to do......), but the online repo is no longer accessible on Magisk Manager, which forces me to push out an update.
Apart from that critical bug fix, it also comes with a lot of updates and improvements, please check the changelog for further info.
Please update your Magisk Manager from Play Store. The direct link is also updated with the new v3.1 version
Magisk v11.0
2017.2.6 Magisk v11.0
Came back from Chinese New Year holiday with some significant updates!
Introducing MagiskSU
Magisk officially becomes its own rooting solution!
Initially I just want to add root management features into Magisk Manager, but ended up updating lots of code.
Since the changes are quite significant, and no longer compatible with older versions, I'll just name it MagiskSU instead of phh Superuser.
The code is based on phh's approach to update the CM Superuser. I spent quite some effort to achieve SuperSU standards, so far the functionality should be nearly equivalent, my only concern now is compatibility, which is what I will focus on in future releases.
Please note, Magisk is still fully compatible and functional with the latest SuperSU (tested against v2.79-SR3)
The Fully Re-factored sepolicy-inject tool
To accompany with the fresh new MagiskSU, I also spent a ton of effort re-factoring the tool sepolicy-inject.
The tool now accepts policy statements, you can get more info about it from from this section of @Chainfire 's wonderful How-To SU documentation.
Basically I aimed to follow the same syntax as SuperSU's supolicy tool, as it is straight forward and same as the .te policy sources. I added a few additional features in sepolicy-inject, you can directly execute the binary with no options to refer to the help info.
See all changes in the changelog
(I named it "sepolicy-inject" instead of "supolicy", since it still differs in many ways (e.g the built-in rules) even though the syntax is now nearly identical. Root app developers might want to handle this difference when live patching sepolicies)
Pseudo SELinux Enforce Mode
Thanks to the new sepolicy-tool, pseudo enforced mode is now possible (the status shows enforced, but actually is permissive).
In some versions of Google Play Services, setting SELinux to permissive causes Safety Net to fail; however some custom ROMs require the system to be in permissive to be fully functional (although it should be considered as a bad practice). This shall be the perfect solution.
This will not be as a switchable option within Magisk Manager, since Google has a history of pulling apps from the Play Store when related to SELinux (see the tragic example of developer @flar2 's awesome app, and there are still more incidents).
MagiskHide binary is now updated to detect the permissive state, patch the current sepolicy to pseudo enforced mode, then switch back to enforced.
ROM developers don't have to change anything, just simply set to permissive on boot with a bundled app or a boot script as usual. If a user decided to enable MagiskHide, it will handle everything itself.
General Purpose Boot Scripts
I removed this feature in Magisk v4 and favored the per-module scripts. Now I decided to bring it back again.
The scripts should be placed in /magisk/.core/post-fs-data.d and /magisk/.core/service.d. The directory name should be self-explanatory.
If you have no idea which to choose, the post-fs-data.d will be a nice bet.
So Magisk will now execute script named post-fs-data.sh in each module, and all files within post-fs-data.d. The same applies to service.
Future
Thank you for everyone providing translations to Magisk Manager, and huge thanks to all donated.
I appreciate all the support, and that is my motivation to continue pumping stuffs out!
I will be maintaining MagiskSU continually; support won't end, at least in the near future.
Magic Mount features and better Magisk Module support are also on my list.
I spent zero time on adding more support to devices in v11, all the effort were put in MagiskSU and MagiskManager and major bug fixes.
The whole project is now in the state I consider "feature-packed" enough, most users/developers haven't used the full potential of the features.
I'll stop adding major new features and instead focusing on bringing Magisk to more devices that currently isn't supported.
And yes, that means I will postpone the long planned but never worked on Multi-ROM feature (I barely spent time on it after the POC video)
Hope you all will enjoy the update
(P.S. It's 9 AM here and I haven't slept. I'll update documentations after some sleep)
Before I got the in-app guides done, here are some tips for you
Many people seems missing these details
2017.2.19 Magisk Manager v4.2
Magisk Manager v4.2 is now live on Play Store. OP direct links are also updated accordingly.
Tons of improvements to the app, check the changelog for more info
Where is the Magisk Update?
I'm aware there are issue in Magisk v11.1 (vendor mount issues, and MagiskSU system rw issue)
I already fixed the system rw MagiskSU issue (so TiBack now 100% functional), you can check the Superuser sources if you're interested into the solution
I'll push an update soon after I fixed all currently known issues, AND add compatibility to more devices.
Please note that I'm only one single man, and also got a real life to deal with, so I can only focus one thing at a time.
I decided to first improve the Magisk Manager application to a point I think it's acceptable. Android application development is quite tedious, I have to put quite some time and effort into it.
After this Magisk Manager update, I will put all my attention on the core Magisk part, so please stay tuned!
New Online Module Info Display
I updated the way Magisk Manager show the details of Online Magisk Modules in the repo.
Previously I let each module include a changelog.txt, donate link, and support link
However, I think it would be better to let module developers to write anything they want
And considering the text rendering needs to be nice and clean, I think Markdown is the best choice here!
You can include links to your thread, links to your donation link, download link for an app required, changelog.... anything!
All Repo Developers Aware!
In Magisk Manager v4.2, the app will read the README.md file within your repo, and render the file properly
The changelog.txt file, support and donate entry within module.prop are no longer read, they can be removed.
Please update your README.md file ASAP to let the new app properly display what your modules do.
Here is an example, I updated the Xposed module's README.md, you can see the results in attachments
This is also a screenshot of what the new UI looks like
Magisk Manager v4.2.5 is live!
Hot fix for Samsung crashes (theoretically, no device to test), also did several adjustments here and there
As usual, full changelog in 2nd post, direct links and Play Store (might need to wait a few hours) are also updated
Sorry for the inconvenience!
Magisk Manager v4.2.6
Finally got the Samsung crash fixed!! Thank you for everyone reporting giving feedback, really appreciate the community!
As a compensate for the frequent updates and inconvenience, I added another feature that was requested to Magisk Manager - add a setting to disable update notifications
Play Store might take a few hours to update, direct link in OP is updated
Finally, I can now focus on the core part, which IMO is much much more important
Device compatibility should be GREATLY improved once the work is done, stay tuned!
For Pixel support though, I'll need to borrow my friend's Pixel XL for a couple of weeks to develop, but this might not happen soon since school is quite busy.
2017.3.21 Magisk v11.5/v11.6
It's about time for some Magisk update!!
Magisk Binary Changes
The original tool sepolicy-inject is now renamed to magiskpolicy. However, for backward compatibility, a symlink named sepolicy-inject will be created, which simply just links to magiskpolicy
The original tool bootimgtools is now renamed to magiskboot, which is a complete rewrite of the existing boot image patching tool. More info later.
Starting from this release, magiskpolicy, sepolicy-inject, resetprop, and if MagiskSU is installed, su, and supolicy (this is NOT the SuperSU supolicy, it just links to magiskpolicy, exists for compatibility) are all added to the PATH, which means you can directly call these commands through shell (and apps) without explicitly calling "/data/magisk/XXXXX"
In a nutshell:
Code:
/sbin/su -> /data/magisk/su
/sbin/resetprop -> /data/magisk/resetprop
/sbin/magiskpolicy -> /data/magisk/magiskpolicy
/sbin/sepolicy-inject -> /data/magisk/magiskpolicy
/sbin/supolicy -> /data/magisk/magiskpolicy
/data/magisk/sepolicy-inject -> /data/magisk/magiskpolicy
New Boot Image Tool: MagiskBoot
I spent a lot of time rewriting the whole boot image patching tool. For now it shall GREATLY improve the compatibility of Magisk. Key features:
Complete rewrite boot image extracting process
Proper MTK header support
Sony ELF type boot image support
Native ramdisk compression method support : gzip, xz, lzma, bzip2, lz4
This means custom kernel developers can now use a different ramdisk compression method with their custom kernels!
Native cpio patching support: auto ramdisk backups, auto ramdisk restores, auto dm-verity patch, auto forencrypt patch, native cpio extract/mkdir/add
This means boot patching process itself does not require root access anymore (it usually does)
Native LG bump and Samsung SEANDROIDENFORCE flag detection
More Magisk installation methods shall come soon!
I believe some of the features above do not exist in any existing rooting methods, I hope this will bring more users on the Magisk bandwagon
MagiskSU Fixes
In all current open source root methods, a common issue is that some apps (most well-known: Titanium Backup) cannot properly mount /system to read-write. Here I'll only briefly explain the technical details.
After spending very many hours, the victims are narrowed down to programs that directly use the "mount" system calls instead of calling the "mount" command. Also, the issue does not only happens to /system, but instead any read-only partitions. The only way to remount them to rw is through the toybox implementation of the mount command, which should be the default of all devices. This means that any external mount command (e.g. busybox) cannot remount them to rw either. After digging through the AOSP toybox source code and some search through the commits, I finally found the culprit: this commit in AOSP. What that commit does in a nutshell is that all blocks mounted read-only will be locked to read-only.
So starting from this release of MagiskSU, all blocks will be unlocked when the daemon is started (this does NOT break your system integrity, meaning it does not break OTAs), everything should work fine.
Another subtle change is that the command "-cn" will not do anything starting from now. All root developers can call the "-cn" command on both SuperSU and MagiskSU, it shall work in both cases.
I had tried to add the "-cn" command in the previous release, which only exists in SuperSU, but it was not implemented correctly, and apps depending on it will not work correctly.
However, this "context switch" command is originally added to SuperSU due to the way it managed selinux back in the old days. The way I deal with selinux, starting from Magisk v7 (Chainfire switched to similar method in his latest beta) DOES NOT need any context change, as all root procedures and processes are running in a permissive domain (in Magisk's case it's a domain that allows everything, which is slightly different to permissive. This is because permissive does not work on Sammy)
Magic Mount Vendor Issues
In Magisk v11.1, devices with a separate vendor partition (newer Nexus devices) will fail to properly magic mount files in vendor, the most common issue is using the ViPER4Android Magisk module.
It is now fixed in v11.5
Module Template Update
The Magisk Module Template is now updated. All developers please adapt your modules to the newer version
An entry in module.prop called template now indicates the template version number.
In future Magisk Manager updates, it will only show the modules that are using the latest two versions of the template.
e.g. If the latest template version is v13, only v13 and v12 modules will be showed in the repo
This gives the time for developers to update their modules, but also enforcing them to adapt to newer scripts, so I don't need to support the old template formats.
I apologize that I was busy and didn't add the existing module requests, I'll add them once you have migrated your module to the latest template
Also please note that I will NOT add modules that ONLY change some props using resetprop, as this is a upcoming feature to Magisk Manager in the near future.
What's Next?
Magisk v11.1 got over 500K downloads! Thank you for all the support!
The next short term goal is to add more features into MagiskManager (including the mentioned prop management, and a new installation method)
The long term goal will be migrating the current script-based magic mount to C program, which shall be run as a daemon in the background, combining resetprop, magiskhide etc. all-in-one. This will take some time to finish though.
For the long awaited Pixel support, I think I'll start working on it, but the complexity of that device might take a very long time for me to understand, since I do not own the device. I can only borrow my friend's device for not that long of a period of time, so progress shall be really slow. I'll not get the Pixel device now, because I don't think it is worth the price and the hassle for me to import it into Taiwan, but I'll definitely get the Pixel 2 to replace my current daily driver lol.
Magisk v11.6 Hotfix
The issue turns out to be a veeeery minor issue, but causes the whole script unable to run correctly on Samsung devices.
Also, I fixed the incorrect value for selinux prop patching for MagiskHide, so people with selinux issues should now be settled.
I guarantee all future releases will go through serious beta testing, especially Samsung devices. This project is in a scale that these kind of mistakes cannot be tolerated.
I'm sorry for all the inconvenience the previous release gave you, and the mess and headaches for all broken devices.
The Module Template is again updated. This bug will also affect module templates, so please update accordingly, thanks!!
But still, I hope you will enjoy this new release
2017.3.31 Magisk V12.0
The major version bump should label this release as a stable release (at least this is what I hope)
This release is thoroughly tested by all my testers, especially focusing on Samsung devices
Unless major issues, the next release should be a complete new redesign, and requires more time, more info later
The FAQ in OP is updated, please check them out!!!
Samsung, Samsung, oh Samsung
My previous release was widely criticized for breaking tons of Samsung devices, the rating on Play Store also reflected this fact
Thanks to helpful testers and developers, we ironed out all the quirks of Sammy, and in addition added more Samsung specific features.
One is adding proper support for Samsung permissive kernels. Another is faking KNOX to 0x0 if MagiskHide enabled.
Is that good enough to compensate my mistakes in the last release?
Sepolicy Live Patch Moved
Another critical update is that the sepolicy live patching is now moved from the post-fs-data mode to the service mode.
This decision is done due to the fact that on some devices (e.g. Samsung), there are too much to patch, which greatly delays the bootup time if the live patching is done in a blocking stage. However, this will require some updates for the minimal sepolicy rules.
The minimal patch is now a little more complete, which requires 20-80KB of ramdisk size (previously 1-4KB). Still not large to be honest.
However, this makes post-fs-data mode NOT completely unrestricted. post-fs-data mode can still do any file related operations, setting system props etc., a lot more than normal users would use. However, service mode would be guaranteed to be executed AFTER the full sepolicy patch is done.
It is recommended to run most scripts in the service mode (service.d/service.sh), except a. mounting files; b. patching system props; c. time critical operations
Magisk Core Only Mode
People complain that Magisk has "too many features", they don't want to use such "complete" solution.
Here I introduce Core Only Mode. It can be enabled in the new Magisk Manager.
What will still be started: MagiskSU, post-fs-data.d, service.d, (if enabled: MagiskHide, systemless hosts, systemless busybox)
What will not be started: Cache (post-fs) mounts, magic mount (system mirror etc.), all modules, all module scripts
So it literally limits Magisk to root + boot scripts. MagiskHide is still there for those who want some Mario Run lol.
Say Goodbye to Outdated Modules
This day finally comes. All modules on the repo that aren't using the latest template (v3 for now) are now hidden.
This not only guarantees that the modules are using the latest scripts, but also a nice way to filter out modules that are no longer maintained by the uploader.
You have to add/update template=(ver) in your module.prop. Magisk Manager will not know if you only updated the scripts
Upcoming Features
Here are some planned features (sorted in priority)
Magisk Manager resetprop GUI
MagiskSU multiuser support
Unified Magisk daemon: As stated before, I'm planning to write Magic Mount in code to achieve more efficiency and features.
All current Magisk features (magiskpolicy, magiskhide, resetprop, superuser, magic mount) will be in a unified daemon
Pixel (XL): Some developers has done some progress, I'll contact them and sort things out
Android O: I bought a Nexus 5X now, finally got some O love
Some details are changed in v12.0, I'll update the documentation (wiki) soon.
Some Recent Updates
I wish I can be more vocal in the forums, so more information can be spread to the community, but being a university student in Taiwan, studying engineering specifically, is not easy.
It has been a while since the last release, I think I would shed some light regarding the next big update.
Unified Binary
First, the most obvious change is that Magisk no longer rely on the overly complicated scripts, but instead replaced with pure C/C++ programs. Along with Magisk's development, more and more features were added, and those cannot be done with scripts are added as binaries (magiskhide, magiskpolicy, resetprop etc.). As a result, in the last build (v12.0) there are tons of binaries scattered, loosely working together with poor communication.
So the first thing to do is to combine everything as a single program, something like busybox, which is a single binary that acts as multiple utilities. This took me quite some time to finish, especially merging the existing superuser with other parts that also requires daemon connection. Another tricky part is to port the spaghetti shell script into proper C code. The good news is that both of them are done (though, some small bugs might exist and I'm currently hunting them down)
No More Busybox!
Second is the decision to remove the bundled busybox. Initially I added busybox into Magisk due to lack of proper commandline tools in native Android environment (e.g. lack of losetup in Android 5.0), and also many selinux specific options for several utilities do not exist in official AOSP toolbox/toybox. The big problem is that the busybox causes more issues than I would ever expect. Many features in v12 are implemented to only work with that specific busybox bundled with Magisk. However due to the variety of configurations of custom roms, the assumption that the target busybox is always there, working as expected obviously isn't true, leading to numerous breakage and headaches. This is one of the reason why tons of issues submitted to Github are not addressed, because all pre-v13 are haunted with the same issue - the environment Magisk is running is a mess.
However, thanks to ditching shell scripts completely, currently I handle everything by natively calling system calls, or by implementing the functions directly into the binary (another tedious task...). So Magisk now works as a complete package itself, no more dependency and requirements in the environment. Due to this change, the Magisk Manager would need to include a busybox in order to provide the environment to install Magisk modules/Magisk updates, which I think many tracking the development on Github would already notice this change.
Those wondering how to add busybox if they want? I'll release a new module in the repo.
Android O
Finally, Android O support! As expected, Android O has quite some security changes, but since I'm gonna start everything from scratch anyway, things are all quickly sorted out. Also thanks to the arrival of my Nexus 5X, I can finally test things on an actual device, as a result Magisk is now 100% working on Android O DP1. The module template might need some slight updates regarding Android O changes, please stay tuned for the announcement!
Of course, tons of other improvements are also included, I won't list all of them here and will leave them for the release post and changelogs. Updates to Magisk Manager are also work in progress (application development is very tiresome...). There are still tons of features/support bugging in my mind and I would hope I can implement all, but the reality and school prevents me to do so, I am now aiming more towards a stable release rather than rushing out poorly designed features and making me regret in future maintenance lol.
I won't have time to publish lots of informative posts as this one, for those who are interested in the active development of Magisk/Magisk Manager, please keep track of the Github repos. I always keep the development work transparent, anyone curious can spend a little effort to build it themselves and have a sneak peak of what's currently going on. Just keep in mind that the cutting edge master branch does not always work properly
Related
After a bit of tinkering and some insight from Chainfire and imoseyon i was finally able to get SuperSU working on AOSP roms without being permissive or having to use Chainfire's prebuilt sepolicy
sepolicy patch is here: https://github.com/PureNexusProject...mmit/0f5072de4580a5db7348917e77e4c1c35d3e3c1a
Stickied.
sorry to be that guy, but how does this affect the average joe?
does it mean theres going to be a new version of supersu with this or does this mean that custom rom makers can use this patch to make there roms not need the the custom boot.img?
WarningHPB said:
sorry to be that guy, but how does this affect the average joe?
Click to expand...
Click to collapse
It doesn't, this is for ROM devs only, they know what to do with this.
Chainfire said:
It doesn't, this is for ROM devs only, they know what to do with this.
Click to expand...
Click to collapse
Welcome back! Hope you had a good break.
Chainfire said:
Stickied.
Click to expand...
Click to collapse
Thanks after including this in my AOSP builds i have noticed a few things, certain "root" app still dont function and get selinux denials. i originally had noticed this with logcat extreme. i was getting read and write denials on logd so i did an audit2allow on my sepolicy and came up with the following allow
Code:
#============= logd ==============
allow logd init:fifo_file { read write };
i did a quick google search on this and came up with https://gist.github.com/poliva/fc5b7402bde74be27518 which is apparently an sediff of your sepolicy, which is heavily modified beyond just what i had for supersu to work in enforcing for aosp roms. so i guess my real question is do us "AOSP" devs have to update our sepolicys with these 300+ additions to get all current root apps working or is this something that you can overcome in an update to SuperSU.
thanks in advance :good:
BeansTown106 said:
Thanks after including this in my AOSP builds i have noticed a few things, certain "root" app still dont function and get selinux denials. i originally had noticed this with logcat extreme. i was getting read and write denials on logd so i did an audit2allow on my sepolicy and came up with the following allow
Code:
#============= logd ==============
allow logd init:fifo_file { read write };
i did a quick google search on this and came up with https://gist.github.com/poliva/fc5b7402bde74be27518 which is apparently an sediff of your sepolicy, which is heavily modified beyond just what i had for supersu to work in enforcing for aosp roms. so i guess my real question is do us "AOSP" devs have to update our sepolicys with these 300+ additions to get all current root apps working or is this something that you can overcome in an update to SuperSU.
thanks in advance :good:
Click to expand...
Click to collapse
There is no such thing now as "all current root apps working".
If SuperSU's deamon can be launched, and it can in turn launch the supolicy tool, most of the rules from the diff will be modified by SuperSU as needed.
What your patch needs to do (and you have already done) is make sure SuperSU can be launched in the right context, and can modify the sepolicy. You do not need to implement those 300+ additions - it will be done at boot automagically.
As for those additions themselves, they are primarily needed to:
- make sure SuperSU can work, internal communications between the different processes and such
- make processes running as the "init" context (where root apps run by default) as powerful as possible
- specifically "allow" a number of things that would otherwise still work, but would be logged (everything that starts with "allow init" or "allow recovery")
Now, even with the above, still not everything works out of the box. Everything that goes from "init" to "non-init" context should already work, but going from "non-init" context to "init" may not. In your example case, we go from "logd" to "init", which isn't specifically allowed. Often apps can be fixed to work around an issue such as this.
Generally speaking, the solution is not to fix the source sepolicy or the supolicy tool, the solution is for the "logcat extreme" app to run the following at launch (as documented in How-To SU):
Code:
supolicy --live "allow logd init fifo_file { read write }"
In this specific case, maybe it could be added to supolicy, it depends on what exactly generates the audit. If it's a simple logcat command, it's a candidate for inclusion. The problem might even be solved by switching contexts rather than modifying any SELinux policies. But that is something for the app developer to figure out.
In either case, it is not something you need to fix in the AOSP patches. Those already do what they need to do.
Since they started doing SELinux Enforcing though, the policies in AOSP have generally been a tad stricter than on retail devices (this was specifically the case during 4.4 days). This may lead to you sometimes having to add/remove a rule manually somewhere that was not added to SuperSU yet. It could happen, but it's unlikely, probably temporary, and it probably should not go into this AOSP patch.
A note on pof's sediff, I'm not sure it was done cleanly, as I see some modifications in there that are not done by supolicy. Either way, such a post is informative, not leading, as supolicy may do more or less modifications depending on various runtime variables (such as Android version). Additionally, due to context names and availabilities changing between Android versions, any rule modification referencing a context not available in the to-be-patched sepolicy will not be applied, and thus will not show up in an sediff.
@BeansTown106
Have you checked by any chance if this patch is enough to allow 2.61 (systemless) to work still ?
Chainfire said:
@BeansTown106
Have you checked by any chance if this patch is enough to allow 2.61 (systemless) to work still ?
Click to expand...
Click to collapse
thanks for the description above now i understand. have never developed a root app so i had not read that part of how to su, but it makes perfect sense that the root apps would handle the denials live via your supolicy
as for system less root i have not tried that yet but i will give it a shot tonight, and report back, i know some people in my ROM thread have used system less root. but i am not sure if you had packaged your sepolicy in the install script for 2.61+ and if it is overwriting mine in the kernel, if that is the case i will modify the installation to not patch the sepolicy and see if it works with my pre compiled one based on the source above
Starting 2.64, I think this addition to init.te is all that is needed:
Code:
allow init kernel:security load_policy;
Confirmation needed though. The original patch will also work with 2.64, and the ZIP installer should default to /system installation mode.
Of course, this also requires that /system isn't verified by dm-verity, and init reloads sepolicy from the standard /data/security/current location.
the link in OP its no longer working...
Also in CM13 tree we have:
Code:
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
# allow init kernel:security load_policy;
and over my builds have no problem with SuperSU system less...
Chainfire said:
Starting 2.64, I think this addition to init.te is all that is needed:
Code:
allow init kernel:security load_policy;
Confirmation needed though. The original patch will also work with 2.64, and the ZIP installer should default to /system installation mode.
Of course, this also requires that /system isn't verified by dm-verity, and init reloads sepolicy from the standard /data/security/current location.
Click to expand...
Click to collapse
will build and test with only load policy enabled, is this for system, and systemless root?
danieldmm said:
the link in OP its no longer working...
Also in CM13 tree we have:
Code:
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
# allow init kernel:security load_policy;
and over my builds have no problem with SuperSU system less...
Click to expand...
Click to collapse
updated link, so your saying systemless supersu works with no selinux modifications?
BeansTown106 said:
updated link, so your saying systemless supersu works with no selinux modifications?
Click to expand...
Click to collapse
Over my builds yes, no issues at all in cm13, although my kernel it's in permissive mode. Maybe it's why it works all good?
Enviado do meu A0001 através de Tapatalk
danieldmm said:
Over my builds yes, no issues at all in cm13, although my kernel it's in permissive mode. Maybe it's why it works all good?
Enviado do meu A0001 através de Tapatalk
Click to expand...
Click to collapse
that is why, these patchs are to allow you to run in enforcing
I dont know if a should post here this question: there is any way to fix this problem with the rom already installed?
Thanks
Garzla said:
I dont know if a should post here this question: there is any way to fix this problem with the rom already installed?
Thanks
Click to expand...
Click to collapse
Try the following. It works for me when needed...
http://forum.xda-developers.com/showthread.php?t=3574688
Thank you for your work!
Link in OP its no longer working...
Is there any actual guide how to add SU directly to AOSP build. I have found bits and pieces but those are mainly 4.x releases.
I'm using Android M release and quite much struggling to get it working.
I have tried to make SU default on AOSP 6.0 by using this guide.
http://forum.khadas.com/t/gapps-and-su-on-soc/118/3
I'm using user build and enabled selinux permissive on that.
i have made also ro.secure=0 ro.debuggable=1 and security.perf_harden=0 (Not sure if needed)
I have also modified to change the su permissions in fs_config.c
I managed to get this work so that when flashing rom SuperSu ask for updating su binary and after that su works.
but i then cleaned work area to verify build by deleting out dir and recompiled. No go anymore.
Why it's so hard to add su by default on AOSP rom. I woud like to have it by default so i would not need to do any tricks everytime i flash new rom.
It reminds me of Korean dramas ,
THIS IS CURRENTLY NOT WORKING
A newer version is available here: https://forum.xda-developers.com/apps/supersu/suhide-lite-t3653855
suhide is an experimental (and officially unsupported) mod for SuperSU that can selectively hide root (the su binary and package name) from other applications.
Pros
- Hides root on a per-app base, no need to globally disable root
- Doesn't need Xposed
- Even supports SuperSU's ancient app compatibility mode (BINDSYSTEMXBIN)
- Passes SafetyNet attestation by default on stock ROMs (last officially tested on 2016.10.07)
Cons
- Ultimately a losing game (see the next few posts)
- No GUI (at the moment) - Unofficial GUI by loserskater
Requirements
- SuperSU v2.78 SR1 or newer (link)
- SuperSU installed in systemless mode
- Android 6.0 or newer
- TWRP (3.0.2 or newer, with access to /data - link!) or FlashFire (link)
Xposed
Xposed is not currently officially supported, but if you want to use it directly, you must be using @topjohnwu 's systemless xposed v86.2 exactly (attached at the bottom). It seems to mostly work during my non-extensive testing, but there are still some performance issues (both boot-time and run-time). Proceed with caution, expect bootloop.
Alternatively, there are some reports that the latest Magisk version + the latest systemless xposed (for Magisk) also works. I have not personally tested this.
CyanogenMod
I've personally tested with CM13 on i9300 without issue, however, several users are reporting it doesn't work for them. Proceed with caution, expect bootloop. Also, aside from just flashing SuperSU, you need to make sure /system/bin/su and /system/xbin/su are removed, or CM's internal root will still be used.
Usage
Install/Upgrade
- Make sure you have the latest SuperSU version flashed in systemless mode
- Make sure you are using the latest TWRP or FlashFire version
- Remove any and all Xposed versions
- If you have been having issues, flash suhide-rm-vX.YY.zip first, and note that your blacklist has been lost.
- Flash the attached suhide-vX.YY.zip
- If you are upgrading from suhide v0.16 or older, reflash SuperSU ZIP, and note that your blacklist has been lost.
- Optionally, flash the Xposed version linked above, and pray
At first install SafetyNet is automatically blacklisted.
If you have just flashed a ROM, it is advised to let it fully boot at least once before installing suhide.
Uninstall
- Flash the attached suhide-rm-vX.YY.zip. The version may appear older, the uninstall script doesn't change very often.
Blacklisting an app
You need the UID (10000 to 99999, usually 10xxx) of the app, which can be tricky to find, or the process name. There may be a GUI for this at some point.
(Note that all commands below need to be executed from a root shell)
If you know the package name, ls -nld /data/data/packagename will show the UID - usually the 3rd column.
Similarly, for running apps, ps -n | grep packagename will also show the UID - usually the 1st column.
Note that the process name is often the same as the package name, but this is not always the case. UID is more reliable for identifying a specific app, and it is also faster than blocking based on process names.
When you know the UID or process name:
Add to blacklist: /su/suhide/add UID or /su/suhide/add processname
Remove from blacklist: /su/suhide/rm UID or /su/suhide/rm processname
List blacklist: /su/suhide/list
All running processes for that UID or process name need to be killed/restarted for su binary hiding. For SuperSU GUI hiding, the device needs to be restarted. I recommend just (soft-)rebooting your device after making any changes.
Please keep in mind that many apps store their rooted state, so you may need to clear their data (and then reboot).
Integration into SuperSU
This mod isn't stable, and probably will never be (see the next few posts). As SuperSU does aim to be stable, I don't think they're a good match. But who knows, it all depends on how things progress on the detection side.
Detections
This mod hides the su binary pretty well, and does a basic job of hiding the SuperSU GUI. The hiding is never perfect, and suhide itself is not undetectable either. This will never be a perfectly working solution.
Debugging bootloops
- Get your device in a booting state
- Make sure you have TWRP or a similar recovery
- Install LiveBoot (link)
- If you are not a LiveBoot Pro user, enable the Freeload option
- Enable the Save logs option
- Recreate the bootloop
- In TWRP, get /cache/liveboot.log , and ZIP+attach it to a post here.
Download
Attached below.
Any rm version should work to uninstall any suhide version.
There may be multiple versions of suhide attached, please look carefully which one you are downloading!
YOU ARE EXPLICITLY NOT ALLOWED TO REDISTRIBUTE THESE FILES
(pre-v0.51: 17410 downloads)
Hiding root: a losing game - rant du jour
Most apps that detect root fall into the payment, banking/investing, corporate security, or (anit cheating) gaming category.
While a lot of apps have their custom root detection routines, with the introduction of SafetyNet the situation for power users has become worse, as developers of those apps can now use a single API to check if the device is not obviously compromised.
SafetyNet is of course developed by Google, which means they can do some tricks that others may not be able to easily do, as they have better platform access and control. In its current incarnation, ultimately the detection routines still run as an unprivileged user and do not yet use information from expected-to-be-secure components such as the bootloader or TPM. In other words, even though they have slightly more access than a 3rd party app, they still have less access than a root app does.
Following from this is that as long as there is someone who is willing to put in the time and effort - and this can become very complex and time consuming very quickly - and SafetyNet keeps their detection routines in the same class, there will in theory always be a way to beat these detections.
While reading that may initially make some of you rejoice, this is in truth a bad thing. As an Android security engineer in Google's employ has stated, they need to "make sure that Android Pay is running on a device that has a well documented set of API’s and a well understood security model".
The problem is that with a rooted device, it is ultimately not possible to guarantee said security model with the current class of SafetyNet tamper detection routines. The cat and mouse game currently being played out - SafetyNet detecting root, someone bypassing it, SafetyNet detecting it again, repeat - only serves to emphasize this point. The more we push this, the more obvious this becomes to all players involved, and the quicker SafetyNet (and similar solutions) will grow beyond their current limitations.
Ultimately, information will be provided and verified by bootloaders/TrustZone/SecureBoot/TIMA/TEE/TPM etc. (Samsung is already doing this with their KNOX/TIMA solutions). Parts of the device we cannot easily reach or patch, and thus there will come a time when these detection bypasses may no longer viable. This will happen regardless of our efforts, as you can be sure malware authors are working on this as well. What we power-users do may well influence the time-frame, however. If a bypass attains critical mass, it will be patched quickly.
More security requires more locking down. Ultimately these security features are about money - unbelievably large amounts of money. This while our precious unlocked bootloaders and root solutions are more of a developer and enthusiast thing. While we're all generally fond of shaking our fists at the likes of Google, Samsung, HTC, etc, it should be noted that there are people in all these companies actively lobbying to keep unlocked/unlockable devices available for us to play with, with the only limitation being that some financial/corporate stuff may not work if we play too hard.
It would be much easier (and safer from their perspective) for all these parties to simply plug that hole and fully lock down the platform (beyond 3rd party apps using only the normal APIs). Bypassing root checks en masse is nothing less than poking the bear.
Nevertheless, users want to hide their roots (so do malware authors...) and at least this implementation of suhide is a simple one. I still think it's a bad idea to do it. Then again, I think it's a bad idea to do anything financial related on Android smartphone that isn't completely clean, but that's just me.
Note that I have intentionally left out any debate on whether SafetyNet/AndroidPay/etc need to be this perfectly secure (most people do their banking on virus ridden Windows installations after all), who should get to decide which risk is worth taking, or even if Google and cohorts would be able to design the systems more robustly so the main app processor would not need to be trusted at all. (the latter could be done for Android Pay, but wouldn't necessarily solve anything for Random Banking App). While those are very interesting discussion points, ultimately it is Google who decides how they want this system to work, regardless of our opinions on the matter - and they want to secure it.
--- reserved ---
Changelogs
2016.10.10 - v0.55 - RELEASE NOTES
- Some code cleanup
- Support for blocking based on process name
- Should fix some crashes (requires uninstall/reinstall to activate)
2016.10.07 - v0.54 - RELEASE NOTES
- Fix for latest SafetyNet update
2016.09.19 - v0.53 - RELEASE NOTES
- Haploid container (monoploid)
2016.09.18 - v0.52 - see v0.51 release notes below
- Fix root loss on some firmwares
2016.09.18 - v0.51 - RELEASE NOTES
- Complete redesign
- Zygote proxying (haploid)
- Binder hijacking (diploid)
- su.d instead of ramdisk modification
- Xposed supported (-ish)
2016.09.04 - v0.16 - RELEASE NOTES
- Fix some SELinux access errors
- Should now work on devices that ask for a password/pattern/pin immediately at boot - for real this time!
- Binderjacking improvements for Nougat
2016.08.31 - v0.12 - RELEASE NOTES
- Fix some issues with suhide-add/rm scripts
- Fix not working at all on 32-bit devices
- Should now work on devices that ask for a password/pattern/pin immediately at boot
- Rudimentary GUI hiding
- No longer limited to arm/arm64 devices: support for x86/x86_64/mips/mips64 devices added
2016.08.29 - v0.01
- Initial release
As always thank you Chainfire! I will try and edit this post.
Edit @Chainfire this seems to work for enabling Android Pay! I didn't get the chance to actually pay yet. But it did let me add my card and did not display the message about a failed authorization of Android check! Before I couldn't even get past that first screen.
Edit 2: @Chainfire It seems to of had an adverse effect on Snapchat. I cleared cache on the app, uninstalled and reinstalled and restarted. It kept Force closing after a photo no matter what. I used suhide-rm and it seems to have fixed the app from any issues. Thanks again and hopefully we'll get you some more reports. Either way your solution works!
Tested on stock rooted 7.0 Nexus 6p.
@Chainfire
What was your reason for doing this project?
Sent from my Nexus 6P using XDA-Developers mobile app
Ofthecats said:
What was your reason for doing this project?
Click to expand...
Click to collapse
For building it, curious if the method I came up with would work well. For releasing, if others are doing it, join them or be left behind.
I'm assuming with custom ROM android pay still won't work right?
HamsterHam said:
I'm assuming with custom ROM android pay still won't work right?
Click to expand...
Click to collapse
I'd just give it a try. It's spoofing the specific app, not the entire ROM that matters. It's fairly simple to try.
Installed on LG G4 w/ V20g-EUR-XX update and rerooted with TWRP 3.0.2-0 and SuperSU-v2.76-2016063161323. seems to be working fine, for the moment. Thank you for the update.
So far so good, I was able to add card to android pay. I would try using it during lunch and report back. Again, thanks for the continuous hard work.
djide said:
So far so good, I was able to add card to android pay. I would try using it during lunch and report back. Again, thanks for the continuous hard work.
Click to expand...
Click to collapse
What was the UID or process you found to blacklist it with?
Sent from my ONEPLUS A3000 using Tapatalk
how to install it? which file should I flash ? Both?
I can't see to add an app using terminal.
I'm typing in
/data/adb/suhide-add 10284
Says file not found. Can someone help, cheers.
Joshmccullough said:
What was the UID or process you found to blacklist it with?
Click to expand...
Click to collapse
Android Pay comes blacklisted out-of-the-box
HamsterHam said:
I can't see to add an app using terminal.
I'm typing in
/data/adb/suhide-add 10284
Says file not found. Can someone help, cheers.
Click to expand...
Click to collapse
Are you in Android or TWRP ?
ls -l /data/adb/
Chainfire said:
Android Pay comes blacklisted out-of-the-box
Click to expand...
Click to collapse
Derp. That's what I get for not reading the entire sentence under 'Install' in the OP......thanks!
PedroM.CostaAndrade said:
how to install it? which file should I flash ? Both?
Click to expand...
Click to collapse
Please don't quote a large post like that just to ask a single question.
Please read the first post, so you know what to do.
OnePlus 2 here, stock 6.0.1, systemless rooted with SuperSU Pro v2.76, flahed using Flashfire.
Passes SafetyNet check, does not pass my bank's root check, propably for the reasons the OP states above.
thdervenis said:
OnePlus 2 here, stock 6.0.1, systemless rooted with SuperSU Pro v2.76, flahed using Flashfire.
Passes SafetyNet check, does not pass my bank's root check, propably for the reasons the OP states above.
Click to expand...
Click to collapse
You need to blacklist the UID for your bank. Directions are in the OP.
*** Urgent Update Notice ***
We are deeply sorry about the installation errors and failures happened in v2.80.
The new update v2.81 has rolled out on XDA and Play Store to fix the problem occured in v2.80.
Chainfire has also released a quick fix on XDA, it's at #1445 post (we will post it here soon)
We have noticed the multiple reports from users on both XDA and Play Store regarding update failure and loss of root. As of now, we have rolled out 2.82 to resolve this issue. If it still persist, please reroot your phone with v2.79.
Again, we apologize for all the trouble and inconvenience caused regarding our 2.80 update. There is hardly any excuse on our side and we should have done a better job. In the coming days, Chainfire and us will review this issue again and provide a note on what went wrong and how we fixed it. In future, we will set up a mechanism to make sure cases like this won't happen again.
P.S. Upon reading ALL the comments posted on this thread, Play Store, Facebook and various sites, we understand the frustrations among users and we are swallowing the heated words. But even at moment like this, we are truly grateful for the community members who shared the details of the error (which speed up our detection process) and those who defended us.
We owe you guys a big thank you.
Download:
SuperSU on Google Play:
https://play.google.com/store/apps/details?id=eu.chainfire.supersu
SuperSU Pro on Google Play:
https://play.google.com/store/apps/details?id=eu.chainfire.supersu.pro
TWRP / FlashFire installable ZIP :
https://s3-us-west-2.amazonaws.com/supersu/download/zip/SuperSU-v2.82-201705271822.zip
*** Xperia users, and others experiencing bootloops ***
Please use this version instead: https://forum.xda-developers.com/attachment.php?attachmentid=4164510&d=1496008012
Contact us:
SuperSU Official Website: www.supersu.com
Forum: forum.supersu.com
Facebook: https://www.facebook.com/SuperSU-1024576694301637/?ref=br_rs
Our team's previous announcement (regarding who we are):
Hello everyone, the CCMT team announces the following statement. We hope this can help everyone have a better picture of who we are and what we will be working on:
1. Our team: Founded in U.S, the team currently operates in Beijing, as a subsidiary of JJ World. Our members consist of operations and engineers from top mobile companies in China, US and Spain. Our mission is to make a difference in Android mobile security, via providing clean, reliable apps.
Though CCMT was founded in the U.S. as a full subsidiary of JJ World, the team currently operates in Beijing. Our members consist of operators and engineers from top mobile companies in China, US and Spain. Our mission is to make a difference in Android mobile security, by providing clean and reliable apps.
2. SuperSU’s future: Our next step is to make SuperSU easier and friendlier to use for broader audience. Our primary effort and achievement since partnering with Chainfire is helping new users (who approached us with no knowledge of how to root) and international users who need special assistance crossing the language barrier.
3. Regarding User Improvement Program (with Google Analytics): In future versions, there will be an option to be included in our user improvement program. It’s essentially adding Google Analytics to understand how SuperSU is used. As stated before, we want SuperSU to be friendlier to rookie users, and we need data to help us achieving that goal. Not a fan? You can always go to settings and disable this feature. Note that the user improvement program does not collect nor store personal information.
4. For concerns regarding possible ads in SuperSU: Maintaining the purity and integrity of SuperSU does not conflict with our team’s business strategy. In other words, we will make sure SuperSU is clean and pure, as it should be.
To conclude, we hope this statement can provide a clearer picture of the CCMT team and we are grateful for those who stayed with us along our ups and downs. We thank you for your support, and stay tuned with CCMT!
Changelogs
SuperSU V2.80 is essentially the stable version of V2.79 SR series, now available on both XDA and Google Play Store. For the past few months, Chainfire and the team have decided to rename the beta versions as service release (SR). Thus the next beta version is expected to be named as v2.80 SR1. The reason for this change is partly due to a significant number of websites outside of XDA update their SuperSU when an elevation of version number takes place ( such as 2.76 to 2.77 beta), but they do not label out the beta. Thus the conventional beta release will be assumed as stable version release in many places other than of XDA. Users who only wish for stable versionsmay accidentally update their SuperSU to beta version.
For the full changelogs including currently in development 'service release' / beta versions and older versions, see Chainfire's changelog post here: https://forum.xda-developers.com/showpost.php?p=64916199&postcount=3
What has changed since the last stable release (v2.79):
26.05.2017 - v2.82
- su: Fix su.d scripts running in the wrong mount context (introduced by ODP sdcardfs fix)
- CCMT: Remove Feedback screen and associated permissions
(v2.81 == v2.79 SR3 with patched version code)
24.05.2017 - v2.80
- CCMT: Update language files
- CCMT: Update guide screen
- CCMT: Update privacy policy screen
- CCMT: Updater: remove 4.3 and 5.0 specific upgrade messages, replace with generic; and detect if root must be manually updated
- CCMT: Add feedback screen
- CCMT: Drop support for Android 2.1 and 2.2. Minimum is now 2.3 (SDK 9, up from 7)
11.04.2017 - v2.79 - SR5 - Not publicly released
- su: Update mount namespace separation code to improve sdcardfs compatibility
- su: Fix kernel panic on ODP1/2 on 5X/6P
- su: Fix ODP1 compatibility on Pixel (XL)
- launch_daemonsu: Revert previous ODP1 work-around
- sukernel: Add option to patch out optional /data encryption (encryptable)
- suinit: cleanup /boot
- ZIP: Get boot image from fstab last-effort
- ZIP: Add REMOVEENCRYPTABLE flag to force disable encryption on newer Samsung firmwares
23.03.2017 - v2.79 - SR4 (ODP1/6P/5X only)
- ZIP: Fix slow /dev/random on some devices, apparently freezing install at "Creating image"
- ZIP: Fix LD_LIBRARY_PATH for hex-patch execution
- supolicy: Fix applying deferred allow rules
- supolicy: Fix setting impossible XPERM causing policy corruption
- supolicy: Add policies for ODP1
- launch_daemonsu: Work-around kernel panic on ODP1 on 5X/6P. Forces service mode for ODP1 on all devices.
14.01.2017 - v2.79 - SR3
- Fix erroneously deleting SuperSU's copy of app_process on 6.0 since 2.79-SR1
- GUI: Fix app_process requirement detection when supersu context used
- Fully eliminate sugote binary, no longer needed due to SELinux handling improvements in earlier versions
- Support /system/xbin/sush as default shell
- Adjust LD_PRELOAD filtering to exclude suhide's libraries
- ZIP: Motorola: default to systemless mode
03.01.2017 - v2.79 - SR2
- supolicy: fix some segfaults(NPEs) in pre-7.0 sepolicy handling
- ZIP: write boot block device once instead of twice (@_alexndr)
- (c) 2017 + CCMT
22.12.2016 - v2.79 - SR1
- Expand Samsung detection
- GUI: reworked portions to work with 'supersu' context on 7.0+
- GUI: fix binary update notice when superuser disabled by user in some cases
- su: reworked portions to work with 'supersu' context on 7.0+
- su/GUI: improve responsiveness when device busy on 7.0+
- sukernel: fix cpio restore failure with very short filenames
- sukernel: no longer patches file_contexts(.bin)
- sukernel: revert force seclabel (no longer needed with 'supersu' context)
- supolicy: add "create", "auditallow", "auditdeny" policy commands
- supolicy: support "*" for permission/range parameter of "allow", "deny", "auditallow", "auditdeny", "allowxperm" policy commands
- supolicy: --live/--file no longer apply default patches if custom patches are supplied
- supolicy: --sdk=X option added (required for 7.0+)
- supolicy: reworked all SELinux rules for 7.0+, run as 'supersu' context
- ZIP: Separate slotselect and system_root logic
- ZIP: Adjust system/system_root device and mount-point detection
- ZIP: Fix minor errors in documentation
- ZIP/frp: Explicitly label /su
The old opening post can be found here: http://forum.xda-developers.com/showthread.php?t=1538053
Older changelogs can be found here: http://forum.xda-developers.com/showpost.php?p=64916199&postcount=3
--- reserved ---
--- reserved ---
--- reserved ---
It would be great if "system-mode" rooting will be implemented again...
Thread cleaned. Yes, this is a new thread for SuperSU as it has been taken over by Coding Code Mobile Technology, Inc (CCMT for short). No, you are not allowed to complain and be disrespectful towards these guys or Chainfire. This has been a long time in the making (some reading for you if you missed out) and if you are upset in the direction it is going, feel free not to use it and/or develop your own root solution (since, you know, we're on a developer's site). Nobody here owes you anything.
Nathan
Forum Moderator
Thank you @nathanchance.... ▶.
Dead Cookies leave no trails...
.zip installed after kernel
Galaxy S7 International.
Android 6.0.1
Custom ROM based on G930FXXU1BPH6 (I'm developer)
No interfering apps.
--
[email protected]:/ $ which su
which su
/su/bin/su
[email protected]:/ $ ls -l `which su`
ls -l `which su`
-rwxr-xr-x root root 108480 2016-08-22 07:19 su
[email protected]:/ $ which su
which su
/su/bin/su
[email protected]:/ $ uname -a
uname -a
Linux localhost 3.18.14-prometheus-v1.5.3 #1 SMP PREEMPT Sat Aug 27 10:53:02 EEST 2016 aarch64
[email protected]:/ $
d8389 said:
.zip installed after kernel
Galaxy S7
--
[email protected]:/ $ which su
which su
/su/bin/su
[email protected]:/ $ ls -l `which su`
ls -l `which su`
-rwxr-xr-x root root 108480 2016-08-22 07:19 su
[email protected]:/ $ which su
which su
/su/bin/su
[email protected]:/ $ uname -a
uname -a
Linux localhost 3.18.14-prometheus-v1.5.3 #1 SMP PREEMPT Sat Aug 27 10:53:02 EEST 2016 aarch64
[email protected]:/ $
Click to expand...
Click to collapse
try it vice versa, first supersu and then the kernel. also, you might want to ask for help in the S7 subforums.
ulxerker said:
try it vice versa, first supersu and then the kernel. also, you might want to ask for help in the S7 subforums.
Click to expand...
Click to collapse
same result
I can ask help from myself only...
instalation fail
sony m4 6.01 stock rom
[Size=+1]Thread cleaned. Again.
As was previously pointed out by another moderator this thread is not the place to discuss the handover of SuperSU or how the company needs to prove itself. This thread is solely for the discussion of SuperSU itself. No more off topic please.[/sizE]
d8389 said:
same result
I can ask help from myself only...
Click to expand...
Click to collapse
I have intsalled Susi from store without problems on your ROM.
SuperSU v2.78
I upgraded through TWRP flashable zip,Running smoothly in my Sony xperia E3 ,No su binaries update issues.
Upgraded by playstore. Seems to be working fine.. ?
Question is why did some, not all of my settings change?
2.77 was installed into system and now 2.78 it is not.
(Install backup script for updates is not there now?)
Sent from my SM-T230NU using XDA Labs
Android 4.4.2
Edit:
Took another (fourth reboot) and now all my settings are reset but, I am back to installed system app. (Still no backup script ?)
If you want to stay or be system less it's super su then kernel. Same if switching kernels
Straight from the one and only Straight Shooter. ?
A quick question...
In order to install suhide we need to flash both, suhide and Supersu in order to avoid boot loops.
Since 2.78 now updates from GP how do we accomplish the above?? I can't flash a GP download and I'll possibly have bootloops after installing suhide and before going to GP.
So, what do we do?
Inquiring minds want to know...
Sent from my LG-H901 using XDA Labs
NYLimited said:
A quick question...
In order to install suhide we need to flash both, suhide and Supersu in order to avoid boot loops.
Since 2.78 now updates from GP how do we accomplish the above?? I can't flash a GP download and I'll possibly have bootloops after installing suhide and before going to GP.
So, what do we do?
Inquiring minds want to know...
Click to expand...
Click to collapse
The latest zip is linked in the OP. I flashed it this afternoon with suhide and it's working perfectly.
Just upgraded from 2.76 to 2.78 through recovery (SuperSU in system partition) on both devices. Surprisingly I see two icons of the application, both start 2.78. The only app file is in /system/app.
No idea what is going on.
This thread/guide is now closed and will no longer be updated. It is only kept for posterity.
The new guide is stickied at the top of the Magisk forum, right here.
This thread/guide is now closed and will no longer be updated. It is only kept for posterity.
The new guide is stickied at the top of the Magisk forum, right here.
Installing Magisk and Modules
Installation
Where to start
It’s always a good idea to read through, at least, the release thread for information about what Magisk is and how to install it. Other useful information can be found in the Magisk All-In-One Wiki and the support thread.
Known issues
There may be issues with certain devices, ROMs and/or apps and Magisk. Check the release thread for information about currently known issues. While you're there, make sure to also take a look at the FAQ. When a new release is imminent, there will also be useful information in the beta thread.
Things to keep on your device
There are a couple of things that are good to keep on your device, making it easier to recover from any problems that might arise.
Magisk zip (release thread).
Magisk Manager apk (release thread) or GitHub.
Uninstall zip (release thread).
Mount Magisk zip (Collection of Magisk Modules v2 thread).
A copy of a clean boot image for your ROM (can be flashed in TWRP in case of problems).
Module zips.
Installation
Installing Magisk is straightforward. Follow the installation instructions in the release thread. After that you can install Magisk Modules through the Manager or via custom recovery (e.g. TWRP).
Moving from another systemless root solution to MagiskSU
If you wan't to install Magisk but already have a systemless root solution installed (SuperSU, phh's superuser) you'll have to first remove that.
With SuperSU, most of the times you can simply use the full unroot option in the SuperSU app and let it restore your stock boot image, alternatively use the full unroot option and then flash the stock boot image in recovery before installing Magisk.
Otherwise, and this applies to any other root solution as well, you an use @osm0sis unSU script (in recovery) and then flash the stock boot image before installing Magisk.
If you're ROM is prerooted it's quite likely that you can still use the boot image from the ROM zip. Many ROMs simply flash a root zip at the end of the ROM installation. If this doesn't work you'll have to check with your ROM developer on how to find an unpatched boot image that work with your ROM. Also see "Boot image patched by other programs" below.
Updating
If there's an update to Magisk, you'll get a notification from the Magisk Manager (if you haven't turned it off, that is). You can update through the Manager or download the Magisk zip from the release thread and flash in recovery. Make sure to read the release notes and the changelog, both can be found in the release thread. Any modules you have installed may have to be updated to conform with possible changes to Magisk.
If you're having problems updating to a newer version. Flash the uninstaller in recovery, restore your stock boot image and start over.
Note that with an update to Magisk, the Uninstall zip may also have been updated. Always keep the latest version on your device.
Boot image patched by other programs
If the installation (or uninstallation) through recovery fails with a message about the boot image being patched by other programs you need to follow the instructions given with the message. You most likely have some other systemless root solution (SuperSU, phh's superuser) or there's something else that have added it's patches to the boot image that will interfere with Magisk and cause the installation/uninstallation to fail. If you're already rooted (not MagiskSU), first unroot ( @osm0sis unSU script is good for this).
You'll have to restore a stock boot image without any other patches before installing/uninstalling Magisk. If you're using TWRP you can simply flash the boot.img file pretty much the same way you would with a zip.
The boot image can usually be found in your device's factory image/firmware file. If you're using a custom ROM it's found in the ROM zip.
If your ROM comes pre-rooted this can be tricky, depending on how the ROM roots your device. Usually the ROM just flashes root at the end of the ROM flash and you can simply open up the zip, unroot and flash the clean boot image from the ROM zip. If the ROM comes pre-patched from the start, ask for advice in your ROM thread or you could try a custom kernel that modifies the ramdisk.
Of course, you can also use a ROM that does not come pre-rooted (the preferred way).
After installation or update
After the first installation or an update, it may be necessary to perform a reboot or two for Magisk and/or any modules you have installed to start functioning properly.
Issues
Long boot time
If your device get stuck on the splash screen for a minute or so, it might mean that the magisk daemon have crashed or that there is some SELinux issue. If it is the case that the magisk daemon crashed, the Magisk debug logging during boot will never finish, even after the device has booted. This will eventually cause the debug log to eat up all your storage space! Take a look in /data and see if the file magisk_debug.log is very large and growing. Save the log and report the issue. Try rebooting to see if this fixes things, otherwise you'll probably need to uninstall Magisk and wait for a fix. Also see "Nothing works!" below.
Bootloop
If you end up in a bootloop when installing Magisk, run the uninstaller script in recovery, flash a clean boot image (the uninstaller restores a copy of the untouched boot image, so this step is “just in case”) and start over. If the uninstaller fails, just flash your unmodified copy of the boot image and you should be good to go. There’ll probably be some leftover files and folders from Magisk laying around in /cache and /data, but these can be removed manually.
First make sure your system can boot up without Magisk.
Boot to recovery and install Magisk. Boot up your system without installing any modules. Also see "Module causing issues" below.
If your system bootloops again and you're using a custom kernel, try starting over without installing that kernel. If there's still a bootloop your system might just not be compatible. One possibility is to try finding another custom kernel that is compatible. Also see "Nothing works!" below.
Magisk Manager crashes
If you're having issues with the Magisk Manager force closing/crashing after an update, clear data for the Manager or uninstall it and install again.
The Manager crashing might also be caused by using a theme engine to theme the Manager (Substratum, etc). Disable it and reapply after an update.
If it still crashes, try reverting to an earlier version of the Manager (they're all on GitHub). But before you do, capture a logcat from the crash and post it in the support thread (with a detailed description of the problem).
There are no modules
If the list of modules under "Downloads" is empty, clear the repo cache (in settings) and/or reload the modules list (pull down).
Can't install modules
If there's an error installing a module, there's a couple of things to try.
If the error occurs when installing a module through the Downloads section of the Magisk Manager, then something is wrong. Capture a logcat and post in the support thread (with a detailed description of the problem).
If the error just states something along the lines "error when installing", try flashing the zip through recovery instead. It might also be that you're trying to flash a v4 template module on a Magisk version lower than v13.1. If you feel you need to stick with an outdated version of Magisk, check with the module developer if there is a v3 template module available.
If the error states that it's not a Magisk zip, or invalid zip in TWRP, something's gone wrong while packing the zip. Open up the zip and you'll probably see a folder (probably named something like <nameofmodule>-master). Take all the contents of that folder and repack it to the root of the zip and try flashing it again.
Module causing issues (Magisk functionality, bootloop, loss of root, etc)
If you have a working Magisk installation, but a module causes Magisk, the Magisk Manager or your device to not function properly (bootloop, loss of root, etc), here's a tip:
Boot to recovery and flash the Mount Magisk zip (see “Things to keep on your device” above). This mounts the Magisk image to /magisk and it can now be accessed as any other directory. You now have a couple of options to remove the module:
Simply delete the modules folder under /magisk and reboot.
Navigate to the modules directory under /magisk and rename the "module.prop" file to "remove".
In terminal you can type (without quotation marks) "touch /magisk/<module folder>/remove" (or “/magisk/<module folder>/disable”, depending on your preference).
If you create the "remove" or "disable" files, Magisk will take care of removing or disabling the module on the next reboot.
You can also keep a copy of the corresponding disable or remove files on your device and copy them to the module folder as needed.
If you get an error in recovery when flashing Mount Magisk it might mean your Magisk image has become corrupted. Check the recovery log for details. Easiest way to fix this is to run the uninstaller and start from the beginning. It might also be possible to use fsck in terminal in recovery or through ADB. Google it (and check the recovery log for details).
Since Magisk v12.0 and Magisk Manager 4.3.0 you can also use the "Magisk Core Only Mode" in Manager settings. This disables all modules and only keeps the core functions of Magisk active (MagiskSU, MagiskHide, systemless hosts and, for Magisk v12.0, Busybox).
Installing/disabling/uninstalling modules through the Manager or recovery
If you’re experiencing problems with installing, disabling or uninstalling a module through the Manager, simply try it through recovery instead. For disabling or uninstalling a module through recovery, see the described method above under “Module causing issues”.
Apps are force closing
If a bunch of apps suddenly start force closing after installing Magisk, your ROM might have issues with WebView. More precisely with the signatures for Chrome and Google WebView. You can take a logcat when one of the apps crash and see if there's anything about WebView in there. The reason is that MagiskHide sets ro.build.type to "user" and this enables the signature check. Ask your ROM developer to fix the signature error... Meanwhile, you can fix it temporarily by disabling MagiskHide.
It's also possible that removing and reinstalling Chrome stable, Chrome Beta or Google WebView (or simply installing one of them if it's not already) will fix the issue.
Magisk isn't working
If you can boot up, but Magisk isn't working as expected (not detecting the Magisk installation, loss of root, etc), there's a few things you can try.
First, reboot. Sometimes this helps Magisk mount everything as it should.
Second, try removing any installed modules to see if it's a faulty module causing issues. If that seems to fix it, install the modules one at a time to find which one causes issues.
If nothing else works, try starting fresh with a new installation. Also see “Asking for help” and “Nothing works!” below.
Root issues
<insert app name here> can’t detect root
Since Magisk v11 and the included MagiskSU, some apps have started having troubles detecting root. Usually this means the app in question is looking for root in a specific location and needs to be updated to work with MagiskSU.
You can try symlinking the su binary to the location where the troublesome app is looking for it. Here’s an example on how to do this in terminal (If you don’t know about symlinking, Google it.):
Code:
ln -s /sbin/su /system/xbin/su
@laggardkernel have made a Magisk module that does this completely systemlessly. Which, of course, is preferable as we're using a systemless mask... :good: You'll find it here. Please note that doing this might have the effect of MagiskHide not being able to hide root.
Tasker and MagiskSU
Any version before Tasker v5.0 will have issues detecting MagiskSU. If you by any chance feel that you cannot update to v5+, you can use this Magisk module to enable Tasker root support. Reportedly, Secure Settings will also function with MagiskSU thanks to this module.
Another way is to use “Run Shell” in Tasker and use shell commands to do what you want, prefaced by “/sbin/su -c”. Example (copy a new host file to Magisk):
Code:
/sbin/su -c cp /sdcard/hosts /magisk/.core/hosts
If the command doesn’t work, try putting quotation marks around the command, like so:
Code:
/sbin/su -c "cp /sdcard/hosts /magisk/.core/hosts”
Randomly losing root
Some devices seem to have issues with memory management where the Magisk Manager will not be kept in memory and as a result root management is lost. This can sometimes be fixed by clearing the Manager from memory (swipe it away from recent apps list) and opening it again. Make sure the Manager is removed from any battery optimisation.
Magisk but no MagiskSU
There have been a few reports of devices/ROMs where Magisk gets installed properly, but MagiskSU fails to install. This might have to do with your device/ROM not letting Magisk symlink the required binaries and files to /sbin. See the release thread for known issues. If you know of a solution that's not listed, here or in the release thread, please let me know and I'll add it.
Other things to try
Starting fresh
If you've been trying a lot of things and can't get Magisk to work properly it can be a good idea to start fresh. Start by uninstalling Magisk, flashing a clean boot image and installing Magisk again. If that doesn't work you could try wiping your device and starting out completely clean.
Older versions of Magisk
It is possible that an older version of Magisk and MagiskHide may work if the latest does not. This is a last resort and should be considered unsupported. If the latest version of Magisk doesn’t work, but an earlier version does, please help fixing the issue by reporting it with all the necessary details (see “Asking for help” and “Nothing works!” below)
Installation files back to Magisk v12 can be found in the release thread.
Please note that there’s no guarantee that an older version of Magisk will work with the current Magisk Manager. Compatible apk's can be found inside the Magisk zip.
Asking for help
If you can't fix the problem yourself, start by looking in the support thread where you might find that someone else have had this problem as well. Search for your device and/or problem. If you can't find anything (it's a big thread), provide as much information as possible (in the support thread). For example:
Detailed description of the issue and what you've tried so far.
Details about your device and ROM, custom kernel, mods, etc.
Current and previous root solution (and what you've done to remove it, if applicable)
Logs! And when providing logs, do NOT paste them into your post. Attach as a file or use a service like Pastebin.
Recovery log from installation (in TWRP, go to Advanced - Copy log).
Magisk log (from the Manager or in /cache through recovery if you don't have root access)
Logcat. Get it via ADB or an app.
If you have boot issues (stuck or long boot time), take a look in /data for a file called magisk_debug.log (access through recovery if necessary). If it's not there, try capturing a logcat through ADB during boot (see above).
Nothing works!
If nothing works and you just can't get Magisk to install/function properly on your device, check the troubleshooting section in the release thread for instructions on how to help topjohnwu fix any compatibility issues with your device. The best thing you can do if Magisk isn't compatible with your device is to open an issue on GitHub and upload logs (recovery log, Magisk log, logcat, whatever is applicable) and a copy of your boot image. No boot image, no fix.
If you're using an older release of Magisk, take a look at the Old and outdated tips and tricks for "Installing Magisk and Modules". There might be something in there that applies to you.
Beta releases
It's also possible that whatever problem you're facing has been fixed in code, but not yet released. For this you have two options. The official beta and the unofficial beta snapshot.
The official beta is for @topjohnwu to test the release before it goes out to the masses. Read the OP carefully and follow any directions given. When reporting things about the beta, provide the necessary details and logs for whatever issue you're facing. Please don't spam the thread with "useless" posts...
If you're feeling brave you can try the unofficial beta snapshot. It's built directly from source and can sometimes be unusable. Keep an eye on the thread for current issues.
Changelog
Installing Magisk and Modules - Changelog
2017-07-21
Tasker v5.0 is released. Update "Tasker and MagiskSU" to reflect this.
2017-07-19
Added some links to the Manager apk downloads on GitHub.
Updated and moved "Magisk Manager crashes".
Updated "Module causing issues".
Updated "Nothing works!".
2017-07-17
Slight update to "Boot image patched by other programs".
2017-07-14
Added a new section, "Moving from another systemless root solution to MagiskSU".
Added a new section, "Can't install modules".
Added a new section, "Apps are force closing".
2017-07-13
Added a note about using themes with the Manager under "Magisk Manager is crashing".
2017-07-12
Updated "Boot image patched by other programs".
Added a section about "Long boot time".
Added a section about "Magisk Manager crashes".
2017-07-11
Updated for Magisk v13.1
2017-06-19
Updated info about beta releases.
2017-06-18
Moved "Outdated tips and tricks" to it's own post.
2017-05-25
Some clarifications for SuperSU pre-patched boot image.
2017-05-08
Added "Magisk but no MagiskSU"
Added a link to the solution for no MagiskSU on Sony devices by @[email protected].
2017-05-06
Added some clarifying headings.
Added an index in the OP.
2017-05-01
Slight clarification under "Asking for help".
2017-04-19
Added "Starting fresh".
2017-04-14
Added a link to a Magisk module for Tasker compatibility with MagiskSU.
2017-04-09
Updated "Losing root".
2017-04-04
Added "There are no modules".
2017-03-31
Updated for Magisk v12.
Moved old and outdated tips and tricks to the bottom.
2017-03-28
Minor clarification on Module issues.
Updated link to new Modules Collection thread.
2017-03-21
Added information about updating.
Slight restructuring.
2017-03-20
Updated for Magisk v11.6
2017-03-14
Added a link to the Beta snapshot thread.
2017-03-05
Added more ways to make Tasker recognise root with MagiskSU.
2017-03-02
Changelog started.
Refinements.
2017-02-23 - 2017-03-02
Various additions.
Refinements.
2017-02-23
Initial post.
This thread/guide is now closed and will no longer be updated. It is only kept for posterity.
The new guide is stickied at the top of the Magisk forum, right here.
Hiding root and passing Safety Net
MagiskHide works, IF your system is set up correctly and is compatible.
Basics
Requirements:
A Linux kernel version of at least 3.8 or a kernel that has the necessary features (mount namespace) backported.
MagiskHide hides:
Magisk and some modules (it depends on what the module does)
MagiskSU
Unlocked bootloader
Permissive SELinux
Things that may trigger SafetyNet and apps looking for root. Can't be hidden by MagiskHide
Magisk Manager - Some apps look specifically for the Magisk Manager and there is currently no simple way of fixing this. See "Detecting Magisk Manager or apps requiring root" below.
Other known root apps - Same as above.
Remnants of previous root method, including any root management apps (a good way to remove most remnants of root is osm0sis' unSU script).
Xposed (deactivate or uninstall). It doesn't matter if it's systemless, Magisk can't hide it.
USB/ADB Debugging (disable under Developer options). This isn't necessary on all devices/ROMs.
Make sure that your device conforms to the above requirements before continuing.
Known issues
There may be devices that have issues with MagiskHide. Check the release thread for information about currently known issues. While you're there, make sure to also take a look at the FAQ. When a new release is imminent, there will also be useful information in the beta thread.
Passing SafetyNet
If everything works out, SafetyNet should pass with no further input from the user. Nothing needs to be added to the Hide list. You'll see in the Magisk Manager if it works by checking the SafetyNet status. If SafetyNet doesn't pass after enabling Hide, try rebooting (also see “Hide isn’t working” and the sections about SafetyNet below).
Hiding root from apps
If you have other apps that you need to hide root from, open MagiskHide and select the app in question. Just remember there are apps out there with their own ways of detecting root that may circumvent MagiskHide (also see “More things to try” below).
MagiskHide isn't working
If you can’t get MagiskHide to work, either for SafetyNet or any other app detecting root, there are a few things you can try:
First make sure Hide is actually working by using a root checker. Start by making sure the root checker can detect that your device is rooted. After that, add the root checker to the Hide list and see if it no longer can detect root. If that is the case, MagiskHide is working on your device.
Check the logs
Take a look in the Magisk log. In there you should see something like this (just an example, YMMV):
Code:
--------- beginning of main
I( [I]<numbers>: <numbers>[/I]) Magisk v13.3(1330) daemon started
I( [I] <numbers>: <numbers>[/I]) ** post-fs mode running
--------- beginning of system
I( [I]<numbers>: <numbers>[/I]) ** post-fs-data mode running
I( [I]<numbers>: <numbers>[/I]) * Mounting /data/magisk.img
I( [I]<numbers>: <numbers>[/I]) * Running post-fs-data.d scripts
[I]<Here you'll see scripts that are installed to /magisk/.core/post-fs-data.d running>[/I]
I( [I]<numbers>: <numbers>[/I]) post-fs-data.d: exec ************
I( [I]<numbers>: <numbers>[/I]) * Loading modules
[I]<Your installed modules will be loaded here.>[/I]
I( [I]<numbers>: <numbers>[/I]) ***********: loading [system.prop]
I( [I]<numbers>: <numbers>[/I]) ***********: constructing magic mount structure
I( [I]<numbers>: <numbers>[/I]) * Mounting system/vendor mirrors
I( [I]<numbers>: <numbers>[/I]) mount: /dev/block/bootdevice/by-name/system -> /dev/magisk/mirror/system
I( [I]<numbers>: <numbers>[/I]) link: /dev/magisk/mirror/system/vendor -> /dev/magisk/mirror/vendor
[I]<If you have modules that install files/folders to /system, you might see a lot of bind_mount entries.>[/I]
I( [I]<numbers>: <numbers>[/I]) bind_mount: **************
I( [I]<numbers>: <numbers>[/I]) * Running module post-fs-data scripts
[I]<Here you'll see scripts that are installed in modules running.>[/I]
I( [I]<numbers>: <numbers>[/I]) ************: exec [post-fs-data.sh]
I( [I]<numbers>: <numbers>[/I]) * Enabling systemless hosts file support
I( [I]<numbers>: <numbers>[/I]) bind_mount: /system/etc/hosts
I( [I]<numbers>: <numbers>[/I]) * Starting MagiskHide
I( [I]<numbers>: <numbers>[/I]) hide_utils: Hiding sensitive props
I( [I]<numbers>: <numbers>[/I]) hide_list: [com.google.android.gms.unstable]
[I]<Any other apps/processes added to the Hide list will be seen here.>[/I]
I( [I]<numbers>: <numbers>[/I]) proc_monitor: init ns=mnt:[[I]<numbers>[/I]]
I( [I]<numbers>: <numbers>[/I]) ** late_start service mode running
I( [I]<numbers>: <numbers>[/I]) * Running service.d scripts
[I]<Here you'll see scripts that are installed to /magisk/.core/service.d running>[/I]
I( [I]<numbers>: <numbers>[/I]) service.d: exec ***************
I( [I]<numbers>: <numbers>[/I]) * Running module service scripts
[I]<Here you'll see scripts that are installed in modules running.>[/I]
I( [I]<numbers>: <numbers>[/I]) ************: exec [service.sh]
I( [I]<numbers>: <numbers>[/I]) proc_monitor: zygote ns=mnt:[[I]<numbers>[/I]] [I]<possibly more zygotes and numbers>[/I]
I( [I]<numbers>: <numbers>[/I]) proc_monitor: com.google.android.gms.unstable (PID=[I]<numbers>[/I] ns=mnt:[[I]<numbers>[/I]])
I( [I]<numbers>: <numbers>[/I]) hide_utils: Re-linking /sbin
If there are no entries in the log about MagiskHide starting, take a look under "Restarting the MagiskHide daemon" and "Starting MagiskHide Manually" below.
Restarting the MagiskHide daemon
Sometimes the MagiskHide daemon needs to restart, or haven't properly started on a reboot. Fix this by toggling MagiskHide off and then on again in settings. You can also try disabling MagiskHide, rebooting and then enabling it again.
If you previously have had MagiskHide functioning on your device, but suddenly it stops working, it's a good chance the MagiskHide daemon hasn't properly started on boot. Toggle off and on (and possibly reboot) and you should be good. If not, keep reading to the next section, "Starting MagiskHide manually".
Starting MagiskHide manually
If MagiskHide just won't start when toggling it in the Magisk Manager, try starting it manually. This can be done in a terminal emulator (as su) by executing the following command:
Code:
su
magiskhide --disable
magiskhide --enable
Systemless hosts
Some users have reported issues with MagiskHide if systemless hosts is enabled in Magisk Manager settings. Try disabling it and rebooting to see if it fixes your issue.
Kernel logcat support
If your device's kernel doesn't have logcat support the MagiskHide process monitor won't be able to see when a process/package is started and therefore won't unmount the necessary folders to hide Magisk and it's core features. You can test for this by running the following command in a terminal app:
Code:
logcat -b events -v raw -t 10
If you get an error you might have a logcat issue. Ask in your kernel/ROM thread for advice or try a different kernel.
There's also a possibility that your issue can be fixed by using a kernel managing app like Kernel Adiutor. It might be enough just to install it to enable logcat support. This is untested (by me at least) and just speculation on my part from what I've seen around the forums (please confirm if you have information about this or tested it).
A huge thank you to @tamer7 for teaching me about this.
Logger buffer size
If you have turned off Logger buffer size under Developer Options, MagiskHide won't be able to monitor when a process/package is started and won't unmount the necessary folders to hide Magisk and it's core features.
Thank you to @Chaplan for the tip.
Mount namespace issues
If you see this line in the Magisk log: "proc_monitor: Your kernel doesn't support mount namespace", your device has a Linux kernel that is to old. The Linux kernel version have to be at least 3.8 (thank you @TheCech12), or otherwise have the necessary features backported. Ask in your ROM/kernel thread or try a different ROM and/or kernel.
SafetyNet
Google continuously updates SafetyNet. Currently, the only version of Magisk that will pass SafetyNet without workarounds is Magisk v13.3.
SafetyNet incompatible devices and ROMs
There are some devices/ROM’s that just won’t be able to pass SafetyNet fully. This has to do with how Google certifies devices, CTS certification (Compatiblity Test Suite). If a device hasn’t passed the Google certification process, or if the ROM alters how the device is perceived by Google, it won’t be able to fully pass SafetyNet (CTS profile mismatch). You might be able to get basic integrity to report as true (see Checking if Basic integrity passes below) and this means that MagiskHide is working as it should and it's most likely a CTS certification issue. If there is anything to be done about this it's most likely found in your device's forums. Go there and ask...
You can find out if your device/ROM has issues by checking SafetyNet with your current ROM without Magisk, any other root solution or mod (e.g. Xposed) You’ll also have to either relock your bootloader or flash a custom kernel that hides the bootloader state (disabled verified boot flag), set SELinux to enforcing (if it isn’t already) and possibly disable USB/ADB Debugging. If SafetyNet passes with a clean system, you’re good to go and can start troubleshooting MagiskHide. If it fails with a CTS profile mismatch you might be out of luck, but not necessarily. You can still give MagiskHide a go and see if you can get your device to pass, but if it doesn't it might be the ROM causing issues. If your device's stock ROM can pass SafetyNet, you could try finding a ROM that’s closer to stock and see if this helps.
It's also possible that you can match your ROM's ro.build.fingerprint and/or ro.build.description (or other props) with an official ROM for your device to make it pass SafetyNet fully. See Matching official prop values to pass SafetyNet below.
CTS profile mismatch vs Basic integrity
There are two parts to a SafetyNet check, CTS compatibility and Basic integrity. The CTS check is a server side checkup up that's difficult to spoof, while Basic integrity is done on the device side and is a lower level of security. Some apps only use the Basic integrity part of the SafetyNet API and thus can be used even if SafetyNet doesn't fully pass.
Checking if Basic integrity passes
You can use a SafetyNet checker app (SafetyNet Helper and SafetyNet Playground are two good examples) to see if you at least pass Basic integrity. If you can't pass SafetyNet, but Basic integrity shows as true, that basically means Google doesn't trust your device for some reason (also see "SafetyNet incompatible devices and ROMs" above). You should be able to fix this by matching prop values with a ROM that passes SafetyNet (see below).
Matching official prop values to pass SafetyNet
If you use an unofficial/developers ROM you'll have to match an official/stable ROM's details (usually ro.build.fingerprint and possibly ro.build.description) to pass SafetyNet. Check your device's forum for details. Also, see the section about "Sensitive props" below.
@coolguy_16 have made a guide for Moto G 2015 here. Thank you to @diegopirate for the tip.
Spoofing device fingerprint
As a last resort you could try changing your device's ro.build.fingerprint to a device's/ROM's that is known to pass SafetyNet. This can be done with a Magisk module or with boot script and the resetprop tool. See the section about "Sensitive props" below. Or you can use the Universal SafetyNet Fix module. Spoofing the device fingerprint is part of what it does.
SafetyNet check never finishes
If the SafetyNet status check never finishes (make sure to wait a while), it might mean that your Google Play Services aren’t working properly or have crashed. Try force closing Play Services, clearing data and/or rebooting the device.
You can also try updating to a newer version (take a look at APKMirror).
Device uncertified in Play store/Some apps won't install or doesn't show up
If some apps won't install or doesn't show up in the Play store, check the Play store settings. At the bottom there's a section called "Device certification". Some apps won't install if this shows "uncertified" (a couple of known apps are Netflix and Mario Run).
The solution is to make sure your device passes SafetyNet and then clear data for the Play store and reboot. If you have multiple users on your device, you might have to clear data for all users. Next time you open up the Play store, "Device certification" should show "certified" and the apps should be able to install/show up again. You might have to wait a bit before the apps show up. Some users have reported having to wait mere minutes, others several hours up to a whole day.
Some users have reported having to add the Play store to the MagiskHide list.
I still can't pass SafetyNet
First, keep reading and see if there's anything you can try below that you haven't already.
If you've tried everything and SafetyNet still doesn't pass, give the Universal SafetyNet Fix module by @Deic a try.
Other things to try
First make sure Hide is actually working by using a root checker. Start by making sure the root checker can detect that your device is rooted. After that, add the root checker to the Hide list and see if it no longer can detect root. If that is the case, MagiskHide is working on your device.
USB/ADB debugging
If you haven’t yet, try disabling USB/ADB debugging to see if this helps you use your root detecting app or pass SafetyNet.
Dependencies
There are some apps that require one or more other apps or processes being added to MagiskHide. For example, if an app is asking for extra permissions, try hiding the corresponding app/process as well. As an example: for a banking app asking for permissions to make phone calls it might be necessary to add the Phone app as well as the banking app to MagiskHide. Unfortunately it's not necessarily the case that the app or process used for finding root asks for permissions (also see "Figuring out if an app has dependencies, looks for 'sensitive props', Busybox, etc" below).
Sensitive props
Some apps trigger if they find "sensitive props". Also, on some devices SafetyNet triggers if certain props are not set to the expected values. A few props get set to "safe" values by MagiskHide by default. Currently these are ro.debuggable, ro.secure, ro.build.type, ro.build.tags and ro.build.selinux.
Some examples of props may include:
Code:
ro.build.selinux [I](careful, it might cause issues with SELinux)[/I]
ro.build.flavor
ro.build.description
ro.build.fingerprint
ro.bootimage.build.fingerprint
ro.build.oemfingerprint
etc...
Use the command "getprop" (without quotations) on the props in a terminal emulator to see what they're set to. Note that not all props used can be found in build.prop.
The props can be changed with a Magisk module or a boot script and the resetprop tool.
If you have a ROM (stock is usually a good bet) that can pass SafetyNet or use an app on without modifications, check for props on that ROM that you can change to on the ROM you're having trouble with (also see "Figuring out if an app has dependencies, looks for 'sensitive props', Busybox, etc" below).
Please note that changing prop values may have other consequences for your device than just being able to pass SafetyNet or hide root. If you're experiencing issues after changing prop values, revert them and see if that helps.
Developer options disappeared from settings
If Developer options suddenly disappeared from settings after installing Magisk, it's probably because MagiskHide changes ro.build.type from "userdebug" to "user" (known "safe" prop value). On some devices/ROMs this prop need to be set to "userdebug" to show the Developer options. A solution is to temporarily disable MagiskHide and reboot if you need access to the Developer options.
Or, there's a much better solution... You can ask your ROM developer to add this commit: https://github.com/DirtyUnicorns/an...mmit/5a647d96432abcb1276fab695600c5233e88b8d3
Busybox
Some apps detect Busybox and see this as a sign of your device being compromised (rooted). Magisk should be able to hide any Busybox installed as a Magisk module.
Figuring out if an app has dependencies, looks for "sensitiveprops", Busybox, etc
It can be tricky figuring out if an app is dependent on another app or process for detecting root, expects certain prop values, doesn't like Busybox or whatever is triggering a root warning within the app. Apart from trying one thing/prop at a time, finding this out could mean you have to decompile the apk to look at the source code. Google it...
Detecting Magisk Manager or apps requiring root
There are apps that detect the Magisk Manager or known apps that require root and refuse to work properly or even start if that is the case. This can be worked around by uninstalling or possibly freezing the Manager or root app when you need to use these apps and reinstalling/unfreezing it afterwards. Cumbersome, but it might work. There are also some Xposed modules that can hide apps from other apps, but having Xposed installed might cause other issues with tampering detection...
Samsung...
Yeah... Samsung doesn't have the mod-friendliest devices out there. But anyway...
Parts of Magisk have had a history of breaking/not working on Samsung devices. This is constantly being worked on. Check the Known issues in the release thread, the support thread and other relevant threads in the Magisk forums for information. If you can't find anything about your issue, make sure you leave as detailed a report as possible when asking for help. See "Asking for help" below.
Lineage OS...
Yeah... Cyanogenmod had a history of breaking things for many mods and it seems like Lineage OS is continuing on this legacy.
Parts of Magisk have had a history of breaking/not working on devices with Lineage OS. Check the Known issues in the release thread, the support thread and other relevant threads in the Magisk forums for information. If you can't find anything about your issue, make sure you leave as detailed a report as possible when asking for help. See "Asking for help" below.
Magisk Core Only Mode
If you can't get MagiskHide to work, try enabling the Core Only Mode in Magisk Manager settings. No modules will be loaded and any conflicts as a result of that part of Magisk will be bypassed. Note: In Magisk v13.1 there seems to be a bug with Core Only Mode where it will disable MagiskHide and Systemless hosts. Toggle MagiskHide and Systemless hosts off and on in settings to fix this.
Starting fresh
If you've been trying a lot of things and can't pass SafetyNet it can be a good idea to start fresh. Start by uninstalling Magisk, flashing a clean boot image and installing Magisk again. If that doesn't work you could try wiping your device and starting out completely clean.
Older versions of Magisk
It is possible that an older version of Magisk and MagiskHide may work if the latest does not. This is a last resort and should be considered unsupported. If the latest version of Magisk doesn’t work, but an earlier version does, please help fixing the issue by reporting it with all the necessary details (see “Asking for help” and “Nothing works!” below)
Installation files back to Magisk v12 can be found in the release thread.
Please note that there’s no guarantee that an older version of Magisk will work with the current Magisk Manager. Compatible apk's can be found inside the Magisk zip.
Asking for help
If you can't fix the problem yourself, start by looking in the support thread where you might find that someone else have had this problem as well. Search for your device and/or problem. If you can't find anything (it's a big thread), provide as much information as possible (in the support thread).
Detailed description of the issue and what you've tried so far.
Details about your device and ROM, custom kernel, mods, etc.
Logs! And when providing logs, do NOT paste them into your post. Attach as a file or use a service like Pastebin.
Recovery log from installation (in TWRP, go to Advanced - Copy log).
Magisk log (from the Manager or in /cache through recovery if you don't have root access)
Logcat. Get it via ADB or an app.
If you have boot issues (stuck or long boot time), take a look in /data for a file called magisk_debug.log (access through recovery if necessary). If it's not there, try capturing a logcat through ADB during boot (see above).
Nothing works!
If MagiskHide does not work for you even though you've tried everything, check the troubleshooting section in the release thread for instructions on how to help topjohnwu fix any compatibility issues with your device. The best thing you can do if Magisk isn't compatible with your device is to open an issue on GitHub and upload logs (recovery log, Magisk log, logcat, whatever is applicable) and a copy of your boot image. No boot image, no fix. Just remember that there are some things @topjohnwu can't fix, like if your device's kernel doesn't have mount namespace support (you need a Linux kernel version of at least 3.8) or similar.
If you're using an older release of Magisk, take a look at the Old and outdated tips and tricks for "Hiding root and passing Safety Net". There might be something in there that applies to you.
And, if nothing else works you could try the Universal SafetyNet Fix module by @Deic.
Beta releases
It's also possible that whatever problem you're facing has been fixed in code, but not yet released. For this you have two options. The official beta and the unofficial beta snapshot.
The official beta is for @topjohnwu to test the release before it goes out to the masses. Read the OP carefully and follow any directions given.
If you're feeling brave you can try the unofficial beta snapshot. It's built directly from source and can sometimes be unusable. Keep an eye on the thread for current issues.
Changelog
Hiding root and passing SafetyNet - Changelog
2017-07-19
Updated "Check the logs".
Updated "Nothing works!".
2017-07-14
Added a link to a commit that fixes the disappearing Developer options issue on some ROMs with ro.build.type set to "user". Thank you @The Flash.
Moved "SafetyNet never finishes" to a more logical location.
2017-07-11
Updated for Magisk v13.1.
2017-07-06
Updated the section about "Magisk Manager" being detected. Renamed to "Detecting Magisk Manager or apps requiring root".
Removed duplicate information about SafetyNet being updated.
2017-06-27
Updated info about "Spoofing device fingerprint".
Small update to "Dangerous props".
2017-06-19
Updated info about beta releases.
2017-06-18
Updated info about the latest SafteyNet update and how to bypass it.
Updated info about the Universal SafetyNet fix module by @Deic.
Added section about "Spoofing ro.build.fingerprint".
Moved "Outdated tips and tricks" to it's own post.
2017-06-16
Added notes about the update to SafetyNet and how to bypass it.
2017-06-01
Removed "Unlocked bootloader, permissive SELinux and Samsung KNOX".
Moved "Samsung KNOX".
Added "Magisk Manager".
2017-05-26
Some more clarifications on "Magisk Hide isn't unmounting...".
Added info about multiuser under "Device uncertified...".
2017-05-25
Added some info about setns support under "Magisk Hide isn't unmounting folders as it should".
2017-05-19
Added "some Moto device" to known devices that need official prop values added to custom ROMs to pass SafetyNet.
Added a link to the guide to pass SafetyNet on Moto G 2015 by @coolguy_16.
Some clarifications about Samsung KNOX.
Minor clarifications on Play store certification.
2017-05-14
Minor clarifications.
2017-05-09
Added a new section, "Magisk v12 can't hide root (but v11.6 could)".
2017-05-06
Added some more tips under "Magisk Hide isn't unmounting folder as it should" (Xiaomi devices).
Added some clarifying headings.
Added an index in the OP.
2017-05-03
Added a section about matching official ROM prop values to pass SafetyNet.
Added a link to Xiaomi SafetyNet fix module by @Deic.
2017-05-02
Slightly update information regarding SafetyNet incompatibility, CTS profile matching and Basic integrity.
Minor cosmetic changes, rearranging and typos.
2017-05-01
Another small clarification. This time under "Asking for help".
Slight clarification on issues with unmounting.
2017-04-28
Added a section about setting Logger buffer size to off breaking Magisk Hide.
2017-04-25
Added a command to test for kernel logcat support and a possible solution for a lack thereof.
2017-04-24
Moved info about busybox and systemless host issues to "Busybox conflict" and "Systemless hosts" under the section about Magisk hide not unmounting folders.
2017-04-20
Added a section about certification status in the Play store. "Some apps won't install or doesn't show up in the Play store".
Added "Check the logs".
Added "Magisk Hide isn't unmounting folders as it should". Again: thank you @tamer7.
More minor clarifications.
2017-04-19
Minor clarifications.
2017-04-16
Added a note about Core Only Mode.
2017-04-09
Added section about starting Magisk Hide manually.
Added section about Magisk built-in busybox or systemless hosts possibly causing SafetyNet to fail on some ROMs.
2017-04-07
Updated "Dangerous props".
Updated information about Samsung KNOX (Samsung pay probably won't work).
2017-03-31
Updated for Magisk v12.
Moved old and outdated tips and tricks to the bottom.
2017-03-22
Changing prop values may have undesired effect (duh).
Moved "Restarting Magisk Hide" to the beginning of the text and updated it. Might be a good thing to start with when troubleshooting.
2017-03-21
Added ro.build.flavor to "dangerous props".
Added information about what to try when a prop value isn't set properly.
More updates for Magisk v11.6 (resetprop added to PATH).
Clarifications.
2017-03-20
Updated for Magisk v11.6
Removed "ro.build.selinux" from "dangerous props" since it might cause issues with SELinux.
2017-03-15
Clarifications about finding out if you have "dangerous props" set to undesired values.
Added a new "dangerous prop" example (ro.build.selinux).
2017-03-14
Added a link to the Beta snapshot thread.
2017-03-10
Small update to the "Samsung..." section.
2017-03-06
Clarification about setting props and figuring out dependencies, etc.
2017-03-06
Added some info to "Dependencies".
Added section about how to figure out what an app is looking for to detect root.
2017-03-03
Added some information about "Dangerous props".
Updated information about SafetyNet CTS profile mismatch and Basic integrity.
2017-03-02
Changelog started.
Added Samsung SELinux tips.
Refinements.
2017-02-23 - 2017-03-02
Various additions.
Refinements.
2017-02-23
Initial post.
Old and outdated tips and tricks for "Installing Magisk and Modules"
Unmounting of folders is no longer showed in the Magisk log, since Magisk v13.1.
MagiskHide isn't unmounting folders as it should
If MagiskHide isn't unmounting as it chould for the processes/packages added to the Hide list (there are no "hide_daemon: Unmounted" entries in the log or there are entries showing that the unmount failed ("hide_daemon: Unmount Failed")), see "MagiskHide isn't unmounting folders as it should" below.
If you don't see any entries in the Magisk log for "hide_daemon: Unmounted", MagiskHide isn't functioning as it should and can't hide Magisk from apps and processes that trigger if root is found. There are a few reasons as to why this might happen. See "Kernel logcat support", "Logger buffer size", and "Mount namespace issues" below. Of course, these might not be the only reasons. If you're lucky, one of the solutions below will work for your particular case.
If there are entries in the Magisk log showing that the unmount failed ("hide_daemon: Unmount Failed"), take a look at what folder it's failing for and disable the corresponding Magisk module. If you can't work out what module is causing the issue, disable them all and enable one by one until you find the culprit. If it is one of your installed modules causing the issue, ask for advice in the module's support thread.
It might be that you have to rely on manually starting MagiskHide to make it unmount folders properly (known: some Xiaomi devices/MIUI). See "Starting MagiskHide manually" above.
Busybox is no longer bundled with Magisk since v13.1.
Randomly losing root
Some devices and/or ROMs (known: Lineage OS) have issues with losing root when using MagiskSU. This can sometimes be fixed by disabling busybox in Magisk Manager settings. Some users have also reported success by disabling systemless hosts instead/as well.
Magisk v13+ is fully compatible with stock Sony ROMs.
Sony and MagiskSU
If you're using a Sony device and have the above issue with MagiskSU, you're probably running a stock boot image or otherwise haven't disabled Sony RIC. Don't worry, @[email protected] have got the fix for you here.
Old and outdated tips and tricks for "Hiding root and passing Safety Net"
The changed prop values have been reintroduced with Magisk v13.1.
Magisk v12 can't hide root (but v11.6 could)
If you have an app that you can hide root from with Magisk v11.5/v11.6 but not after upgrading to v12, you need to take a look at the "Dangerous props" section below. In Magisk v11.5 and v11.6, Magisk Hide would alter a few build.prop values, specifically a couple of the usual suspects mentioned in "Dangerous props". These are ro.build.tags and ro.build.type. This was reverted with Magisk v12 since it has the potential to cause issues and is better left to the users discretion.
So, if you can fool an app with Magisk v11.5/v11.6, but not with v12. Try changing ro.build.tags and/or ro.build.type to "safe" values. Again, see "Dangerous props" below.
Scripts are no longer used in Magisk v13.1.
If you have a device where you find you have to start Magisk Hide manually to pass SafetyNet, try editing the enable script (found in /magisk/.core/magiskhide) and change the last line to:
Code:
(su -c $BINPATH/magiskhide --daemon)
This might make Magisk Hide work properly on your device.
Busybox is no longer bundled with Magisk since v13.1.
Busybox conflict
If you already have busybox installed or your ROM comes with it built-in, enabling Magisk busybox may cause a conflict that breaks Magisk Hide. Either use and update the existing installation or remove it if you want to use Magisk busybox.
Magisk v13.1 does note have these issues.
Since beginning of June 2017, SafetyNet has been updated. Magisk v12 and lower versions can't pass. The solution is to enable Core Only Mode in Magisk Manager settings and you might also have to disable systemless hosts. In Magisk v13.0 beta, this has been fixed (but of course, there might be other issues present). Note that this guide is written for Magisk v12 and the tips in it may not be applicable for Magisk v13 beta. I'll update the guide for v13 when it is released from beta.
For users of Magisk v12 @Deic have made a Magisk module that might make SafetyNet pass with modules active. Note that this module will also change your device's fingerprint to match a Xiaomi Mi 6 (for devices/ROMs that have no CTS certification), also see "Spoofing ro.build.fingerprint" below. @yochananmarqos have made a version of the module that leaves out the fingerprint part, for users that could pass SafetyNet before the update. See the links for details.
Module link removed from the guide since it does so much more than just editing the fingerprint.
@Deic have updated his Xiaomi SafetyNet fix module to be a Universal SafetyNet fix module that does just this. It'll change your devices fingerprint to match an official one for Xiaomi Mi 6. It'll also make Magisk v12 pass SafetyNet with modules installed.
IMO it'd be best if you could use a fingerprint that more closely matches your device (you'll find it in the build.prop file). If you're on a custom ROM that doesn't pass SafetyNet and the stock ROM does, use the stock ROM's prop values, etc. To change the fingerprint set by the module, unzip it and open up the post-fs-data.sh file in a text editor that can handle Unix line endings (on Windows this means Sublime, Atom, Notepad++ etc). Change the following two lines to match your device's stock ROM:
Code:
$RESETPROP "ro.build.fingerprint" "Xiaomi/sagit/sagit:7.1.1/NMF26X/V8.2.17.0.NCACNEC:user/release-keys"
$RESETPROP "ro.bootimage.build.fingerprint" "Xiaomi/sagit/sagit:7.1.1/NMF26X/V8.2.17.0.NCACNEC:user/release-keys"
No longer applicable.
An app still detects the original prop value
If Magisk Hide doesn't start properly at boot, it can be started by toggling Hide off and on again in settings. But, when doing this, some of the prop values changed by Magisk Hide may not get set properly. Try rebooting your device and see if Hide starts up properly. If it doesn't it might be one of your modules causing issues.
If it's a prop value you're changing yourself with a Magisk module and you're using system.prop to set the value, try moving the script to post-fs-data.sh and use resetprop instead. See here for more resetprop syntax. Example:
Code:
[I]system.prop code:[/I]
ro.build.tags=release-keys
[I]post-fs-data.sh code:[/I]
resetprop ro.build.tags release-keys
Removed from the guide since the feature doesn't seem to work anyway.
Samsung KNOX
If you're having issues with Samsung KNOX, use a KNOX checker app from the Play store to see if it reports as triggered or not. Samsung pay and other Samsung apps/services that check KNOX have been reported to still see the KNOX counter as triggered, even though it gets masked by Magisk Hide.
The module have been updated to a universal SafetyNet fix.
Deic have made a Magisk module for Xiaomi devices that does the above, Xiaomi SafetyNet fix.
Since Magisk v11.5 resetprop is added to PATH and can be called directly through shell and apps.
Code:
/data/magisk/resetprop ro.build.tags release-keys
This part is no longer necessary since Magisk v11.5. It's changed by Magisk by default. Only do this if you're using an earlier release.
Some Samsung users with custom ROMs have reported that they have had to do some modifications to the permissions for a couple of files related to SELinux to pass SafetyNet. These files are "/sys/fs/selinux/enforce" and "/sys/fs/selinux/policy". The "enforce" file should have permission 640 (rw-r-----) and the "policy" file should have permission 440 (r--r-----). This can be easily automated with Magisks General Purpose Boot Scripts (see here for details) or a Magisk module. The lines needed for the script are:
Code:
#!/system/bin/sh
chmod 640 /sys/fs/selinux/enforce
chmod 440 /sys/fs/selinux/policy
Magisk Hide uses a pseudo-enforcing SELinux state to mask a permissive kernel
Permissive SELinux
You can check if it’s SELinux causing problems by typing (without quotation marks) “getenforce” in a terminal emulator. If it reports permissive you can try temporarily setting it to enforcing by typing “setenforce 1” (this requires root access) and see if this makes SafetyNet pass. To make SELinux permissive again, use “setenforce 0” or reboot your device (if it’s permissive by default). If you want a more permanent solution it can be done with Magisks General Purpose Boot Scripts. See here for details. The lines needed for the script to set SELinux to enforcing are:
Code:
#!/system/bin/sh
setenforce 1
Check the module support thread for update.
Update 20170228
Since a little syntax error in the mounting script from Magisk v11.0-v11.1, mounting link systemless-ly won't success. Hence we choose copy but not to link the su binary for v11.0-v11.1. Don't worry, both methods are systemless.
==========
Great guide. :good:
Just made a simple module try to solve the /sbin/su not detectable problem. This module will look for existing su binary, and create a link as /magisk/su_xbin_bind/system/xbin/su pointing to the real su. The link will also be mounted as /system/xbin/su systemless-ly later.
Installation
Flash it in RECOVERY, then reboot. And you will find a link /system/xbin/su. All the work is done systemless-ly.
Uninstallation
Open Magisk Manager, go to Modules, disable or uninstall the module called "Su xbin_bind". Then it will disappear after reboot.
laggardkernel said:
Great guide. :good:
Just made a simple module try to solve the /sbin/su not detectable problem. This module will look for existing su binary, and create a link as /magisk/su_xbin_bind/system/xbin/su pointing to the real su. The link will also be mounted as /system/xbin/su systemless-ly later.
Installation
Flash it in recovery, then reboot. And you will find a link /system/xbin/su. All the work is done systemless-ly.
Uninstallation
Open Magisk Manager, go to Modules, disable or uninstall the module called "Su xbin_bind". Then it will disappear after reboot.
Click to expand...
Click to collapse
Nice! I added a mention of this in the guide. You should get this in the repo...
Great guide. Apparently this contains almost all the troubleshoot steps and known issues right from the original support thread of Magisk. However it would be complete if you had added the steps that user reported working on various custom roms that are known to not pass safetynet. One of the step is below for pre rooted custom roms :
1. Go back to recovery.
2. Flash unSU.zip by osmosis
3. Flash magisk 10.2
4. Boot to system. Install Phh superuser. Update binary.
5. Update to latest magisk from magist manager. Reboot.
6. Check safetynet, it should work.
This is reported to be working for some user, and some other reported it didn't work. But still worth a try.
iubjaved said:
Great guide. Apparently this contains almost all the troubleshoot steps and known issues right from the original support thread of Magisk. However it would be complete if you had added the steps that user reported working on various custom roms that are known to not pass safetynet. One of the step is below for pre rooted custom roms :
1. Go back to recovery.
2. Flash unSU.zip by osmosis
3. Flash magisk 10.2
4. Boot to system. Install Phh superuser. Update binary.
5. Update to latest magisk from magist manager. Reboot.
6. Check safetynet, it should work.
This is reported to be working for some user, and some other reported it didn't work. But still worth a try.
Click to expand...
Click to collapse
I hadn't seen that one before. Looks a little fishy (updating the phh's superuser binary?), but I'll do some research on that and see if I can work this into the guide somehow.
2 posts removed.
Do not discuss or post warez on XDA.
Thank you.
:good:
The Merovingian said:
2 posts removed.
Do not discuss or post warez on XDA.
Thank you.
:good:
Click to expand...
Click to collapse
Sorry
Didgeridoohan said:
I hadn't seen that one before. Looks a little fishy (updating the phh's superuser binary?), but I'll do some research on that and see if I can work this into the guide somehow.
Click to expand...
Click to collapse
These steps are from the Magisk thread, i could be wrong about binary update ( considering when installing any superuser, you will get prompt for updating binary?) but rest of the steps are exactly as it was mentioned there. I wish i could link you for reference but i have to go through the whole thread again and search for these . You can post these steps on the magisk support thread for clarification. Great work once again. Good luck!
laggardkernel said:
Great guide. :good:
Just made a simple module try to solve the /sbin/su not detectable problem. This module will look for existing su binary, and create a link as /magisk/su_xbin_bind/system/xbin/su pointing to the real su. The link will also be mounted as /system/xbin/su systemless-ly later.
Installation
Flash it in recovery, then reboot. And you will find a link /system/xbin/su. All the work is done systemless-ly.
Uninstallation
Open Magisk Manager, go to Modules, disable or uninstall the module called "Su xbin_bind". Then it will disappear after reboot.
Click to expand...
Click to collapse
Hey installed ur module, but still root checker detects no su file symlinks in xbin :crying:
Xennet said:
Hey installed ur module, but still root checker detects no su file symlinks in xbin :crying:
Click to expand...
Click to collapse
Did you reboot your phone after installation? And try to check its existence in /magisk/su_xbin_bind/system/xbin. If the su link exists here, where does it point to?
laggardkernel said:
Did you reboot your phone after installation? And try to check its existence in /magisk/su_xbin_bind/system/xbin. If the su link exists here, where does it point to?
Click to expand...
Click to collapse
Yes rebooted. It is activated in magisk. The su link exists in /magisk/su_xbin_bind/system/xbin/. Opening t link directs to su...But how to check it where it directs to..
Really dis is a great module to get t apps dat look for real root location xbin/su...
Please help
Xennet said:
Yes rebooted. It is activated in magisk. The su link exists in /magisk/su_xbin_bind/system/xbin/. Opening t link directs to su...But how to check it where it directs to..
Really dis is a great module to get t apps dat look for real root location xbin/su...
Please help
Click to expand...
Click to collapse
How about /magisk/su_xbin_bind/auto_mount, does it exist? If not, create an empty file and name it as auto_moint.
laggardkernel said:
How about /magisk/su_xbin_bind/auto_mount, does it exist? If not, create an empty file and name it as auto_moint.
Click to expand...
Click to collapse
auto_mount exists too
Xennet said:
auto_mount exists too
Click to expand...
Click to collapse
Now, I need more detail to figure it out.
1. Where does the su link point to? Does it exist in /system/xbin and /dev/magisk/dummy/system/xbin. Use a explore to check su's position and the Link's property, or use a terminal
Code:
su
ls -al /magisk/su_xbin_bind/system/xbin/su
2. What is the version of your magisk? Upload your /cache/magisk.log and /sbin_orig/magisk_mask.sh for me, please.
3. Which ROM are you using and is there any root imbedded?
I'm using an op3 with OOS 3.2.7, Magisk v11.1, and the su_xbin_bind module works well now. It seems you're using an op3 or op3t. So it's weird for me the module don't work on your device.
Much obliged if you could tell me the package name of the root checker app in your picture.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Smali Patcher
WHAT THE HELL IS THIS THING? ::
To sum things up this is an application I developed that pulls the android framework from your device, applies what I (or other users) consider useful patches to the sourced files and then finally generates a magisk module applying the patches system-lessly.
The unique thing about Smali Patcher is it sources the framework files from your device, in an attempt to provide maximum compatibility across the entire android device family.
While I have your attention I wanted to throw out a massive thank you to all the people who have provided support to the project and the thread over the years, you guys are absolute champions. I can't thank you enough and couldn't have done it without you, here's to ya!
PATCHES ::
Mock locations - Hide mock locations status, allowing apps like Pokemon GO to treat them as genuine location updates.
Mock Providers: Allow creation of mock providers without mock permissions.
GNSS updates: Disable all GNSS (GPS) location updates.
Secure flag - Allow screenshots/screensharing in secure apps.
Signature verification (as-is, legacy support only) - Disable signature verification allowing modification/execution of signed system apps.
Signature spoofing (as-is) - Enable signature spoofing app permission.
Recovery reboot - Reboot directly back into recovery from powermenu.
Samsung Knox (as-is, legacy support only) - Bypass Samsung Knox trip protection, only confirmed working for secure folder.
High volume warning - Disable high volume popup dialog.
Any patches marked "as-is" are no longer maintained and only kept in for legacy device support only, not recommended to be used on newer android versions (10/11).. use at your own risk.
GPS SPOOFERS / FUSEDLOCATION / RUBBERBANDING NOTICE ::
FusedLocation API GPS spoofers are NOT compatible with the mock location patch.. your required to use a traditional GPS spoofer! Spoofed location updates will be fed into fusedlocation all the same, meaning you don't need to disable the service.. which means while your not spoofing you still gain the benefit of fusedlocation which is all around more accurate location updates!
REQUIREMENTS ::
PC with at least 3GB+ of RAM.
.NET Framework 4.7.1 or later installed
Java installed
Android device running 6.0 or above.
INSTRUCTIONS (ADB METHOD/AUTOMATED - RECOMMENDED):
COMPATIBLE WITH BOTH ODEX & DEODEXED ROMS! WILL AUTOMATICALLY DEODEX REQUIRED FILES IF NECESSARY.
Backup device.. safety first kids.
Enable USB debugging in developer settings on your device and connect via USB to your PC.
Authorise USB debugging connection on your phone.. example of popup.
Run "SmaliPatcher.exe", First startup will automatically download the latest necessary binary's.
Select your desired patches.
Hit "ADB PATCH" button (yes without browsing for a .jar file).
Once the process has completed, magisk module will be generated in the same directory as "SmaliPatcher.exe" named: "[email protected]".
Install the generated magisk module either in recovery mode or from the magisk app.
Enable smali patcher module in magisk.
INSTRUCTIONS (ALTERNATIVE METHOD - FOLLOW ONLY IF ADB METHOD FAILS) ::
Backup device.
Enable USB debugging in developer settings on your device and connect via USB to your PC.
Authorise USB debugging connection on your phone.. example of popup.
Run "SmaliPatcher.exe", First startup will download the latest necessary binary's.
Browse to your "/system/framework" directory. Easiest way to obtain these files is from your rom img/zip.
Select your desired patches.
Hit the "PATCH" button.
Once the process has completed, magisk module will be generated in the same directory as "SmaliPatcher.exe".
Install the generated magisk module either in recovery mode or from the magisk app.
Enable smali patcher module in magisk.
YOU ARE STILL REQUIRED TO HAVE A DEVICE CONNECTED TO YOUR PC IF YOU USE THIS METHOD.. THE PATCHER WILL NOT PROGRESS OTHERWISE.
A ADB DEVICE IS REQUIRED TO EXTRACT CDEX FILES.. IF YOU'RE PARANOID/SAVY ENOUGH, YOU CAN USE A ANDROID EMULATOR.
BEFORE REPORTING ANY ISSUES ::
You have tried running the patcher as administrator.
You have accepted the USB debugging connection & ticked "Always allow from this computer".
You have tried running the patcher with phone booted in recovery mode with /system mounted.
shoey63 said:
Adb method works flawlessly on android 8.1 for Sony AOSP roms on X and XZ premium. The trick is to run the program in recovery (with system mounted obviously), to avoid permission issues.
Awesome tool!
Click to expand...
Click to collapse
UPDATING MODULE INSTRUCTIONS:
Disable/uninstall any active smali patcher modules before generating a new one! If you generate a module with a older version active there's a chance the outdated patches will carry over to the new module.. I do my best efforts to prevent this, but it may still happen. Before reporting issues, make sure you have tried this.
CHANGELOG ::
7.4
Modified patch - GNSS updates: now correctly handles protected methods.
7.3
First pass of android 11 patch updates: mock provider, gnss update & secure flag patch updated.
7.2
Modified patch - Secure flag: revert a change I made, should solve issues on some devices.. hopefully.
7.1
New patch - GNSS updates: Disable all GNSS (GPS) location updates.
Modified patch - Secure flag: tested & working on Samsung devices running android 10.
7.0
New patch - Mock Providers: Allow creation of mock providers without mock permissions.
6.9
Allow devices booted in recovery mode through ADB check.
6.8
Made patches "compatible" with the latest android 11 beta (pixel).. none of which have been tested on android 11. BACKUP! BACKUP! BACKUP!
6.7
Removed "magisk-module-template" dependency.
6.6
Fixed patch - Magisk reboot: was not being applied when selected.
"Magisk reboot" patch renamed to "Recovery reboot".
6.5
Updated patch - Magisk reboot: now compatible with Samsung One UI 2.0 (android Q).
6.4
New patch - Samsung Knox: Bypass samsung knox trip protection, only confirmed working for secure folder.
6.3
ADB error checking: require a ADB device to be present even while patching "browsed" for framework dumps.
Framework error checking: display an error if no odex, vdex or oats are found.. incomplete framework dump.
Display hints for common mistakes made by users, hopefully reduces the amount of "error" reports by people that don't follow instructions.
6.2
ADB error checking: unauthorized ADB device check.
6.1
Error handling - Verify required files are found during deodex process.
6.0
Fixed index out of bounds crash.
Revert mock location patch to the original.
5.9
Mock location patch updated. Reverted patch back to the original, new patch failed.
Adapted back end functions to support multi-file patches.
Browse for .jar has now been changed to browse for "/system/framework" directory.. no longer requires a deodexed file to be targeted, will deodex necessary files if required.
5.8
Check if patcher is being ran with administrator privileges, otherwise display a warning.
Fixed a possible false positive error during cdex extraction.
5.7
Error handling - verify classes.dex is found during cdex extraction.
Added few more status updates to assist error checking.
5.6
Changed binary download percentage behaviour: avoid users reporting false "stuck on XYZ percent".
Updated mock location patch to support android 10/Q.
Updated reboot behaviour patch to support android 10/Q.
Save/restore selected patches when browsing for a JAR.
5.5
Fixed force close during vdex extraction.
5.4
Modified secure flag patch - need testing & feedback.
Modified java detection to allow more runtime environments.
5.3
Suppress false positive "magisk download failed" errors.
Verify patched APK's have been generated before creating module.
5.2
Modified secure flag patch.
Added paypal donation button.
5.1
Removed signature verification "class not found" error report, false positive on legacy android versions.
5.0
Adapted backend functions to support multi-file patches.
Require at least one patch to be enabled before proceeding.
Fix download percentage status updates.
Popup explorer window to output directory on completion.
Modified signature verification patch (android P).
When browsing for a JAR only display compatible patches (preparation for multi-file patches, services.jar must be named "services.jar" from this point onward for verification purposes.. otherwise no patches will be displayed).
New patch - disable high volume warning popup.. this has annoyed me so much recently! I was only able to test this on android P, if you find the patch does not work on your device please supply a deodexed services.jar so I can investigate further.
4.9
Fixed a crash when applying magisk reboot patch to a already patched target.
Improved magisk reboot patch, removed the potential to not reboot back into magisk.
Redirect output for certain binary functions with working status indicators.
Fix mock location patch that I broke in the most stupid way possible.. if you're updating from 4.8, make sure you disable/remove any installed smali patcher magisk modules before updating.
4.8
Display command line window until inbuilt patcher status updates are fixed to prevent user confusion.
4.7
Secure flag patch update (based off 9.0).
Signature verification patch update (based off 9.0).
4.6
Dynamically calculate base directory.
Modify output loop to ensure all output is displayed.
Magisk reboot patch (Galaxy S10 only).
4.5 [UNTESTED - I OWN A S10 WHICH CURRENTLY IS NOT MAGISK COMPATIBLE.. USE AT YOUR OWN RISK]
Force unix config formatting.
4.4 [UNTESTED - I OWN A S10 WHICH CURRENTLY IS NOT MAGISK COMPATIBLE.. USE AT YOUR OWN RISK]
Magisk "installation failed" fix.. (I shouldn't have been lazy and read all the module documentation.. probably could of avoided this).
4.3 [UNTESTED - I OWN A S10 WHICH CURRENTLY IS NOT MAGISK COMPATIBLE.. USE AT YOUR OWN RISK]
Magisk v19.0 compatible (magisk template download failed fix).
4.2 [TESTING]
Potential slowdown fix?
4.1
Allow the patcher to run without having any patches selected for testing purposes.
Force a single classes.dex to be generated when applying signature spoofing patch.. (potential slowdown fix?)
Remove irrelevant debug output.
4.0
Modified ADB error checking function to fix false error reports.
3.9 ::
ADB error checking: verify a single ADB device is connected before proceeding.
Added few more status updates to assist error checking.
Updated magisk template & URL.
3.8 [TESTING] ::
Potential slowdown fix?
3.7 ::
Modified java detection.
3.6 ::
Added some more error checking.
3.5 ::
Verify Java is installed & detected before proceeding.
3.4 ::
Amend legacy dummy file to generated magisk module config.sh.
3.3 ::
Create dummy file in magisk module (legacy devices).
3.2 ::
Fixed a issue calculating file paths on legacy devices.
3.1 ::
Added "/system/system" path to dumping functions.
Added output filter to avoid user confusion when spitting out harmless errors.
3.0 ::
Updated dependencies.
Reworked some core functions to attempt to fix unknown caused crash for certain users.
2.9 ::
Reworked some functions, made them dynamically detect file names to avoid potential issues.
2.8 ::
Verify dexpatcher patches are found, otherwise re-download.
Change patch button text to indicate patching mode.
Error handling - verify classes.dex is found before recompiling.
Error handling - verify services.jar is found before recompiling.
Error handling - verify input files are not dummy's.
Conditional dead end bug fix while patching multi-class jar's.
2.7 ::
Re-added signature spoofing patch.
Added dexpatcher as a dependency.
2.6 ::
Added support for Android P.
Modified binary download function to prevent crashes.
2.5 ::
Added support for multi-classes.dex.
2.4 ::
Improved binary download function - verify binary size, will attempt to re-download if necessary.
Improved binary URL grabber function - should now fetch correct address.
2.3 ::
Improved de/odex detection function - should now allow generating a module with no mods selected (debugging purposes)
Improved error checking & reports.
2.2 ::
Android 8.0-8.1 compatibility.
2.1 ::
Corrected missing variables in config.sh for magisk module (lollipop bootloop fix) - full credit to @Eng.Raman
2.0 ::
Prevent false "detected api" message.
Play's nice with android lollipop - full credit to @Eng.Raman
1.9 ::
Potential fix for random crash aka. dumping framework freeze/crash.
1.8 ::
Handle "permission denied" error when pulling build.prop.
1.7 ::
Improved framework base directory detection.
1.6 ::
Framework base directory detection.
1.5 ::
Improved error checking - added more debug info which hopefully will make diagnosing bugs a little easier.
Proper API detection using rom build.prop.
Improved a search function used for locating framework files.
1.4 ::
Improved error checking - verify's services.odex size detecting if module already active.
Potential fix for "magisk download failed" that certain user's are experiencing.
1.3 (BETA) ::
Added in ADB libary which allows us to now pull/push files to the device.
Added in smali & baksmali which allows us to now deodex.
One click function to pull all the required files from the device, deodex (if necessary), patch and finally generate a magisk module! (I plan to code in a function that pushes the module to the device upon completion in the future - fully automated baby woohoo)
If you would like to use the adb method of patching, make sure you have "USB debugging" enabled in developer options otherwise it simply won't work.. you obviously need to plug in your phone to the PC and authorize the USB connection on your device.
1.2 ::
Updated to Magisk v15.
Improved error checking & reports.
1.1 ::
Removed signature spoofing for the time being - causing bootloop for some users, need to rework the patch when I have time.
1.0 ::
Improved patching function: should now be compatible with even more unique service.jar's.
Improved patching function: now reports errors for each independent patch, should make diagnosing patch errors a little easier.
Fixed some debug code I left from previous release which may have prevented patch process from completing. (whoops.. sorry about that!)
0.9 ::
Added new patch: signature spoofing.
0.8 ::
Improved patching function.
0.7 ::
Merged projects together - Mock locations, secure flag & signature verification.
Assembly version used as module version and in generated module zip name.
Fixed minor bug when selecting a JAR named something other than "services.jar".
0.6 ::
Error handling for failed downloads of magisk module template.
Updated to Magisk v14.0.
0.4 / 0.5 ::
Potential spaces in file path error fix - unsure as I have been unable to reproduce this issue, so it's been very difficult to fix.
0.3 ::
Increased default Java memory heap size - fixes "out of memory" error on lowend PC's.
0.2 ::
Simplified patching process.
Fixed reboot issue with certain GPS spoofers.
Verify's target JAR is deodexed before proceeding with patch.
0.1 ::
Initial release
Cheers,
Honorable mention to @Eng.Raman & @A30NI_Y, who has been kind enough to patch service.jar's for tons of users who lack the knowledge to deodex (despite my best efforts of writing out clear instructions!)... the smali patcher user base thanks you for your service!
PRECAUTIONS / TERMS OF USE ::
You must backup your device prior to flashing the module, I am not responsible or providing support to recover any devices stuck in bootloops.. if for what ever reason you find yourself in this situation, simply uninstall magisk and reinstall.. doing this will reset your installed modules.
PLEASE READ FAQ IN POST 2 & SEARCH THE THREAD BEFORE ASKING QUESTIONS, CHANCES ARE THEY HAVE BEEN ANSWERED ALREADY AND YOU CAN FIND YOUR ANSWER IMMEDIATELY.
Rather then making mirrors of the download link, please redirect traffic to this thread to ensure they are always using the latest version! Oh hi reddit.
DOWNLOAD MIRRORS
Google drive
FAQ
HELP! I'M STUCK IN A BOOTLOOP, HOW DO I UNINSTALL ::
Boot into TWRP
Advanced -> File Manager
Navigate to: data -> adb -> modules -> select the module directory (in this case "fomey.smalipatcher") -> Folder icon (bottom right of screen) -> Delete
Alternatively you can just uninstall/reinstall magisk to clear all your modules.
MAGISK TEMPLATE DOWNLOAD FAILED ::
Run the patcher as administrator, may not have read / write access to drive.
Verify you have a active internet connection.
Verify firewall is not blocking the patcher.
Verify your not running a outdated .NET framework.
MOCK LOCATION RUBBER BANDS TO REAL LOCATION ::
Set device only in location method settings (Settings -> Location -> Location method).
Disable improve location accuracy settings (Settings -> Location -> Improve accuracy).
If you are still experiencing rubber banding after trying everything above, try a different spoofer.
INVALID OR CORRUPT JAR FILE BIN ::
Delete the "bin" directory and restart the patcher to re-download the binary files.
Corruption is caused by a unreliable internet connection.
HOW DO I CLEAR A MOCK LOCATION WHILE USING A GPS SPOOFER ::
Exit the app by pressing the "back" key, you may have to press this a few times. Any good spoofer should clean up after itself, by removing any mock providers on exit.
MAGISK TEMPLATE FAILED TO DOWNLOAD ::
Make sure you're using the LATEST release of the patcher.
If you are using the latest version already.. a update will be available shortly to fix this issue.
UNSUPPORTED MAJOR.MINOR VERSION XX.X ::
Use the Java Uninstall Tool to clean up out-of-date java versions and reinstall the latest java release.
W: COULD NOT FIND RESOURCES ::
This is a harmless warning, you can safely ignore it.
!!! ERROR: BASE DIRECTORY NOT FOUND ::
You did not accept the USB debugging permission popup on your phone.. the patcher can't do anything without this permission (example of popup).
The permission popup should be displayed after hitting the "ADB PATCH" button.. or as soon as you connect your phone to your PC.
If you can't see the permission popup: go to settings -> developer options -> revoke usb debugging authorisations.. disconnect and reconnect your phone and try again.
Make sure you tick "always allow from this computer".. otherwise you may have to confirm the popup multiple times during a single patch.
!!! ERROR: XYZ CLASS NOT FOUND ::
The patch is most likely not compatible with your android version/device, if a patch is marked "as-is" no further support is provided.
If you are browsing for a services.jar - it's most likely not deodexed.. try the "ADB METHOD".
If you are using the "ADB METHOD" and you receive this error, post a reply to this thread including as much information as you can. Useful information: android version, patcher log and the directory named "adb" in the patcher folder (upload this directory to google drive).
Reserved 3
Thank you very much for your smali patcher. I am using your mock location for a while now. Will it be compatible with Android Oreo?
flyfire04 said:
Thank you very much for your smali patcher. I am using your mock location for a while now. Will it be compatible with Android Oreo?
Click to expand...
Click to collapse
I have not tried it with a oreo services.jar, test it out let me know how you go.. if you run into issues please upload your deodexed services.jar.
Hey, could you make it just a zip that would do all the patches? I don't have a windows machine but I really want the screenshot thing I... Also I can do any testing that you want on the Oreo.
Thank you mate!!!
Awesome! Thank you!
Hi devs, sorry for interrupt. I have some problems while patching it here. I choose all three patch and run the patcher, However it suddenly stops and saying jar is not deodexed. When im untick all 3 patch and run the patcher, it runs well until completed. The problems only happens when I choose all or either one of the patches.
Im using samsung note 4 with custom deodexed rom :crying:
TheBuduLord said:
Hi devs, sorry for interrupt. I have some problems while patching it here. I choose all three patch and run the patcher, However it suddenly stops and saying jar is not deodexed. When im untick all 3 patch and run the patcher, it runs well until completed. The problems only happens when I choose all or either one of the patches.
Im using samsung note 4 with custom deodexed rom :crying:
Click to expand...
Click to collapse
Has anyone tried this on the Google pixel XL? Also when I download it and try to open it it tells me it can not be open ed
@fOmey Sir, when Smali Patcher on Linux and Android devices?
um, is this tool still not compatible with nougat's services.jar?
The patch button doesn't do anything at all.
Edit: nvm, restarting the program fixed it
HI !
When I extract my zip rom, I don't see any "system" folder ... (It's pixel ROM for nexus 5)...
Any ideas ?
Thanks.
AvisAile said:
HI !
When I extract my zip rom, I don't see any "system" folder ... (It's pixel ROM for nexus 5)...
Any ideas ?
Thanks.
Click to expand...
Click to collapse
This thread will help you out: https://forum.xda-developers.com/an.../how-to-conver-lollipop-dat-files-to-t2978952
rawimagee said:
Hi, i took my "services.jar" from my framework folder (OnePlus 5) and it says it is not deodexed. I have tried programs that will make the jar file to work in your flasher but it still does not work. Can you like write a little tutorial to me? Thanks
Click to expand...
Click to collapse
Copy the systems folder from your smartphone. (I copy it to the download folder, zip it, copy it and unzip it on the computer).
use Fulmics Deodexer (xda), download smali and baksmali from here https://bitbucket.org/JesusFreke/smali/downloads/ point fulmics deodexer to those files in the settings. Look for your systems folder with fulmics deodexer and only tick the frameworks box (the other ones are unneccesary for this task). then proceed with the smali patcher
@fOmey
I can not start your program. Can you make this pacher for me on my services.jar file so that I can put it into the framework system? My file with S7 edge nougat 7.0 Stock.
https://files.fm/u/j388jjj5
Tested on Oreo and it works great
The app crashes after i hit the start making path button on windows 10.. any help ??? Got the bins downloaded and my services.jar loaded in youre app/program.
rawimagee said:
I did that and but it still seems to not work, it said that it processed the "services.jar" file but it still says the same in the patcher;(
edit: do i pick the normal "services.jar" file from the normal folder or do the "edited" file get placed somewhere else?
Click to expand...
Click to collapse
OP5 is on Nougat, so I don't think this will work.
Sent from my OnePlus3 using XDA Labs