TheArchive/Magisk
1
0
Fork 0
mirror of https://github.com/topjohnwu/Magisk.git synced 2024-12-18 22:17:40 +00:00
Code Issues Packages Projects Releases Wiki Activity
Magisk/native/jni/magiskhide/magiskhide.h

59 lines
1.2 KiB
C
Raw Normal View History

Make zygote notifier more reliable
2019-03-06 18:22:04 -05:00
#pragma once
Separate all binaries and makefile
2016-12-31 02:44:24 +08:00
More MagiskHide optimizations - Use a general procfs traversal function with callbacks - Much better functions for killing processes
2019-02-13 20:16:26 -05:00
#include <sys/types.h>
#include <sys/stat.h>
Always detach all child threads before leaving
2019-03-12 16:48:01 -04:00
#include <pthread.h>
More MagiskHide optimizations - Use a general procfs traversal function with callbacks - Much better functions for killing processes
2019-02-13 20:16:26 -05:00
#include <unistd.h>
Always detach all child threads before leaving
2019-03-12 16:48:01 -04:00
#include <dirent.h>
Migrate to STL
2019-01-19 23:59:37 -05:00
#include <string>
More MagiskHide optimizations - Use a general procfs traversal function with callbacks - Much better functions for killing processes
2019-02-13 20:16:26 -05:00
#include <functional>
Application Component Granularity MagiskHide 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.
2019-03-01 17:08:08 -05:00
#include <map>
Use both package name and process name as key Different packages could potentially use the same process name, and they shouldn't conflict with each other.
2019-03-06 05:40:52 -05:00
#include <set>
Separate magiskhide logic from main daemon
2018-11-01 14:08:33 -04:00
Reboot to recovery when running as recovery
2019-03-30 06:49:29 -04:00
#include <daemon.h>
Add magiskhide list management
2017-04-20 22:45:56 +08:00
Switch to Zygote ptrace-ing 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.
2019-03-05 03:22:20 -05:00
#define SIGTERMTHRD SIGUSR1
Prevent race condition on /magisk symlink
2017-11-09 03:05:01 +08:00
Hardcode GMS unstable to MagiskHide 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>
2019-02-13 09:04:27 +09:00
#define SAFETYNET_COMPONENT "com.google.android.gms/.droidguard.DroidGuardService"
#define SAFETYNET_PROCESS "com.google.android.gms.unstable"
#define SAFETYNET_PKG "com.google.android.gms"
Add MicroG DroidGuardHelper as target 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.
2019-03-06 05:43:52 -05:00
#define MICROG_SAFETYNET "org.microg.gms.droidguard"
Hardcode GMS unstable to MagiskHide 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>
2019-02-13 09:04:27 +09:00
Switch to Zygote ptrace-ing 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.
2019-03-05 03:22:20 -05:00
// CLI entries
More MagiskHide optimizations - Use a general procfs traversal function with callbacks - Much better functions for killing processes
2019-02-13 20:16:26 -05:00
void launch_magiskhide(int client);
Separate magiskhide logic from main daemon
2018-11-01 14:08:33 -04:00
int stop_magiskhide();
int add_list(int client);
int rm_list(int client);
void ls_list(int client);
Switch to Zygote ptrace-ing 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.
2019-03-05 03:22:20 -05:00
// Process monitoring
Isolate root daemon from requests
2017-04-22 00:54:08 +08:00
void proc_monitor();
Monitor app_process 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
2019-04-22 16:36:23 -04:00
void update_uid_map();
Separate all binaries and makefile
2016-12-31 02:44:24 +08:00
MagiskHide refactor
2017-07-10 23:39:33 +08:00
// Utility functions
Auto start magiskhide
2017-04-17 16:36:49 +08:00
void manage_selinux();
Update to Google CTS (2017.7.17)
2017-07-18 12:26:23 +08:00
void clean_magisk_props();
More MagiskHide optimizations - Use a general procfs traversal function with callbacks - Much better functions for killing processes
2019-02-13 20:16:26 -05:00
void crawl_procfs(const std::function<bool (int)> &fn);
Always detach all child threads before leaving
2019-03-12 16:48:01 -04:00
void crawl_procfs(DIR *dir, const std::function<bool (int)> &fn);
More MagiskHide optimizations - Use a general procfs traversal function with callbacks - Much better functions for killing processes
2019-02-13 20:16:26 -05:00
Add CLI to detect MagiskHide status
2018-11-16 00:37:41 -05:00
extern bool hide_enabled;
Switch to Zygote ptrace-ing 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.
2019-03-05 03:22:20 -05:00
extern pthread_mutex_t monitor_lock;
Use both package name and process name as key Different packages could potentially use the same process name, and they shouldn't conflict with each other.
2019-03-06 05:40:52 -05:00
extern std::set<std::pair<std::string, std::string>> hide_set;
Separate all binaries and makefile
2016-12-31 02:44:24 +08:00
Separate magiskhide logic from main daemon
2018-11-01 14:08:33 -04:00
enum {
LAUNCH_MAGISKHIDE,
STOP_MAGISKHIDE,
ADD_HIDELIST,
RM_HIDELIST,
Add CLI to detect MagiskHide status
2018-11-16 00:37:41 -05:00
LS_HIDELIST,
HIDE_STATUS,
Separate magiskhide logic from main daemon
2018-11-01 14:08:33 -04:00
};
enum {
Completely rework MagiskHide 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>
2019-02-12 23:12:03 +09:00
HIDE_IS_ENABLED = DAEMON_LAST,
Separate magiskhide logic from main daemon
2018-11-01 14:08:33 -04:00
HIDE_NOT_ENABLED,
HIDE_ITEM_EXIST,
Minor MagiskHide adjustments - 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
2019-02-14 04:08:05 -05:00
HIDE_ITEM_NOT_EXIST,
HIDE_NO_NS
Separate magiskhide logic from main daemon
2018-11-01 14:08:33 -04:00
};
Reference in New Issue Copy Permalink