2018-09-16 04:16:18 -04:00
|
|
|
#include <sys/types.h>
|
|
|
|
#include <sys/wait.h>
|
|
|
|
#include <unistd.h>
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <fcntl.h>
|
|
|
|
#include <stdio.h>
|
|
|
|
|
2019-02-10 03:57:51 -05:00
|
|
|
#include <daemon.h>
|
|
|
|
#include <utils.h>
|
Introduce component agnostic communication
Usually, the communication between native and the app is done via
sending intents to either broadcast or activity. These communication
channels are for launching root requests dialogs, sending root request
notifications (the toast you see when an app gained root access), and
root request logging.
Sending intents by am (activity manager) usually requires specifying
the component name in the format of <pkg>/<class name>. This means parts
of Magisk Manager cannot be randomized or else the native daemon is
unable to know where to send data to the app.
On modern Android (not sure which API is it introduced), it is possible
to send broadcasts to a package, not a specific component. Which
component will receive the intent depends on the intent filter declared
in AndroidManifest.xml. Since we already have a mechanism in native code
to keep track of the package name of Magisk Manager, this makes it
perfect to pass intents to Magisk Manager that have components being
randomly obfuscated (stub APKs).
There are a few caveats though. Although this broadcasting method works
perfectly fine on AOSP and most systems, there are OEMs out there
shipping ROMs blocking broadcasts unexpectedly. In order to make sure
Magisk works in all kinds of scenarios, we run actual tests every boot
to determine which communication method should be used.
We have 3 methods in total, ordered in preference:
1. Broadcasting to a package
2. Broadcasting to a specific component
3. Starting a specific activity component
Method 3 will always work on any device, but the downside is anytime
a communication happens, Magisk Manager will steal foreground focus
regardless of whether UI is drawn. Method 1 is the only way to support
obfuscated stub APKs. The communication test will test method 1 and 2,
and if Magisk Manager is able to receive the messages, it will then
update the daemon configuration to use whichever is preferable. If none
of the broadcasts can be delivered, then the fallback method 3 will be
used.
2019-10-21 13:59:04 -04:00
|
|
|
#include <logging.h>
|
2019-02-10 03:57:51 -05:00
|
|
|
|
2018-09-16 04:16:18 -04:00
|
|
|
#include "su.h"
|
|
|
|
|
2019-07-07 00:31:49 -07:00
|
|
|
using namespace std;
|
|
|
|
|
Introduce component agnostic communication
Usually, the communication between native and the app is done via
sending intents to either broadcast or activity. These communication
channels are for launching root requests dialogs, sending root request
notifications (the toast you see when an app gained root access), and
root request logging.
Sending intents by am (activity manager) usually requires specifying
the component name in the format of <pkg>/<class name>. This means parts
of Magisk Manager cannot be randomized or else the native daemon is
unable to know where to send data to the app.
On modern Android (not sure which API is it introduced), it is possible
to send broadcasts to a package, not a specific component. Which
component will receive the intent depends on the intent filter declared
in AndroidManifest.xml. Since we already have a mechanism in native code
to keep track of the package name of Magisk Manager, this makes it
perfect to pass intents to Magisk Manager that have components being
randomly obfuscated (stub APKs).
There are a few caveats though. Although this broadcasting method works
perfectly fine on AOSP and most systems, there are OEMs out there
shipping ROMs blocking broadcasts unexpectedly. In order to make sure
Magisk works in all kinds of scenarios, we run actual tests every boot
to determine which communication method should be used.
We have 3 methods in total, ordered in preference:
1. Broadcasting to a package
2. Broadcasting to a specific component
3. Starting a specific activity component
Method 3 will always work on any device, but the downside is anytime
a communication happens, Magisk Manager will steal foreground focus
regardless of whether UI is drawn. Method 1 is the only way to support
obfuscated stub APKs. The communication test will test method 1 and 2,
and if Magisk Manager is able to receive the messages, it will then
update the daemon configuration to use whichever is preferable. If none
of the broadcasts can be delivered, then the fallback method 3 will be
used.
2019-10-21 13:59:04 -04:00
|
|
|
enum connect_mode {
|
|
|
|
UNINITIALIZED = 0,
|
|
|
|
MODE_ACTIVITY,
|
|
|
|
MODE_BROADCAST_COMPONENT,
|
|
|
|
MODE_BROADCAST_PACKAGE
|
|
|
|
};
|
|
|
|
|
|
|
|
static connect_mode current_mode = UNINITIALIZED;
|
2019-05-13 02:01:10 -07:00
|
|
|
|
2019-04-10 23:35:31 -04:00
|
|
|
#define START_ACTIVITY \
|
2019-01-26 14:53:49 -05:00
|
|
|
"/system/bin/app_process", "/system/bin", "com.android.commands.am.Am", \
|
2019-04-10 23:35:31 -04:00
|
|
|
"start", "-n", nullptr, "--user", nullptr, "-f", "0x18000020", "-a"
|
|
|
|
|
|
|
|
// 0x18000020 = FLAG_ACTIVITY_NEW_TASK|FLAG_ACTIVITY_MULTIPLE_TASK|FLAG_INCLUDE_STOPPED_PACKAGES
|
2018-09-16 04:16:18 -04:00
|
|
|
|
2019-05-13 02:01:10 -07:00
|
|
|
#define START_BROADCAST \
|
|
|
|
"/system/bin/app_process", "/system/bin", "com.android.commands.am.Am", \
|
|
|
|
"broadcast", "-n", nullptr, "--user", nullptr, "-f", "0x00000020", \
|
|
|
|
"-a", "android.intent.action.REBOOT", "--es", "action"
|
|
|
|
|
Introduce component agnostic communication
Usually, the communication between native and the app is done via
sending intents to either broadcast or activity. These communication
channels are for launching root requests dialogs, sending root request
notifications (the toast you see when an app gained root access), and
root request logging.
Sending intents by am (activity manager) usually requires specifying
the component name in the format of <pkg>/<class name>. This means parts
of Magisk Manager cannot be randomized or else the native daemon is
unable to know where to send data to the app.
On modern Android (not sure which API is it introduced), it is possible
to send broadcasts to a package, not a specific component. Which
component will receive the intent depends on the intent filter declared
in AndroidManifest.xml. Since we already have a mechanism in native code
to keep track of the package name of Magisk Manager, this makes it
perfect to pass intents to Magisk Manager that have components being
randomly obfuscated (stub APKs).
There are a few caveats though. Although this broadcasting method works
perfectly fine on AOSP and most systems, there are OEMs out there
shipping ROMs blocking broadcasts unexpectedly. In order to make sure
Magisk works in all kinds of scenarios, we run actual tests every boot
to determine which communication method should be used.
We have 3 methods in total, ordered in preference:
1. Broadcasting to a package
2. Broadcasting to a specific component
3. Starting a specific activity component
Method 3 will always work on any device, but the downside is anytime
a communication happens, Magisk Manager will steal foreground focus
regardless of whether UI is drawn. Method 1 is the only way to support
obfuscated stub APKs. The communication test will test method 1 and 2,
and if Magisk Manager is able to receive the messages, it will then
update the daemon configuration to use whichever is preferable. If none
of the broadcasts can be delivered, then the fallback method 3 will be
used.
2019-10-21 13:59:04 -04:00
|
|
|
#define START_BROADCAST_PKG \
|
|
|
|
"/system/bin/app_process", "/system/bin", "com.android.commands.am.Am", \
|
|
|
|
"broadcast", "-p", nullptr, "--user", nullptr, "-f", "0x00000020", \
|
|
|
|
"-a", "android.intent.action.REBOOT", "--es", "action"
|
|
|
|
|
2019-05-13 02:01:10 -07:00
|
|
|
// 0x00000020 = FLAG_INCLUDE_STOPPED_PACKAGES
|
|
|
|
|
Introduce component agnostic communication
Usually, the communication between native and the app is done via
sending intents to either broadcast or activity. These communication
channels are for launching root requests dialogs, sending root request
notifications (the toast you see when an app gained root access), and
root request logging.
Sending intents by am (activity manager) usually requires specifying
the component name in the format of <pkg>/<class name>. This means parts
of Magisk Manager cannot be randomized or else the native daemon is
unable to know where to send data to the app.
On modern Android (not sure which API is it introduced), it is possible
to send broadcasts to a package, not a specific component. Which
component will receive the intent depends on the intent filter declared
in AndroidManifest.xml. Since we already have a mechanism in native code
to keep track of the package name of Magisk Manager, this makes it
perfect to pass intents to Magisk Manager that have components being
randomly obfuscated (stub APKs).
There are a few caveats though. Although this broadcasting method works
perfectly fine on AOSP and most systems, there are OEMs out there
shipping ROMs blocking broadcasts unexpectedly. In order to make sure
Magisk works in all kinds of scenarios, we run actual tests every boot
to determine which communication method should be used.
We have 3 methods in total, ordered in preference:
1. Broadcasting to a package
2. Broadcasting to a specific component
3. Starting a specific activity component
Method 3 will always work on any device, but the downside is anytime
a communication happens, Magisk Manager will steal foreground focus
regardless of whether UI is drawn. Method 1 is the only way to support
obfuscated stub APKs. The communication test will test method 1 and 2,
and if Magisk Manager is able to receive the messages, it will then
update the daemon configuration to use whichever is preferable. If none
of the broadcasts can be delivered, then the fallback method 3 will be
used.
2019-10-21 13:59:04 -04:00
|
|
|
#define am_app_info(info, ...) \
|
|
|
|
if (current_mode == MODE_BROADCAST_PACKAGE) { \
|
|
|
|
const char *cmd[] = { START_BROADCAST_PKG, __VA_ARGS__, nullptr }; \
|
|
|
|
exec_am_cmd(cmd, info); \
|
|
|
|
} else if (current_mode == MODE_BROADCAST_COMPONENT) { \
|
|
|
|
const char *cmd[] = { START_BROADCAST, __VA_ARGS__, nullptr }; \
|
|
|
|
exec_am_cmd(cmd, info); \
|
|
|
|
} else { \
|
|
|
|
const char *cmd[] = { START_ACTIVITY, __VA_ARGS__, nullptr }; \
|
|
|
|
exec_am_cmd(cmd, info); \
|
|
|
|
}
|
|
|
|
|
|
|
|
#define am_app(...) am_app_info(ctx.info.get(), __VA_ARGS__)
|
|
|
|
|
|
|
|
static const char *get_command(const su_request *to) {
|
2018-10-04 04:59:51 -04:00
|
|
|
if (to->command[0])
|
2018-09-16 04:16:18 -04:00
|
|
|
return to->command;
|
2018-10-04 04:59:51 -04:00
|
|
|
if (to->shell[0])
|
2018-09-16 04:16:18 -04:00
|
|
|
return to->shell;
|
|
|
|
return DEFAULT_SHELL;
|
|
|
|
}
|
|
|
|
|
Introduce component agnostic communication
Usually, the communication between native and the app is done via
sending intents to either broadcast or activity. These communication
channels are for launching root requests dialogs, sending root request
notifications (the toast you see when an app gained root access), and
root request logging.
Sending intents by am (activity manager) usually requires specifying
the component name in the format of <pkg>/<class name>. This means parts
of Magisk Manager cannot be randomized or else the native daemon is
unable to know where to send data to the app.
On modern Android (not sure which API is it introduced), it is possible
to send broadcasts to a package, not a specific component. Which
component will receive the intent depends on the intent filter declared
in AndroidManifest.xml. Since we already have a mechanism in native code
to keep track of the package name of Magisk Manager, this makes it
perfect to pass intents to Magisk Manager that have components being
randomly obfuscated (stub APKs).
There are a few caveats though. Although this broadcasting method works
perfectly fine on AOSP and most systems, there are OEMs out there
shipping ROMs blocking broadcasts unexpectedly. In order to make sure
Magisk works in all kinds of scenarios, we run actual tests every boot
to determine which communication method should be used.
We have 3 methods in total, ordered in preference:
1. Broadcasting to a package
2. Broadcasting to a specific component
3. Starting a specific activity component
Method 3 will always work on any device, but the downside is anytime
a communication happens, Magisk Manager will steal foreground focus
regardless of whether UI is drawn. Method 1 is the only way to support
obfuscated stub APKs. The communication test will test method 1 and 2,
and if Magisk Manager is able to receive the messages, it will then
update the daemon configuration to use whichever is preferable. If none
of the broadcasts can be delivered, then the fallback method 3 will be
used.
2019-10-21 13:59:04 -04:00
|
|
|
static void get_user(char *user, const su_info *info) {
|
2019-04-10 23:35:31 -04:00
|
|
|
sprintf(user, "%d",
|
|
|
|
info->cfg[SU_MULTIUSER_MODE] == MULTIUSER_MODE_USER
|
|
|
|
? info->uid / 100000
|
|
|
|
: 0);
|
|
|
|
}
|
|
|
|
|
Introduce component agnostic communication
Usually, the communication between native and the app is done via
sending intents to either broadcast or activity. These communication
channels are for launching root requests dialogs, sending root request
notifications (the toast you see when an app gained root access), and
root request logging.
Sending intents by am (activity manager) usually requires specifying
the component name in the format of <pkg>/<class name>. This means parts
of Magisk Manager cannot be randomized or else the native daemon is
unable to know where to send data to the app.
On modern Android (not sure which API is it introduced), it is possible
to send broadcasts to a package, not a specific component. Which
component will receive the intent depends on the intent filter declared
in AndroidManifest.xml. Since we already have a mechanism in native code
to keep track of the package name of Magisk Manager, this makes it
perfect to pass intents to Magisk Manager that have components being
randomly obfuscated (stub APKs).
There are a few caveats though. Although this broadcasting method works
perfectly fine on AOSP and most systems, there are OEMs out there
shipping ROMs blocking broadcasts unexpectedly. In order to make sure
Magisk works in all kinds of scenarios, we run actual tests every boot
to determine which communication method should be used.
We have 3 methods in total, ordered in preference:
1. Broadcasting to a package
2. Broadcasting to a specific component
3. Starting a specific activity component
Method 3 will always work on any device, but the downside is anytime
a communication happens, Magisk Manager will steal foreground focus
regardless of whether UI is drawn. Method 1 is the only way to support
obfuscated stub APKs. The communication test will test method 1 and 2,
and if Magisk Manager is able to receive the messages, it will then
update the daemon configuration to use whichever is preferable. If none
of the broadcasts can be delivered, then the fallback method 3 will be
used.
2019-10-21 13:59:04 -04:00
|
|
|
static void get_uid(char *uid, const su_info *info) {
|
2019-04-10 23:35:31 -04:00
|
|
|
sprintf(uid, "%d",
|
|
|
|
info->cfg[SU_MULTIUSER_MODE] == MULTIUSER_MODE_OWNER_MANAGED
|
|
|
|
? info->uid % 100000
|
|
|
|
: info->uid);
|
|
|
|
}
|
|
|
|
|
2019-07-07 00:31:49 -07:00
|
|
|
static void exec_am_cmd(const char **args, const su_info *info) {
|
Introduce component agnostic communication
Usually, the communication between native and the app is done via
sending intents to either broadcast or activity. These communication
channels are for launching root requests dialogs, sending root request
notifications (the toast you see when an app gained root access), and
root request logging.
Sending intents by am (activity manager) usually requires specifying
the component name in the format of <pkg>/<class name>. This means parts
of Magisk Manager cannot be randomized or else the native daemon is
unable to know where to send data to the app.
On modern Android (not sure which API is it introduced), it is possible
to send broadcasts to a package, not a specific component. Which
component will receive the intent depends on the intent filter declared
in AndroidManifest.xml. Since we already have a mechanism in native code
to keep track of the package name of Magisk Manager, this makes it
perfect to pass intents to Magisk Manager that have components being
randomly obfuscated (stub APKs).
There are a few caveats though. Although this broadcasting method works
perfectly fine on AOSP and most systems, there are OEMs out there
shipping ROMs blocking broadcasts unexpectedly. In order to make sure
Magisk works in all kinds of scenarios, we run actual tests every boot
to determine which communication method should be used.
We have 3 methods in total, ordered in preference:
1. Broadcasting to a package
2. Broadcasting to a specific component
3. Starting a specific activity component
Method 3 will always work on any device, but the downside is anytime
a communication happens, Magisk Manager will steal foreground focus
regardless of whether UI is drawn. Method 1 is the only way to support
obfuscated stub APKs. The communication test will test method 1 and 2,
and if Magisk Manager is able to receive the messages, it will then
update the daemon configuration to use whichever is preferable. If none
of the broadcasts can be delivered, then the fallback method 3 will be
used.
2019-10-21 13:59:04 -04:00
|
|
|
char target[128];
|
|
|
|
if (args[3][0] == 'b') {
|
|
|
|
// Broadcast
|
|
|
|
if (args[4][1] == 'p') {
|
|
|
|
// Broadcast to package (receiver can be obfuscated)
|
|
|
|
strcpy(target, info->str[SU_MANAGER].data());
|
|
|
|
} else {
|
|
|
|
// a.h is the broadcast receiver
|
|
|
|
sprintf(target, "%s/a.h", info->str[SU_MANAGER].data());
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
// a.m is the activity
|
|
|
|
sprintf(target, "%s/a.m", info->str[SU_MANAGER].data());
|
|
|
|
}
|
2019-04-10 23:35:31 -04:00
|
|
|
char user[8];
|
|
|
|
get_user(user, info);
|
|
|
|
|
Introduce component agnostic communication
Usually, the communication between native and the app is done via
sending intents to either broadcast or activity. These communication
channels are for launching root requests dialogs, sending root request
notifications (the toast you see when an app gained root access), and
root request logging.
Sending intents by am (activity manager) usually requires specifying
the component name in the format of <pkg>/<class name>. This means parts
of Magisk Manager cannot be randomized or else the native daemon is
unable to know where to send data to the app.
On modern Android (not sure which API is it introduced), it is possible
to send broadcasts to a package, not a specific component. Which
component will receive the intent depends on the intent filter declared
in AndroidManifest.xml. Since we already have a mechanism in native code
to keep track of the package name of Magisk Manager, this makes it
perfect to pass intents to Magisk Manager that have components being
randomly obfuscated (stub APKs).
There are a few caveats though. Although this broadcasting method works
perfectly fine on AOSP and most systems, there are OEMs out there
shipping ROMs blocking broadcasts unexpectedly. In order to make sure
Magisk works in all kinds of scenarios, we run actual tests every boot
to determine which communication method should be used.
We have 3 methods in total, ordered in preference:
1. Broadcasting to a package
2. Broadcasting to a specific component
3. Starting a specific activity component
Method 3 will always work on any device, but the downside is anytime
a communication happens, Magisk Manager will steal foreground focus
regardless of whether UI is drawn. Method 1 is the only way to support
obfuscated stub APKs. The communication test will test method 1 and 2,
and if Magisk Manager is able to receive the messages, it will then
update the daemon configuration to use whichever is preferable. If none
of the broadcasts can be delivered, then the fallback method 3 will be
used.
2019-10-21 13:59:04 -04:00
|
|
|
// Fill in non static arguments
|
|
|
|
args[5] = target;
|
2019-04-10 23:35:31 -04:00
|
|
|
args[7] = user;
|
|
|
|
|
2019-01-26 14:53:49 -05:00
|
|
|
exec_t exec {
|
|
|
|
.pre_exec = []() -> void {
|
|
|
|
int null = xopen("/dev/null", O_WRONLY | O_CLOEXEC);
|
|
|
|
dup2(null, STDOUT_FILENO);
|
|
|
|
dup2(null, STDERR_FILENO);
|
|
|
|
setenv("CLASSPATH", "/system/framework/am.jar", 1);
|
|
|
|
},
|
|
|
|
.fork = fork_dont_care,
|
|
|
|
.argv = args
|
|
|
|
};
|
|
|
|
exec_command(exec);
|
2018-09-16 04:16:18 -04:00
|
|
|
}
|
|
|
|
|
2019-05-13 02:01:10 -07:00
|
|
|
#define LOG_BODY \
|
|
|
|
"log", \
|
|
|
|
"--ei", "from.uid", fromUid, \
|
|
|
|
"--ei", "to.uid", toUid, \
|
|
|
|
"--ei", "pid", pid, \
|
|
|
|
"--ei", "policy", policy, \
|
2019-07-07 00:31:49 -07:00
|
|
|
"--es", "command", get_command(&ctx.req), \
|
Introduce component agnostic communication
Usually, the communication between native and the app is done via
sending intents to either broadcast or activity. These communication
channels are for launching root requests dialogs, sending root request
notifications (the toast you see when an app gained root access), and
root request logging.
Sending intents by am (activity manager) usually requires specifying
the component name in the format of <pkg>/<class name>. This means parts
of Magisk Manager cannot be randomized or else the native daemon is
unable to know where to send data to the app.
On modern Android (not sure which API is it introduced), it is possible
to send broadcasts to a package, not a specific component. Which
component will receive the intent depends on the intent filter declared
in AndroidManifest.xml. Since we already have a mechanism in native code
to keep track of the package name of Magisk Manager, this makes it
perfect to pass intents to Magisk Manager that have components being
randomly obfuscated (stub APKs).
There are a few caveats though. Although this broadcasting method works
perfectly fine on AOSP and most systems, there are OEMs out there
shipping ROMs blocking broadcasts unexpectedly. In order to make sure
Magisk works in all kinds of scenarios, we run actual tests every boot
to determine which communication method should be used.
We have 3 methods in total, ordered in preference:
1. Broadcasting to a package
2. Broadcasting to a specific component
3. Starting a specific activity component
Method 3 will always work on any device, but the downside is anytime
a communication happens, Magisk Manager will steal foreground focus
regardless of whether UI is drawn. Method 1 is the only way to support
obfuscated stub APKs. The communication test will test method 1 and 2,
and if Magisk Manager is able to receive the messages, it will then
update the daemon configuration to use whichever is preferable. If none
of the broadcasts can be delivered, then the fallback method 3 will be
used.
2019-10-21 13:59:04 -04:00
|
|
|
"--ez", "notify", ctx.info->access.notify ? "true" : "false"
|
2019-05-13 02:01:10 -07:00
|
|
|
|
2019-07-07 00:31:49 -07:00
|
|
|
void app_log(const su_context &ctx) {
|
2018-09-16 04:16:18 -04:00
|
|
|
char fromUid[8];
|
2019-07-07 00:31:49 -07:00
|
|
|
get_uid(fromUid, ctx.info.get());
|
2018-09-16 04:16:18 -04:00
|
|
|
|
|
|
|
char toUid[8];
|
2019-07-07 00:31:49 -07:00
|
|
|
sprintf(toUid, "%d", ctx.req.uid);
|
2018-09-16 04:16:18 -04:00
|
|
|
|
|
|
|
char pid[8];
|
2019-07-07 00:31:49 -07:00
|
|
|
sprintf(pid, "%d", ctx.pid);
|
2018-09-16 04:16:18 -04:00
|
|
|
|
|
|
|
char policy[2];
|
2019-07-07 00:31:49 -07:00
|
|
|
sprintf(policy, "%d", ctx.info->access.policy);
|
2018-09-16 04:16:18 -04:00
|
|
|
|
Introduce component agnostic communication
Usually, the communication between native and the app is done via
sending intents to either broadcast or activity. These communication
channels are for launching root requests dialogs, sending root request
notifications (the toast you see when an app gained root access), and
root request logging.
Sending intents by am (activity manager) usually requires specifying
the component name in the format of <pkg>/<class name>. This means parts
of Magisk Manager cannot be randomized or else the native daemon is
unable to know where to send data to the app.
On modern Android (not sure which API is it introduced), it is possible
to send broadcasts to a package, not a specific component. Which
component will receive the intent depends on the intent filter declared
in AndroidManifest.xml. Since we already have a mechanism in native code
to keep track of the package name of Magisk Manager, this makes it
perfect to pass intents to Magisk Manager that have components being
randomly obfuscated (stub APKs).
There are a few caveats though. Although this broadcasting method works
perfectly fine on AOSP and most systems, there are OEMs out there
shipping ROMs blocking broadcasts unexpectedly. In order to make sure
Magisk works in all kinds of scenarios, we run actual tests every boot
to determine which communication method should be used.
We have 3 methods in total, ordered in preference:
1. Broadcasting to a package
2. Broadcasting to a specific component
3. Starting a specific activity component
Method 3 will always work on any device, but the downside is anytime
a communication happens, Magisk Manager will steal foreground focus
regardless of whether UI is drawn. Method 1 is the only way to support
obfuscated stub APKs. The communication test will test method 1 and 2,
and if Magisk Manager is able to receive the messages, it will then
update the daemon configuration to use whichever is preferable. If none
of the broadcasts can be delivered, then the fallback method 3 will be
used.
2019-10-21 13:59:04 -04:00
|
|
|
am_app(LOG_BODY)
|
2018-09-16 04:16:18 -04:00
|
|
|
}
|
|
|
|
|
2019-05-13 02:01:10 -07:00
|
|
|
#define NOTIFY_BODY \
|
|
|
|
"notify", \
|
|
|
|
"--ei", "from.uid", fromUid, \
|
Introduce component agnostic communication
Usually, the communication between native and the app is done via
sending intents to either broadcast or activity. These communication
channels are for launching root requests dialogs, sending root request
notifications (the toast you see when an app gained root access), and
root request logging.
Sending intents by am (activity manager) usually requires specifying
the component name in the format of <pkg>/<class name>. This means parts
of Magisk Manager cannot be randomized or else the native daemon is
unable to know where to send data to the app.
On modern Android (not sure which API is it introduced), it is possible
to send broadcasts to a package, not a specific component. Which
component will receive the intent depends on the intent filter declared
in AndroidManifest.xml. Since we already have a mechanism in native code
to keep track of the package name of Magisk Manager, this makes it
perfect to pass intents to Magisk Manager that have components being
randomly obfuscated (stub APKs).
There are a few caveats though. Although this broadcasting method works
perfectly fine on AOSP and most systems, there are OEMs out there
shipping ROMs blocking broadcasts unexpectedly. In order to make sure
Magisk works in all kinds of scenarios, we run actual tests every boot
to determine which communication method should be used.
We have 3 methods in total, ordered in preference:
1. Broadcasting to a package
2. Broadcasting to a specific component
3. Starting a specific activity component
Method 3 will always work on any device, but the downside is anytime
a communication happens, Magisk Manager will steal foreground focus
regardless of whether UI is drawn. Method 1 is the only way to support
obfuscated stub APKs. The communication test will test method 1 and 2,
and if Magisk Manager is able to receive the messages, it will then
update the daemon configuration to use whichever is preferable. If none
of the broadcasts can be delivered, then the fallback method 3 will be
used.
2019-10-21 13:59:04 -04:00
|
|
|
"--ei", "policy", policy
|
2019-05-13 02:01:10 -07:00
|
|
|
|
2019-07-07 00:31:49 -07:00
|
|
|
void app_notify(const su_context &ctx) {
|
2018-10-27 22:06:24 -04:00
|
|
|
char fromUid[8];
|
2019-07-07 00:31:49 -07:00
|
|
|
get_uid(fromUid, ctx.info.get());
|
2018-10-27 22:06:24 -04:00
|
|
|
|
|
|
|
char policy[2];
|
2019-07-07 00:31:49 -07:00
|
|
|
sprintf(policy, "%d", ctx.info->access.policy);
|
2018-10-27 22:06:24 -04:00
|
|
|
|
Introduce component agnostic communication
Usually, the communication between native and the app is done via
sending intents to either broadcast or activity. These communication
channels are for launching root requests dialogs, sending root request
notifications (the toast you see when an app gained root access), and
root request logging.
Sending intents by am (activity manager) usually requires specifying
the component name in the format of <pkg>/<class name>. This means parts
of Magisk Manager cannot be randomized or else the native daemon is
unable to know where to send data to the app.
On modern Android (not sure which API is it introduced), it is possible
to send broadcasts to a package, not a specific component. Which
component will receive the intent depends on the intent filter declared
in AndroidManifest.xml. Since we already have a mechanism in native code
to keep track of the package name of Magisk Manager, this makes it
perfect to pass intents to Magisk Manager that have components being
randomly obfuscated (stub APKs).
There are a few caveats though. Although this broadcasting method works
perfectly fine on AOSP and most systems, there are OEMs out there
shipping ROMs blocking broadcasts unexpectedly. In order to make sure
Magisk works in all kinds of scenarios, we run actual tests every boot
to determine which communication method should be used.
We have 3 methods in total, ordered in preference:
1. Broadcasting to a package
2. Broadcasting to a specific component
3. Starting a specific activity component
Method 3 will always work on any device, but the downside is anytime
a communication happens, Magisk Manager will steal foreground focus
regardless of whether UI is drawn. Method 1 is the only way to support
obfuscated stub APKs. The communication test will test method 1 and 2,
and if Magisk Manager is able to receive the messages, it will then
update the daemon configuration to use whichever is preferable. If none
of the broadcasts can be delivered, then the fallback method 3 will be
used.
2019-10-21 13:59:04 -04:00
|
|
|
am_app(NOTIFY_BODY)
|
2018-10-27 22:06:24 -04:00
|
|
|
}
|
|
|
|
|
Introduce component agnostic communication
Usually, the communication between native and the app is done via
sending intents to either broadcast or activity. These communication
channels are for launching root requests dialogs, sending root request
notifications (the toast you see when an app gained root access), and
root request logging.
Sending intents by am (activity manager) usually requires specifying
the component name in the format of <pkg>/<class name>. This means parts
of Magisk Manager cannot be randomized or else the native daemon is
unable to know where to send data to the app.
On modern Android (not sure which API is it introduced), it is possible
to send broadcasts to a package, not a specific component. Which
component will receive the intent depends on the intent filter declared
in AndroidManifest.xml. Since we already have a mechanism in native code
to keep track of the package name of Magisk Manager, this makes it
perfect to pass intents to Magisk Manager that have components being
randomly obfuscated (stub APKs).
There are a few caveats though. Although this broadcasting method works
perfectly fine on AOSP and most systems, there are OEMs out there
shipping ROMs blocking broadcasts unexpectedly. In order to make sure
Magisk works in all kinds of scenarios, we run actual tests every boot
to determine which communication method should be used.
We have 3 methods in total, ordered in preference:
1. Broadcasting to a package
2. Broadcasting to a specific component
3. Starting a specific activity component
Method 3 will always work on any device, but the downside is anytime
a communication happens, Magisk Manager will steal foreground focus
regardless of whether UI is drawn. Method 1 is the only way to support
obfuscated stub APKs. The communication test will test method 1 and 2,
and if Magisk Manager is able to receive the messages, it will then
update the daemon configuration to use whichever is preferable. If none
of the broadcasts can be delivered, then the fallback method 3 will be
used.
2019-10-21 13:59:04 -04:00
|
|
|
#define SOCKET_BODY \
|
|
|
|
"request", \
|
|
|
|
"--es", "socket", socket
|
|
|
|
|
|
|
|
void app_socket(const char *socket, const shared_ptr<su_info> &info) {
|
|
|
|
am_app_info(info.get(), SOCKET_BODY)
|
2019-05-13 02:01:10 -07:00
|
|
|
}
|
|
|
|
|
Introduce component agnostic communication
Usually, the communication between native and the app is done via
sending intents to either broadcast or activity. These communication
channels are for launching root requests dialogs, sending root request
notifications (the toast you see when an app gained root access), and
root request logging.
Sending intents by am (activity manager) usually requires specifying
the component name in the format of <pkg>/<class name>. This means parts
of Magisk Manager cannot be randomized or else the native daemon is
unable to know where to send data to the app.
On modern Android (not sure which API is it introduced), it is possible
to send broadcasts to a package, not a specific component. Which
component will receive the intent depends on the intent filter declared
in AndroidManifest.xml. Since we already have a mechanism in native code
to keep track of the package name of Magisk Manager, this makes it
perfect to pass intents to Magisk Manager that have components being
randomly obfuscated (stub APKs).
There are a few caveats though. Although this broadcasting method works
perfectly fine on AOSP and most systems, there are OEMs out there
shipping ROMs blocking broadcasts unexpectedly. In order to make sure
Magisk works in all kinds of scenarios, we run actual tests every boot
to determine which communication method should be used.
We have 3 methods in total, ordered in preference:
1. Broadcasting to a package
2. Broadcasting to a specific component
3. Starting a specific activity component
Method 3 will always work on any device, but the downside is anytime
a communication happens, Magisk Manager will steal foreground focus
regardless of whether UI is drawn. Method 1 is the only way to support
obfuscated stub APKs. The communication test will test method 1 and 2,
and if Magisk Manager is able to receive the messages, it will then
update the daemon configuration to use whichever is preferable. If none
of the broadcasts can be delivered, then the fallback method 3 will be
used.
2019-10-21 13:59:04 -04:00
|
|
|
#define TEST_BODY \
|
|
|
|
"test", "--ei", "mode", mode, nullptr
|
|
|
|
|
|
|
|
void broadcast_test(int client) {
|
|
|
|
if (client >= 0) {
|
|
|
|
// Make it not uninitialized
|
|
|
|
current_mode = MODE_ACTIVITY;
|
|
|
|
write_int(client, 0);
|
|
|
|
close(client);
|
|
|
|
}
|
|
|
|
|
2019-05-13 02:01:10 -07:00
|
|
|
su_info info;
|
|
|
|
get_db_settings(info.cfg);
|
|
|
|
get_db_strings(info.str);
|
|
|
|
validate_manager(info.str[SU_MANAGER], 0, &info.mgr_st);
|
|
|
|
|
Introduce component agnostic communication
Usually, the communication between native and the app is done via
sending intents to either broadcast or activity. These communication
channels are for launching root requests dialogs, sending root request
notifications (the toast you see when an app gained root access), and
root request logging.
Sending intents by am (activity manager) usually requires specifying
the component name in the format of <pkg>/<class name>. This means parts
of Magisk Manager cannot be randomized or else the native daemon is
unable to know where to send data to the app.
On modern Android (not sure which API is it introduced), it is possible
to send broadcasts to a package, not a specific component. Which
component will receive the intent depends on the intent filter declared
in AndroidManifest.xml. Since we already have a mechanism in native code
to keep track of the package name of Magisk Manager, this makes it
perfect to pass intents to Magisk Manager that have components being
randomly obfuscated (stub APKs).
There are a few caveats though. Although this broadcasting method works
perfectly fine on AOSP and most systems, there are OEMs out there
shipping ROMs blocking broadcasts unexpectedly. In order to make sure
Magisk works in all kinds of scenarios, we run actual tests every boot
to determine which communication method should be used.
We have 3 methods in total, ordered in preference:
1. Broadcasting to a package
2. Broadcasting to a specific component
3. Starting a specific activity component
Method 3 will always work on any device, but the downside is anytime
a communication happens, Magisk Manager will steal foreground focus
regardless of whether UI is drawn. Method 1 is the only way to support
obfuscated stub APKs. The communication test will test method 1 and 2,
and if Magisk Manager is able to receive the messages, it will then
update the daemon configuration to use whichever is preferable. If none
of the broadcasts can be delivered, then the fallback method 3 will be
used.
2019-10-21 13:59:04 -04:00
|
|
|
char mode[2];
|
|
|
|
{
|
|
|
|
sprintf(mode, "%d", MODE_BROADCAST_PACKAGE);
|
|
|
|
const char *cmd[] = { START_BROADCAST_PKG, TEST_BODY };
|
|
|
|
exec_am_cmd(cmd, &info);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
sprintf(mode, "%d", MODE_BROADCAST_COMPONENT);
|
|
|
|
const char *cmd[] = { START_BROADCAST, TEST_BODY };
|
|
|
|
exec_am_cmd(cmd, &info);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void broadcast_ack(int client) {
|
|
|
|
int mode = read_int(client);
|
|
|
|
if (mode < 0) {
|
|
|
|
// Return connection mode to client
|
|
|
|
write_int(client, current_mode);
|
|
|
|
} else {
|
|
|
|
if (mode > current_mode) {
|
|
|
|
LOGD("* Use connect mode [%d] for su request and notify\n", mode);
|
|
|
|
current_mode = static_cast<connect_mode>(mode);
|
|
|
|
}
|
|
|
|
write_int(client, 0);
|
|
|
|
}
|
|
|
|
close(client);
|
2018-09-16 04:16:18 -04:00
|
|
|
}
|
|
|
|
|
2019-07-07 00:31:49 -07:00
|
|
|
void socket_send_request(int fd, const shared_ptr<su_info> &info) {
|
2018-10-04 04:59:51 -04:00
|
|
|
write_key_token(fd, "uid", info->uid);
|
2018-09-16 04:16:18 -04:00
|
|
|
write_string_be(fd, "eof");
|
|
|
|
}
|