5ffb9eaa5b
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.
75 lines
4.7 KiB
Markdown
75 lines
4.7 KiB
Markdown
# Magisk
|
|
|
|
[Downloads](https://github.com/topjohnwu/Magisk/releases) \| [Documentation](https://topjohnwu.github.io/Magisk/) \| [XDA Thread](https://forum.xda-developers.com/apps/magisk/official-magisk-v7-universal-systemless-t3473445)
|
|
|
|
## Introduction
|
|
|
|
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 are 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](https://github.com/topjohnwu/Magisk/issues) or directly in the thread.
|
|
|
|
## Building Environment Requirements
|
|
|
|
- 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
|
|
|
|
- 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`
|
|
- `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
|
|
Certificate fingerprints:
|
|
MD5: CE:DA:68:C1:E1:74:71:0A:EF:58:89:7D:AE:6E:AB:4F
|
|
SHA1: DC:0F:2B:61:CB:D7:E9:D3:DB:BE:06:0B:2B:87:0D:46:BB:06:02:11
|
|
SHA256: B4:CB:83:B4:DA:D9:9F:99:7D:BE:87:2F:01:3A:A1:6C:14:EE:C4:1D:16:70:21:F3:71:F7:E1:33:0F:27:3E:E6
|
|
Signature algorithm name: SHA256withRSA
|
|
Version: 3
|
|
```
|
|
|
|
## License
|
|
|
|
Magisk, including all git submodules are free software:
|
|
you can redistribute it and/or modify it under the terms of the
|
|
GNU General Public License as published by the Free Software Foundation,
|
|
either version 3 of the License, or (at your option) any later version.
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
GNU General Public License for more details.
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
along with this program. If not, see <http://www.gnu.org/licenses/>.
|