For example, Lineage's com.android.ondevicepersonalization apex_manifest.pb has a # char, which strings keeps in its output, and breaks the mount for that apex before this fix
I previously refered to minigzip from libz which copies all trailing
data to the output when decompressing. However, gzip, on the other
hand, drop trailing garbage by default. Consider ZIMAGE append
the kernel size with zero padding, we should drop trailing garbage
as well.
Before this change, the root manager package name is only written into
the database after the repackaged APK is installed. In the time between
the repackaged APK being installed and the package name being written
into the database, if some operation calls `get_manager`, the Magisk
daemon will cache this result and ignore the repackaged APK, even if
the package name is set afterwards, because the cache won't be
invalidated. The result is that the repackaged manager APK will not be
recognized as the root manager, breaking the hide manager feature.
This race condition is more likely to happen when Zygisk is enabled,
because `get_manager` is called with a very high frequency in that case.
To fix the issue, we have to set the new package name into the database
BEFORE installing the repackaged APK. We also stop pruning the
database if the repackaged manager is not found, moving this logic into
the Magisk app. By doing so, we can guarantee that the instant after
the repackaged manager APK is installed, the Magisk daemon will
immediately pick it up and treat it as the root manager.
Another small optimization: when the requester is root, simply bypass
the whole database + manager package check. Since the Magisk app hiding
APK installation proces will call `su` several times to run `pm` under
different UIDs, doing this opimization will reduce the amount of
unnecessary database query + filesystem traversals.
Previously, magic mount creates its own mirror devices and mount
mirror mount points. With these mirror mount points, magic mount
can get the original files and directory trees. However, some
devices use overlayfs to modify some mount points, and thus after
magic mount, the overlayed files are missing because the mirror
mount points do not contain the overlayed files. To address this
issue and make magic mount more compatible, this patch refactors
how magic mount works.
The new workflows are as follows:
1. make MAGISKTMP a private mount point so that we can create the
private mount points there
2. for mirror mount points, we instead of creating our own mirror
devices and mount the mirror mount points, we "copy" the
original mount points by recursively mounting /
3. to prevent magic mount affecting the mirror mount points, we
recursively set the mirror mount points private
4. to trace the mount points we created for reverting mounts, we
again make the mirror mount points shared, and by this way we
create a new peer group for each mirror mount points
5. as for tracing the newly created tmpfs mount point by magic
mount, we create a dedicated tmpfs mount point for them, namely
worker mount point, and obviously, it is shared as in a newly
created peer group for tracing
6. when reverting mount points by magic mount, we can then trace
the peer group id and unmount the mount points whose peer group
ids are created by us
The advantages are as follows:
1. it is more compatible, (e.g., with overlayfs, fix#2359)
2. it can mount more partitions for which previous implementation
cannot create mirror mount points (fix#3338)
It turns out that decompressing and recompressing the kernel is enough to break booting on many devices that use MT6763.
Fix#5124, fix#6204, fix#6566
Co-authored-by: LoveSy <shana@zju.edu.cn>
Co-authored-by: 南宫雪珊 <vvb2060@gmail.com>
We resolve available partitions for sepolicy.rules when patching
boot and bind mount the partition by magiskinit.
For older devices, the previous logic won't work because the part name
is never readable.
Co-authored-by: topjohnwu <topjohnwu@gmail.com>
- Fix#6385. (Maybe the reason is, the call to stopForeground() with STOP_FOREGROUND_DETACH ensures the notification is shown so it reposts the notification?)
- Use FOREGROUND_SERVICE_IMMEDIATE on Android 12+ to make sure the downloading notification always shows immediately
- /system/bin/su was being removed in error from the live system so update remove_system_su to be aware of a running A/B OTA and generalize/simplify removal logic with relative paths to correctly run on the updated system slot
In French, install as an adjective depends on the gender of its related noun. For instance, “Magisk installed” is translated “Magisk installé” (masculine form), whereas “Application installed” is translated “Application installée” (feminine form).
By using “Version installée”, “installed” is related to “version” which is feminine. For consistency of the GUI, I’m also changing "home_latest_version" string to ”Dernière version” instead of “Dernière”.
Some Android 11+ devices have the /sbin partition but not accessible by the global shell (`PATH` doesn't contain `/sbin`). Not only custom ROMs but also some stock ROMs have the same behavior so I believe it is something we need to deal with.
Fix#6427, fix#4309, fix#5728, fix#3593
Current readme suggests python 3.6+
However, the file `build.py` on executing `build.py ndk` runs the command `shutil.copytree(src_dir, lib_dir, copy_function=cp, dirs_exist_ok=True)`
This command errors out on python 3.7, because the `dirs_exist_ok` parameter is new in Python 3.8 (https://docs.python.org/3/library/shutil.html#shutil.copytree)
So the README should suggest python 3.8+
If remote process died, `xreadlink` fails and leaves `buf` uninitialized. Then the daemon calls `str_ends`, creates a temp `std::string_view` with the uninitialized buffer and undefined behavior occurs.
`daemon_entry` calls `getprop` which initializes sysprop impl and checks whether we need to load persistent property file. On FDE devices, magiskd starts before /data is actually decrypted, and the check always fails. Thus `persist_getprop("persist.sys.safemode")` will always fail.
With Android 13 GKI kernels, the boot partition has no ramdisk, so
Magisk constructs one from scratch. In this scenario, there's no backup
init binary at /.backup/init. For normal boot, magiskinit will symlink
/init -> /system/bin/init if needed. This commit implements the same
for booting into recovery. Before, magiskinit would just exec itself
over and over again because it couldn't restore the backup init.
Signed-off-by: Andrew Gunnerson <chillermillerlong@hotmail.com>
Meizu devices using 2SI won't switch root to /system and still on rootfs, and /init is the 1st stage's, which cannot handle the 2nd stage. So we have to manually execute /system/bin/init for the 2nd stage.
* Added new strings based on the recent source.
* Fixed some words based on Indonesian National Dictionary (KBBI).
Link: https://kbbi.kemdikbud.go.id
Signed-off-by: fadlyas07 <mhmmdfdlyas@gmail.com>
util_functions.sh overrides `get_flags` function (defined in manager.sh), which sets `RECOVERYMODE` and causes `check_boot_ramdisk` not overriding the incorrect value.
Old Android (pre 8.0) enforces `optimizedDirectory` to have the same uid with the process. If repackaged, root service (uid=0) will crash when trying to load current.apk. So we set `optimizedDirectory` to null to bypass the check.
Many Amlogic devices (e.g. FireTV 2nd gen Cube, Vero 4k+, MI Smart Speaker, etc.) are A-only with androidboot.slot_suffix=normal argument. I think "normal" actually means A-only in this case so just ignore it.
Fix topjohnwu#5806
Configuration changes in FlashFragment may cause the installation process to be triggered twice. The simplest way to reproduce this behavior is to choose a module ZIP file in landscape mode (which is the default on some tablets).
This commit fixes the problem by ensuring `savedInstanceState == null` before starting installation.
Or in languages like Arabic, an "IllegalArgumentException: invalid date string" will be thrown.
Since JcaX509v3CertificateBuilder does not accepts Locales, we must switch to its super class, X509v3CertificateBuilder.
The hijacked load node does not need to be a FIFO. A FIFO is only
required for blocking init's control flow, which is already achieved
by hijacking the enforce node.
Previously `read_string()` calls `std::string.resize()` with a int read from remote process. When I/O error occurs, -1 will be used for resizing the string, `std::bad_alloc` is thrown and since magisk is compiled with `-fno-exceptions`, it will crash the whole daemon process.
May fix topjohnwu#5681
Since Android 13, sepolicy are also loaded from APEX modules. Part
of the change is to run restorecon before SELinux is set to enforce.
In order to support this situation, we also hijack plat_file_contexts
if necessary to properly order our operations.
Original idea credits to @yujincheng08, close#5603
On older Android versions, pre-mounting selinuxfs will lead to errors,
so we have to use a different method to block init's control flow.
Since all devices that falls in this catagory must both:
1. Be Android 8.0 - 9.0
2. Have early mount fstab in its device tree
We can actually use the same FIFO trick, but this time not on selinuxfs,
but on the read-only device tree nodes in sysfs or procfs. By mocking
the fstab/compatible node in the device tree, we can block init when
it attempts to do early mount; at that point, we can then mock selinuxfs
as we normally would, successfully hijack and inject patched sepolicy.
In the current implementation, Magisk will either have to recreate
all early mount implementation (for legacy SAR and rootfs devices) or
delegate early mount to first stage init (for 2SI devices) to access
required partitions for loading sepolicy. It then has to recreate the
split sepolicy loading implementation in-house, apply patches, then
dump the compiled + patched policies into monolithic format somewhere.
Finally, it patches the original init to force it to load the sepolicy
file we just created.
With the increasing complexity involved in early mount and split
sepolicy (there is even APEX module involved in the future!),
it is about time to rethink Magisk's sepolicy strategy as rebuilding
init's functionality is not scalable and easy to maintain.
In this commit, instead of building sepolicy ourselves, we mock
selinuxfs with FIFO files connected to a pre-init daemon, waiting
for the actual init process to directly write the sepolicy file into
MagiskInit. We then patch the file and load it into the kernel. Some
FIFO tricks has to be used to hijack the original init process's
control flow and prevent race conditions, details are directly in the
comments in code.
At the moment, only system-as-root (read-only root) support is added.
Support for legacy rootfs devices will come with a follow up commit.
Design credit to @yujincheng08
Close#5146. Fix#5491, fix#3752
Previously, Magisk changes the mount point from /system to /system_root
by patching fstab to prevent the original init from changing root.
The reason why we want to prevent the original init from switching the
root directory is because it will then be read-only, making patching
and injecting magiskinit into the boot chain difficult.
This commit (ab)uses the fact that the /data folder will never be part
of early mount (because it is handled very late in the boot by vold),
so that we can use it as the mount point of tmpfs to store files.
Some advantages of this method:
- No need to switch root manually
- No need to modify fstab, which significantly improves compatibility
e.g. avoid hacks for weird devices like those using oplus.fstab,
and avoid hacking init to bypass fstab in device trees
- Supports skip_mount.cfg
- Support DSU
The adapter will cache a LayoutInflater which refers the current activity, and the ViewModel object will keep alive until activity finished. After activity recreates (e.g. split-screen), it will use the cached LayoutInflater which refers a destroyed activity and crashes. This also is a memory-leak, according to Google's official document, ViewModel shouldn't refer activity. See https://developer.android.com/topic/libraries/architecture/viewmodel
Fix topjohnwu#5413
All bug reports require you to **USE CANARY BUILDS**. Please include the version name and version code in the bug report.
All bug reports require you to **USE DEBUG BUILDS**. Please include the version name and version code in the bug report.
If you experience a bootloop, attach a `dmesg` (kernel logs) when the device refuse to boot. This may very likely require a custom kernel on some devices as `last_kmsg` or `pstore ramoops` are usually not enabled by default. In addition, please also upload the result of `cat /proc/mounts` when your device is working correctly **WITHOUT ROOT**.
If you experience a bootloop, attach a `dmesg` (kernel logs) when the device refuse to boot. This may very likely require a custom kernel on some devices as `last_kmsg` or `pstore ramoops` are usually not enabled by default. In addition, please also upload the result of `cat /proc/mounts` when your device is working correctly **WITHOUT MAGISK**.
If you experience issues during installation, in recovery, upload the recovery logs, or in Magisk, upload the install logs. Please also upload the `boot.img` or `recovery.img` that you are using for patching.
@@ -31,7 +30,7 @@ Without following the rules above, your issue will be closed without explanation
@@ -50,9 +50,15 @@ For Magisk app crashes, record and upload the logcat when the crash occurs.
- Run `./build.py ndk` to let the script download and install NDK for you
- To start building, run `build.py` to see your options. \
For each action, use `-h` to access help (e.g. `./build.py all -h`)
- To start development, open the project with Android Studio. The IDE can be used for both app (Kotlin/Java) and native (C++/C) sources.
- To start development, open the project with Android Studio. The IDE can be used for both app (Kotlin/Java) and native sources.
- Optionally, set custom configs with `config.prop`. A sample `config.prop.sample` is provided.
- To sign APKs and zips with your own private keys, set signing configs in `config.prop`. For more info, check [Google's Documentation](https://developer.android.com/studio/publish/app-signing.html#generate-key).
## Signing and Distribution
- The certificate of the key used to sign the final Magisk APK product is also directly embedded into some executables. In release builds, Magisk's root daemon will enforce this certificate check and reject and forcefully uninstall any non-matching Magisk apps to protect users from malicious and unverified Magisk APKs.
- To do any development on Magisk itself, switch to an **official debug build and reinstall Magisk** to bypass the signature check.
- To distribute your own Magisk builds signed with your own keys, set your signing configs in `config.prop`.
- Check [Google's Documentation](https://developer.android.com/studio/publish/app-signing.html#generate-key) for more details on generating your own key.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
