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.
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:
New Badass Tool - resetprop
- 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!
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:
# 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
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/resetpropMagisk 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!
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!