Magisk/app/src/main/java/com/topjohnwu/magisk/ktx/XAndroid.kt

372 lines
12 KiB
Kotlin
Raw Normal View History

2020-07-11 14:36:31 +02:00
package com.topjohnwu.magisk.ktx
2019-04-19 16:32:01 +02:00
2020-10-27 23:03:27 +01:00
import android.annotation.SuppressLint
2020-01-28 18:49:59 +01:00
import android.app.Activity
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 09:49:17 +02:00
import android.content.ComponentName
2019-05-03 09:36:39 +02:00
import android.content.Context
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 09:49:17 +02:00
import android.content.ContextWrapper
import android.content.Intent
2019-04-19 16:32:01 +02:00
import android.content.pm.ApplicationInfo
import android.content.pm.PackageManager
import android.content.pm.PackageManager.*
import android.content.pm.ServiceInfo
import android.content.pm.ServiceInfo.FLAG_ISOLATED_PROCESS
import android.content.pm.ServiceInfo.FLAG_USE_APP_ZYGOTE
2019-08-12 10:54:33 +02:00
import android.content.res.Configuration
2019-09-28 07:56:16 +02:00
import android.content.res.Resources
2019-07-28 00:46:44 +02:00
import android.database.Cursor
import android.graphics.Bitmap
import android.graphics.Canvas
import android.graphics.drawable.AdaptiveIconDrawable
import android.graphics.drawable.BitmapDrawable
import android.graphics.drawable.LayerDrawable
2019-05-03 10:42:57 +02:00
import android.net.Uri
2019-09-28 07:56:16 +02:00
import android.os.Build
import android.os.Build.VERSION.SDK_INT
import android.system.Os
2020-08-14 11:00:06 +02:00
import android.text.PrecomputedText
2019-09-28 07:56:16 +02:00
import android.view.View
2020-08-14 11:00:06 +02:00
import android.view.ViewGroup
import android.view.ViewTreeObserver
2020-01-28 18:49:59 +01:00
import android.view.inputmethod.InputMethodManager
2020-08-14 11:00:06 +02:00
import android.widget.TextView
2019-09-28 07:56:16 +02:00
import androidx.annotation.ColorRes
import androidx.annotation.DrawableRes
import androidx.appcompat.content.res.AppCompatResources
2019-09-28 07:56:16 +02:00
import androidx.core.content.ContextCompat
2020-01-28 18:49:59 +01:00
import androidx.core.content.getSystemService
2019-09-28 18:17:34 +02:00
import androidx.core.net.toUri
2020-08-14 11:00:06 +02:00
import androidx.core.text.PrecomputedTextCompat
import androidx.core.view.isGone
import androidx.core.widget.TextViewCompat
import androidx.databinding.BindingAdapter
2020-01-28 18:49:59 +01:00
import androidx.fragment.app.Fragment
2020-08-14 11:00:06 +02:00
import androidx.interpolator.view.animation.FastOutSlowInInterpolator
import androidx.transition.AutoTransition
import androidx.transition.TransitionManager
import com.topjohnwu.magisk.R
2020-01-13 15:01:46 +01:00
import com.topjohnwu.magisk.core.Const
2020-08-14 11:00:06 +02:00
import com.topjohnwu.magisk.core.ResMgr
2020-01-13 15:01:46 +01:00
import com.topjohnwu.magisk.core.utils.currentLocale
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 09:49:17 +02:00
import com.topjohnwu.magisk.utils.DynamicClassLoader
2020-08-18 15:31:15 +02:00
import com.topjohnwu.magisk.utils.Utils
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 19:59:04 +02:00
import com.topjohnwu.superuser.Shell
2020-08-14 11:00:06 +02:00
import kotlinx.coroutines.CoroutineScope
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.GlobalScope
import kotlinx.coroutines.launch
import java.io.File
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 19:59:04 +02:00
import java.lang.reflect.Array as JArray
2019-04-19 16:32:01 +02:00
2019-08-05 09:21:38 +02:00
val packageName: String get() = get<Context>().packageName
fun symlink(oldPath: String, newPath: String) {
if (SDK_INT >= 21) {
Os.symlink(oldPath, newPath)
} else {
// Just copy the files pre 5.0
val old = File(oldPath)
val newFile = File(newPath)
old.copyTo(newFile)
if (old.canExecute())
newFile.setExecutable(true)
}
}
val ServiceInfo.isIsolated get() = (flags and FLAG_ISOLATED_PROCESS) != 0
@get:SuppressLint("InlinedApi")
val ServiceInfo.useAppZygote get() = (flags and FLAG_USE_APP_ZYGOTE) != 0
2019-05-03 09:36:39 +02:00
fun Context.rawResource(id: Int) = resources.openRawResource(id)
2019-05-03 10:42:57 +02:00
fun Context.getBitmap(id: Int): Bitmap {
var drawable = AppCompatResources.getDrawable(this, id)!!
if (drawable is BitmapDrawable)
return drawable.bitmap
if (SDK_INT >= 26 && drawable is AdaptiveIconDrawable) {
drawable = LayerDrawable(arrayOf(drawable.background, drawable.foreground))
}
val bitmap = Bitmap.createBitmap(
drawable.intrinsicWidth, drawable.intrinsicHeight,
Bitmap.Config.ARGB_8888
)
val canvas = Canvas(bitmap)
drawable.setBounds(0, 0, canvas.width, canvas.height)
drawable.draw(canvas)
return bitmap
}
val Context.deviceProtectedContext: Context get() =
if (SDK_INT >= 24) {
createDeviceProtectedStorageContext()
} else { this }
fun Intent.startActivity(context: Context) = context.startActivity(this)
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 19:59:04 +02:00
fun Intent.startActivityWithRoot() {
val args = mutableListOf("am", "start", "--user", Const.USER_ID.toString())
val cmd = toCommand(args).joinToString(" ")
Shell.su(cmd).submit()
}
fun Intent.toCommand(args: MutableList<String> = mutableListOf()): MutableList<String> {
action?.also {
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 09:49:17 +02:00
args.add("-a")
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 19:59:04 +02:00
args.add(it)
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 09:49:17 +02: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 19:59:04 +02:00
component?.also {
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 09:49:17 +02:00
args.add("-n")
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 19:59:04 +02:00
args.add(it.flattenToString())
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 09:49:17 +02: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 19:59:04 +02:00
data?.also {
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 09:49:17 +02:00
args.add("-d")
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 19:59:04 +02:00
args.add(it.toString())
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 09:49:17 +02: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 19:59:04 +02:00
categories?.also {
for (cat in it) {
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 09:49:17 +02:00
args.add("-c")
args.add(cat)
}
}
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 19:59:04 +02:00
type?.also {
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 09:49:17 +02:00
args.add("-t")
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 19:59:04 +02:00
args.add(it)
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 09:49:17 +02: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 19:59:04 +02:00
extras?.also {
loop@ for (key in it.keySet()) {
val v = it[key] ?: continue
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 09:49:17 +02:00
var value: Any = v
val arg: String
when {
v is String -> arg = "--es"
v is Boolean -> arg = "--ez"
v is Int -> arg = "--ei"
v is Long -> arg = "--el"
v is Float -> arg = "--ef"
v is Uri -> arg = "--eu"
v is ComponentName -> {
arg = "--ecn"
value = v.flattenToString()
}
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 19:59:04 +02:00
v is List<*> -> {
if (v.isEmpty())
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 09:49:17 +02:00
continue@loop
arg = if (v[0] is Int)
"--eial"
else if (v[0] is Long)
"--elal"
else if (v[0] is Float)
"--efal"
else if (v[0] is String)
"--esal"
else
continue@loop /* Unsupported */
val sb = StringBuilder()
for (o in v) {
sb.append(o.toString().replace(",", "\\,"))
sb.append(',')
}
// Remove trailing comma
sb.deleteCharAt(sb.length - 1)
value = sb
}
v.javaClass.isArray -> {
arg = if (v is IntArray)
"--eia"
else if (v is LongArray)
"--ela"
else if (v is FloatArray)
"--efa"
else if (v is Array<*> && v.isArrayOf<String>())
"--esa"
else
continue@loop /* Unsupported */
val sb = StringBuilder()
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 19:59:04 +02:00
val len = JArray.getLength(v)
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 09:49:17 +02:00
for (i in 0 until len) {
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 19:59:04 +02:00
sb.append(JArray.get(v, i)!!.toString().replace(",", "\\,"))
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 09:49:17 +02:00
sb.append(',')
}
// Remove trailing comma
sb.deleteCharAt(sb.length - 1)
value = sb
}
else -> continue@loop
} /* Unsupported */
args.add(arg)
args.add(key)
args.add(value.toString())
}
}
args.add("-f")
args.add(flags.toString())
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 19:59:04 +02:00
return args
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 09:49:17 +02:00
}
2019-07-21 06:04:06 +02:00
fun Intent.chooser(title: String = "Pick an app") = Intent.createChooser(this, title)
fun Context.cachedFile(name: String) = File(cacheDir, name)
2019-07-28 00:46:44 +02:00
fun <Result> Cursor.toList(transformer: (Cursor) -> Result): List<Result> {
val out = mutableListOf<Result>()
while (moveToNext()) out.add(transformer(this))
return out
}
2019-08-12 10:54:33 +02:00
fun ApplicationInfo.getLabel(pm: PackageManager): String {
runCatching {
if (labelRes > 0) {
val res = pm.getResourcesForApplication(this)
val config = Configuration()
config.setLocale(currentLocale)
res.updateConfiguration(config, res.displayMetrics)
return res.getString(labelRes)
}
}
return loadLabel(pm).toString()
}
2019-09-28 07:56:16 +02:00
fun Intent.exists(packageManager: PackageManager) = resolveActivity(packageManager) != null
fun Context.colorCompat(@ColorRes id: Int) = try {
ContextCompat.getColor(this, id)
} catch (e: Resources.NotFoundException) {
null
}
fun Context.colorStateListCompat(@ColorRes id: Int) = try {
ContextCompat.getColorStateList(this, id)
} catch (e: Resources.NotFoundException) {
null
}
fun Context.drawableCompat(@DrawableRes id: Int) = ContextCompat.getDrawable(this, id)
/**
* Pass [start] and [end] dimensions, function will return left and right
* with respect to RTL layout direction
*/
fun Context.startEndToLeftRight(start: Int, end: Int): Pair<Int, Int> {
2020-01-12 14:52:32 +01:00
if (SDK_INT >= Build.VERSION_CODES.JELLY_BEAN_MR1 &&
2019-09-28 07:56:16 +02:00
resources.configuration.layoutDirection == View.LAYOUT_DIRECTION_RTL
) {
return end to start
}
return start to end
2019-09-28 18:17:34 +02:00
}
fun Context.openUrl(url: String) = Utils.openLink(this, url.toUri())
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 09:49:17 +02:00
@Suppress("FunctionName")
inline fun <reified T> T.DynamicClassLoader(apk: File) =
DynamicClassLoader(apk, T::class.java.classLoader)
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 09:49:17 +02:00
fun Context.unwrap(): Context {
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 09:49:17 +02:00
var context = this
while (true) {
if (context is ContextWrapper)
context = context.baseContext
else
break
}
return context
}
fun Context.hasPermissions(vararg permissions: String) = permissions.all {
ContextCompat.checkSelfPermission(this, it) == PERMISSION_GRANTED
2019-10-26 20:59:30 +02:00
}
2020-01-28 18:49:59 +01:00
fun Activity.hideKeyboard() {
val view = currentFocus ?: return
getSystemService<InputMethodManager>()
?.hideSoftInputFromWindow(view.windowToken, 0)
view.clearFocus()
}
fun Fragment.hideKeyboard() {
activity?.hideKeyboard()
}
2020-08-14 11:00:06 +02:00
fun View.setOnViewReadyListener(callback: () -> Unit) = addOnGlobalLayoutListener(true, callback)
fun View.addOnGlobalLayoutListener(oneShot: Boolean = false, callback: () -> Unit) =
viewTreeObserver.addOnGlobalLayoutListener(object :
ViewTreeObserver.OnGlobalLayoutListener {
override fun onGlobalLayout() {
if (oneShot) viewTreeObserver.removeOnGlobalLayoutListener(this)
callback()
}
})
fun ViewGroup.startAnimations() {
val transition = AutoTransition()
.setInterpolator(FastOutSlowInInterpolator())
.setDuration(400)
.excludeTarget(R.id.main_toolbar, true)
2020-08-14 11:00:06 +02:00
TransitionManager.beginDelayedTransition(
this,
transition
)
}
var View.coroutineScope: CoroutineScope
get() = getTag(R.id.coroutineScope) as? CoroutineScope ?: GlobalScope
set(value) = setTag(R.id.coroutineScope, value)
@set:BindingAdapter("precomputedText")
var TextView.precomputedText: CharSequence
get() = text
set(value) {
val callback = tag as? Runnable
// Don't even bother pre 21
if (SDK_INT < 21) {
post {
text = value
isGone = false
callback?.run()
}
return
}
coroutineScope.launch(Dispatchers.IO) {
if (SDK_INT >= 29) {
2020-08-14 12:17:10 +02:00
// Internally PrecomputedTextCompat will use platform API on API 29+
2020-08-14 11:00:06 +02:00
// Due to some stupid crap OEM (Samsung) implementation, this can actually
// crash our app. Directly use platform APIs with some workarounds
val pre = PrecomputedText.create(value, textMetricsParams)
post {
try {
text = pre
} catch (e: IllegalArgumentException) {
// Override to computed params to workaround crashes
textMetricsParams = pre.params
text = pre
}
isGone = false
callback?.run()
}
} else {
val tv = this@precomputedText
val params = TextViewCompat.getTextMetricsParams(tv)
val pre = PrecomputedTextCompat.create(value, params)
post {
TextViewCompat.setPrecomputedText(tv, pre)
isGone = false
callback?.run()
}
}
}
}
fun Int.dpInPx(): Int {
val scale = ResMgr.resource.displayMetrics.density
return (this * scale + 0.5).toInt()
}