Magisk v31.1 发布：Android root 套件适配 Googlebook 与 HSUM，隐藏应用功能退场

导语：10 月 25 日,Android 定制套件 Magisk 推送 v31.1 BETA,正式把 Googlebook(Aluminium OS)纳入支持,并适配了 Android 的无头系统用户模式。有意思的是,它把”隐藏应用”和交互式 su 授权弹窗一起拆了——用户少折腾,安全团队却要重新校准检测思路。

v31.1 速览

先摆事实。Magisk v31.1 于 10 月 25 日凌晨推送,官方仓库至今 63,488 个 star、19,020 次 fork,主语言 Kotlin,许可证 GPL-3.0,项目从 2016 年 9 月一路活到了今天。

需要留意的第一件事:这一版是 BETA。GitHub Release 页面把 v31.1 标成了 prerelease,而上一个稳定版还是今年 2 月的 v30.7。尝鲜无妨,生产设备请老老实实待在 v30.7。

这一版最值得说的三件事

第一件,Googlebook 正式入列。 Googlebook OS(代号 Aluminium OS)是 Google 用 Android 替换 ChromeOS 的桌面系统,10 月 4 日正式发布,第一批设备来自五家 OEM。Magisk v31.1 对它给出了完整支持:自动为 Pixel 和 Googlebook 设备推荐官方固件下载,能直接给 Aluminium OS 的 recovery GPT 镜像打补丁,还能把补丁后的镜像直接写进已连接的 U 盘。官方安装文档里也新增了 Googlebook 专属章节。

第二件,HSUM 逼着 Magisk 改了授权模型。 为了支持 Googlebook,Magisk 不得不适配 Android 的 Headless System User Mode——在这种模式下 user 0 不再是那个坐在前台的交互式用户,而是纯粹的后台系统用户,真人用户跑在次级用户配置里。这一改动看着只是”用户模型变了”,实际上把 Magisk 很多年积累的假设全推翻了:过去那种”后台守护进程拦截到 root 调用、再弹个框问用户同不同意”的被动授权流,在 HSUM 下根本不成立,因为 adb shell 这类根本不属于任何前台用户会话。

于是 Magisk v31.1 把交互式 su 授权弹窗整个删掉了,superuser 权限改成在 Superuser 标签页里预先授权。顺带被拆掉的还有”隐藏应用”(包名重打包)功能和 stub 应用,Magisk 也不再在应用被卸载后自动把自己装回去。官方的说法很直白:交互式弹窗都不需要了,想藏就配置完策略和模块之后,把 Magisk 应用自己卸掉。

第三件,工程层面的扎实活。 这一版把各类镜像的补丁管线统一了——裸 img、OTA zip、factory image、Samsung Odin tar、Aluminium OS recovery GPT 都能走同一条流程;ChromeOS boot 镜像改为原生签名,不再依赖外部 futility;AVB 1.0 的 ECDSA 签名改用 ASN.1 DER 编码;重打包时保留 Samsung SignerVer02 签名;magiskboot 也能直接在 Linux 和 macOS 上原生构建了。

顺带复习:Magisk 到底做了什么

下面这张是官方 Logo,顺带把它的组件结构捋一遍——理解了这些,才能明白上面那些改动为什么重要。

Magisk 的核心是不改系统分区:它用 MagiskInit 接管启动流程,再用 Magic Mount 在运行时把修改过的文件”叠”上去,系统分区保持原样,卸载只需删掉几个文件。MagiskBoot 负责解包与重打包 boot/init_boot/vendor_boot 等镜像;MagiskSU 提供 su 命令与权限策略;Zygisk 则是那个最”扎手”的能力——通过 zygote 注入,让模块代码能加载进其他应用的进程空间;DenyList 负责给指定应用”隔离视图”,让它们看不见这些改动。

下载与安装

官方下载地址(已逐一验证可访问,均为 GitHub 官方 Release 资产):

v31.1(新,BETA)
https://github.com/topjohnwu/Magisk/releases/download/v31.1/Magisk-v31.1.apk

v30.7(当前稳定版)
https://github.com/topjohnwu/Magisk/releases/download/v30.7/Magisk-v30.7.apk

调试版(带额外日志,勿用于日常设备)
https://github.com/topjohnwu/Magisk/releases/download/v31.1/app-debug.apk

安装思路官方文档写得很清楚:先解锁 bootloader,装好 Magisk App,在首页看 “Result of Ramdisk” 判断该打哪个分区——有 ramdisk 就补 boot.img / init_boot.img / vendor_boot.img,没有就只能劫持 recovery.img。App 支持直接从存储选镜像、填一个 HTTPS 链接让它流式提取,或者一键拉取最新的 Pixel 官方固件;打好补丁后 adb pull 出来,用 fastboot 刷回对应分区即可。

安全提醒:只从 github.com/topjohnwu/Magisk 官方 Release 下载。搜”Magisk APK”会跳出一大堆第三方镜像站和下载站,这类地方重打包、夹带、替换资产的事故早不是什么新闻了;装 root 工具时装到带后门的 APK,那可就太讽刺了。另外官方文档特意警告过:永远不要刷别人给的补丁镜像,补丁必须在你要装 Magisk 的那台设备上打。

紫队视角:root 是把双刃剑

对安全研究者来说,Magisk 加 Zygisk 是移动端研究的底层基建——没有它,应用层 hook、运行时注入、取证绕过这些实验都无从谈起。但对企业安全团队来说,同一套东西是风险清单上的一整行。

v31.1 的两个”拆除”尤其值得琢磨。隐藏应用功能下线,意味着”把 Magisk 从设备上藏起来”这条老路基本走不通了,基于包名扫描的检测反而更有效——这是防守方的利好。反过来,su 授权从”运行时弹窗”变成”预先授权”,防守方的审计对象就变了:以前要盯的是弹窗日志和即时授权记录,现在要盯的是 Superuser 策略表本身。一台被预授权过的设备,可能半年都不弹一次窗,却在持续放行某个应用拿 root。

给企业设备准入检查表提三条实在的:一是看 Play Integrity 的硬件证明结果,root 设备通常在这一关就露馅;二是查 su 二进制与相关挂载点、SELinux 状态;三是把”设备是否允许预授权 root”写进 BYOD 政策,别让员工的私人机 root 之后顺手连上公司 VPN。

红队靠 Magisk 拿到隐蔽的执行通道,蓝队靠 Magisk 找到”哪些设备其实不该有 root”。工具还是那把工具,变的是我们怎么用它反推对方。

版权声明：本文由华盟网原创发布，保留所有权利。文中信息引自 Magisk 官方发布说明与官方文档,配图由华盟网授权使用。