• Magisk

    2021-02-23 13:57:39
  • Magisk安装包

    2019-04-04 14:18:58
    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

    2019-01-07 10:11:05
    Magisk是xda作者topjohnwu制作的一款能够root设备,修改boot image或者添加文件到/data 以及/cache目录,从而在不修改系统的情况下实现一些系统性的功能,最近一段时间Magisk的更新较为频繁,而最近一次的版本更新更...
  • Magisk32.zip

    2021-01-21 14:00:46
  • magisk-v16.0

    2018-07-25 12:32:45
  • magisk_潜水Magisk兔子洞

    2020-07-29 05:23:41
    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 ...


    [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用户几乎可以访问整个设备,从而违反了应用程序沙箱化的原则。

    Image for post
    Application sandboxing in 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生根过程中安装的。

    Image for post
    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的安装信息:

    Image for post
    DIVA’s mount information when Magisk Hide is disabled
    禁用“ Magisk Hide”时DIVA的安装信息

    Now, here it is when Magisk Hide is enabled:

    现在,这是启用Magisk Hide的时间:

    Image for post
    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?


    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中:

    Image for post
    System log when DIVA app is launched

    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:


    Image for post
    Logcat with am_proc_start filter when DIVA app is launched

    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.


    So, which method does Magisk use to detect app process starts?


    The answer is “All of them”, depending on which Magisk version you’re using.


    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。 下图显示了主应用程序进程的安装信息。

    Image for post
    Mount information of the main process

    The next figure shows the mount information of the isolated process that was started by the main process.


    Image for post
    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条目所示。

    Image for post
    am_proc_start logcat entries for isolated process

    Because of this, Magisk v18 and below are more resistant to certain forms of root detection than versions 19 and newer.

    因此,与版本19及更高版本相比,Magisk v18及更低版本对某些形式的根目录检测更具抵抗力。

    那SafetyNet呢? (What about SafetyNet?)

    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的SafetyNet认证。 原则上,SafetyNet并非旨在执行根目录检测,而是确保设备通过Google的Android兼容性测试套件(CTS)。 这不包括血汗工厂工厂从未预装过Google应用程序的廉价平板电脑以及有根设备。 因此,许多Android开发人员,例如Niantic(神奇宝贝Go的制造商)都使用它来检测有根设备。 尽管它直接来自Google,但SafetyNet并非万无一失。 通过为SafetyNet检测过程创建一个隔离的“安全环境”,Magisk能够成功规避SafetyNet认证,并创建篡改后的SafetyNet结果来满足软件认证。

    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.

    自那以后,Google实施了硬件认证 ,脱掉了孩子们的手套,使植根的设备变得更加困难。 这意味着将执行一些硬件支持的验证。 这种验证不容易被软件欺骗。

    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.

    Google SafetyNet硬件认证还是逃避根源的主要障碍,是否可以克服这一点还有待观察。

    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-v20.4 MagiskManager-v7.5.0 Magisk-uninstaller-20200323
  • 您在寻找适用于Android 2021的Magisk App或Magisk Manager应用程序的最新版本吗? 是的,那么此扩展名适合您。 使用此chrome扩展程序,您可以直接从官方开发人员Topjohnwu直接访问最新的Zip文件和管理App文件。 我们...
  • magisk.apk

    2020-04-28 01:41:43
  • 大家好,我是根据其他开发人员的资源通过改进或提高效率来为magisk制作模块的。
  • Magisk字体替换模块

    2018-10-23 14:08:28
    magisk字体模块,用magisk框架刷入。替换系统字体。 中文替换为宁静之雨大神的筑紫A丸,英文替换为Google Sans
  • Magisk && Magisk Manager 下载

    千次阅读 2018-11-14 15:40:05
    Magisk &amp;amp;&amp;amp; Magisk Manager 下载: https://github.com/topjohnwu/Magisk/releases 截图: google 手机 root 教程 ......
  • UnblockNeteaseMusic Magisk模块 这是用于Magisk的UnblockNeteaseMusic 本模块已包含 安装 从release下载,然后在Magisk Manager中安装 使用 使用前 1.安装busybox 2.确保您的设备有curl命令(更新脚本会使用到)3....
  • Magisk-v18.1

    2019-03-21 14:22:39
    Magisk可以ROOT您的设备,以及标准的常见修补程序。 它包含一个超强大的通用无系统接口,允许无限的潜力!你也可以通过各种模块来实现对你的手机各种定义,基本可以替代SuperSu超级权限!
  • magisk+edxposed.zip

    2021-03-03 21:08:55
    magisk、edxposed安装 ,抓包工具,过SSL校验
  • 想要使用 Magisk 无系统地和系统地更改您的 android 系统字体吗? 我们为您提供完美的解决方案。 我们的模块适用于最新的 Magisk 并支持 Android 10。 我们目前为您准备了英语(作为系统范围)和孟加拉语字体模块。 ...
  • Magisk-v21.4.zip

    2021-01-26 07:26:45
  • Magisk安装包V18.1

    2019-03-08 21:04:03
    Magisk是xda作者topjohnwu制作的一款能够root设备,修改boot image或者添加文件到/data 以及/cache目录,从而在不修改系统的情况下实现一些系统性的功能
  • Magisk-v21.1.zip

    2021-01-01 11:11:17
  • 刷入magisk.zip

    2020-06-02 17:40:54
  • Magisk-v20.3.1.zip

    2020-03-17 11:57:00
    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-v21.2.zip

    2021-01-08 09:21:14
    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 v17.2.zip

    2021-09-23 21:58:27
    magisk 17.2 卡刷包和反安装包
  • Magisk-v20.4.zip

    2020-05-18 23:20:59
    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到骨架系统
    5.遍历骨架中剩余没有被mount的文件,通过真正的system文件进行bind mount。


    3.Magisk Hide(对单个应用隐藏 Magisk 的 root 权限)
    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模块编写



    3).修改Android Property属性。


    从Android Nougat开始,默认情况下,应用不再信任用户证书。开发人员仍然可以通过在应用程序的AndroidManifest.xml文件中配置networkSecurityConfig属性来选择接受用户证书,但默认情况下,它们不再受信任。


    ➜  tree MagiskTrustUserCerts
    ├── META-INF
    │   └── com
    │       └── google
    │           └── android
    │               ├── update-binary
    │               └── updater-script
    ├── common
    │   ├── post-fs-data.sh
    │   ├── service.sh
    │   └── system.prop
    ├── config.sh
    └── module.prop



    一: 其中module.prop里面存放着magisk模块的基本信息

    name=Always Trust User Certificates
    author=Jeroen Beckers (NVISO.be)
    description=This module adds all installed user certificates to the system trust store.

    二: config.sh文件里设置要执行的脚本。可以看到开启了Mount和执行post-fs-data 脚本

    # Set to true if you need to enable Magic Mount
    # Most mods would like it to be enabled
    # Set to true if you need post-fs-data script

    三: post-fs-data.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
    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
    # More info in the main Magisk thread


    # 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
    # 5. For changing props, add your additional/modified props into common/system.prop


    1.切入目标APP进程的mount space, 将Magisk相关的所有文件和目录进行unmount操作。

    2.对Magisk需要用到的unix domain socket name, Android system service name进行随机化,也支持对自身管理器的包名随机化。

    0x03 其他

    安装MM 管理器,不过大部分模块都没什么问题,不怕一万,就怕万一,如果刷错了开不了机,就用MM管理器卸载模块就行了。具体操作 就是进入第三方rec 进入高级 终端命令 输入data/media/mm 确定然后按步骤卸载或停用模块就行了。





    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`





1 2 3 4 5 ... 20
收藏数 1,604
精华内容 641