• ## Magisk

2021-02-23 13:57:39
Magisk
• Magisk安装包，可以支持root，Magisk Hide，为广告屏蔽应用提供 systemless hosts 支持，通过 SafetyNet 检查
• Magisk文件托管 此仓库托管Magisk相关文件
• magisk-module-installer 此回购仅适用于magisk模块模板，请阅读以获取有关如何创建Magisk模块安装程序的说明。 更新的存储库为：20200117 Magisk兼容性：20.3+
• magisk-blobmoji：将Blobmoji与Magisk一起使用
• Magisk is a suite of open source software for customizing Android, supporting devices higher than Android 5.0. Some highlight features: MagiskSU: Provide root access for applications Magisk Modules...
• Magisk是xda作者topjohnwu制作的一款能够root设备，修改boot image或者添加文件到/data 以及/cache目录，从而在不修改系统的情况下实现一些系统性的功能，最近一段时间Magisk的更新较为频繁，而最近一次的版本更新更...
• Magisk32.zip
• magisk-v16.0magisk-v16.0magisk-v16.0magisk-v16.0magisk-v16.0

magisk

[Disclaimer: The goal of this article is to bring academic insights to Magisk’s functionalities and how Magisk evades root detection. The insights shared are purely for learning purposes. The author and CSG does not condone, encourage, nor intend for the lessons described below to be used for any purposes other than cybersecurity research.]
[免责声明：本文的目的是为Magisk的功能以及Magisk如何规避根检测带来学术见解。 共享的见解纯粹是出于学习目的。 作者和CSG不会纵容，鼓励也不打算将以下所述的课程用于网络安全研究以外的任何其他目的。]
介绍 (Introduction)
While rooting and root detection methods for Android devices have been around for more than a decade, Magisk software continues to be extremely resistant to root detection methods. Today, there are no known methods on how to detect rooting by Magisk. While testers are presented a convenient and reliable “cheat code” when conducting penetration tests, the downside: we have no means of mitigating against attacks that use Magisk.
尽管Android设备的生根和根检测方法已经存在了十多年，但Magisk软件仍然极力抵抗根检测方法。 如今，尚无有关如何检测Magisk生根的已知方法。 尽管在进行渗透测试时会向测试人员显示一个方便且可靠的“作弊代码”，但不利的一面是：我们无法缓解使用Magisk的攻击。
Recent discussions with my colleagues, however, have got me thinking about a new Magisk detection method. This blog post summarises a joint attempt by my colleagues and I at a Magisk detection method. I will first introduce the concept of rooting and explain how Magisk evades root detection. I will then outline some methods for Magisk root detection.
但是，最近与同事的讨论使我开始思考一种新的Magisk检测方法 。 这篇博客文章总结了我和我的同事在Magisk检测方法上的共同尝试。 我将首先介绍生根的概念，并解释Magisk如何逃避根检测。 然后，我将概述一些用于Magisk根检测的方法。
什么是生根？ (What is rooting?)
Before we dive down the Magisk rabbit hole, it may be helpful to understand what rooting is, and why people, particularly security testers, want to root their mobile devices. We will be looking specifically at the Magisk software, which only works on Android. A “rooted” Android device is conceptually similar to a “jailbroken” iOS device, but iOS jailbreaking will not be discussed here.
在我们深入Magisk兔子洞之前，了解根源是什么，以及为什么人们(尤其是安全测试人员)想要扎根其移动设备可能会有所帮助。 我们将专门研究仅在Android上运行的Magisk软件。 从概念上讲，“扎根” Android设备类似于“越狱” iOS设备，但此处不再讨论iOS越狱问题。
Android has its roots (pun intended) in the Linux kernel, which stems from UNIX. In UNIX/Linux terminology, the root user is a special user with administrative privileges. In fact, the command in Android/Linux to elevate a normal user’s privileges to root is called su, which is short for “super user”. One can only imagine the kind of privileges accorded to the root user.
Android起源于Linux内核(出于双关语意)，它源自UNIX。 在UNIX / Linux术语中，root用户是具有管理特权的特殊用户。 实际上，Android / Linux中将普通用户的特权提升为root的命令称为su ，它是“超级用户”的缩写。 只能想象授予根用户的那种特权。
By default, Android devices do not have root users. The security model of Android is such that each application exists as a separate non-privileged user, denoted by its own User ID, or UID. Like how users in Linux only have access to their own data and not data of others, this ensures that Android applications only have access to their own data. This is the foundation of the Android application sandboxing concept. Yet, with the introduction of a root user, all bets are off, since a root user has access to pretty much the entire device, thereby violating the principle of application sandboxing.
默认情况下，Android设备没有root用户。 Android的安全性模型使得每个应用程序都作为一个单独的非特权用户(以其自己的用户ID或UID表示)存在。 就像Linux中的用户只能访问自己的数据而不能访问其他人的数据一样，这可以确保Android应用程序只能访问自己的数据。 这是Android应用程序沙箱概念的基础。 但是，随着root用户的引入，所有赌注都消失了，因为root用户几乎可以访问整个设备，从而违反了应用程序沙箱化的原则。

Application sandboxing in Android

Android中的应用沙箱

Attackers, security testers, and power users prefer full control of the devices they own (or pwn). With normal access, a user’s or application’s actions are limited by the Android framework; such restrictions have also become increasingly tighter with each Android iteration. Root access reduces the number of OS level restrictions, thereby expanding the possibilities of what one can do with the device. For attackers and security testers, this means that they can now run tools and use techniques to reverse engineer applications, find vulnerabilities, and exploit them.
攻击者，安全测试人员和超级用户喜欢完全控制他们拥有(或拥有)的设备。 在具有正常访问权限的情况下，Android框架会限制用户或应用程序的操作； 每次Android迭代时，此类限制也变得越来越严格。 根访问减少了操作系统级别限制的数量，从而扩大了用户可以使用该设备进行操作的可能性。 对于攻击者和安全测试人员来说，这意味着他们现在可以运行工具并使用技术来反向工程应用程序，查找漏洞并加以利用。
什么是Magisk？ (What is Magisk?)
Magisk is a popular “systemless” Android root method and has been the de facto Android root method since 2016. Traditional root methods, such as the now defunct Chainfire SuperSu, worked by modifying the system partition which contains the system files. Magisk’s “systemless” root means that it roots an Android device without modifying the system partition. It does this by storing the modifications in the boot partition instead of modifying the actual system files. Since the original system files remain unchanged, Magisk can avoid detection by popular root detection methods such as Google SafetyNet.
Magisk是一种流行的“无系统” Android根方法，自2016年以来一直是事实上的Android根方法。传统的根方法(例如现已失效的Chainfire SuperSu)通过修改包含系统文件的系统分区来工作。 Magisk的“无系统”根目录意味着它可以在不修改系统分区的情况下以Android设备为根目录。 通过将修改存储在启动分区中，而不是修改实际的系统文件来完成此操作。 由于原始系统文件保持不变，因此Magisk可以避免通过流行的根检测方法(例如Google SafetyNet)进行检测。
寻根军备竞赛 (The root detection arms race)
Root methods and root detection is a constant arms race: software developers are constantly looking out for new ways of detecting root methods, and root developers are constantly looking for new ways to evade detection. Despite not modifying the system partition, Magisk nevertheless leaves behind hints of its presence. Software developers leverage these trails to detect Magisk’s presence, and Magisk has since been updated to counter such methods to evade detection. One such trail can be found at a process’ mount points.
根方法和根检测是一场持续不断的军备竞赛：软件开发人员一直在寻找检测根方法的新方法，而根开发人员也在不断寻找逃避检测的新方法。 尽管没有修改系统分区，Magisk仍然留下了其存在的提示。 软件开发人员利用这些线索来检测Magisk的存在，并且自那时以来，Magisk已进行了更新以应对此类逃避检测的方法。 可以在流程的安装点找到一个这样的线索。
Linux Procfs (Linux Procfs)
Before elaborating further on the root detection and evasion methods, let’s briefly refresh our knowledge of the Linux Process File Systems, or “procfs”. Procfs is a special filesystem maintained by the kernel that contains information about processes and other system resources, and resides in /proc. Every process that is currently running will have a corresponding directory in /proc referenced by its process id (PID). Hence, a running process with the PID of “1234” will have a directory in /proc/1234 that presents information about itself, such as status, memory, and thread information. One such piece of information available here is mount information, which resides in /proc/<PID>/mounts. This shows the mount points visible to the process.
在进一步详细介绍根检测和规避方法之前，让我们简要地刷新一下对Linux Process File Systems或“ procfs”的了解。 Procfs是由内核维护的特殊文件系统，它包含有关进程和其他系统资源的信息，并且位于/proc 。 当前正在运行的每个进程都将在/proc中通过其进程ID(PID)引用相应的目录。 因此，PID为“ 1234”的正在运行的进程将在/proc/1234中具有一个目录，该目录显示有关其自身的信息，例如状态，内存和线程信息。 此处提供的此类信息之一是安装信息，它位于/proc/<PID>/mounts 。 这显示了该过程可见的安装点。
In Linux, different processes may see different mount points due to OS restrictions. For example, a process may be restricted to a subtree of the filesystem tree because of the chroot command. In other words, a “chrooted” process will not see mount points outside its root. The mount points in procfs, therefore, show the list of paths that are visible to the running process.
在Linux中，由于操作系统限制，不同的进程可能会看到不同的挂载点。 例如，由于chroot命令，进程可能仅限于文件系统树的子树。 换句话说，“ chroot”进程将不会在根目录之外看到挂载点。 因此，procfs中的安装点将显示正在运行的进程可见的路径列表。
输入Magisk隐藏 (Enter Magisk Hide)
Magisk Hide is a built-in module within Magisk that attempts to evade root detection for selected apps. It allows fine-grained control of which apps to hide Magisk from, and is configured through the Magisk Manager app, which is installed as part of the Magisk rooting process.
Magisk Hide是Magisk中的内置模块，它试图逃避所选应用程序的根目录检测。 它允许对要隐藏Magisk的应用程序进行细粒度的控制，并通过Magisk Manager应用程序进行配置，该应用程序是在Magisk生根过程中安装的。

Magisk Hide in Magisk Manager

Magisk隐藏在Magisk Manager中

Once enabled, root status should theoretically not be visible to the selected apps. In other words, the apps will continue to function as if they are installed in a non-rooted device.
启用后，根状态在理论上应该对所选应用程序不可见。 换句话说，这些应用程序将继续运行，就像安装在非root用户的设备中一样。
To understand how root detection works, we need to delve into how Magisk Hide works behinds the scenes.
要了解根检测的工作原理，我们需要深入研究Magisk Hide在幕后的工作方式。
As mentioned earlier, the Linux procfs tracks the state of all running processes, including the mount information. Since Android uses the Linux kernel, this feature exists here as well.
如前所述，Linux procfs跟踪所有正在运行的进程的状态，包括安装信息。 由于Android使用Linux内核，因此此功能也存在。
Let’s look at the differences between an app’s mount information when Magisk Hide is disabled as compared to when it is enabled. In this case, we are looking at the “Damn Insecure and Vulnerable” App, or DIVA.
让我们看看禁用Magisk Hide时与启用时相比，应用程序的安装信息之间的差异。 在这种情况下，我们正在研究“该死的不安全和易受攻击的”应用程序或DIVA。
Here is DIVA’s mount information when Magisk Hide is disabled:
这是禁用Magisk Hide时DIVA的安装信息：

DIVA’s mount information when Magisk Hide is disabled

禁用“ Magisk Hide”时DIVA的安装信息

Now, here it is when Magisk Hide is enabled:
现在，这是启用Magisk Hide的时间：

DIVA’s mount information when Magisk Hide is enabled

启用“ Magisk Hide”时DIVA的安装信息

As you can see, Magisk Hide unmounts the Magisk specific paths and /sbin (boxed up in red), from the app process. This prevents apps scanning for the presence of these paths from detecting Magisk.
如您所见，Magisk Hide从应用程序进程中卸载了Magisk特定的路径和/sbin (以红色框出)。 这样可以防止扫描这些路径的应用程序检测到Magisk。
The /proc/<PID> directory is dynamic, which is to say that the directory will only exist for the duration that the process is running. As such, Magisk will need to know when the app process starts in order to unmount the paths right at this point. Any later and the root detection may kick in and defeat Magisk Hide.
/proc/<PID>目录是动态的，也就是说，该目录仅在进程运行期间存在。 因此，Magisk需要知道应用程序启动的时间，以便此时卸载路径。 稍后，根检测可能会生效并击败Magisk Hide。
Now, the question is, how does Magisk know when an app process starts?
现在的问题是，Magisk如何知道应用程序进程何时开始？
There are several ways of detecting when a process starts in Android. Here are some possibilities.
有几种检测进程何时在Android中启动的方法。 这里有一些可能性。
Monitoring logcat 监控日志猫
Logcat is a command line tool that dumps a log of system messages. It is similar to the Linux dmesg, except it displays both system and application logs. When an app process starts, Android dumps a series of log messages. For example, the following log message appears in logcat when the DIVA is started using the Android launcher:
Logcat是一个命令行工具，用于转储系统消息日志。 它与Linux dmesg相似，但它同时显示系统和应用程序日志。 应用程序启动后，Android会转储一系列日志消息。 例如，当使用Android启动器启动DIVA时，以下日志消息出现在logcat中：

System log when DIVA app is launched

启动DIVA应用程序时的系统日志

Additionally, we can filter out process start system log messages by using am_proc_startfilter, which then yields the following output when the DIVA is started:
此外，我们可以使用am_proc_startfilter过滤掉进程启动系统日志消息，然后在启动DIVA时产生以下输出：

Logcat with am_proc_start filter when DIVA app is launched

启动DIVA应用程序时，带有am_proc_start过滤器的Logcat

By monitoring the logs, one can detect am_proc_start events in order to deduce when an app process starts. Due to the overheads required to constantly monitor the system logs, however, this method is very slow.
通过监视日志，可以检测到am_proc_start事件，以便推断应用程序进程何时启动。 但是，由于需要经常监视系统日志的开销，因此此方法非常慢。
inotify 声化
Linux has a feature called inode notify (inotify) that allows filesystems to notice changes to themselves, and report those changes to applications. Whenever an app is started, its corresponding APK file will be accessed from the filesystem. We can, therefore, use inotify to detect open() syscalls to the target APKs to detect app process starts.
Linux具有称为inode notify( inotify )的功能，该功能允许文件系统注意到自身的更改，并将这些更改报告给应用程序。 每当启动应用程序时，就会从文件系统访问其相应的APK文件。 因此，我们可以使用inotify来检测对目标APK的open()系统调用，以检测应用程序启动的过程。
Ptrace 跟踪
Since all Android app processes are forked from zygote, we can also monitor zygote by attaching to it with ptrace and stepping through all fork events in order to detect forks of app processes.
由于所有Android应用程序进程都是从合子派生的，因此我们也可以通过使用ptrace附加到合子并逐步检查所有fork事件来检测合子，以检测应用进程的派生。
So, which method does Magisk use to detect app process starts?
那么，Magisk使用哪种方法来检测应用程序进程启动？
The answer is “All of them”, depending on which Magisk version you’re using.
答案是“全部”，这取决于您所使用的Magisk版本。
Magisk started by using the Logcat monitoring method, presumably because it was a well-known and easy way of accomplishing the goal. As mentioned earlier, Logcat has its downsides: it is slow due to the overheads required for constant log monitoring. Also, its success depends on Magisk reacting fast enough to hijack the process before root detection is performed — essentially creating a race condition — which could in turn lead to inconsistent results.
Magisk从使用Logcat监视方法开始，大概是因为它是实现目标的众所周知且简单的方法。 如前所述，Logcat有其缺点：由于持续进行日志监视所需的开销，它的速度很慢。 同样，其成功取决于Magisk做出足够快速的React以在执行根检测之前劫持该过程-本质上造成了竞争状况-进而可能导致结果不一致。
In early 2019, Magisk Hide was completely reworked to use the inotify method. The advantage gained is that there is now much fewer overheads: instead of polling logcat, it just sits in the background and is notified by inotify whenever an app starts. The race condition problem, however, still applies as Magisk is still just reacting to app process starts.
在2019年初，Magisk Hide进行了彻底改造以使用inotify方法。 所获得的好处是现在的开销要少得多：它不需要轮询logcat，而是位于后台，并在应用程序启动时通过inotify通知。 但是，由于Magisk仍只是对应用程序启动过程做出React，因此竞争条件问题仍然存在。
Shortly after experimenting with inotify, Magisk Hide moved to the zygote ptrace method. This method is more reliable because of 2 reasons. Firstly, all zygote forks will be notified, meaning no polling overhead. Secondly, subsequent thread spawning from child processes are also closely monitored to find the earliest point to identify what the process will eventually be. Essentially, this can target a process before it even starts to run, eliminating the race condition problem.
在尝试了inotify之后不久，Magisk Hide转移到了zygote ptrace方法。 由于两个原因，此方法更可靠。 首先，将通知所有合子叉子，这意味着没有轮询开销。 其次，还密切监视子进程产生的后续线程，以找出最早的点，以识别该进程最终将是什么。 本质上，这可以在进程甚至开始运行之前就将其定为目标，从而消除了竞争条件问题。
游戏结束进行根检测？ (Game over for root detection?)
So far, it seems like zygote ptrace solves the problem of the previous methods, so is it “ggkthx” for root detection? Not so fast…
到目前为止，似乎zygote ptrace解决了以前方法的问题，因此用于根检测的“ ggkthx”吗？ 没那么快…
While Zygote ptrace is supposedly much faster and more reliable, it relies on the assumption that zygote is the one forking a new app process.
尽管Zygote ptrace据说更快，更可靠，但它依赖于这样的假设，即合子是派生新应用程序进程的人。
As it turns out, this assumption does not always hold.
事实证明，这种假设并不总是成立。
魔皮和孤立的过程 (Magisk Hide and isolated processes)
When an app spawns a service through Android APIs, the new service can run in the same process context, or a different one, depending on the android:process attribute in the Android Manifest. For the latter, the service’s parent process is usually zygote, and the process runs with the same process name as the main app process, but with a suffix indicated in the Android Manifest. For a long time, Magisk was unable to hide the mount points from remoted services, leading to root detection methods leveraging on this fact to detect Magisk. Eventually, Magisk Hide started to hide the paths from this remote service.
当应用通过Android API生成服务时，新服务可以在相同的流程上下文中运行，也可以在不同的流程上下文中运行，具体取决于Android清单中的android:process属性。 对于后者，该服务的父进程通常是合子，并且该进程以与主应用程序进程相同的进程名称运行，但在Android清单中标有后缀。 长期以来，Magisk无法隐藏远程服务的挂载点，从而导致根检测方法利用这一事实来检测Magisk。 最终，Magisk Hide开始隐藏此远程服务中的路径。
Android also introduced the concept of Isolated Process in version 4.1, where such services run under a special process that is isolated from the rest of the system and has no permissions of its own. This can be configured in the Android Manifest with the android:isolatedProcess attribute. The only way to communicate with it is through service APIs such as binding and starting. In this case, the zygote ptrace method apparently cannot reliably detect isolated processes that are spawned by a parent app. This is shown in the two mount information screenshots below where Magisk Hide was enabled for the app. The following figure shows the mount information of the main app process.
Android在4.1版中还引入了隔离进程的概念，其中此类服务在与系统其余部分隔离的特殊进程下运行，并且没有自己的权限。 可以在Android Manifest中使用android:isolatedProcess属性进行配置。 与之通信的唯一方法是通过服务API(例如绑定和启动)。 在这种情况下，zygote ptrace方法显然无法可靠地检测由父应用程序生成的隔离进程。 这显示在下面的两个安装信息屏幕快照中，其中为该应用程序启用了Magisk Hide。 下图显示了主应用程序进程的安装信息。

Mount information of the main process

主要过程的挂载信息

The next figure shows the mount information of the isolated process that was started by the main process.
下图显示了由主进程启动的隔离进程的安装信息。

Mount information of isolated process

挂载隔离进程的信息

As you can see, the familiar Magisk specific paths and /sbin paths (boxed up in red) appear once again in the isolated process mount information. Leveraging on this fact, root detection can be performed by spawning an isolated process from the main app and then checking that process’s mount information to detect the tell-tale paths.
如您所见，熟悉的Magisk特定路径和/sbin路径(以红色框出)再次出现在隔离的进程安装信息中。 利用这一事实，可以通过从主应用程序生成隔离的进程，然后检查该进程的安装信息以检测提示路径来执行根检测。
Ironically, the older logcat monitoring method catches this, as shown by the 2 am_proc_start entries in logcat.
具有讽刺意味的是，较旧的logcat监视方法捕获了此问题，如logcat中的2 am_proc_start条目所示。

am_proc_start logcat entries for isolated process

am_proc_start隔离进程的logcat条目

Because of this, Magisk v18 and below are more resistant to certain forms of root detection than versions 19 and newer.
因此，与版本19及更高版本相比，Magisk v18及更低版本对某些形式的根目录检测更具抵抗力。
You may have heard of Google’s SafetyNet attestation. In principle, SafetyNet was not designed to perform root detection, but rather to ensure that devices pass Google’s Android Compatibility Test Suite (CTS). This excludes cheap tablets from a sweatshop factory that were never pre-installed with Google’s apps, as well as rooted devices. Therefore, many Android developers, such as Niantic (the makers of Pokémon Go) use it to detect rooted devices. Despite it coming straight from Google, SafetyNet has not been foolproof. Magisk was able to successfully evade SafetyNet attestation by creating an isolated “safe environment” for the SafetyNet detection process and create a tampered SafetyNet result to satisfy the software attestation.
Google has since taken off their kid gloves and made it explicitly harder for rooted devices, by implementing hardware attestation. What this means is that some hardware-backed verification will be performed; such verification is not easily spoofed with software.
SafetyNet hardware attestation has not been officially rolled out yet, though several devices have apparently already been affected over the past few months. Once fully deployed, this will present a major challenge to root evasion tools such as Magisk Hide, which will have to figure out novel ways of defeating it.
SafetyNet硬件认证尚未正式推出，尽管在过去几个月中显然已经影响了几台设备 。 一旦完全部署，这将对根逃避工具(例如Magisk Hide)提出重大挑战，后者必须找出击败它的新颖方法。
结论 (Conclusion)
As reverse engineers and penetration testers, we typically prefer the path of least resistance. Rather than reverse engineering the app binary, figuring out where root detection is happening, and then tampering with the binary or runtime instance to bypass it, we use tools that can do all that for us automatically, thereby freeing up our time for more interesting attacks. In this case, despite the slower performance, Magisk v18 seems to be more reliable in evading root detection. More importantly, because Magisk v18 does not involve ptracing an app process, it allows us to perform runtime tampering using debuggers or instrumentation frameworks such as Frida, which also require ptracing the app process.
作为反向工程师和渗透测试人员，我们通常首选阻力最小的路径。 我们不是对应用程序二进制文件进行反向工程，弄清楚发生根检测的位置，然后篡改二进制文件或运行时实例以绕过二进制文件，而是使用可以自动为我们完成所有操作的工具，从而腾出时间进行更有趣的攻击。 在这种情况下，尽管性能降低，但Magisk v18在逃避根检测方面似乎更可靠。 更重要的是，由于Magisk v18不涉及跟踪应用程序进程，因此它使我们能够使用调试器或工具框架(例如Frida)执行运行时篡改，这也需要跟踪应用程序进程。
Unfortunately, this is a known and acknowledged problem of Magisk, and its sole developer is not keen on fixing this problem. However, as this is ultimately a cat and mouse game, and Magisk is an open source project, it may not be too long before another Magisk module is released to fix this problem. Then, the ball will once again be returned the root detection developers’ court.
不幸的是，这是Magisk的一个已知且公认的问题，它的唯一开发者并不热衷于解决此问题。 但是，由于这最终是猫和老鼠的游戏，而Magisk是一个开源项目，因此发布另一个Magisk模块来解决此问题可能不会太久。 然后，球将再次被根探测开发人员法院退还。
Google SafetyNet hardware attestation is also a major hurdle for root evasion, and it remains to be seen if this can be overcome.
For mobile app developers, understand that root detection, while important, cannot be the only mitigating control that is protecting your apps. Defence in depth is especially important in mobile apps since the app binary is installed on uncontrolled devices, of which users — including attackers — have full access and control. It is only a matter of time before client-side protections are defeated. Evading root detection is just the first step.
对于移动应用程序开发人员，请了解根检测虽然很重要，但它并不是保护您的应用程序的唯一缓解控件。 深度防御在移动应用程序中尤其重要，因为应用程序二进制文件安装在不受控制的设备上，用户(包括攻击者)拥有完全的访问和控制权。 取消客户端保护只是时间问题。 规避根检测只是第一步。

翻译自: https://medium.com/csg-govtech/diving-down-the-magisk-rabbit-hole-aaf88a8c2de0

magisk

展开全文
• Magisk-v20.4 MagiskManager-v7.5.0 Magisk-uninstaller-20200323
• 您在寻找适用于Android 2021的Magisk App或Magisk Manager应用程序的最新版本吗？ 是的，那么此扩展名适合您。 使用此chrome扩展程序，您可以直接从官方开发人员Topjohnwu直接访问最新的Zip文件和管理App文件。 我们...
• Magisk的apk管理软件，用于小米/红米手机获取root根目录权限，相关文章介绍见：https://blog.csdn.net/weimeig/article/details/105804198
• 大家好，我是根据其他开发人员的资源通过改进或提高效率来为magisk制作模块的。
• Magisk &amp;amp;&amp;amp; Magisk Manager 下载： https://github.com/topjohnwu/Magisk/releases 截图： google 手机 root 教程 ......
Magisk && Magisk Manager 下载：
https://github.com/topjohnwu/Magisk/releases
截图：
或者：
https://www.bilibili.com/read/cv1055376/
展开全文
• UnblockNeteaseMusic Magisk模块 这是用于Magisk的UnblockNeteaseMusic 本模块已包含 安装 从release下载，然后在Magisk Manager中安装 使用 使用前 1.安装busybox 2.确保您的设备有curl命令（更新脚本会使用到）3....
• Magisk可以ROOT您的设备，以及标准的常见修补程序。 它包含一个超强大的通用无系统接口，允许无限的潜力！你也可以通过各种模块来实现对你的手机各种定义，基本可以替代SuperSu超级权限!
• magisk、edxposed安装 ，抓包工具，过SSL校验
• 想要使用 Magisk 无系统地和系统地更改您的 android 系统字体吗？ 我们为您提供完美的解决方案。 我们的模块适用于最新的 Magisk 并支持 Android 10。 我们目前为您准备了英语（作为系统范围）和孟加拉语字体模块。 ...
• Magisk（俗称面具）免费开源的安卓系统ROOT工具，目前获取最新安卓版ROOT权限有效方式，其独特的挂载机制(systemless)，通过Magisk管理器刷入Magisk补丁可以不修改系统实现超级权限且不影响OTA。
• Magisk是xda作者topjohnwu制作的一款能够root设备，修改boot image或者添加文件到/data 以及/cache目录，从而在不修改系统的情况下实现一些系统性的功能
• Magisk-v21.1.zip
• 安卓手机Root工具，magisk,超级用户，模块管理。
• Welcome to the official Magisk Release / Announcement thread! Installing Magisk will give you ROOT, a super powerful Systemless Interface, Magisk Modules support, and hide from tons of integrity ...
• Magisk是一套用于自定义Android的开源工具，支持高于Android 4.2的设备。它涵盖了Android自定义的基本部分：root，启动脚本，SELinux补丁，AVB2.0 / dm-verity / forceencrypt删除等。 以下是一些功能亮点： ...
• OpenGMS_Magisk 适用于Magisk（@topjohnwu）用户的OpenGApps pico 对于中文（中国大陆）用户/简体中文介绍 欢迎使用GMS_Magisk项目及其下属的所有文件包，它们基于OpenGApps为各个Android系统版本所提供的Pico版...
• magisk 17.2 卡刷包和反安装包
• Magisk-v20.4版本搬运，包含installer和uninstall The Magisk Manager is completely a different application compared to the previous crappy app. It has now packed with features, and it is now part of the ...
• ## Magisk模块编写

万次阅读 2019-08-09 00:44:13
0x00 magisk介绍 Magisk 本质上是一种文件挂载系统。我们大多数时候所接触到的那个图标为面具的应用，其实只是我们与之发生各种交互行为的「媒介」。 首先简单介绍一下magisk的原理。magisk做的事情是通过boot中创建...
0x00 magisk介绍
Magisk 本质上是一种文件挂载系统。我们大多数时候所接触到的那个图标为面具的应用，其实只是我们与之发生各种交互行为的「媒介」。
首先简单介绍一下magisk的原理。magisk做的事情是通过boot中创建钩子，进而bind mount构建出一个在system基础上能够自定义替换，增加以及删除的文件系统，实际上并没有对 system 分区进行修改（即 systemless 接口，以不触动 system 的方式修改 system）。所有操作都在启动的时候完成，启动过程中magisk所做的事情： 1.准备阶段，将会把/data/magisk.img 挂到/magisk。同时它会遍历magisk目录中的模块是否为启用状态，并且记录。 2.创建骨架system文件系统(由于bind mount 必须要有一个目标文件才能进行bind mount)，全部由mkdir 和touch构建 3.将每个标记为启用的/magisk/$MODID/system中文件bind mount到骨架系统 4.执行自定义模块中的脚本 5.遍历骨架中剩余没有被mount的文件，通过真正的system文件进行bind mount。 因为它不会以任何方式改变您的system分区。这意味着您仍然可以安装官方OTA更新，而不会丢失root。 然后Magisk能实现哪些功能？ 1.集成了类似SuperSU的root管理功能（MagiskSU） 2.类似于Xposed，可以安装使用Magisk相关模块 3.Magisk Hide（对单个应用隐藏 Magisk 的 root 权限） 4.日志功能 5.Systemless hosts（为广告屏蔽应用提供Systemless hosts支持） 6.SafetyNet 检查功能 0x01 magisk 模块的本质，是将原本需要玩家繁复操作的玩机过程与 Magisk「不改动系统」（Systemless-ly） 的特性结合在一起，并进行打包和分发。 知道模块可以从哪里得到后，我们要讨论的就是管理问题。管理主要是刷入和卸载两方面。广义地说，任何能给手机刷入 .zip 包的工具都可以进行模块的刷入，比如 TWRP、Magisk Manager 和 Franco Kernel Manager 等，操作也都简单得类似，刷入、重启生效。 谷歌服务中的 SafetyNet 安全性测试。想要通过 SafetyNet 测试，最好使用原厂系统，或者是值得信赖的第三方 ROM 正式版（也就是 Official Builds），以减少不必要的麻烦。 如果是 basic integrity 这一项没有通过认证，那说明你遇到了大麻烦：试着开启「Magisk 核心功能模式」或者卸载所有模块，如果还是没有通过，那么你可能需要换一个系统或者第三方 ROM 了。 如果是 ctsProfile 这一项没有通过，那说明你的 ROM 没有通过其兼容性测试，一些 beta 版本或者国内厂商的 ROM 可能出现这种问题。这时我们下载使用 MagiskHide Props Config 这个模块往往能够解决问题。 0x02 magisk模块编写 以MagiskTrustUserCerts为例来分析magisk模块如何编写 1).在init执行时，执行自定义的命令。 2).以overlay的形式覆盖系统文件 3).修改Android Property属性。 以7.0以上的抓包需求为例： 从Android Nougat开始，默认情况下，应用不再信任用户证书。开发人员仍然可以通过在应用程序的AndroidManifest.xml文件中配置networkSecurityConfig属性来选择接受用户证书，但默认情况下，它们不再受信任。 一个完整的magisk模块整体如下： ➜ tree MagiskTrustUserCerts MagiskTrustUserCerts ├── META-INF │ └── com │ └── google │ └── android │ ├── update-binary │ └── updater-script ├── common │ ├── post-fs-data.sh │ ├── service.sh │ └── system.prop ├── config.sh └── module.prop  安装流程就是将上面的内容打包成MagiskTrustUserCerts.zip然后push到sdcard。 最后在magisk的APP上点击增加模块，找到该zip刷入即可。 分析模块的基本内容： 一： 其中module.prop里面存放着magisk模块的基本信息 id=trustusercerts name=Always Trust User Certificates version=v0.3 versionCode=1 author=Jeroen Beckers (NVISO.be) description=This module adds all installed user certificates to the system trust store. minMagisk=1500  二： config.sh文件里设置要执行的脚本。可以看到开启了Mount和执行post-fs-data 脚本 # Set to true if you need to enable Magic Mount # Most mods would like it to be enabled AUTOMOUNT=true # Set to true if you need post-fs-data script POSTFSDATA=true  三： post-fs-data.sh里面就是执行的内容。可以看到脚本每次启动就把用户证书移动到移动目录下： #!/system/bin/sh # Please don't hardcode /magisk/modname/... ; instead, please use$MODDIR/...
# This will make your scripts compatible even if Magisk change its mount point in the future
MODDIR=${0%/*} mkdir -p$MODDIR/system/etc/security/cacerts
rm $MODDIR/system/etc/security/cacerts/* cp -f /data/misc/user/0/cacerts-added/*$MODDIR/system/etc/security/cacerts/

# This script will be executed in post-fs-data mode

总结模块的编写流程：
# 1. Place your files into system folder (delete the placeholder file)
# 2. Fill in your module's info into module.prop
# 3. Configure the settings in this file (common/config.sh)
# 4. For advanced features, add shell commands into the script files under common:
#    post-fs-data.sh, service.sh

隐藏自身
Magisk隐藏自身的实现 1.切入目标APP进程的mount space, 将Magisk相关的所有文件和目录进行unmount操作。
2.对Magisk需要用到的unix domain socket name, Android system service name进行随机化,也支持对自身管理器的包名随机化。
0x03 其他
tips1: 安装MM 管理器，不过大部分模块都没什么问题，不怕一万，就怕万一，如果刷错了开不了机，就用MM管理器卸载模块就行了。具体操作 就是进入第三方rec 进入高级 终端命令 输入data/media/mm 确定然后按步骤卸载或停用模块就行了。 参考：https://www.52pojie.cn/thread-881414-1-1.html
tips2：
magisk常用的模块 链接：https://pan.baidu.com/s/1m4-cCckX9EFK5ES8sNJN-g 提取码：zx41
frida开机自启动的magisk模块：省去每次命令行交换 https://github.com/AeonLucid/MagiskFrida
伪造设备的magisk模块 https://github.com/AndroPlus-org/magisk-module-device-faker/blob/master/config.sh
0x04 如何检测magisk
Pokemon Go 会检查/sdcard/ 下是否有MagiskManager 这个目录
Check the installed magisk version
MIN_VER=grep_prop minMagisk $INSTALLER/module.prop [ ! -z$MAGISK_VER_CODE -a $MAGISK_VER_CODE -ge$MIN_VER ] || require_new_magisk
MODID=grep_prop id $INSTALLER/module.prop MODPATH=$MOUNTPATH/\$MODID

参考： https://topjohnwu.github.io/Magisk/
展开全文

...