2019-03-04 21:45:18 +00:00
|
|
|
#include <sys/mount.h>
|
2017-04-08 23:25:10 +00:00
|
|
|
#include <stdlib.h>
|
2017-04-15 10:10:54 +00:00
|
|
|
#include <stdio.h>
|
2017-09-14 13:54:56 +00:00
|
|
|
#include <unistd.h>
|
2017-11-05 21:41:03 +00:00
|
|
|
#include <libgen.h>
|
2018-09-27 07:11:10 +00:00
|
|
|
#include <string.h>
|
2017-04-08 23:25:10 +00:00
|
|
|
|
2019-02-10 06:05:19 +00:00
|
|
|
#include <utils.h>
|
|
|
|
#include <magisk.h>
|
|
|
|
#include <daemon.h>
|
|
|
|
#include <selinux.h>
|
|
|
|
#include <flags.h>
|
2017-04-04 19:44:13 +00:00
|
|
|
|
2019-05-13 09:01:10 +00:00
|
|
|
using namespace std::literals;
|
|
|
|
|
2018-11-04 08:38:06 +00:00
|
|
|
[[noreturn]] static void usage() {
|
2017-04-15 10:10:54 +00:00
|
|
|
fprintf(stderr,
|
2019-09-13 07:14:21 +00:00
|
|
|
FULL_VER(Magisk) R"EOF( multi-call binary
|
|
|
|
|
|
|
|
Usage: magisk [applet [arguments]...]
|
|
|
|
or: magisk [options]...
|
|
|
|
|
|
|
|
Options:
|
|
|
|
-c print current binary version
|
|
|
|
-v print running daemon version
|
|
|
|
-V print running daemon version code
|
|
|
|
--list list all available applets
|
|
|
|
--daemon manually start magisk daemon
|
|
|
|
--remove-modules remove all modules and reboot
|
|
|
|
--[init trigger] start service for init trigger
|
|
|
|
|
|
|
|
Advanced Options (Internal APIs):
|
|
|
|
--unlock-blocks set BLKROSET flag to OFF for all block devices
|
|
|
|
--restorecon restore selinux context on Magisk files
|
|
|
|
--clone-attr SRC DEST clone permission, owner, and selinux context
|
|
|
|
--clone SRC DEST clone SRC to DEST
|
|
|
|
--sqlite SQL exec SQL commands to Magisk database
|
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 17:59:04 +00:00
|
|
|
--connect-mode [MODE] get/set connect mode for su request and notify
|
|
|
|
--broadcast-test manually trigger broadcast tests
|
2019-09-13 07:14:21 +00:00
|
|
|
|
|
|
|
Supported init triggers:
|
|
|
|
post-fs-data, service, boot-complete
|
|
|
|
|
|
|
|
Supported applets:
|
|
|
|
)EOF");
|
2017-04-15 10:10:54 +00:00
|
|
|
|
2018-09-27 22:26:41 +00:00
|
|
|
for (int i = 0; applet_names[i]; ++i)
|
|
|
|
fprintf(stderr, i ? ", %s" : " %s", applet_names[i]);
|
2017-09-27 16:54:01 +00:00
|
|
|
fprintf(stderr, "\n\n");
|
2017-04-15 10:10:54 +00:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
2018-05-13 06:32:21 +00:00
|
|
|
int magisk_main(int argc, char *argv[]) {
|
|
|
|
if (argc < 2)
|
|
|
|
usage();
|
2019-05-13 09:01:10 +00:00
|
|
|
if (argv[1] == "-c"sv) {
|
2019-02-12 10:17:02 +00:00
|
|
|
printf(MAGISK_VERSION ":MAGISK (" str(MAGISK_VER_CODE) ")\n");
|
2018-05-13 06:32:21 +00:00
|
|
|
return 0;
|
2019-05-13 09:01:10 +00:00
|
|
|
} else if (argv[1] == "-v"sv) {
|
2018-06-16 17:28:29 +00:00
|
|
|
int fd = connect_daemon();
|
2018-05-13 06:32:21 +00:00
|
|
|
write_int(fd, CHECK_VERSION);
|
|
|
|
char *v = read_string(fd);
|
|
|
|
printf("%s\n", v);
|
|
|
|
free(v);
|
|
|
|
return 0;
|
2019-05-13 09:01:10 +00:00
|
|
|
} else if (argv[1] == "-V"sv) {
|
2018-06-16 17:28:29 +00:00
|
|
|
int fd = connect_daemon();
|
2018-05-13 06:32:21 +00:00
|
|
|
write_int(fd, CHECK_VERSION_CODE);
|
|
|
|
printf("%d\n", read_int(fd));
|
|
|
|
return 0;
|
2019-05-13 09:01:10 +00:00
|
|
|
} else if (argv[1] == "--list"sv) {
|
2018-09-27 22:26:41 +00:00
|
|
|
for (int i = 0; applet_names[i]; ++i)
|
|
|
|
printf("%s\n", applet_names[i]);
|
2018-05-13 06:32:21 +00:00
|
|
|
return 0;
|
2019-05-13 09:01:10 +00:00
|
|
|
} else if (argv[1] == "--unlock-blocks"sv) {
|
2018-05-13 06:32:21 +00:00
|
|
|
unlock_blocks();
|
|
|
|
return 0;
|
2019-05-13 09:01:10 +00:00
|
|
|
} else if (argv[1] == "--restorecon"sv) {
|
2019-04-24 04:13:48 +00:00
|
|
|
restore_rootcon();
|
2018-06-03 06:43:03 +00:00
|
|
|
restorecon();
|
2018-05-13 06:32:21 +00:00
|
|
|
return 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 17:59:04 +00:00
|
|
|
} else if (argc >= 4 && argv[1] == "--clone-attr"sv) {;
|
2018-05-13 06:32:21 +00:00
|
|
|
clone_attr(argv[2], argv[3]);
|
|
|
|
return 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 17:59:04 +00:00
|
|
|
} else if (argc >= 4 && argv[1] == "--clone"sv) {
|
2019-02-12 09:05:51 +00:00
|
|
|
cp_afc(argv[2], argv[3]);
|
|
|
|
return 0;
|
2019-05-13 09:01:10 +00:00
|
|
|
} else if (argv[1] == "--daemon"sv) {
|
2019-03-04 21:45:18 +00:00
|
|
|
int fd = connect_daemon(true);
|
2018-07-02 14:11:28 +00:00
|
|
|
write_int(fd, DO_NOTHING);
|
2018-05-13 06:32:21 +00:00
|
|
|
return 0;
|
2019-05-13 09:01:10 +00:00
|
|
|
} else if (argv[1] == "--post-fs-data"sv) {
|
2019-03-04 21:45:18 +00:00
|
|
|
int fd = connect_daemon(true);
|
2018-05-13 06:32:21 +00:00
|
|
|
write_int(fd, POST_FS_DATA);
|
|
|
|
return read_int(fd);
|
2019-05-13 09:01:10 +00:00
|
|
|
} else if (argv[1] == "--service"sv) {
|
2019-03-04 21:45:18 +00:00
|
|
|
int fd = connect_daemon(true);
|
2018-05-13 06:32:21 +00:00
|
|
|
write_int(fd, LATE_START);
|
|
|
|
return read_int(fd);
|
2019-05-13 09:01:10 +00:00
|
|
|
} else if (argv[1] == "--boot-complete"sv) {
|
2019-03-04 21:45:18 +00:00
|
|
|
int fd = connect_daemon(true);
|
2018-08-09 06:52:44 +00:00
|
|
|
write_int(fd, BOOT_COMPLETE);
|
|
|
|
return read_int(fd);
|
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 17:59:04 +00:00
|
|
|
} else if (argc >= 3 && argv[1] == "--sqlite"sv) {
|
2018-11-16 08:20:30 +00:00
|
|
|
int fd = connect_daemon();
|
|
|
|
write_int(fd, SQLITE_CMD);
|
|
|
|
write_string(fd, argv[2]);
|
2019-09-01 05:58:50 +00:00
|
|
|
for (;;) {
|
|
|
|
char *res = read_string(fd);
|
|
|
|
if (res[0] == '\0') {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
printf("%s\n", res);
|
|
|
|
free(res);
|
|
|
|
}
|
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 17:59:04 +00:00
|
|
|
} else if (argv[1] == "--connect-mode"sv) {
|
2019-05-13 09:01:10 +00:00
|
|
|
int fd = connect_daemon();
|
|
|
|
write_int(fd, BROADCAST_ACK);
|
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 17:59:04 +00:00
|
|
|
if (argc >= 3) {
|
|
|
|
write_int(fd, parse_int(argv[2]));
|
|
|
|
} else {
|
|
|
|
write_int(fd, -1);
|
|
|
|
}
|
|
|
|
return read_int(fd);
|
2019-09-13 07:14:21 +00:00
|
|
|
} else if (argv[1] == "--remove-modules"sv) {
|
|
|
|
int fd = connect_daemon();
|
|
|
|
write_int(fd, REMOVE_MODULES);
|
|
|
|
return read_int(fd);
|
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 17:59:04 +00:00
|
|
|
} else if (argv[1] == "--broadcast-test"sv) {
|
|
|
|
int fd = connect_daemon();
|
|
|
|
write_int(fd, BROADCAST_TEST);
|
|
|
|
return read_int(fd);
|
2018-05-13 06:32:21 +00:00
|
|
|
}
|
2019-02-10 06:05:19 +00:00
|
|
|
#if 0
|
|
|
|
/* Entry point for testing stuffs */
|
2019-05-13 09:01:10 +00:00
|
|
|
else if (argv[1] == "--test"sv) {
|
2019-02-10 06:05:19 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#endif
|
2018-05-13 06:32:21 +00:00
|
|
|
usage();
|
|
|
|
}
|