Commit Graph

3616 Commits

Author SHA1 Message Date
topjohnwu
d010cb7e42 Update stub 2019-10-23 05:19:54 -04:00
topjohnwu
71136d7347 Manually trigger broadcast tests if necessary 2019-10-22 16:04:20 -04:00
topjohnwu
a18c552ddf Guard env state behind cached objects 2019-10-22 15:37:55 -04:00
topjohnwu
9656878ef3 Actually apply the input name 2019-10-22 05:06:17 -04:00
Viktor De Pasquale
7ded7de39a Added custom dialog for setting app's name after repackaging 2019-10-22 04:52:19 -04:00
topjohnwu
0f74e89b44 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
topjohnwu
953c40b083 Allow upgrade Magisk daemon in emulator 2019-10-21 13:58:57 -04:00
topjohnwu
271b0287d8 Pass in stub version just in case 2019-10-20 17:47:55 -04:00
topjohnwu
96a8a2a8b8 Make SuRequest default to Translucent.NoTitleBar
Close #1959
2019-10-20 17:35:38 -04:00
topjohnwu
75306f658f Revert "Drop API 17 (Android 4.2) support"
Turns out that we cannot use AndroidKeystore anyways, so we don't
actually need to drop API 17. Revert this change.
2019-10-20 07:13:03 -04:00
topjohnwu
325d9a0b86 Generate keys for signing hidden Magisk Manager 2019-10-20 06:56:33 -04:00
topjohnwu
a02493fbaa Workaround R8 bug 2019-10-19 05:44:56 -04:00
topjohnwu
9c27d691dd Drop API 17 (Android 4.2) support 2019-10-19 03:11:54 -04:00
topjohnwu
935bd01f59 Post process release APKs 2019-10-17 18:02:31 -04:00
topjohnwu
eeb5d669f6 Assign signing keystore location in config 2019-10-17 16:20:01 -04:00
topjohnwu
78daa2eb62 Do not use string resources for app label
This not only simplifies hiding stub APKs (no resource IDs involved),
but also opens the opportunity to allow users to customize whatever
app name they want after it is hidden.
2019-10-17 04:47:46 -04:00
topjohnwu
40eda05a30 Make main app fully independent from the stub
- Skip 0x7f01XXXX - 0x7f05XXXX resource IDs in the main app; they are
reserved for stub resources
- Support sending additional data from host to guest
- Use resource mapping passed from host when they are being sent
to the system framework (notifications and shortcuts)
2019-10-17 02:55:42 -04:00
topjohnwu
9f9de8c43b Obfuscate WorkManager components
Remove unused components and hack the context sent into WorkManager
2019-10-16 17:03:55 -04:00
topjohnwu
a910c8ccd8 Support stub APK upgrades 2019-10-16 05:07:29 -04:00
topjohnwu
43bda2d4a4 Allow component classname obfuscation 2019-10-16 04:38:31 -04:00
topjohnwu
c7033dd757 Allow injecting custom channel URL for debug 2019-10-16 01:54:59 -04:00
topjohnwu
5673a9bace Move system accessible resources to shared 2019-10-15 05:49:23 -04:00
topjohnwu
34ff764515 Stabilize resource IDs 2019-10-15 04:37:12 -04:00
topjohnwu
1b3a009da7 Remove unused WorkManager components 2019-10-15 04:36:09 -04:00
topjohnwu
a49002bb2c Reorganize string resources 2019-10-15 03:33:22 -04:00
Omar Kharrab
7342fc2307 Update Arabic translation 2019-10-15 02:57:43 -04:00
topjohnwu
9867a3bd60 Pedantic boot_img_hdr multi-version support 2019-10-15 01:46:29 -04:00
topjohnwu
5ffb9eaa5b Support loading Magisk Manager from stub on 9.0+
In the effort of preventing apps from crawling APK contents across the
whole installed app list to detect Magisk Manager, the solution here
is to NOT install the actual APK into the system, but instead
dynamically load the full app at runtime by a stub app. The full APK
will be stored in the application's private internal data where
non-root processes cannot read or scan.

The basis of this implementation is the class "AppComponentFactory"
that is introduced in API 28. If assigned, the system framework will
delegate app component instantiation to our custom implementation,
which allows us to do all sorts of crazy stuffs, in our case dynamically
load classes and create objects that does not exist in our APK.

There are a few challenges to achieve our goal though. First, Java
ClassLoaders follow the "delegation pattern", which means class loading
resolution will first be delegated to the parent loader before we get
a chance to do anything. This includes DexClassLoader, which is what
we will be using to load DEX files at runtime. This is a problem
because our stub app and full app share quite a lot of class names.
A custom ClassLoader, DynamicClassLoader, is created to overcome this
issue: it will always load classes in its current dex path before
delegating it to the parent.

Second, all app components (with the exception of runtime
BroadcastReceivers) are required to be declared in AndroidManifest.xml.
The full Magisk Manager has quite a lot of components (including
those from WorkManager and Room). The solution is to copy the complete
AndroidManifest.xml from the full app to the stub, and our
AppComponentFactory is responsible to construct the proper objects or
return dummy implementations in case the full APK isn't downloaded yet.

Third, other than classes, all resources required to run the full app
are also not bundled with the stub APK. We have to call an internal API
`AssetManager.addAssetPath(String)` to add our downloaded full APK into
AssetManager in order to access resources within our full app. That
internal API has existed forever, and is whitelisted from restricted
API access on modern Android versions, so it is pretty safe to use.

Fourth, on the subject of resources, some resources are not just being
used by our app at runtime. Resources such as the app icon, app label,
launch theme, basically everything referred in AndroidManifest.xml,
are used by the system to display the app properly. The system get these
resources via resource IDs and direct loading from the installed APK.
This subset of resources would have to be copied into the stub to make
the app work properly.

Fifth, resource IDs are used all over the place in XMLs and Java code.
The resource IDs in the stub and full app cannot missmatch, or
somewhere, either it be the system or AssetManager, will refer to the
incorrect resource. The full app will have to include all resources in
the stub, and all of them have to be assigned to the exact same IDs in
both APKs. To achieve this, we use AAPT2's "--emit-ids" option to dump
the resource ID mapping when building the stub, and "--stable-ids" when
building the full APK to make sure all overlapping resources in full
and stub are always assigned to the same ID.

Finally, both stub and full app have to work properly independently.
On 9.0+, the stub will have to first launch an Activity to download
the full APK before it can relaunch into the full app. On pre-9.0, the
stub should behave as it always did: download and prompt installation
to upgrade itself to full Magisk Manager. In the full app, the goal
is to introduce minimal intrusion to the code base to make sure this
whole thing is maintainable in the future. Fortunately, the solution
ends up pretty slick: all ContextWrappers in the app will be injected
with custom Contexts. The custom Contexts will return our patched
Resources object and the ClassLoader that loads itself, which will be
DynamicClassLoader in the case of running as a delegate app.
By directly patching the base Context of ContextWrappers (which covers
tons of app components) and in the Koin DI, the effect propagates deep
into every aspect of the code, making this change basically fully
transparent to almost every piece of code in full Magisk Manager.

After this commit, the stub app is able to properly download and launch
the full app, with most basic functionalities working just fine.
Do not expect Magisk Manager upgrades and hiding (repackaging) to
work properly, and some other minor issues might pop up.
This feature is still in the early WIP stages.
2019-10-14 03:49:17 -04:00
topjohnwu
b05b688267 Fix issues in stub APK 2019-10-12 03:58:45 -04:00
Simon Shi
f3d7f85063 Fix incorrect link path for /sbin/.core 2019-10-12 01:00:15 -04:00
topjohnwu
de969a9dab Downgrade recyclerview 2019-10-12 00:53:04 -04:00
topjohnwu
59fd38bbf8 Add v7.3.5 changelog 2019-10-11 16:12:32 -04:00
topjohnwu
06dc6df270 Allow dalvik runtime to load snet 2019-10-11 03:58:04 -04:00
topjohnwu
ff8460b361 Update dependencies 2019-10-11 03:29:55 -04:00
topjohnwu
674d272eaa Support pre-5.0 without GMS
Fix #1912
2019-10-11 01:46:15 -04:00
topjohnwu
c3e00c279d Legacy adb shell does not have uname 2019-10-11 01:45:06 -04:00
dark-basic
175d920c94 Update strings.xml
I'M BACK.
New translations were added.
2019-10-10 17:17:09 -04:00
topjohnwu
04920883ea Change code for handling tar files 2019-10-10 15:07:45 -04:00
topjohnwu
5e44b0b9d5 Use raw literals for scripts 2019-10-09 17:38:45 -04:00
topjohnwu
23c1a1dab8 Some code reorganizing 2019-10-09 16:01:21 -04:00
topjohnwu
f5d054b93c Add support for PXA DTBs 2019-10-08 23:49:21 -04:00
topjohnwu
d25ae5e0a9 Add __attribute__((packed)) just in case 2019-10-08 16:55:25 -04:00
topjohnwu
c42a51dcbb Add support to patch DTBH DTBs
Apparently, Qualcomm is not the only on creating weird DTB formats,
Samsung also have their own DTBH format for Exynos platforms.

Close #1902
2019-10-08 16:43:27 -04:00
topjohnwu
da3fd92b31 Prevent unsigned overflow
Close #1898
2019-10-08 15:55:27 -04:00
topjohnwu
4a45ba3c14 Update magisk_files commit hashes 2019-10-08 14:53:04 -04:00
Madis
dbc8bed234 Estonian update 2019-10-07 23:04:19 -04:00
Gaurav
f8b4190a11 Fix Typos 2019-10-07 23:03:09 -04:00
Mevlüt TOPÇU
479972e3ae Update Turkish language
Hi

Merge please

Thank's
2019-10-07 23:02:29 -04:00
Viktor De Pasquale
3ea28b0afb Fixed permission event not being executed 2019-10-07 22:58:14 -04:00
Viktor De Pasquale
2b3cc28966 Fixed snackbar not showing up for dumping files 2019-10-07 22:58:14 -04:00