Android10以后，Android系统限制了System分区的修改，结果就是，即使你i是自己编译的Android系统，即使是有做高的root权限，你依然无法挂载System分区并对其内容进行修改,尽管网上有各种帖子说可以使用mount -o rw,remount /,但这并没有解决开发者的实际问题。这意味着传统的万能root出现局限性，为了解决这个问题Magisk的作者Top John Wu在推文中确认了这一问题，并确认了导致该问题的原因是谷歌在Android10以后引入了EXT4 共享块，而这个共享块和其他分区的区别在于根本没有可用空间的概念，所以也就没办法挂在为可读写。为了解决这个问题，Magisk团队发现可以重定向文件读取时的文件路径来实现修改的目的，这似乎和我们Hook有相似之处，而这个，被Top John Wu称为Systemless（无System分区）而由此概念引申出来的Root方案，也叫做systemless root。。

Magisk系统包含上层的控制App以及下层的可执二进制文件以及一些相关配置或者数据文件。我们从底层往上层看会更容易明白Magisk的功能构成和架构思维。

首先，Magisk 会挂载一个tmpfs目录来存放一些临时数据。在Android11以下，这个目录时sbin，从 Android 11 开始，/sbin文件夹可能不存在，那么 Magisk 会在/dev下随机创建一个文件夹并将其作为Magisk的Root文件夹。

放在sbin或者dev下的原因是：/sbin或/dev目录非su权限不可读，因此第三方APP无法检测。

我们可以通过在adb shell下使用magisk --path打印当前Magisk使用的目录：

接下来我们看下这个目录下都有什么文件，以及如何解读这些文件；

可以看到除了magiskpolicy以外，其他都属于root用户组。

下面的注释说得很清楚了，直接看代码就好了。

下面是/dev/bNpnxq/.magisk/mirror列出的文件列表，对应block的设备节点

不要被目录名迷惑，虽然是adb实际上是Magisk的一个应用目录，这个目录里面保存了Magisk的一些数据和配置文件，安装的模块也是被保存在这里，之所以使用这个目录是有它的优势的：

这个目录下包含以下文件（配合Magisk启动流程来看更容易理解）：

Magisk启动分为以下几步：Pre-Init，post-fs-data，late_start，Resetprop，这几个启动流程我们可以对应上Android系统启动，下面我详细说明一下：

使用 magiskinit替换init并执行：

post-fs-data 过程在 /data 解密并挂载后触发。首先会启动守护进程 magiskd ，执行post-fs-data脚本，这个时候模块文件就挂载完毕了。

在启动过程的后期, late_start 类会被触发，开启Magisk “service” 模式。服务脚本会在这个模式下执行。

到这里Magisk就完全启动了，上面就是App了，他只是负责一些配置的修改和状态显示，以及调用前面启动的服务和程序来执行，大概就是这样的过程。

正常来说，只有init能修改系统属性，非root进程只能读取无法修改。在有root时可以通过由init提供的property_service发送请求（比如adb可以使用setprop命令）来实现修改，但是通过这种方式不能修改和删除只读属性（以ro.开头的属性，例如ro.build.product），除非修改系统源码。

resetprop 通过提取和patch AOSP中和系统属性相关的源代码，从而允许直接修改属性区域（prop_area），不再需要通过property_service来修改系统属性（实际上这个功能和Github上开源的mprop的原理类似）。不过也正是因为绕过了property_service,所以需要有下面的注意事项：

触发事件的修复：由于绕过了property_service，所以当属性改变时，在*.rc脚本中注册的on property:foo=bar 动作事件不会被触发（在init语言中这个叫做属性触发器）。但Mgisk考虑到了这点，所以默认情况下 resetprop设置属性时会和setprop一样，它会触发事件（通过先删除属性再通过property_service来设置属性来实现）。如果不想触发动作事件，可以使用-n参数禁用。

实现重启也保留修改：持久属性（以persist.开头的属性，例如persist.sys.usb.config）在 prop_area 和 /data/property都有存储。默认情况下，删除持久属性时不会把它从持久化存储中移除，也就是说下次重启时持久属性会被恢复； getprop在不会从持久化存储中读取持久属性。但是对于resetprop ，可以使用-p参数，这样删除时会同时将该属性从 prop_area 和 /data/property中移除，读取时也会同时从prop_area 和 持久化存储中读取。

Magisk通过patch原来的sepolicy来确保Magisk的操作可以安全地执行。新的magisk域权限很高， magiskd和所有root shell都会在该域中运行。magisk_file是一个新的文件类型，该文件类型允许每一个域访问（不受限制的文件上下文），下面这个magisk文件用的就是magisk_file上下文。

在 Android 8.0之前，所有被su允许的客户端域都可以直接连接到 magiskd 并且与守护进程连接，从而获得远程的root shell访问。Magisk同时也需要释放一些ioctl 操作以便root shell可以正常工作。

但是，在Android 8.0及以后，为了避免Android沙箱中对规则的放松，Magisk实现了一个新的SELinux模型。 magisk二进制文件被标记为magisk_exec文件类型，进程在以su client的域运行时执行 magisk二进制文件（包括su命令）时会被中转为 magisk_client（通过使用一个type_transition规则）。

规则严格限制了magisk域的进程才被允许归属于magisk_exec文件类型。不再允许直接通过socket连接至magiskd；唯一的访问该守护进程的方式就是通过一个magisk_client 进程。这样做确保了沙箱的完整性，让Magisk专用规则从其它规则中分离。如下magisk64：

关于更加详细规则可以在 magiskpolicy/rules.cpp中找到。