简介面向 MT6735 平台安卓手机开发与 root 权限获取的工具合集适合调试系统、定制固件或研究权限机制的人员参考可用于梳理 SuperSU 方案在不同 CPU 架构下的关键组件与启动链路。压缩包共 62 个文件约 5.56MB涵盖 su、sukernel、supolicy、suinit 等权限与策略组件并配有 apk、updater-script、bootloader、keyblock、rc 配置等安装与引导文件目录按架构和公共模块组织。已有 927 人学习便于对照 MT6735 机型 root 尝试、固件分析与刷机包结构理解权限守护进程、策略加载和组件替换关系。1. 一台 MT6735 老机器为什么值得当成安卓开发的试验台手里这台 MT6735 的机器跑着 Android 6.02GB 内存720p 屏放在今天连备用机都嫌慢。但它有一个新机器给不了的好处分区表干净、启动链简单、刷坏了几乎一定能救回来。做安卓底层开发root工具的选择在 MT6735 这类老平台上反而最直观——preloader、LK、boot.img 三层结构一眼能看穿没有 AVB、没有 A/B 分区、没有动态分区出错的地方就那么几个排查是确定性的而不是猜谜。这篇笔记拆的是在 MT6735 安卓手机开发场景下把 root 做干净的一整套流程从备份分区、补丁 boot.img、回刷验证一直讲到刷成砖以后怎么从 BROM 层把机器拉回来。它适合手里有开发板或者退役老机器、想动内核和 system 分区的人如果你只是想给日常用机装个面具图省事那这套流程对你来说偏重了。2. MT6735 启动链拆解root 的入口到底在哪一层在 MT6735 上瞎刷本质上是不知道自己在改哪一层。先把启动链摆清楚后面所有命令才有落点。2.1 BootROM → Preloader → LK → boot.img四段式启动的职责划分上电之后第一段跑的是芯片内部固化的 BootROM它从 eMMC 的固定偏移读 preloader 到片内 SRAM 执行。这段代码改不了但它留了一个后门当 preloader 校验失败或者被外部信号强制时BootROM 会停在下载模式等主机握手这就是后面救砖要用的 BROM 模式。Preloader 存在独立分区里负责初始化 DRAM、时钟和存储控制器然后去加载 LK。它同时也是常规刷机工具握手的第一站所以 preloader 分区一旦写坏机器就表现为插电脑没反应、黑屏、连不上任何工具。LK 相当于这个平台上的 bootloader管 fastboot 协议、显示开机 logo、校验并加载 boot.img。MT6735 上的 fastboot 是裁剪过的fastboot flashing一类的子命令往往不支持能用的基本只有flash、reboot、getvar、oem。boot.img 是 header kernel ramdisk 三件套。Android 起来以后内核解压 ramdisk 得到 initramfs执行里面的/init再由 init 去挂 system、起 zygote。root 最干净的入口就在这一层——ramdisk 在 system 挂载之前就已经运行改这里的收益最大、副作用最小。分区名典型大小存放内容写坏后的表现preloader256KB~1MB二级引导完全不开机只能 BROM 救lk1~2MBbootloader / fastboot进不去 fastboot黑屏boot16MBkernel ramdisk卡 logo、循环重启recovery16MBrecovery ramdisk进不去 recovery系统仍能起seccfg512KB~1MB解锁状态、锁标志fastboot 直接锁死不响应nvram约 5MBIMEI、WiFi MAC、射频校准能开机但无信号nvdata32MB运行时配置部分机型卡在激活页protect1/28~16MB安全相关数据指纹、密钥类功能失效para512KB启动参数无法进入 recoveryexpdb8MB异常日志不影响开机但排错时很有用frp512KB恢复出厂保护刷完卡在 FRP 校验这张表建议打印出来贴在工位上。MT6735 上九成的“刷完不正常”都能在这张表里找到对应行。2.2 三条 root 路线的选型systemless、内核态、直接改 system这一层选错后面全是返工。MT6735 平台上能走的路就三条各自边界很清楚。第一条是 Magisk 的 systemless 方案只改 boot.img 的 ramdisk注入 magiskinit 顶替原来的 init启动后用 overlayfs 把改动挂到 system 上system 分区本身不动。优点是随时能还原——把原始 boot.img 刷回去就干净了缺点是依赖 ramdisk 空间且对内核版本不敏感3.10 和 3.18 都能跑。第二条是 KernelSU 这类内核态方案把提权逻辑做成内核模块或者直接编进内核用户态通过一个字符设备通信。它更隐蔽、更稳但对内核版本有要求官方主线是奔着 5.10 的 GKI 内核去的MT6735 这种 3.10 / 3.18 的老内核要自己打补丁移植工作量不小非必要不建议在这颗芯片上折腾。第三条是直接改 ramdisk 加 remount system把ro.secure0、ro.debuggable1写进 default.prop再把 su 二进制塞进 /system/xbin。这条路最“传统”也最容易翻车——一旦 system 分区被写dm-verity 校验必然失败机器要么起不来要么起来之后每次开机都提示系统被修改。它只适合临时调试别当长期方案。方案改动位置可还原性主要风险建议场景Magisk systemlessboot.img 的 ramdisk刷回原镜像即还原低日常开发首选KernelSU内核 boot.img需重编内核中老内核移植成本高需要内核态钩子时改 ramdisk remountramdisk system 分区差需整包重刷高破坏 verity一次性调试我一般的做法是先走 Magisk把 boot.img 的原始镜像和补丁镜像各存一份只有在需要 hook 内核函数做抓包或者文件监控时才会去碰第二条路。2.3 动手之前先备份scatter、分区表与 dd 镜像所有教程都会说“先备份”但很少有人讲清楚备份什么、备份到什么程度才算够。MT6735 上最低限度要备四样boot、seccfg、nvram、nvdata。前两个决定你能不能刷回去后两个决定刷回去之后手机还能不能打电话。固件包里会带一个 scatter 文本文件里面按分区列出了起始地址和长度这是所有刷机工具的地图。拿到它之后先在能开机的状态下确认设备的调试通道是否可用# 1) 确认设备连上了并且当前构建类型允许提权 adb devices adb shell getprop ro.build.type # 期望 userdebug 或 eng adb shell getprop ro.debuggable # 期望 1 # 2) 列出 by-name 软链接核对分区名与顺序 adb shell su -c ls -l /dev/block/platform/mtk-msdc.0/by-name/ # 3) 看每个分区的块数换算成字节数核对大小 adb shell su -c cat /proc/partitions第一行只是确认 adb 通道活着。第二行是关键by-name目录下是按名字索引的软链接指向真实的/dev/block/mmcblk0pN如果这个目录不存在部分老 LK 不生成它就只能靠/proc/partitions里的主次设备号自己算偏移那种情况下务必先小范围验证再批量操作。第三行用来交叉核对比如 boot 显示 32768 个 1K 块就是 32MB和你 scatter 里写的 partition_size 对不上就说明固件包和设备不是同一批。确认无误后跑批量备份。这个脚本我在几台机器上用过直接抄#!/usr/bin/env bash # 按 by-name 批量备份 MT6735 的关键分区 set -e OUT./backup_mt6735 mkdir -p $OUT # preloader/lk 决定能否开机seccfg 决定 fastboot 是否可用 # nvram/nvdata 决定刷完后有没有信号其余是排错用的辅助镜像 PARTSpreloader lk boot recovery seccfg nvram nvdata protect1 protect2 para expdb frp for p in $PARTS; do # bs4096 对齐 eMMC 页2/dev/null 屏蔽 toybox dd 的统计输出避免污染日志 adb shell su -c dd if/dev/block/by-name/$p of/sdcard/$p.img bs4096 2/dev/null adb pull /sdcard/$p.img $OUT/$p.img /dev/null adb shell su -c rm -f /sdcard/$p.img echo [ok] $p $(stat -c%s $OUT/$p.img) bytes donebs4096是块大小eMMC 的页一般是 4K用它读写最省事分区大小不是 4K 整数倍时 dd 会自动补齐不影响还原。2/dev/null不是可有可无的装饰某些精简版 dd 会把 “xxx bytes copied” 写到 stderr混进脚本输出后容易让人误判成报错。adb pull之后立刻删掉设备上的临时文件是因为不少老机器的/sdcard只剩几百 MB备份几个 32MB 的分区就可能写满写满之后 dd 会静默截断得到的镜像比实际分区短——这种半截镜像刷回去比不刷还危险。备份完成后做一次校验把每个镜像的字节数和/proc/partitions里对应分区的块数乘 1024 对一遍对不上就重来。这一步花两分钟能省掉后面几个小时的救砖。3. Magisk 补丁 boot.img在 MT6735 上做一次干净的 systemless root选型定在 systemless 之后剩下的事就是把 boot.img 拿出来、打补丁、刷回去、验证。听起来三步实际每步都有坑。3.1 提取原始 boot.img 的两条路径路径一是有临时提权或者 userdebug 构建时最省事的直接 dd。前提是adb shell su能用或者adb root能成功。# 从设备上直接导出原始 boot命名带 stock 便于区分 adb shell su -c dd if/dev/block/by-name/boot of/sdcard/boot_stock.img bs4096 adb pull /sdcard/boot_stock.img ./boot_stock.img # 顺手记一下它的 SHA256回刷前用它确认镜像没被改过 sha256sum boot_stock.img这里的逻辑很直白把块设备当普通文件读出来bs4096保证读取粒度对齐。SHA256 那行不是形式主义——后面打完补丁你要确认“刷回去的是不是原来那个”光看文件大小不够因为 magiskboot 重打包后大小经常正好相同。路径二是设备已经起不来的时候用的从固件包里直接拿 boot.img。绝大多数 MT6735 的官方固件包是压缩包套文件夹里面有一个 scatter 文本和一堆以分区名命名的 .img。这种情况下不用担心版本问题但要确认固件包的版本号和机器背贴上的 build 号一致跨版本刷 boot 有可能因为 kernel 与 vendor 的接口不匹配而起不来。如果连固件包都没有还有第三条兜底路用刷机工具的 Readback 功能按地址读。打开 scatter 文件找到 boot 那一项的linear_start_addr和partition_size在 Readback 页里填进去长度按分区大小填读出来就是原始镜像。注意linear_start_addr在不同批次的 scatter 里是不一样的必须以你手上这份为准照抄网上的地址大概率读到别的东西。3.2 打补丁从 App 内修补到 magiskboot 命令行校验拿到 boot_stock.img 之后最稳的补丁方式是在设备上用 Magisk 应用做本地修补而不是在电脑上手工重打包。原因很简单App 里跑的是和设备同架构的 magiskboot它读得懂这颗芯片的 header 格式能原样保留 page size、kernel offset、ramdisk offset 这些字段。操作顺序是安装 Magisk 应用 → 首页“安装” → 选择“选择并修补一个文件” → 选中 boot_stock.img → 开始。完成后会在 Download 目录生成一个magisk_patched-xxxxx_xxxxx.imgpull 回电脑。补丁做完别急着刷先在电脑上做一次静态校验。这套命令我用得最多# 1) 解包补丁镜像看 header 是否被魔改 magiskboot unpack magisk_patched.img # 2) 列出 ramdisk 根目录确认 magiskinit 已经注入 magiskboot cpio ramdisk.cpio ls | head -40 # 3) 确认存在 .backup 目录原始 init 的备份和 overlay.d magiskboot cpio ramdisk.cpio exists .backup magiskboot cpio ramdisk.cpio exists overlay.d # 4) 校验原始镜像对比没有被动过 magiskboot unpack boot_stock.img cat header | head -5第一步的unpack会把镜像拆成 kernel、ramdisk.cpio、header、dtb如果有几个文件同时打印KERNEL_FMT、RAMDISK_FMT、HEADER_FMT三个值。MT6735 上常见的是HEADER_FMT为boot也就是 Android 9 之前的 v0 headerRAMDISK_FMT为gzip或者lz4_legacy。如果这里显示的不是这几个值说明你拿到的根本不是这颗芯片的 boot。第二步的cpio ls是判断补丁是否生效的核心。正常的输出里应该能看到magiskinit、overlay.d、.backup三个条目。.backup目录里存的是原始 init它存在的意义是让你能用magiskboot cpio还原回去overlay.d则是放自定义脚本的地方后面要改属性就靠它。第三步的两个exists是给脚本用的返回码 0 表示存在。把它们写进 CI 或者本地检查脚本里比肉眼看输出可靠。第四步容易漏把原始镜像也 unpack 一次用cat header对比两次的 header。如果补丁后 header 里的 page_size 变了比如从 2048 变成 4096刷上去必卡 logo这时候要用magiskboot repack显式指定--header把原始 header 塞回去。3.3 回刷、首次开机与 adb root / remount 的验证回刷这一步在 MT6735 上有两种做法fastboot 和 BROM 层工具。机器能正常进 fastboot 就走前者速度快、可回滚。# 1) 进 bootloader 并确认 fastboot 认到了设备 adb reboot bootloader fastboot devices # 2) 刷入补丁镜像只刷 boot不要碰 recovery fastboot flash boot magisk_patched.img # 3) 重启首次开机会比平时慢 1~3 分钟属正常 fastboot rebootfastboot devices如果返回空八成是 LK 没起来或者 USB 驱动问题别反复插拔直接转第 4 章的 BROM 方案。flash boot只动 boot 分区这是刻意的——把补丁镜像误刷进 recovery 分区会导致 recovery 起不来而且很多 MT6735 的 recovery 分区比 boot 小刷到一半就报长度越界。开机之后按顺序验证四件事# 1) 提权是否真的生效Magisk 会弹授权框 adb shell su -c id # 2) 看 Magisk 版本和挂载方式确认是 systemless adb shell su -c magisk -v adb shell su -c magisk --path # 3) 确认 system 分区还是只读没有被物理写入 adb shell su -c mount | grep -E /system | /system_root # 4) 需要临时改 system 时走 overlay 而不是 remount adb shell su -c cp /sdcard/test.prop /data/adb/modules/test/system/build.prop第一条id返回uid0才算通。第二条的magisk --path会输出一个/sbin或者/debug_ramdisk路径这个路径不是/system正好证明了改动没落到物理分区上这就是 systemless 的标志。第三条的mount输出里system 应该还是ro如果显示rw说明之前有人 remount 过并且没恢复那种状态下 OTA 和 verity 都会出问题。第四条演示的是正确姿势要往 system 里加文件就在模块目录下建对应的system/子目录Magisk 开机时用 overlayfs 叠上去物理分区一动不动。需要adb root的话MT6735 上要注意它是构建属性决定的不是刷个 Magisk 就能有。ro.debuggable1且ro.secure0的 userdebug 构建才能adb rootuser 构建上执行会返回adbd cannot run as root in production builds这是正常的用adb shell su代替即可。4. mtkclient 兜底刷成砖之后BROM 层还能把机器拉回来前面所有步骤都建立在“机器还能进 fastboot”这个前提上。这个前提一旦破了唯一的路就是 BROM 层。4.1 BROM 模式与 Preloader 模式的区别这两种模式经常被混为一谈实际差别很大直接决定了救砖能不能成功。对比项BROM 模式Preloader 模式触发方式关机状态下按住音量键插 USB或短接测试点preloader 正常执行后主动等待下载依赖分区无代码在芯片内部依赖 preloader 分区完好握手对象BootROM需要 Download Agentpreloader 自身典型用途救砖、整片读写、擦 eMMC常规固件刷写成功率只要芯片没物理损坏基本都能进preloader 一坏就没戏判断自己在哪个模式看设备管理器里的端口名就行BROM 一般枚举成MediaTek USB PortPreloader 枚举成MediaTek PreLoader USB VCOM。前者出现的时间窗口很短开机后一两秒所以 BROM 模式下经常需要“先点工具上的开始再插线”。4.2 读分区、写分区、强制进 BROM 的具体命令命令行工具 mtkclient 比图形界面的刷机工具更适合排错因为它每一步都能看到返回码。装好依赖后按顺序来# 1) 最安全的握手测试只读 GPT不写任何东西 python mtk printgpt # 2) 整片备份到目录慢几十分钟到几小时视容量而定 python mtk rl backup_full # 3) 只写回 boot 分区 python mtk w boot magisk_patched.img # 4) 只擦 userdata忘记锁屏、system 起不来时用 python mtk e userdata # 5) 握手失败时显式指定 preloader 文件重试 python mtk printgpt --preloaderpreloader_kai.bin # 6) 所有操作完成复位设备 python mtk reset第一条是整套流程里最重要的一条。printgpt只读 GPT 表并打印出来不改任何数据只要它能列出 preloader、lk、boot 这些名字就说明 BROM 握手成功、DA 加载成功、存储可读后面的写操作才有意义。很多人一上来就w boot握手其实没成命令超时然后误判成“工具坏了”。第二条rl是 read all 的缩写会把全部分区按名字导出到一个目录。这一步耗时取决于 eMMC 容量16GB 的机器大概 40 分钟。它的价值在于只要这份全量备份在任何误操作都能整体回滚。第三条w后面跟分区名和文件路径工具会自动按 GPT 里记录的分区边界截断或补齐。如果文件比分区大会直接报错不会写半截进去——这个行为比 fastboot 友好。第四条e是 erase只擦不写。e userdata相当于恢复出厂e frp用来清 FRP 锁e seccfg要慎用它会改变解锁状态。第五条是排错关键。--preloader把指定的 preloader 文件当作握手时的 DA 用当设备里的 preloader 版本和工具内置的不匹配、握手一直停在Waiting for preloader时指定一个同批次的文件往往能过。4.3 NVRAM / NVDATA / protect 分区比 root 更该先备份的东西我见过太多人把精力全放在“怎么 root 成功”上结果刷机时手滑点了全擦机器是起来了但插卡没信号、WiFi 打不开、蓝牙地址是一串 0。这些数据全在 nvram 和 nvdata 里而它们不在任何官方固件包的默认刷写列表里——也就是说官方固件刷一百遍也补不回来。nvram 分区里存的是射频校准参数、IMEI、WiFi 和蓝牙的 MAC 地址。这些值是在产线逐台校准写入的同型号不同批次之间都不通用。nvdata 存的是运行时的配置快照部分机型把它清掉之后会卡在激活向导反复要求联网校验。protect1 和 protect2 里放的是和安全相关的数据指纹模板、密钥材料这类东西通常挂在这里。它们被清掉的表现是“能开机、能 root但指纹录不进去”而且没有任何报错提示只有日志里一行protect partition invalid。所以备份顺序应该是nvram → nvdata → protect1/2 → seccfg → boot → 其他。前面四个加起来不到 50MB但它们决定了这台机器刷完之后是“开发板”还是“能打电话的开发板”。备份文件至少存两份一份放本机硬盘一份放移动盘只存一份的话某次误格式化就全没了那时候再想找同批次的 nvram基本只能靠运气。顺带说一句如果备份确实丢了不要试图自行改写 IMEI 去“修好”它——那是另一个层面的合规问题能不碰就不碰。正确做法永远是在第一次动手前把备份做掉。5. 避坑MT6735 root 过程中五次真实的翻车记录下面这五条都是我在 MT6735 上真实遇到过并且能稳定复现的。写出来不是为了吓人是为了让你在遇到时三分钟内定位。5.1 现象adb root提示 adbd cannot run as root in production builds原因很明确adb root走的是 adbd 的重启逻辑它检查的是ro.debuggable和ro.secure两个属性。官方正式版固件这两个值分别是 0 和 1adbd 编译时就把提权分支裁掉了跟有没有刷 Magisk 无关。解决分两种情况。如果你有源码或者能拿到 userdebug 版 boot直接刷 userdebug 镜像adb root立刻可用。如果没有就别在这上面耗时间改用adb shell su -c 命令把 su 当成提权入口写脚本时用一个变量包一层两种环境都能跑# 统一提权入口userdebug 下无 su 也能工作 if adb shell which su /dev/null 21; then SHadb shell su -c else adb root /dev/null 21; adb wait-for-device SHadb shell fi $SH id这段判断的逻辑是先看设备上有没有 su 二进制有就走 su没有就尝试adb root再等设备重连。adb wait-for-device不能省adbd 重启期间设备会短暂离线紧接着执行的命令会报device offline。5.2 现象刷完 boot.img 卡在开机 logo不进系统也不重启原因通常有两个。一是镜像大小超过了 boot 分区容量写的时候被截断二是 header 里的 page size 或加载基址和原机不一致内核压根没被正确解压。先确认大小。切到 fastboot 里看分区长度再和本地文件对比# 查 boot 分区实际容量部分 LK 支持该变量 fastboot getvar partition-size:boot # 本地镜像大小单位字节 stat -c%s magisk_patched.img如果本地文件更大说明补丁后的镜像塞不进去。MT6735 的 boot 分区常见 16MB补丁会往 ramdisk 里加 magiskinit 和几个脚本正常情况下只增加几百 KB不该超一旦超了多半是选错了源文件比如拿 recovery 当 boot 打补丁。大小没问题就往 header 上查。用magiskboot unpack boot_stock.img和magiskboot unpack magisk_patched.img各拆一次cat header对比两边的page_size、kernel_offset、ramdisk_offset、tags_offset四个字段。有任何一项不同就用原始 header 重打包# 用补丁后的 ramdisk 重新打包但强制沿用原始 header magiskboot repack boot_stock.img new_boot.imgrepack的语义是以第一个参数原始镜像为模板把当前目录下已经解包好的 kernel 和 ramdisk 装回去。把这个命令放在unpack出来的目录里执行header 就一定是原来的。5.3 现象Magisk 应用能装但打开一直转圈日志里刷 verity 相关报错根因是 dm-verity。MT6735 跑 Android 6.0 及以上的固件基本都开了 veritysystem 分区在挂载时会被逐块校验一旦发现被改过就拒绝挂载表现就是开机动画放完直接黑屏或者反复重启。正确的处理顺序是先关 verity 再刷 boot而不是反过来# 1) 在 userdebug 构建上关闭 verity 并重启 adb root adb disable-verity adb reboot # 2) 重启后确认 verity 状态 adb shell getprop ro.boot.veritymode # 期望输出 disabled # 3) 再刷补丁后的 boot adb reboot bootloader fastboot flash boot magisk_patched.imgadb disable-verity只在 userdebug 上可用正式版会返回SERVICE_NAME_NOT_FOUND。正式版的处理办法是在 boot 的 ramdisk 里改 fstab把 system 那一行的verify标志去掉这个改动可以直接写进overlay.d的post-fs-data.sh里跟着模块一起走。顺带提一个容易混淆的点网上很多教程让你刷vbmeta分区来关验证那是 Android 8 以后 AVB 的做法。MT6735 这批机器大多没有 vbmeta 分区照抄那条命令会得到partition not found别以为是命令写错了。5.4 现象刷机后能开机、能 root但插卡无信号WiFi 打开是一串 00:00:00这是最典型的一类“成功即失败”。现象背后是 nvram 被清了多半是在图形刷机工具里选了Format All Download而不是Download Only。前者会把包括 nvram、nvdata、protect 在内的全部分区格式化后者只写固件包里列出的那些。解决只有一个方向把之前备份的镜像写回去。# 依次写回射频与配置相关分区顺序不要颠倒 python mtk w nvram nvram.img python mtk w nvdata nvdata.img python mtk w protect1 protect1.img python mtk w protect2 protect2.img python mtk reset写回之后第一次开机会比平时慢很多两到三分钟内 modem 会重新初始化并读取校准参数这期间信号栏可能是空的不要急着判定失败。如果五分钟之后依然无信号用adb shell dumpsys telephony.registry看射频状态或者在日志里搜nvram关键字确认是不是写错了分区。如果压根没备份过那就只能承认这台机器的射频部分回不来了。这也是我为什么在第 2 章把 nvram 排进第一批备份的原因。5.5 现象fastboot devices永远是空的机器黑屏但插上电脑有 USB 枚举声原因分两层。浅层是 LK 没起来boot 分区炸了之后 LK 会反复尝试加载失败最终掉回 BootROM这时候设备枚举出来的是 BROM 端口而不是 fastboot 端口。深层原因是 USB 口供电或者线材问题劣质线只通电不传数据插上照样有枚举声。先排线材换一根确定能传数据的线插机箱后面的 USB 2.0 口3.0 口在 BROM 握手阶段兼容性反而差。换完还是不行直接走 BROM# 1) 设备完全断电拔电池或长按电源 15 秒按住音量下插 USB # 2) 确认工具能握手 python mtk printgpt # 3) 握手成功后直接写回原始 boot python mtk w boot boot_stock.img python mtk reset如果printgpt卡在Waiting for preloader不动加上--preloader指定文件重试。如果连 BROM 都进不去说明问题不在分区层得去查硬件了——短接点、eMMC 虚焊这类已经不是软件能解决的范围。6. 把 root 变成可复现流程一份自检脚本和两个进阶方向手工刷一次成功不叫会能重复刷十次成功才叫会。我在吃过两次“同样的步骤这次就是不行”的亏之后把所有关键判断写成了一个自检脚本每次动手前后各跑一遍。#!/usr/bin/env bash # MT6735 root 前后自检镜像侧 设备侧 set -u IMG${1:-magisk_patched.img} STOCK${2:-boot_stock.img} fail0 # 镜像侧大小、header 一致性、ramdisk 注入痕迹 [ -f $IMG ] || { echo [FAIL] 补丁镜像不存在; exit 1; } orig$(stat -c%s $STOCK); new$(stat -c%s $IMG) echo [INFO] stock$orig patched$new delta$((new-orig)) [ $new -le $((16*1024*1024)) ] || { echo [FAIL] 超过 16MB boot 分区上限; fail1; } work$(mktemp -d); cp $IMG $work/; cd $work magiskboot unpack $IMG /dev/null 21 magiskboot cpio ramdisk.cpio exists .backup || { echo [FAIL] 缺少 .backup; fail1; } magiskboot cpio ramdisk.cpio exists overlay.d || { echo [WARN] 无 overlay.d; } head -3 header | grep -qi page_size echo [INFO] header 字段$(grep -i page_size header) # 设备侧连接、构建类型、提权、system 挂载状态 adb devices | grep -q device$ || { echo [FAIL] 设备未连接; exit 1; } echo [INFO] build.type$(adb shell getprop ro.build.type | tr -d \r) adb shell su -c id 2/dev/null | grep -q uid0 || { echo [FAIL] 提权未生效; fail1; } adb shell su -c mount 2/dev/null | grep -E /system | grep -q ro, \ echo [OK] system 仍为只读systemless 成立 || echo [WARN] system 已可写 cd - /dev/null; rm -rf $work [ $fail -eq 0 ] echo 自检通过 || echo 自检未通过勿刷 脚本分两段。镜像段做三件事比对补丁前后的大小差值正常是几百 KB超过 16MB 的 boot 分区上限就说明塞爆了、确认 ramdisk 里有.backup目录、打印 header 里的 page_size 供人工核对。设备段确认连接状态、构建类型、su -c id是否返回 uid0以及 system 挂载是不是还是只读——最后这一条是判断 systemless 是否成立的硬指标比看 Magisk 版本可靠得多。脚本里grep -q ro,那个逗号不能省rw,和ro,只差一个字母省了就永远匹配上。第一个进阶方向是自编内核。MT6735 的内核源码通常随开发板资料一起给出编之前先确认arch/arm64/configs/下的 defconfig 名字编出来的 Image 用magiskboot --mkboot boot_stock.img Image new_boot.img直接替换内核而不动 ramdisk。这样做的好处是可以在内核里加 trace hook 做行为监控比用户态的抓包干净。代价是每换一次内核就要重新打一次 Magisk 补丁因为 ramdisk 里的 magiskinit 和内核对齐方式有关联。第二个方向是把整个流程脚本化、版本化。我的习惯是每台机器的备份目录下放一个MANIFEST记录原机 build 号、备份时间、每个镜像的 SHA256补丁镜像同样记一条。这样半年后回头看能立刻判断“这个镜像是哪台机器、哪个版本上打的”而不是对着一堆boot.img、boot(1).img猜。验证项通过标准检查命令镜像未超分区小于 boot 分区字节数stat -c%s对比 scatterheader 未被改写page_size 与原镜像一致magiskboot unpack后cat headerramdisk 注入成功存在.backup与magiskinitmagiskboot cpio exists提权生效uid0adb shell su -c idsystemless 成立system 挂载标志为romount | grep /system 射频数据完好插卡有信号、MAC 非全零拨号盘查状态信息坦白讲我最早也是拿着一份网上的教程直接fastboot flash boot结果把那台机器的 nvram 弄丢了到现在它还是一块只能连 WiFi 的“开发板”。从那以后我每次动手前都强制走一遍自检脚本备份不落在两个不同物理位置就不允许开始——这套习惯救回来的时间比脚本本身花的时间多得多。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/30 11:47:26 · 阅读 1.2k MT6735 安卓 root：boot.img 补丁与 BROM 救砖
简介面向 MT6735 平台安卓手机开发与 root 权限获取的工具合集适合调试系统、定制固件或研究权限机制的人员参考可用于梳理 SuperSU 方案在不同 CPU 架构下的关键组件与启动链路。压缩包共 62 个文件约 5.56MB涵盖 su、sukernel、supolicy、suinit 等权限与策略组件并配有 apk、updater-script、bootloader、keyblock、rc 配置等安装与引导文件目录按架构和公共模块组织。已有 927 人学习便于对照 MT6735 机型 root 尝试、固件分析与刷机包结构理解权限守护进程、策略加载和组件替换关系。1. 一台 MT6735 老机器为什么值得当成安卓开发的试验台手里这台 MT6735 的机器跑着 Android 6.02GB 内存720p 屏放在今天连备用机都嫌慢。但它有一个新机器给不了的好处分区表干净、启动链简单、刷坏了几乎一定能救回来。做安卓底层开发root工具的选择在 MT6735 这类老平台上反而最直观——preloader、LK、boot.img 三层结构一眼能看穿没有 AVB、没有 A/B 分区、没有动态分区出错的地方就那么几个排查是确定性的而不是猜谜。这篇笔记拆的是在 MT6735 安卓手机开发场景下把 root 做干净的一整套流程从备份分区、补丁 boot.img、回刷验证一直讲到刷成砖以后怎么从 BROM 层把机器拉回来。它适合手里有开发板或者退役老机器、想动内核和 system 分区的人如果你只是想给日常用机装个面具图省事那这套流程对你来说偏重了。2. MT6735 启动链拆解root 的入口到底在哪一层在 MT6735 上瞎刷本质上是不知道自己在改哪一层。先把启动链摆清楚后面所有命令才有落点。2.1 BootROM → Preloader → LK → boot.img四段式启动的职责划分上电之后第一段跑的是芯片内部固化的 BootROM它从 eMMC 的固定偏移读 preloader 到片内 SRAM 执行。这段代码改不了但它留了一个后门当 preloader 校验失败或者被外部信号强制时BootROM 会停在下载模式等主机握手这就是后面救砖要用的 BROM 模式。Preloader 存在独立分区里负责初始化 DRAM、时钟和存储控制器然后去加载 LK。它同时也是常规刷机工具握手的第一站所以 preloader 分区一旦写坏机器就表现为插电脑没反应、黑屏、连不上任何工具。LK 相当于这个平台上的 bootloader管 fastboot 协议、显示开机 logo、校验并加载 boot.img。MT6735 上的 fastboot 是裁剪过的fastboot flashing一类的子命令往往不支持能用的基本只有flash、reboot、getvar、oem。boot.img 是 header kernel ramdisk 三件套。Android 起来以后内核解压 ramdisk 得到 initramfs执行里面的/init再由 init 去挂 system、起 zygote。root 最干净的入口就在这一层——ramdisk 在 system 挂载之前就已经运行改这里的收益最大、副作用最小。分区名典型大小存放内容写坏后的表现preloader256KB~1MB二级引导完全不开机只能 BROM 救lk1~2MBbootloader / fastboot进不去 fastboot黑屏boot16MBkernel ramdisk卡 logo、循环重启recovery16MBrecovery ramdisk进不去 recovery系统仍能起seccfg512KB~1MB解锁状态、锁标志fastboot 直接锁死不响应nvram约 5MBIMEI、WiFi MAC、射频校准能开机但无信号nvdata32MB运行时配置部分机型卡在激活页protect1/28~16MB安全相关数据指纹、密钥类功能失效para512KB启动参数无法进入 recoveryexpdb8MB异常日志不影响开机但排错时很有用frp512KB恢复出厂保护刷完卡在 FRP 校验这张表建议打印出来贴在工位上。MT6735 上九成的“刷完不正常”都能在这张表里找到对应行。2.2 三条 root 路线的选型systemless、内核态、直接改 system这一层选错后面全是返工。MT6735 平台上能走的路就三条各自边界很清楚。第一条是 Magisk 的 systemless 方案只改 boot.img 的 ramdisk注入 magiskinit 顶替原来的 init启动后用 overlayfs 把改动挂到 system 上system 分区本身不动。优点是随时能还原——把原始 boot.img 刷回去就干净了缺点是依赖 ramdisk 空间且对内核版本不敏感3.10 和 3.18 都能跑。第二条是 KernelSU 这类内核态方案把提权逻辑做成内核模块或者直接编进内核用户态通过一个字符设备通信。它更隐蔽、更稳但对内核版本有要求官方主线是奔着 5.10 的 GKI 内核去的MT6735 这种 3.10 / 3.18 的老内核要自己打补丁移植工作量不小非必要不建议在这颗芯片上折腾。第三条是直接改 ramdisk 加 remount system把ro.secure0、ro.debuggable1写进 default.prop再把 su 二进制塞进 /system/xbin。这条路最“传统”也最容易翻车——一旦 system 分区被写dm-verity 校验必然失败机器要么起不来要么起来之后每次开机都提示系统被修改。它只适合临时调试别当长期方案。方案改动位置可还原性主要风险建议场景Magisk systemlessboot.img 的 ramdisk刷回原镜像即还原低日常开发首选KernelSU内核 boot.img需重编内核中老内核移植成本高需要内核态钩子时改 ramdisk remountramdisk system 分区差需整包重刷高破坏 verity一次性调试我一般的做法是先走 Magisk把 boot.img 的原始镜像和补丁镜像各存一份只有在需要 hook 内核函数做抓包或者文件监控时才会去碰第二条路。2.3 动手之前先备份scatter、分区表与 dd 镜像所有教程都会说“先备份”但很少有人讲清楚备份什么、备份到什么程度才算够。MT6735 上最低限度要备四样boot、seccfg、nvram、nvdata。前两个决定你能不能刷回去后两个决定刷回去之后手机还能不能打电话。固件包里会带一个 scatter 文本文件里面按分区列出了起始地址和长度这是所有刷机工具的地图。拿到它之后先在能开机的状态下确认设备的调试通道是否可用# 1) 确认设备连上了并且当前构建类型允许提权 adb devices adb shell getprop ro.build.type # 期望 userdebug 或 eng adb shell getprop ro.debuggable # 期望 1 # 2) 列出 by-name 软链接核对分区名与顺序 adb shell su -c ls -l /dev/block/platform/mtk-msdc.0/by-name/ # 3) 看每个分区的块数换算成字节数核对大小 adb shell su -c cat /proc/partitions第一行只是确认 adb 通道活着。第二行是关键by-name目录下是按名字索引的软链接指向真实的/dev/block/mmcblk0pN如果这个目录不存在部分老 LK 不生成它就只能靠/proc/partitions里的主次设备号自己算偏移那种情况下务必先小范围验证再批量操作。第三行用来交叉核对比如 boot 显示 32768 个 1K 块就是 32MB和你 scatter 里写的 partition_size 对不上就说明固件包和设备不是同一批。确认无误后跑批量备份。这个脚本我在几台机器上用过直接抄#!/usr/bin/env bash # 按 by-name 批量备份 MT6735 的关键分区 set -e OUT./backup_mt6735 mkdir -p $OUT # preloader/lk 决定能否开机seccfg 决定 fastboot 是否可用 # nvram/nvdata 决定刷完后有没有信号其余是排错用的辅助镜像 PARTSpreloader lk boot recovery seccfg nvram nvdata protect1 protect2 para expdb frp for p in $PARTS; do # bs4096 对齐 eMMC 页2/dev/null 屏蔽 toybox dd 的统计输出避免污染日志 adb shell su -c dd if/dev/block/by-name/$p of/sdcard/$p.img bs4096 2/dev/null adb pull /sdcard/$p.img $OUT/$p.img /dev/null adb shell su -c rm -f /sdcard/$p.img echo [ok] $p $(stat -c%s $OUT/$p.img) bytes donebs4096是块大小eMMC 的页一般是 4K用它读写最省事分区大小不是 4K 整数倍时 dd 会自动补齐不影响还原。2/dev/null不是可有可无的装饰某些精简版 dd 会把 “xxx bytes copied” 写到 stderr混进脚本输出后容易让人误判成报错。adb pull之后立刻删掉设备上的临时文件是因为不少老机器的/sdcard只剩几百 MB备份几个 32MB 的分区就可能写满写满之后 dd 会静默截断得到的镜像比实际分区短——这种半截镜像刷回去比不刷还危险。备份完成后做一次校验把每个镜像的字节数和/proc/partitions里对应分区的块数乘 1024 对一遍对不上就重来。这一步花两分钟能省掉后面几个小时的救砖。3. Magisk 补丁 boot.img在 MT6735 上做一次干净的 systemless root选型定在 systemless 之后剩下的事就是把 boot.img 拿出来、打补丁、刷回去、验证。听起来三步实际每步都有坑。3.1 提取原始 boot.img 的两条路径路径一是有临时提权或者 userdebug 构建时最省事的直接 dd。前提是adb shell su能用或者adb root能成功。# 从设备上直接导出原始 boot命名带 stock 便于区分 adb shell su -c dd if/dev/block/by-name/boot of/sdcard/boot_stock.img bs4096 adb pull /sdcard/boot_stock.img ./boot_stock.img # 顺手记一下它的 SHA256回刷前用它确认镜像没被改过 sha256sum boot_stock.img这里的逻辑很直白把块设备当普通文件读出来bs4096保证读取粒度对齐。SHA256 那行不是形式主义——后面打完补丁你要确认“刷回去的是不是原来那个”光看文件大小不够因为 magiskboot 重打包后大小经常正好相同。路径二是设备已经起不来的时候用的从固件包里直接拿 boot.img。绝大多数 MT6735 的官方固件包是压缩包套文件夹里面有一个 scatter 文本和一堆以分区名命名的 .img。这种情况下不用担心版本问题但要确认固件包的版本号和机器背贴上的 build 号一致跨版本刷 boot 有可能因为 kernel 与 vendor 的接口不匹配而起不来。如果连固件包都没有还有第三条兜底路用刷机工具的 Readback 功能按地址读。打开 scatter 文件找到 boot 那一项的linear_start_addr和partition_size在 Readback 页里填进去长度按分区大小填读出来就是原始镜像。注意linear_start_addr在不同批次的 scatter 里是不一样的必须以你手上这份为准照抄网上的地址大概率读到别的东西。3.2 打补丁从 App 内修补到 magiskboot 命令行校验拿到 boot_stock.img 之后最稳的补丁方式是在设备上用 Magisk 应用做本地修补而不是在电脑上手工重打包。原因很简单App 里跑的是和设备同架构的 magiskboot它读得懂这颗芯片的 header 格式能原样保留 page size、kernel offset、ramdisk offset 这些字段。操作顺序是安装 Magisk 应用 → 首页“安装” → 选择“选择并修补一个文件” → 选中 boot_stock.img → 开始。完成后会在 Download 目录生成一个magisk_patched-xxxxx_xxxxx.imgpull 回电脑。补丁做完别急着刷先在电脑上做一次静态校验。这套命令我用得最多# 1) 解包补丁镜像看 header 是否被魔改 magiskboot unpack magisk_patched.img # 2) 列出 ramdisk 根目录确认 magiskinit 已经注入 magiskboot cpio ramdisk.cpio ls | head -40 # 3) 确认存在 .backup 目录原始 init 的备份和 overlay.d magiskboot cpio ramdisk.cpio exists .backup magiskboot cpio ramdisk.cpio exists overlay.d # 4) 校验原始镜像对比没有被动过 magiskboot unpack boot_stock.img cat header | head -5第一步的unpack会把镜像拆成 kernel、ramdisk.cpio、header、dtb如果有几个文件同时打印KERNEL_FMT、RAMDISK_FMT、HEADER_FMT三个值。MT6735 上常见的是HEADER_FMT为boot也就是 Android 9 之前的 v0 headerRAMDISK_FMT为gzip或者lz4_legacy。如果这里显示的不是这几个值说明你拿到的根本不是这颗芯片的 boot。第二步的cpio ls是判断补丁是否生效的核心。正常的输出里应该能看到magiskinit、overlay.d、.backup三个条目。.backup目录里存的是原始 init它存在的意义是让你能用magiskboot cpio还原回去overlay.d则是放自定义脚本的地方后面要改属性就靠它。第三步的两个exists是给脚本用的返回码 0 表示存在。把它们写进 CI 或者本地检查脚本里比肉眼看输出可靠。第四步容易漏把原始镜像也 unpack 一次用cat header对比两次的 header。如果补丁后 header 里的 page_size 变了比如从 2048 变成 4096刷上去必卡 logo这时候要用magiskboot repack显式指定--header把原始 header 塞回去。3.3 回刷、首次开机与 adb root / remount 的验证回刷这一步在 MT6735 上有两种做法fastboot 和 BROM 层工具。机器能正常进 fastboot 就走前者速度快、可回滚。# 1) 进 bootloader 并确认 fastboot 认到了设备 adb reboot bootloader fastboot devices # 2) 刷入补丁镜像只刷 boot不要碰 recovery fastboot flash boot magisk_patched.img # 3) 重启首次开机会比平时慢 1~3 分钟属正常 fastboot rebootfastboot devices如果返回空八成是 LK 没起来或者 USB 驱动问题别反复插拔直接转第 4 章的 BROM 方案。flash boot只动 boot 分区这是刻意的——把补丁镜像误刷进 recovery 分区会导致 recovery 起不来而且很多 MT6735 的 recovery 分区比 boot 小刷到一半就报长度越界。开机之后按顺序验证四件事# 1) 提权是否真的生效Magisk 会弹授权框 adb shell su -c id # 2) 看 Magisk 版本和挂载方式确认是 systemless adb shell su -c magisk -v adb shell su -c magisk --path # 3) 确认 system 分区还是只读没有被物理写入 adb shell su -c mount | grep -E /system | /system_root # 4) 需要临时改 system 时走 overlay 而不是 remount adb shell su -c cp /sdcard/test.prop /data/adb/modules/test/system/build.prop第一条id返回uid0才算通。第二条的magisk --path会输出一个/sbin或者/debug_ramdisk路径这个路径不是/system正好证明了改动没落到物理分区上这就是 systemless 的标志。第三条的mount输出里system 应该还是ro如果显示rw说明之前有人 remount 过并且没恢复那种状态下 OTA 和 verity 都会出问题。第四条演示的是正确姿势要往 system 里加文件就在模块目录下建对应的system/子目录Magisk 开机时用 overlayfs 叠上去物理分区一动不动。需要adb root的话MT6735 上要注意它是构建属性决定的不是刷个 Magisk 就能有。ro.debuggable1且ro.secure0的 userdebug 构建才能adb rootuser 构建上执行会返回adbd cannot run as root in production builds这是正常的用adb shell su代替即可。4. mtkclient 兜底刷成砖之后BROM 层还能把机器拉回来前面所有步骤都建立在“机器还能进 fastboot”这个前提上。这个前提一旦破了唯一的路就是 BROM 层。4.1 BROM 模式与 Preloader 模式的区别这两种模式经常被混为一谈实际差别很大直接决定了救砖能不能成功。对比项BROM 模式Preloader 模式触发方式关机状态下按住音量键插 USB或短接测试点preloader 正常执行后主动等待下载依赖分区无代码在芯片内部依赖 preloader 分区完好握手对象BootROM需要 Download Agentpreloader 自身典型用途救砖、整片读写、擦 eMMC常规固件刷写成功率只要芯片没物理损坏基本都能进preloader 一坏就没戏判断自己在哪个模式看设备管理器里的端口名就行BROM 一般枚举成MediaTek USB PortPreloader 枚举成MediaTek PreLoader USB VCOM。前者出现的时间窗口很短开机后一两秒所以 BROM 模式下经常需要“先点工具上的开始再插线”。4.2 读分区、写分区、强制进 BROM 的具体命令命令行工具 mtkclient 比图形界面的刷机工具更适合排错因为它每一步都能看到返回码。装好依赖后按顺序来# 1) 最安全的握手测试只读 GPT不写任何东西 python mtk printgpt # 2) 整片备份到目录慢几十分钟到几小时视容量而定 python mtk rl backup_full # 3) 只写回 boot 分区 python mtk w boot magisk_patched.img # 4) 只擦 userdata忘记锁屏、system 起不来时用 python mtk e userdata # 5) 握手失败时显式指定 preloader 文件重试 python mtk printgpt --preloaderpreloader_kai.bin # 6) 所有操作完成复位设备 python mtk reset第一条是整套流程里最重要的一条。printgpt只读 GPT 表并打印出来不改任何数据只要它能列出 preloader、lk、boot 这些名字就说明 BROM 握手成功、DA 加载成功、存储可读后面的写操作才有意义。很多人一上来就w boot握手其实没成命令超时然后误判成“工具坏了”。第二条rl是 read all 的缩写会把全部分区按名字导出到一个目录。这一步耗时取决于 eMMC 容量16GB 的机器大概 40 分钟。它的价值在于只要这份全量备份在任何误操作都能整体回滚。第三条w后面跟分区名和文件路径工具会自动按 GPT 里记录的分区边界截断或补齐。如果文件比分区大会直接报错不会写半截进去——这个行为比 fastboot 友好。第四条e是 erase只擦不写。e userdata相当于恢复出厂e frp用来清 FRP 锁e seccfg要慎用它会改变解锁状态。第五条是排错关键。--preloader把指定的 preloader 文件当作握手时的 DA 用当设备里的 preloader 版本和工具内置的不匹配、握手一直停在Waiting for preloader时指定一个同批次的文件往往能过。4.3 NVRAM / NVDATA / protect 分区比 root 更该先备份的东西我见过太多人把精力全放在“怎么 root 成功”上结果刷机时手滑点了全擦机器是起来了但插卡没信号、WiFi 打不开、蓝牙地址是一串 0。这些数据全在 nvram 和 nvdata 里而它们不在任何官方固件包的默认刷写列表里——也就是说官方固件刷一百遍也补不回来。nvram 分区里存的是射频校准参数、IMEI、WiFi 和蓝牙的 MAC 地址。这些值是在产线逐台校准写入的同型号不同批次之间都不通用。nvdata 存的是运行时的配置快照部分机型把它清掉之后会卡在激活向导反复要求联网校验。protect1 和 protect2 里放的是和安全相关的数据指纹模板、密钥材料这类东西通常挂在这里。它们被清掉的表现是“能开机、能 root但指纹录不进去”而且没有任何报错提示只有日志里一行protect partition invalid。所以备份顺序应该是nvram → nvdata → protect1/2 → seccfg → boot → 其他。前面四个加起来不到 50MB但它们决定了这台机器刷完之后是“开发板”还是“能打电话的开发板”。备份文件至少存两份一份放本机硬盘一份放移动盘只存一份的话某次误格式化就全没了那时候再想找同批次的 nvram基本只能靠运气。顺带说一句如果备份确实丢了不要试图自行改写 IMEI 去“修好”它——那是另一个层面的合规问题能不碰就不碰。正确做法永远是在第一次动手前把备份做掉。5. 避坑MT6735 root 过程中五次真实的翻车记录下面这五条都是我在 MT6735 上真实遇到过并且能稳定复现的。写出来不是为了吓人是为了让你在遇到时三分钟内定位。5.1 现象adb root提示 adbd cannot run as root in production builds原因很明确adb root走的是 adbd 的重启逻辑它检查的是ro.debuggable和ro.secure两个属性。官方正式版固件这两个值分别是 0 和 1adbd 编译时就把提权分支裁掉了跟有没有刷 Magisk 无关。解决分两种情况。如果你有源码或者能拿到 userdebug 版 boot直接刷 userdebug 镜像adb root立刻可用。如果没有就别在这上面耗时间改用adb shell su -c 命令把 su 当成提权入口写脚本时用一个变量包一层两种环境都能跑# 统一提权入口userdebug 下无 su 也能工作 if adb shell which su /dev/null 21; then SHadb shell su -c else adb root /dev/null 21; adb wait-for-device SHadb shell fi $SH id这段判断的逻辑是先看设备上有没有 su 二进制有就走 su没有就尝试adb root再等设备重连。adb wait-for-device不能省adbd 重启期间设备会短暂离线紧接着执行的命令会报device offline。5.2 现象刷完 boot.img 卡在开机 logo不进系统也不重启原因通常有两个。一是镜像大小超过了 boot 分区容量写的时候被截断二是 header 里的 page size 或加载基址和原机不一致内核压根没被正确解压。先确认大小。切到 fastboot 里看分区长度再和本地文件对比# 查 boot 分区实际容量部分 LK 支持该变量 fastboot getvar partition-size:boot # 本地镜像大小单位字节 stat -c%s magisk_patched.img如果本地文件更大说明补丁后的镜像塞不进去。MT6735 的 boot 分区常见 16MB补丁会往 ramdisk 里加 magiskinit 和几个脚本正常情况下只增加几百 KB不该超一旦超了多半是选错了源文件比如拿 recovery 当 boot 打补丁。大小没问题就往 header 上查。用magiskboot unpack boot_stock.img和magiskboot unpack magisk_patched.img各拆一次cat header对比两边的page_size、kernel_offset、ramdisk_offset、tags_offset四个字段。有任何一项不同就用原始 header 重打包# 用补丁后的 ramdisk 重新打包但强制沿用原始 header magiskboot repack boot_stock.img new_boot.imgrepack的语义是以第一个参数原始镜像为模板把当前目录下已经解包好的 kernel 和 ramdisk 装回去。把这个命令放在unpack出来的目录里执行header 就一定是原来的。5.3 现象Magisk 应用能装但打开一直转圈日志里刷 verity 相关报错根因是 dm-verity。MT6735 跑 Android 6.0 及以上的固件基本都开了 veritysystem 分区在挂载时会被逐块校验一旦发现被改过就拒绝挂载表现就是开机动画放完直接黑屏或者反复重启。正确的处理顺序是先关 verity 再刷 boot而不是反过来# 1) 在 userdebug 构建上关闭 verity 并重启 adb root adb disable-verity adb reboot # 2) 重启后确认 verity 状态 adb shell getprop ro.boot.veritymode # 期望输出 disabled # 3) 再刷补丁后的 boot adb reboot bootloader fastboot flash boot magisk_patched.imgadb disable-verity只在 userdebug 上可用正式版会返回SERVICE_NAME_NOT_FOUND。正式版的处理办法是在 boot 的 ramdisk 里改 fstab把 system 那一行的verify标志去掉这个改动可以直接写进overlay.d的post-fs-data.sh里跟着模块一起走。顺带提一个容易混淆的点网上很多教程让你刷vbmeta分区来关验证那是 Android 8 以后 AVB 的做法。MT6735 这批机器大多没有 vbmeta 分区照抄那条命令会得到partition not found别以为是命令写错了。5.4 现象刷机后能开机、能 root但插卡无信号WiFi 打开是一串 00:00:00这是最典型的一类“成功即失败”。现象背后是 nvram 被清了多半是在图形刷机工具里选了Format All Download而不是Download Only。前者会把包括 nvram、nvdata、protect 在内的全部分区格式化后者只写固件包里列出的那些。解决只有一个方向把之前备份的镜像写回去。# 依次写回射频与配置相关分区顺序不要颠倒 python mtk w nvram nvram.img python mtk w nvdata nvdata.img python mtk w protect1 protect1.img python mtk w protect2 protect2.img python mtk reset写回之后第一次开机会比平时慢很多两到三分钟内 modem 会重新初始化并读取校准参数这期间信号栏可能是空的不要急着判定失败。如果五分钟之后依然无信号用adb shell dumpsys telephony.registry看射频状态或者在日志里搜nvram关键字确认是不是写错了分区。如果压根没备份过那就只能承认这台机器的射频部分回不来了。这也是我为什么在第 2 章把 nvram 排进第一批备份的原因。5.5 现象fastboot devices永远是空的机器黑屏但插上电脑有 USB 枚举声原因分两层。浅层是 LK 没起来boot 分区炸了之后 LK 会反复尝试加载失败最终掉回 BootROM这时候设备枚举出来的是 BROM 端口而不是 fastboot 端口。深层原因是 USB 口供电或者线材问题劣质线只通电不传数据插上照样有枚举声。先排线材换一根确定能传数据的线插机箱后面的 USB 2.0 口3.0 口在 BROM 握手阶段兼容性反而差。换完还是不行直接走 BROM# 1) 设备完全断电拔电池或长按电源 15 秒按住音量下插 USB # 2) 确认工具能握手 python mtk printgpt # 3) 握手成功后直接写回原始 boot python mtk w boot boot_stock.img python mtk reset如果printgpt卡在Waiting for preloader不动加上--preloader指定文件重试。如果连 BROM 都进不去说明问题不在分区层得去查硬件了——短接点、eMMC 虚焊这类已经不是软件能解决的范围。6. 把 root 变成可复现流程一份自检脚本和两个进阶方向手工刷一次成功不叫会能重复刷十次成功才叫会。我在吃过两次“同样的步骤这次就是不行”的亏之后把所有关键判断写成了一个自检脚本每次动手前后各跑一遍。#!/usr/bin/env bash # MT6735 root 前后自检镜像侧 设备侧 set -u IMG${1:-magisk_patched.img} STOCK${2:-boot_stock.img} fail0 # 镜像侧大小、header 一致性、ramdisk 注入痕迹 [ -f $IMG ] || { echo [FAIL] 补丁镜像不存在; exit 1; } orig$(stat -c%s $STOCK); new$(stat -c%s $IMG) echo [INFO] stock$orig patched$new delta$((new-orig)) [ $new -le $((16*1024*1024)) ] || { echo [FAIL] 超过 16MB boot 分区上限; fail1; } work$(mktemp -d); cp $IMG $work/; cd $work magiskboot unpack $IMG /dev/null 21 magiskboot cpio ramdisk.cpio exists .backup || { echo [FAIL] 缺少 .backup; fail1; } magiskboot cpio ramdisk.cpio exists overlay.d || { echo [WARN] 无 overlay.d; } head -3 header | grep -qi page_size echo [INFO] header 字段$(grep -i page_size header) # 设备侧连接、构建类型、提权、system 挂载状态 adb devices | grep -q device$ || { echo [FAIL] 设备未连接; exit 1; } echo [INFO] build.type$(adb shell getprop ro.build.type | tr -d \r) adb shell su -c id 2/dev/null | grep -q uid0 || { echo [FAIL] 提权未生效; fail1; } adb shell su -c mount 2/dev/null | grep -E /system | grep -q ro, \ echo [OK] system 仍为只读systemless 成立 || echo [WARN] system 已可写 cd - /dev/null; rm -rf $work [ $fail -eq 0 ] echo 自检通过 || echo 自检未通过勿刷 脚本分两段。镜像段做三件事比对补丁前后的大小差值正常是几百 KB超过 16MB 的 boot 分区上限就说明塞爆了、确认 ramdisk 里有.backup目录、打印 header 里的 page_size 供人工核对。设备段确认连接状态、构建类型、su -c id是否返回 uid0以及 system 挂载是不是还是只读——最后这一条是判断 systemless 是否成立的硬指标比看 Magisk 版本可靠得多。脚本里grep -q ro,那个逗号不能省rw,和ro,只差一个字母省了就永远匹配上。第一个进阶方向是自编内核。MT6735 的内核源码通常随开发板资料一起给出编之前先确认arch/arm64/configs/下的 defconfig 名字编出来的 Image 用magiskboot --mkboot boot_stock.img Image new_boot.img直接替换内核而不动 ramdisk。这样做的好处是可以在内核里加 trace hook 做行为监控比用户态的抓包干净。代价是每换一次内核就要重新打一次 Magisk 补丁因为 ramdisk 里的 magiskinit 和内核对齐方式有关联。第二个方向是把整个流程脚本化、版本化。我的习惯是每台机器的备份目录下放一个MANIFEST记录原机 build 号、备份时间、每个镜像的 SHA256补丁镜像同样记一条。这样半年后回头看能立刻判断“这个镜像是哪台机器、哪个版本上打的”而不是对着一堆boot.img、boot(1).img猜。验证项通过标准检查命令镜像未超分区小于 boot 分区字节数stat -c%s对比 scatterheader 未被改写page_size 与原镜像一致magiskboot unpack后cat headerramdisk 注入成功存在.backup与magiskinitmagiskboot cpio exists提权生效uid0adb shell su -c idsystemless 成立system 挂载标志为romount | grep /system 射频数据完好插卡有信号、MAC 非全零拨号盘查状态信息坦白讲我最早也是拿着一份网上的教程直接fastboot flash boot结果把那台机器的 nvram 弄丢了到现在它还是一块只能连 WiFi 的“开发板”。从那以后我每次动手前都强制走一遍自检脚本备份不落在两个不同物理位置就不允许开始——这套习惯救回来的时间比脚本本身花的时间多得多。希望帮到你。本文还有配套的精品资源点击获取