随身WiFi 救砖之路 · 第一回从 chroot 到删框架到变砖关键词UFI103_CT | 高通 MSM8916 | 随身WiFi 刷机 | Android 删框架 | 内核打补丁 | 变砖 | boot 分区阅读时长15 分钟适合人群手上有高通随身WiFi/盒子想改造成 Linux 服务器、又不怕折腾的玩家〇、写在前面为什么会有这篇文章本系列记录了我把一台电信定制的随身 WiFiUFI103_CT改造成无头 Linux 服务器的全过程。这是第一回从成功 chroot 到头脑发热删掉 Android 框架最终把设备干成砖的心路历程。第二回9008 救砖 chroot 成功见同目录另一篇。⚠️本文所有操作都有明确风险刷机有风险折腾需谨慎全篇包含直接把设备刷成砖的真实案例。一、设备背景先认清你的猎物这台设备是一个典型的高通随身 WiFi 改造成服务器素材项目值备注设备型号UFI103_CT电信定制随身 WiFi带电池/USB供电SoC高通 MSM8916骁龙41032位 ARM2014 年的经典芯片系统Android 4.4.4KitKatarmv7内存402MB RAM 196MB swap很小跑轻量服务够用存储/data 2.4G 空闲足够装 Debian rootfs 应用序列号4a3388afadb 识别用RootMagisk 22.0提权在内核 ramdiskAPK 只是遥控器Boot 分区/dev/block/mmcblk0p2216MB32768 扇区特点无屏幕、无按键只有复位孔—— 属于典型的无头设备双卡NV RUIM电信定制WiFi 芯片WCNSSpronto 方案/system/lib/modules/pronto/pronto_wlan.ko二、目标我想干嘛把热点发射器改成WiFi 客户端 Linux 服务器改造前随身WiFi 开热点MIFI-A009手机连它上网 改造后随身WiFi 连家里路由器Xiaomi_F5A3PC 通过它 SSH 进 Debian具体清单WiFi 从热点模式切到STA 客户端连家里Xiaomi_F5A3开机自动连接 adb 无线端口10242宿主机 Debian chroot跑 SSH/nginx 等轻量服务三、前期探索这些全成功了3.1 格式化 /data 后 su 依然可用Magisk 机制验证很多人以为卸载面具 App 就失去 root实测证明用户格式化 /data → 重装 Magisk-v22.0.apk → su 恢复 再卸载全部 APK0 个用户 APK重启 → su 依然 uid0结论Magisk 22.0 的提权逻辑全在内核 ramdisk/sbin/magisk系列APK 只是个遥控器。*所以哪怕系统 UI 全没su 照样能用——这给后面删框架提供了底气也是悲剧的伏笔。3.2 热点机制查清为什么默认是热点svc wifi enable → 实际是起 hostapd 热点 配置文件: /data/misc/wifi/softap.conf SSID: MIFI-A009 IP: 192.168.100.1 密码: 1234567890坑系统活着时Tethering/netd 会反复brctl addif bridge1 wlan0抢回接口。所以想切 STA 必须绕过系统层——这就是为什么后来要停框架/删框架。3.3 手动 STA 验证成功最振奋的一次1. stop zygote ← 停整个 Java 框架 2. 杀 hostapd 拆桥 3. 手动起 wpa_supplicant wpa_supplicant -Dnl80211 -iwlan0 \ -c/data/misc/wifi/wpa_supplicant.conf \ -O/data/misc/wifi/sockets 4. wpa_stateCOMPLETED ← WPA2 连上 Xiaomi_F5A3 5. dhcpcd → 拿到 192.168.31.206 6. 手动加路由 ip route add 192.168.31.0/24 dev wlan0 默认路由曾报 unreachable必须手动加这次成功证明设备硬件/驱动完全支持 STA 客户端只是系统不提供入口。同时也埋下伏笔要是系统一直活着Tethering 永远抢接口 → 干脆删了框架一了百了。四、删框架灾难的起点但当时认为是正解4.1 决策过程既然框架zygote/system_server对当服务器毫无用处框架活着还会抢 WiFi 接口su 又在内核里不怕删结论物理删除 Java 框架层。4.2 执行命令# 先备份最关键的一个cp/system/framework/core.jar /data/fw_backup/# 物理删除框架rm/system/framework/*.jarrm/system/framework/*.odexrm/system/bin/app_processrm/system/bin/dalvikvmrm/system/bin/dex2oatrm/system/bin/dexopt4.3 绝对保留清单删框架的铁律文件作用能不能删/system/bin/linker动态链接器所有 ELF 靠它❌必留/system/lib/libc.soC 库❌必留/system/bin/sh→mkshshell❌必留/system/lib/modules/pronto/pronto_wlan.koWiFi 驱动❌必留经验删 /system 前必须 adb rootcat 写文件会解引用软链接曾经因此覆盖过 /system/bin/toolbox血泪教训。4.4 删完的效果看起来很美zygote / system_server / hostapd ← 全没了Java 层 adbd / magiskd / su ← 全活native 层 surfaceflinger / netd / rild / vold ← 全活wcnss 驱动不再自动加载需要手动insmod /system/lib/modules/pronto/pronto_wlan.ko# 加载后 phy2/wlan0 出现当时以为完美系统干净了可以安心装 Debian 了。五、反复硬重启第一个警钟5.1 症状四灯全亮 → 熄灭 → 重启 uptime 17~69s 归零无限循环 设备在线窗口极短操作必须赶窗口5.2 dmesg 诊断关键证据Power-off reason: Triggered from PS_HOLD (PS_HOLD/MSM controlled shutdown) Power-on reason: Hard Reset and cold boot翻译软件主动断电PS_HOLD 触发 硬复位。这是内核看门狗在干活。5.3 排除项避免误判温度正常 43~46°C不是过热/dev/watchdog 不存在不是用户态 watchdog/proc/sys/kernel/panic5tombstone 全是 sh/ls SIGPIPE我命令的噪音非系统崩溃5.4 真正的根因链删了 app_processzygote 的可执行文件 → init 反复尝试启动 zygote → 失败 → 失败 → 失败 → 每次失败触发 onrestart 重启 media netd → 重启用完又失败 → 循环 → 内核触发 watchdog / panicpanic5 → 5秒后重启 → Hard Reset本质init 是死脑筋你删了 zygote 它也要一遍遍拉最后系统被自己耗死。六、内核打补丁第二次自救尝试6.1 思路和当年 ZTE 盒子同套路既然 zygote 起不来那就别让它起——给 init.rc 里的 zygote 加disabled从源头掐断循环。6.2 完整操作流程① 拉 boot 分区adb shellsu-cdd if/dev/block/mmcblk0p22 of/data/local/tmp/boot.img bs4096adb pull /data/local/tmp/boot.img /tmp/boot.img# 16777216 字节 16MB确认 Android bootimg, page size 2048② 解包abootimg-x/tmp/boot.img# 得到zImage(5857552B) initrd.img(938766B) bootimg.cfg# 解开的 ramdisk 里发现 Magisk 全家桶# magiskinit(179544B)# .backup/init原版 init 备份# .backup/.magiskKEEPVERITYfalse, SHA18c9d7cae...# .rmlistoverlay.d/sbin/magisk32.xz③ 改 init.rcpython 精确替换只动 zygote 一处# 服务定义原样servicezygote /system/bin/app_process-Xzygote/system/bin--zygote--start-system-server class main socket zygote stream660root system onrestartwrite/sys/android_power/request_state wake# 补丁后servicezygote /system/bin/app_process-Xzygote/system/bin--zygote--start-system-server class main disabled ← 新增这一行 socket zygote stream660root system onrestart...用 python 是因为 sed 会误伤class main下的其他服务比如 drm 就被误伤过一次后来修回来了。④ 重打包 ramdisk# 解包 → 改 → 重新 cpiogzip# 得到 initrd_new.img943870B比原版大 5104B 补丁增量⑤ 用 abootimg -u 更新 boot-r 指定新 ramdisk保留 zImage/头部偏移abootimg-u/tmp/boot.img-r/tmp/boot_extract/initrd_new.img⑥ 刷前备份这是后来唯一救命的东西adb shellsu-cdd if/dev/block/mmcblk0p22 of/data/local/tmp/boot_orig_backup.img bs4096# 刷前分区的逐字节完整备份16MB⑦ push dd 写回 回读验证adb push /tmp/boot.img /data/local/tmp/boot_new.img adb shellsu-cdd if/data/local/tmp/boot_new.img of/dev/block/mmcblk0p22 bs4096adb shellsu-cdd if/dev/block/mmcblk0p22 of/data/local/tmp/boot_verify.img bs4096adb pull...# PC 端 MD5 对比# 9ceef4ad4763cb8ee5e658a8fe0c6768 9ceef4ad4763cb8ee5e658a8fe0c6768 ✅ 写入无损七、变砖结局7.1 时间线16:31 dd 写入补丁版 boot 回读验证 MD5 一致 16:32 adb reboot 16:34 设备离线 → 等 3 分钟 → 不回来 16:40 USB 树里彻底消失无 adb、无 fastboot、无 9008 → 变砖bootloader 级别拒绝启动7.2 变砖根因复盘后来才查明的真相做法结果Magisk 打补丁保持 boot头部原封不动只改 ramdisk 字节 → bootloader 校验通过 ✅我abootimg重建了整个 headerid[8]SHA1 摘要区和 name 区都变了 → 高通 lk bootloader 校验失败 →拒绝启动❌逐字节 diff 证据头部差异 23 字节分布 偏移 16-17 ramdisk_size正常ramdisk 变大 偏移 42 name 区异常 偏移 576-595 id[8] SHA1 签名区关键原版全 0修改版被工具算了个新值教训一句话这种板子刷 boot 必须像 Magisk 一样原地改字节不能整个重打包。八、变砖后的资产盘点还有没有救资产位置状态说明完整原版 bootdd 备份设备/data/local/tmp/boot_orig_backup.img⚠️ 在设备里最权威进 9008 后能导出原始内核 zImagePC/tmp/boot_extract/✅未动过原始 ramdiskPC/tmp/boot_extract/✅未打补丁的原版原始 boot 头PC/tmp/boot_extract/bootimg.cfg✅偏移/cmdline重建原版 bootPC 桌面/随身wifi_boot备份/01_boot_原版rebuilt.img✅内容 100% 原版头部后配补丁版 boot罪魁PC 桌面/随身wifi_boot备份/02_boot_修改版⚠️就是它刷砖的关键判断重建版内容验证过字节级一致内核 ramdisk MD5 对上但头部 id0 是后配的 →不敢赌唯一 100% 原版 设备里那份 dd 备份 →但设备失联拿不出来结论救砖的唯一钥匙 让设备进 9008把备份导出来 / 直接刷同型号固件包九、当时的五条总结动手前必备份—— 5 分钟的 dd 备份 后面的全部希望改 boot 不能重打包—— 高通 lk 校验头部Magisk 式原地改才是正道init 是死脑筋—— 删了 zygote 它也会一遍遍拉必须从 init.rc 源头掐断9008 是最终底牌—— 只要 EDL 能进变砖重装系统这台设备救不救得回来取决于够不够备份包9008这三样十、FAQQ: 为什么恢复出厂不能救A: 恢复出厂只擦 /data /cache不还原 /system。framework 是我物理删的恢复出厂不会变回来。Q: 为什么不让 init 直接不启动 zygote 就完了A: 思路对但实现错了。正确做法应该是 Magisk 式原地改字节改 init.rc而不是 abootimg 重打包整个 boot 头。Q: 删框架到底能不能成功当服务器A: 能。第二回里最终救回来后就不删框架了直接 chroot Debian宿主 Android 只当引导网络层——这才是正解。Q: /data/fw_backup 里的 core.jar 有用吗A: 留着没坏处。但整体框架没了单一个 jar 也拼不回去救砖靠的是 boot 分区备份 固件包。—— 第一回 完第二回9008 救砖 chroot 成功同目录