In commit 8d4c407, native Magisk always launches an activity for
communicating with Magisk Manager. While this works extremely well,
since it also workaround stupid OEMs that blocks broadcasts, it has a
problem: launching an activity will claim the focus of the device,
which could be super annoying in some circumstances.
This commit adds a new feature to run a broadcast test on boot complete.
If Magisk Manager successfully receives the broadcast, it will toggle
a setting in magiskd so all future su loggings and notifies will always
use broadcasts instead of launching activities.
Fix#1412
For devices come with two /data mount points, magisk will bind the one in tmpfs and failed to load modules since this partition is empty.
Signed-off-by: Shaka Huang <shakalaca@gmail.com>
- this would likely occur on an FDE device with block map OTAs (a la LineageOS) since they do not require/request decrypt
- for reference all other addon.d "v1" cases should work fine:
1) FDE with openrecovery script works fine since it requests decrypt
2) FBE with openrecovery script OR block map work fine since /data/adb remains accessible
We used to construct /sbin tmpfs overlay in early-init stage after
SELinux is properly initialized. However the way it is implemented
(forking daemon from magiskinit with complicated file waiting triggers)
is extremely complicated and error prone.
This commit moves the construction of the sbin overlay to pre-init
stage. The catch is that since SELinux is not present at that point,
proper selabel has to be reconstructed afterwards. Some additional
SEPolicy rules are added to make sure init can access magisk binaries,
and the secontext relabeling task is assigned to the main Magisk daemon.
Some stupid Samsung ROMs will spawn multiple zygote daemons. Since we
switched to ptrace based process monitoring, we have to know all zygote
processes to trace. This is an attempt to fix this issue.
Close#1272
Also updated material library and injected backported styles which were incompatible with the current UI for the most part and as it was over-carded all cards were removed and replaced with flat UI components.
This change is temporary and *will* be redone to the final redesign, in other words this is sufficient for the transition period.
All themers should refrain from trying to theme the app until the redesign is done. It will break your efforts with every other release.
Exported old update card to special xml include where binding takes care of everything that had to be done in code beforehand.
Added several easing functions and enums.
Backported some classes and functions from the old fork
Expect major breakage. Literally nothing works as the functionality needs to be implemented
Converted App class and Main activity to Kotlin. With that refactored fields within App class to allow lazy initialization
BEWARE: at this point the navigation is very much broken, won't let you anywhere beyond home screen
Since Android Q does not allow launching activities from the background
(Services/BroadcastReceivers) and our native process is root, directly
launch activities and use it for communication between native and app.
The target activity is not exported, so non-root apps cannot send an
intent to fool Magisk Manager. This is as safe as the previous
implementation, which uses protected system broadcasts.
This also workaround broadcast limitations in many ROMs (especially
in Chinese ROMs) which blocks the su request dialog if the app is
frozen/force stopped by the system.
Close#1326
We upgrade compileSdkVersion to Q, but keep targetSdkVersion as 28.
The reason is because targeting Q will no longer allow us to execute
native binaries in an app's private data, which Magisk Manager relies
a lot for performing stock boot image patches in non rooted environment.
For more information regarding this issue, check this link:
https://redd.it/b2inbu
Some workarounds has been discovered (https://github.com/termux/proot),
however for the time being there is no point to introduce these huge
hacks just for targeting Q, which we don't benefit anything.
The root nodes are /system and /vendor. Adding new files into these
directories, although works on some devices, mostly bootloops on many
devices out there. So don't allow it, which also makes the whole magic
mounting logic much easier and extensible.
Samsung does not like running cmd before system services are started.
Instead of failing, it will enter an infinite wait on binder.
Move APK installation to boot complete to make sure pm can be run
without blocking process.
Forseeing the future that more and more A only system-as-root devices
would have similar bootloader behavior as the latest Samsung devices
(that is, no ramdisk will be loaded into memory when booting from
the boot partition), a solution/workaround has to be made when Magisk
is installed to the recovery partition, making custom recoveries
unable to co-exist with Magisk.
This commit allows magiskinit to read input device events from the
kernel to detect when a user holds volume key up to toggle whether
system-as-root mode is enabled. When system-as-root mode is disabled,
magiskinit will boot with ramdisk instead of cloning rootfs from system,
which in this case will boot to the recovery.
Some devices (mainly new Samsung phones we're talking here...) using
A only system-as-root refuse to load ramdisk when booted with boot
no matter what we do. With many A only system-as-root devices, even
though their boot image is kernel only, we can still be able to add
a ramdisk section into the image and force the kernel to use it as
rootfs. However the bootloader on devices like the S10 simply does
not load anything within boot image into memory other than the kernel.
This gives as the only option is to install Magisk on the recovery
partition. This commits adds proper support for these kind of scenarios.
It seems that even adding this to the list doesn't 100% works on all
devices out there, and some even reported crashes on several Google
services. Disable it for now and do further investigations in the future.
95%+ of existing modules enables auto mount (obviously).
Switching auto mount to opt-out makes more sense than opt-in as
in previous module format. The file 'auto_mount' will be ignored, and
the file 'skip_mount' will be checked to toggle the mounting behavior.
After scanning through the current Magisk Module Repo modules, no
modules are using custom bind mounting; all modules with auto mount
disabled have empty system folder, which means this change will not
affect any existing module.
It seems both Android cancers, Samsung and Huawei devices, don't
like preloading sepolicy. For a temporary solution now is to limit
the sepolicy loading to Android Q only.
Of course, the cancer of Android, Huawei, has to do some f**king weird
modifications to the Linux kernel. Its kernel only accepts 1 single
policy load in its lifetime, a second load will result in ENOMEM error.
Since Huawei devices always use their own stupid ramdisk setup and not
system-as-root, not loading sepolicy is not a concern (for now).
Android Q init assumes rootfs to always be on EXT4 images, thus
never runs restorecon on the whole root directory. This is an issue
because some folders in rootfs were set with special selabels in
the system partition, but when copying over to initramfs by magiskinit,
these labels will not be preserved.
So the solution is to relabel the files in rootfs with the original
context right? Yes, but rootfs does not allow security xattr to be set
on files before the kernel SELinux initializes with genfs_contexts.
We have to load our sepolicy to the kernel before we clone the root
directory from system partition, which we will also restore the selabel
in the meantime.
Unfortunately this means that for each reboot, the exact same policy
will be loaded to the kernel twice: once in magiskinit so we can label
rootfs properly, and once by the original init, which is part of the
boot procedure. There is no easy way to prevent init from loading
sepolicy, as init will refuse to continue if policy loading has failed.
Allow zygote to execute other programs (such as dex2oat).
This fixes the bug that cause ART framework boot images failed to load
and result to extremely serious performance degradation.
Fix#1195
vector<bool> uses bitsets, so we actually only use 12k memory to
store all 3 possible PID info tables. PID checkup will be now become
O(1) instead of O(logn).
P.S. The reason why we don't use unordered_map is because including it
will result in significant binary size increase (might be due to the
complex hash table STL implementation? I really don't know).
MicroG uses a different package to handle DroidGuard service (SafetyNet),
but still uses the same com.google.android.gms.unstable process name.
Thanks to the changes in 4e53ebfe, we can target both official GMS
and MicroG SafetyNet services at the same time.
No matter if we use the old, buggy, error prone am_proc_start monitoring,
or the new APK inotify method, both methods rely on MagiskHide 'reacting'
fast enough to hijack the process before any detection has been done.
However, this is not reliable and practical. There are apps that utilize
native libraries to start detects and register SIGCONT signal handlers
to mitigate all existing MagiskHide process monitoring mechanism. So
our only solution is to hijack an app BEFORE it is started.
All Android apps' process is forked from zygote, so it is easily the
target to be monitored. All forks will be notified, and subsequent
thread spawning (Android apps are heaviliy multithreaded) from children
are also closely monitored to find the earliest possible point to
identify what the process will eventually be (before am_proc_bound).
ptrace is extremely complicated and very difficult to get right. The
current code is heaviliy tested on a stock Android 9.0 Pixel system,
so in theory it should work fine on most devices, but more tests and
potentially fixes are expected to follow this commit.
Shut down any UID matching process and resume if it turns out not to
be our target. Since we will record every single process we have ever
paused, this means that the same process will not be paused erroneously
for another time.
This is an optimization to hijack the app as soon as possible.
Before switching to the new MagiskHide implementation (APK inotify),
logcat parsing provides us lots of information to target a process.
We were targeting components so that apps with multi-processes
can still be hidden properly.
After switching to the new implementation, our granularity is limited
to the UID of the process. This is especially dangerous since Android
allow apps signed with the same signature to share UIDs, and many system
apps utilize this for elevated permissions for some services.
This commit introduces process name matching. We could not blanketly
target an UID, so the workaround is to verify its process name before
unmounting.
The tricky thing is that any app developer is allowed to name the
process of its component to whatever they want; there is no 'one
rule to catch them all' to target a specific package. As a result,
Magisk Manager is updated to scan through all components of all apps,
and show different processes of the same app, each as a separate
hide target in the list.
The hide target database also has to be updated accordingly.
Each hide target is now a <package name, process name> pair. The
magiskhide CLI and Magisk Manager is updated to support this new
target format.
Most Chinese devices (and supposedly Galaxy S10) running Android Pie
is using system-as-root without A/B partition.
https://source.android.com/devices/bootloader/system-as-root#about-system-as-root
According to the docs above, these devices will have a ramdisk block
with size 0 in their boot images. Since magiskinit can run independently
on system-as-root devices, we simply just create an empty ramdisk with
magiskinit added as init.
Huge thanks to @vvb2060 for the heads up and original PR.
Close#980, close#1102
Fixed wordings to fit Taiwanese accent.
e.g. 日誌 (log) to 記錄檔
Kept proper nouns in English
e.g. Superuser instead of 超級使用者
Removed westernised Chinese as much as possible.
Since we switched to imageless Magisk, module files are directly
stored in /data. However, /data is mounted with nosuid, which also
prevents SELinux typetransition to work (auto transition from one
domain to another when executing files with specific context).
This could cause serious issues when we are replacing system critical
components (e.g. app_process for Xposed), because most of them
are daemons that run in special process domains.
This commit introduced /data mirror. Using similar mirroring technique
we used for system and vendor, we mount another mirror that mounts
/data without nosuid flag. All module files are then mounted from this
mirror mountpoint instead of directly from /data.
Close#1080
Reinstalling system apps as data creates tons of issues.
Calling pm path <pkg> is extremely expensive and doesn't work in post-fs-data.
Parse through packages.xml to get APK path and UID at the same time.
As a bonus, we don't need to traverse /data/app for packages anymore.
Since we are parsing through /data/app/ to find target APKs for
monitoring, system apps will not be covered in this case.
Automatically reinstall system apps as if they received an update
and refresh the monitor target after it's done.
As a bonus, use RAII idioms for locking pthread_mutex_t.
- Fail fast on unsupported systems
- Show proper fail message on unsupported systems
- inotify_fd shall be swapped out before closing to prevent
the proc_monitor thread to read from incomplete inotify fd
- Directly get UID instead of traversing /data/data everytime
- Use /data/user_de/0 instead of /data/data on Android 7.0+
- Update hide_uid set incrementally when adding/initializing targets
- Guard hide_uid set with the same lock as hide_list vector
- Do not add GMS package into database; only add to in-memory list
With the new detection method, it is impossible to check for components.
Remove additional checks for components and simply hardcode string to
proc_monitor.cpp and query cmdline to see if it's GMS unstable.
This addresses wasted resources on applying custom namespace
on all GMS processes.
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
Previous MagiskHide detects new app launches via listening through logcat
and filtering launch info messages.
This is extremely inefficient and prone to cause multiple issues both
theoratically and practically.
Rework this by using inotify to detect open() syscalls to target APKs.
This also solves issues related to Zygote-forked caching mechanisms such as
OnePlus OxygenOS' embryo.
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
Android 4.1 init miss several significant features Magisk reply on,
so the final decision is to forget about it in the future.
Pull minSdkVersion of Magisk Manager back to 17 and remove some
unnecessary adjustments done for SDK 16
Mounting ext4 images causes tons of issues, such as unmountable with broken F2FS drivers.
Resizing is also very complicated and does not work properly on all devices.
Each step in either measuring free space, resizing, and shrinking the image is a
point of failure, and either step's failure could cause the module system completely broken.
The new method is to directly store modules into /data/adb/modules, and for module installation
on boot /data/adb/modules_update. Several compatibility layers has been done: the new path is
bind mounted to the old path (/sbin/.magisk/img), and the helper functions in util_functions.sh
will now transparently make existing modules install to the new location without any changes.
MagiskHide is also updated to unmount module files stored in this new location.
I changed some words for their synonyms. In order to verify how it behaves on screens less than 5 inches.
(Some changes were made, since several devices I have, some words do not appear yet having space)
Magisk Manager sometimes updates the code for patching the APK due to several changes.
When an old manager tries to patch an updated APK using its internal methods, it is
sometimes incomplete, or simply won't work at all.
This commit exposes an API that can be dynamically loaded from an old app to invoke the
updated patchAPK method from the downloaded new APK.
Magisk is a suite of open source tools for customizing Android, supporting devices higher than Android 5.0 (API 21). It covers the fundamental parts for Android customization: root, boot scripts, SELinux patches, AVB2.0 / dm-verity / forceencrypt removals etc.
Magisk is a suite of open source tools for customizing Android, supporting devices higher than Android 4.2 (API 17). It covers the fundamental parts for Android customization: root, boot scripts, SELinux patches, AVB2.0 / dm-verity / forceencrypt removals etc.
Furthermore, Magisk provides a **Systemless Interface** to alter the system (or vendor) arbitrarily while the actual partitions stay completely intact. With its systemless nature along with several other hacks, Magisk can hide modifications from nearly any system integrity verifications used in banking apps, corporation monitoring apps, game cheat detections, and most importantly [Google's SafetyNet API](https://developer.android.com/training/safetynet/index.html).
## Bug Reports
**Make sure to install the latest [Canary Build](https://forum.xda-developers.com/apps/magisk/dev-magisk-canary-channel-bleeding-edge-t3839337) before reporting any bugs!** **DO NOT** report bugs that is already fixed upstream. Follow the instructions in the [Canary Channel XDA Thread](https://forum.xda-developers.com/apps/magisk/dev-magisk-canary-channel-bleeding-edge-t3839337), and report a bug either by opening an issue on GitHub or directly in the thread.
## Building Environment Requirements
1. Python 3.5+: run `build.py` script
2. Java Development Kit (JDK) 8: Compile Magisk Manager and sign zips
3. Latest Android SDK: set `ANDROID_HOME` environment variable to the path to Android SDK
4. Android NDK: Install NDK along with SDK (`$ANDROID_HOME/ndk-bundle`), or optionally specify a custom path `ANDROID_NDK_HOME`
5. (Windows Only) Python package Colorama: Install with `pip install colorama`, used for ANSI color codes
- Python 3: run `build.py` script
- Java Development Kit (JDK) 8: Compile Magisk Manager and sign zips
- Latest Android SDK: set `ANDROID_HOME` environment variable to the path to Android SDK
- Android NDK: Install NDK along with SDK (`$ANDROID_HOME/ndk-bundle`), or optionally specify a custom path `ANDROID_NDK_HOME`
- (Windows Only) Python package Colorama: Install with `pip install colorama`, used for ANSI color codes
## Building Notes and Instructions
1. Clone sources with submodules: `git clone --recurse-submodules https://github.com/topjohnwu/Magisk.git`
2. Building is supported on macOS, Linux, and Windows. Official releases are built and tested with [FrankeNDK](https://github.com/topjohnwu/FrankeNDK); point `ANDROID_NDK_HOME` to FrankeNDK if you want to use it for compiling.
3. Set configurations in `config.prop`. A sample file `config.prop.sample` is provided as an example.
4. Run `build.py` with argument `-h` to see the built-in help message. The `-h` option also works for each supported actions, e.g. `./build.py binary -h`
5. By default, `build.py` build binaries and Magisk Manager in debug mode. If you want to build Magisk Manager in release mode (via the `-r, --release` flag), you need a Java Keystore file `release-key.jks` (only `JKS` format is supported) to sign APKs and zips. For more information, check out [Google's Official Documentation](https://developer.android.com/studio/publish/app-signing.html#signing-manually).
- Clone sources with submodules: `git clone --recurse-submodules https://github.com/topjohnwu/Magisk.git`
- Building is supported on macOS, Linux, and Windows. Official releases are built and tested with [FrankeNDK](https://github.com/topjohnwu/FrankeNDK); point `ANDROID_NDK_HOME` to FrankeNDK if you want to use it for compiling.
- Set configurations in `config.prop`. A sample file `config.prop.sample` is provided as an example.
- Run `build.py` with argument `-h` to see the built-in help message. The `-h` option also works for each supported actions, e.g. `./build.py binary -h`
- By default, `build.py` build binaries and Magisk Manager in debug mode. If you want to build Magisk Manager in release mode (via the `-r, --release` flag), you need a Java Keystore file `release-key.jks` (only `JKS` format is supported) to sign APKs and zips. For more information, check out [Google's Official Documentation](https://developer.android.com/studio/publish/app-signing.html#signing-manually).
## Translations
Default string resources for Magisk Manager are scattered throughout
- `app/src/main/res/values/strings.xml`
- `stub/src/main/res/values/strings.xml`
- `shared/src/main/res/values/strings.xml`
Translate each and place them in the respective locations (`<module>/src/main/res/values-<lang>/strings.xml`).
## Signature Verification
Official release zips and APKs are signed with my personal private key. You can verify the key certificate to make sure the binaries you downloaded are not manipulated in anyway.
``` bash
# Use the keytool command from JDK to print certificates
keytool -printcert -jarfile <APK or Magisk zip>
# The output should contain the following signature
Owner: CN=John Wu, L=Taipei, C=TW
Issuer: CN=John Wu, L=Taipei, C=TW
Serial number: 50514879
Valid from: Sun Aug 14 13:23:44 EDT 2016 until: Tue Jul 21 13:23:44 EDT 2116
This repo is no longer an independent component. It is merged into the [Magisk Project](https://github.com/topjohnwu/Magisk).
# Translations
The default (English) strings are mainly in `src/full/res/values/strings.xml`; some are scattered in `src/main/res/values/strings.xml` and `src/stub/res/values/strings.xml`.
Translations are highly appreciated via pull requests here on Github.
Place translated XMLs in the corresponding locale folder.
public abstract S onCreateSectionViewHolder(ViewGroup parent);
public abstract C onCreateItemViewHolder(ViewGroup parent, int viewType);
public abstract void onBindSectionViewHolder(S holder, int section);
public abstract void onBindItemViewHolder(C holder, int section, int position);
}
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.
