Zlion

Z500/Z503/Z507升级小方糖公版系统

Fri, 28 Aug 2026 00:00:00 GMT

说明#

该教程由@cnjn首发于恩山论坛：中兴小方糖 Z503 刷 Z506 固件，这里进行优化，适用于小白操作。

准备工作#

操作步骤#

1. 开启Telnet#

从路由器网页管理后台导出配置文件config.bin，与一键开启Telnet脚本放在一起，双击脚本运行得到config-telnet-enable.bin，将其再从管理后台还原回去，路由器会自动重启，Telnet就打开了，默认的账密为admin。

2. 扩容分区#

使用MobaXterm新建Telnet会话连接路由器，执行下面的命令，扩容 /var 目录。

Terminal window

1
mount -o remount,size=32M /var

3. 修改设备型号#

将设备型号Z500/Z503/Z507通通改为中兴的公版型号Z506。

设置MobaXterm的TFTP服务

TFTP 目录配置参考

命令中的 192.168.5.7请替换为电脑当前的局域网 IP。

3.1 提取Tag分区#

Terminal window

1
cat /dev/mtdblock2 > /tmp/tag.bin
2
tftp -p -l /tmp/tag.bin -r tag.bin 192.168.5.7

3.2 修改Tag分区#

把提取出来的tag.bin与一键修改Tag脚本放在一起双击脚本，得到tag-Z506.bin文件，放到TFTP目录中。

3.3 写入Tag分区#

Terminal window

1
tftp -g -l /tmp/tag.bin -r tag-E2631.bin 192.168.5.7
2
cat /tmp/tag.bin > /dev/mtdblock2

4. 上传公版固件#

进入路由器管理后台，找到系统更新固件上传zxhnze50x_hv100_fv1002b28000_firmware-20230615093954.bin ,确认升级即可。重启完毕后就成功刷为公版系统了。

5. 重置#

升级完成后可以恢复出厂设置一次。

设计遥控器：一款 Android TV 手机遥控 App 的设计实录

Mon, 24 Aug 2026 00:00:00 GMT

本文档面向想要设计「手机遥控电视」类 App 的产品与开发人员，涵盖设计目标、视觉语言、信息架构、核心交互与踩坑经验。 适用系统： Android 8.0+（TV 端）/ Android 8.0+（手机端） 适用平台： 智能电视 / 电视盒子 + 安卓手机
手机遥控电视概念图

1. 为什么要重新设计遥控器#

智能电视的遥控器越做越短：按键从三十多个砍到十几个，最后只剩一个十字键加几个功能键。但电视上的内容越来越复杂——应用商店、设置菜单、登录页面、验证码输入框，都在逼着用户在「十字键一格一格挪」里浪费时间。

实体遥控器的物理极限暴露无遗：

场景	实体遥控器	手机遥控
搜索片名	十字键逐字选择	直接打字
安装应用	逐格导航到安装按钮	手机上点一下推送
输入密码	虚拟键盘逐字符移动	手机键盘直接输入
精准点击小按钮	几乎不可能	触控板 + 光标

于是我们决定做一款手机遥控 Android TV 的 App，对标市面上的八爪鱼遥控：TV 端 + 手机端双端架构，手机负责输入与展示，TV 端负责接收指令并注入系统事件。

2. 设计目标与约束#

设计开始前，先把约束摆清楚。约束不是敌人，它决定了方案的下限。

2.1 产品功能范围#

六大核心功能一个都不能少：

基础遥控（方向、确认、返回、主页、菜单、音量、电源）
App 安装推送
远程输入法（IME）
电视清理 / 加速
远程应用管理（启动 / 卸载）
基于传感器的 TV 端浮动光标

2.2 技术约束#

重要

TV 端无法开启 Accessibility 服务（部分厂商环境限制），ADB 路线也被明确排除。输入注入必须依赖 AccessibilityService 或厂商私有插件，这直接决定了浮动光标必须做成「虚拟光标」而非系统鼠标。

手机与电视在同一局域网，走 HTTP（TCP）+ UDP 自研协议
TV 端覆盖层窗口必须由 AccessibilityService 上下文创建
传感器数据驱动光标，位移采用 0..1000 归一化坐标，TV 端按分辨率缩放

2.3 设计目标#

一句话：让用户拿起手机的三秒内，就能完成一次电视操作。

3. 设计语言：为什么选 iOS 16 风格#

遥控器 App 是一个「工具」，工具的最高境界是被忽略——用户看的是电视，不是手机。因此视觉上追求极简、安静、零学习成本。

最终确定的设计规范：

元素	规范
背景色	`#F2F2F7`（iOS 分组式灰底）
卡片圆角	14dp，白色卡片浮在灰底上
图标	线性图标（stroke 风格），不用填充图标
导航	底部 Tab Bar，四个入口
特效	毛玻璃（半透明 + 模糊），仅用于顶栏与 Tab Bar
阴影	无阴影，靠灰底与白卡的对比分层

警告

明确禁用一切 Material Design 元素：FAB 悬浮按钮、ripple 水波纹、hamburger 抽屉菜单、投影卡片。这些元素一旦混入，整个界面会立刻「变味」，视觉一致性是这类工具 App 的生命线。

设计语言统一的好处立竿见影：遥控页、应用页、工具页、我的页四个页面，用户在任何一页都能凭肌肉记忆找到返回方式与操作入口。

遥控页 UI 设计稿

4. 信息架构：四个底部 Tab#

信息架构遵循「高频前置、低频收敛」原则：

遥控 App

遥控 Tab

方向键 / 触控板 / 音量

应用 Tab

安装推送 / 启动卸载

工具 Tab

清理加速 / 输入法

我的 Tab

设备管理 / 设置

遥控 App

遥控 Tab

方向键 / 触控板 / 音量

应用 Tab

安装推送 / 启动卸载

工具 Tab

清理加速 / 输入法

我的 Tab

设备管理 / 设置

遥控 Tab：默认首屏，打开 App 即用，承载 80% 的高频操作
应用 Tab：TV 端应用列表镜像，支持远程启动、卸载、推送安装
工具 Tab：清理加速、远程输入法等中低频功能
我的 Tab：设备连接状态、版本信息、设置项

底部 Tab Bar 采用毛玻璃效果，内容滚动时图标下若隐若现，既保持层次又不喧宾夺主。

5. 遥控页：一块屏幕装下整个遥控器#

遥控页是整个 App 的核心，布局从上到下分为四层：

设备状态条：当前连接的电视名称与信号状态，一眼确认「我连的是哪台电视」
触控板区：大面积手势区域，滑动即移动 TV 端光标，点按即确认
十字键区：圆形 D-pad，中心 OK 键，四向箭头线性图标
功能键排：返回、主页、菜单、音量加减、电源，一行排列

5.1 按键布局的取舍#

实体遥控器按键隔离布局，手机屏幕按使用频率布局：

方向与确认是最高频操作，占据视觉中心
音量键做成横向长条，天然对应「左右/上下滑动调音量」的心智模型
电源键放在角落，防止误触——误触电源把电视关了，是这类 App 差评的重灾区

建议

所有按键的点击热区不小于 48dp，宁可视觉留白多一点，也不要让用户在大屏手机上出现「按不中」的情况。

5.2 按键到协议的映射#

每个按键最终都会转成一条 HTTP 指令发往 TV 端：

1
{
2
  "type": "key",
3
  "action": "down_up",
4
  "keycode": 82
5
}

常用键值映射：

手机按键	keycode	说明
返回	4	KEYCODE_BACK
主页	3	KEYCODE_HOME
菜单	82	KEYCODE_MENU
音量加	24	KEYCODE_VOLUME_UP
音量减	25	KEYCODE_VOLUME_DOWN
电源	26	KEYCODE_POWER

6. 触控板：从绝对坐标到相对位移#

触控板是设计迭代中最典型的一次「推倒重来」。

6.1 第一版：绝对坐标（失败）#

最初的设计是把手指位置直接映射到 TV 屏幕坐标：手指按在触控板左上角，TV 端光标就出现在屏幕左上角。

手指按下 x,y

归一化 0..1000

HTTP POST /api/cursor

TV 端光标跳到绝对位置

手指按下 x,y

归一化 0..1000

HTTP POST /api/cursor

TV 端光标跳到绝对位置

真机测试发现致命问题：触控板面积只有巴掌大，映射到 55 寸电视上，精度完全不够——想点一个设置按钮，手指 1mm 的抖动在电视上就是几十像素的偏移，根本点不中。

6.2 第二版：相对位移 + 虚拟鼠标（成功）#

改为笔记本电脑触控板的心智模型：TV 端自己维护一个光标位置，手机只上报位移量。

手指滑动 delta

POST /api/mouse dx,dy

TV 端光标位置 + delta

滑一次光标动一点位置保持

手指滑动 delta

POST /api/mouse dx,dy

TV 端光标位置 + delta

滑一次光标动一点位置保持

对比项	绝对坐标	相对位移
精度	手指抖动被放大	多滑几次即可微调
心智模型	直接点屏幕	笔记本触控板
抬手后光标	跟随消失	保持原位
实现复杂度	低	中（TV 端维护光标）

协议设计：

1
{
2
  "dx": 120,
3
  "dy": -45,
4
  "show": true
5
}

dx / dy：0..1000 归一化相对位移，TV 端按屏幕分辨率缩放为像素
show：true 显示光标，false 隐藏，缺省保持当前状态

抬手后光标保持原位这一点尤为关键——用户可以分多次滑动，把光标「挪」到目标上再点按确认，这正是触控板体验的精髓。

7. 浮动光标：倾斜手机即可移动光标#

触控板解决了「精准」，但还有更极致的输入方式：手机拿起来，往哪边倾，光标往哪边走。

7.1 传感器选型#

手机竖直持握时，加速度计三个轴的物理含义：

轴	竖直持握时含义
X 轴 (ax)	左右倾斜量
Y 轴 (ay)	重力（约 9.8 m/s²）
Z 轴 (az)	前后倾斜量

光标速度映射：

dx=(ax−ax0)⋅k,dy=(az−az0)⋅kdx = (a_x - a_{x0}) \cdot k, \quad dy = (a_z - a_{z0}) \cdot kdx=(ax−ax0)⋅k,dy=(az−az0)⋅k

其中 ax0a_{x0}ax0、az0a_{z0}az0 是校准基准（开始控制时记录），kkk 是灵敏度系数。

提示

不用陀螺仪（TYPE_ROTATION_VECTOR）而用加速度计（TYPE_ACCELEROMETER），是因为倾斜角度比角速度更直观：手机保持某个倾斜角，光标就持续匀速移动，松回水平则停止，符合「指哪打哪」的直觉。

7.2 防抖设计#

手持必然有抖动，两个参数直接决定手感：

死区：倾斜量小于 0.6 m/s² 时视为静止，过滤手部微抖
灵敏度系数：倾斜 1 m/s² 对应光标移动速度，当前取值 4 倍基准灵敏度

完整控制流程：

是

否

进入浮动光标页

记录校准基准 ax0, az0

显示 TV 端光标

倾斜量超过死区?

按倾斜方向持续发送位移

停止移动光标保持

点按屏幕 = 点击确认

双击或按钮 = 长按

是

否

进入浮动光标页

记录校准基准 ax0, az0

显示 TV 端光标

倾斜量超过死区?

按倾斜方向持续发送位移

停止移动光标保持

点按屏幕 = 点击确认

双击或按钮 = 长按

7.3 TV 端光标渲染#

TV 端用 TYPE_ACCESSIBILITY_OVERLAY 窗口绘制光标：白色圆形主体 + 深色描边 + 中心蓝点 + 柔和光晕，直径 40px，在深浅背景上都能看清。

注意

TYPE_ACCESSIBILITY_OVERLAY 窗口必须用 AccessibilityService 的上下文创建，用 Application Context 创建的窗口不会显示，且不会抛异常——这是最难排查的一类「静默失败」。

8. 设计规范落地清单#

为保证四个页面视觉一致，落地时逐条对照检查：

全局背景 #F2F2F7，卡片白色、圆角 14dp
图标全部线性风格，笔画粗细统一
底部 Tab Bar 毛玻璃，四个入口图标 + 文字
无 FAB、无 ripple、无 hamburger、无投影
按键热区 ≥ 48dp
电源等危险操作与常规操作区隔开
页面标题与状态栏留出安全距离，不与系统状态栏重叠
顶栏显示连接状态，任何页面都能确认连接是否正常

9. 踩坑与经验#

警告

以下是真机调试中付出过代价的经验，做同类 App 时可以直接绕开。

光标窗口「静默失败」：Application Context 创建 overlay 窗口不报错但不显示，必须用 Service Context；WindowManager.addView 还必须在主线程执行，HTTP 工作线程直接调用会偶发崩溃。
重装 APK 后无障碍服务被重置：TV 端重装后服务进入 Crashed 状态，需要完整重置序列——移除服务 → 禁用 accessibility → force-stop → 重新添加 → 启用。
菜单键无焦点可回退：部分界面没有焦点节点，菜单指令应回退为在屏幕中心派发长按手势，否则用户会觉得「菜单键坏了」。
状态栏与标题重叠：未处理 insets 时页面顶部内容会钻到系统状态栏底下，需统一处理状态栏安全距离。
触控板精度：任何把「手指位置」直接映射到「大屏坐标」的方案都会死于精度不足，相对位移是唯一出路。

10. 总结#

设计一款遥控器 App，表面上是画界面，本质上是回答三个问题：

用户在什么姿势下用它——决定了按键布局与热区大小
电视端能做到什么——决定了交互方案的技术边界（虚拟光标 vs 系统鼠标）
什么样的光标移动符合直觉——决定了相对位移、死区、倾斜控制这些细节

iOS 16 风格解决的是「看起来对」，相对位移触控板和倾斜光标解决的是「用起来对」。工具类 App 的设计没有炫技空间，把每一次点击、每一次滑动做到符合直觉，就是最好的设计。

TCL 固件冻结 Google 相关进程的分析记录

Sat, 22 Aug 2026 00:00:00 GMT

本文档只记录 TCL 电视冻结 Google 相关进程的发现、确认结果和失败尝试，不提供完整的 Google 三件套安装教程。
适用设备： TCL tcl_mt5879_cn 适用系统： Android 11 / API 30，固件 V729 连接方式： ADB 192.168.5.2:5555

结论

Google 三件套 APK 可以被系统识别并安装，但无法正常运行。临时停用 com.tcl.guard 也不能解决问题。

1. 发现#

通过 ADB 检查 TCL 电视运行状态、系统组件和固件内容时，发现 TCL 系统存在针对 Google 进程的冻结逻辑。

2. 确认结果#

确认 freeze 配置中包含以下 Google 相关进程：

1
com.google.android.gms
2

3
com.android.vending:download_service
4

5
com.android.vending:instant_app_installer

这些进程分别涉及 Google Play services、Play Store 下载服务和即时应用安装服务。

同时确认：

TCL 使用 FreezeManager 管理相关进程。
com.tcl.guard 是 TCL 的守护组件，会参与进程管理。
com.tcl.providers.config 是 TCL 配置提供者，不应当作为普通应用随意停用。
Play Store 被拉回 TCL 主界面或无法继续运行时，原因更接近 TCL 系统限制，而不是单纯 APK 文件损坏。
Google 三件套包可以被 pm path 识别，说明 APK 安装本身成功。
安装成功不代表获得系统签名、特权权限或 Google 认证状态。

3. 已进行的尝试#

3.1 临时停用 `com.tcl.guard`#

执行过以下操作：

Terminal window

1
adb -s 192.168.5.2:5555 shell pm disable-user --user 0 com.tcl.guard

结果：com.tcl.guard 可以进入 disabled-user 状态，但 Google 三件套仍不能正常运行。之后已恢复：

Terminal window

1
adb -s 192.168.5.2:5555 shell pm enable --user 0 com.tcl.guard

3.2 安装 Google 三件套#

针对设备的 Android 11、32 位 armeabi-v7a 和 Android TV 环境，尝试安装：

1
com.google.android.gsf
2

3
com.google.android.gms 26.24.34
4

5
com.android.vending 52.0.20

结果：三个 APK 均可被系统识别，但 Play Store 无法正常进入，Google 相关进程也不能稳定运行。

3.3 修改 `freeze` 配置#

尝试通过 TCL content 接口修改冻结配置，目标是从 freezeProcessList 中移除 Google 相关进程。

结果：普通 ADB shell 下的 JSON 写入没有成功，原始配置保持不变。

3.4 查询或调用 TCL 特殊接口#

尝试使用 cmd feature 等接口进一步查询或修改 TCL 配置。

结果：相关功能需要更高权限或 debug 模式，普通 ADB shell 无法完成写入。

3.5 修改系统组件或刷写固件#

未执行以下高风险操作：

修改 com.tcl.tcore.apex。
修改 FreezeManager 或 freezeProcessList。
修改 boot、system、vendor、product、system_ext 分区。
刷入其他版本 TCL 固件。

原因：这些操作涉及系统签名、分区校验和变砖风险，且没有证据表明仅修改其中一处就能恢复 Google 三件套运行。

4. 最终结论#

TCL 固件确实存在冻结 Google 相关进程的机制。
已确认冻结对象包括 com.google.android.gms、com.android.vending:download_service 和 com.android.vending:instant_app_installer。
com.tcl.guard 只是相关守护组件之一，临时停用它不能绕过完整的 TCL 系统限制。
Google 三件套 APK 安装成功，但无法正常运行。
直接修改 freeze 配置、调用特殊接口等尝试均未成功。
当前结果只能确认 TCL 的冻结机制和失败原因，不能确认已经实现 Google 三件套可用。

文档版本： 2026-08-22 记录状态： 已确认冻结机制，处理尝试均未成功

E2633转正官方版分析（Telnet篇）

Tue, 04 Aug 2026 00:00:00 GMT

免责声明与使用约定

禁止以任何形式出售、打包收费、付费分发、引流获利，或将本教程及随附工具用于其他商业获利行为。
对教程、文档或工具进行二次修改、转载和再分发时，必须保留原作者 zlion。
固件刷写、Telnet和 MTD 操作均可能造成数据丢失、设备变砖或其他不可预期后果。操作者应对自己的设备和全部操作结果负责并自行承担风险。
如本文内容存在侵权、错误引用或其他权益问题，请联系作者核实；确认后将及时删除或修正相关内容。

1. Config.bin的加解密与Telnet开启#

1.1 Config.bin的加解密#

config.bin 不是明文 XML，而是 ZTE 的 Type-4 外层容器。E2631 中使用的是 AES-256-CBC。中兴巡天及其套娃机的值有多组，这里仅展示一组：

参数	值
`keySeed`	`E2631Key13515211`
`ivSeed`	`E2631Iv13515211`
`key`	`SHA256(keySeed)`
`iv`	`SHA256(ivSeed)` 取前 16 字节
填充	关闭，尾部补零到 AES 块边界

解包流程如下：

config.bin Type-4 外层容器

AES-256-CBC 解密

Type-0 内层容器

zlib 解压

最终 XML

config.bin Type-4 外层容器

AES-256-CBC 解密

Type-0 内层容器

zlib 解压

最终 XML

回写流程如下：

修改后的 XML

zlib 压缩

封装 Type-0 内层容器

AES-256-CBC 加密

写回 config.bin

修改后的 XML

zlib 压缩

封装 Type-0 内层容器

AES-256-CBC 加密

写回 config.bin

1.2 修改Config.bin开启Telnet#

这里提供一个一键开启Telnet脚本config-telnet-enable.zip

PortControl 中 TELNET 行：

1
<DM name="ServName" val="TELNET"/>
2
<DM name="PortEnable" val="1"/>

TelnetCfg 中启用 LAN、关闭 WAN：

1
<Tbl name="TelnetCfg" RowCount="1">
2
  <Row No="0">
3
    <DM name="TS_Enable" val="1"/>
4
    <DM name="Wan_Enable" val="0"/>
5
    <DM name="Lan_Enable" val="1"/>
6
    <DM name="TS_Port" val="23"/>
7
    <DM name="TS_UName" val="admin"/>
8
    <DM name="TS_UPwd" val="admin"/>
9
  </Row>
10
</Tbl>

注意

本工具由 zlion 原创，首发于 zlion.top 禁止倒卖、打包收费或用于任何商业盈利行为，转载须保留完整出处及作者署名。

使用说明

将 config-telnet-enable.bat、zte_config_telnet_enable.js 和 config.bin 放在同一个目录。
双击 config-telnet-enable.bat。
成功后，同目录会生成 config-telnet-enable.bin。
Telnet 端口为 23，账号和密码均为 admin。

运行环境：

完整工具包已经附带 node.exe，无需安装 Node.js 或 Python。
请勿单独移动 BAT；config-telnet-enable.bat、zte_config_telnet_enable.js 和 node.exe 必须放在一起。
不支持的配置会显示“config文件暂不适配”，且不会保留输出文件

2. 本机信息优化#

本节提醒

适用于保留自己设备的 Tag、Wi-Fi 等身份和无线数据分区
适用于刷了三方固件无法绑定APP（未验证APP端是否只检测设备型号，仅猜测）

2.1 Tag 、Wifi 分区读取#

在路由器 Telnet 终端执行：

Terminal window

1
cat /proc/mtd

可以看到：

1
mtd2: 00100000 00020000 "tag"
2
mtd3: 00100000 00020000 "wifi"

两者大小均为 0x100000，即 1048576 字节。

读取 Tag 分区：

Terminal window

1
cat /dev/mtd2 > /tmp/tag-backup.bin

读取 Wi-Fi 分区：

Terminal window

1
cat /dev/mtd3 > /tmp/wifi-backup.bin

确认电脑的 TFTP 服务已启动，根目录允许写入。

上传 Tag 备份：

Terminal window

1
tftp -p -l /tmp/tag-backup.bin -r tag-backup.bin 192.168.5.7

上传 Wi-Fi 备份：

Terminal window

1
tftp -p -l /tmp/wifi-backup.bin -r wifi-backup.bin 192.168.5.7

192.168.5.7请替换为电脑当前的局域网 IP。

2.2 修改Tag分区信息#

这里只需要修改型号就可以了，使用脚本改型号为E2631 把tag-backup.bin重命名为tag.bin，跟脚本放在同一级目录下，双击脚本即可得到tag-E2631.bin。这样其他信息都还是自己贴纸上的提醒一下tag分区是有校验的，Tag 中同时存在主 MAC、第二 MAC、MAC 前缀、D-SN、S/N、型号和 Wi-Fi 信息。F87*** 只是 MAC 前三字节，不是完整 MAC；

Tag分区信息

Tag结构：

1
0x00  33 33 33 33
2
0x04  payload size，小端
3
0x08  CRC32，小端
4
0x0c  记录区
5
尾部  ff 填充

CRC32 计算范围从 0x0c 开始，长度由 payload size 决定。

2.3 使用 TFTP 将 Tag 和 Wi-Fi 分区传输到路由器中去#

本节先把待写入的 tag-E2631.bin、wifi.bin 以及方案二使用的 mtd_write_tag_armv7传入路由器。以下示例中 192.168.5.7 是电脑的 TFTP 地址，请按实际网络修改。

电脑端 TFTP 根目录至少放置：

1
tag-E2631.bin
2
wifi.bin
3
mtd_write_tag_armv7

路由器 Telnet 端执行：

Terminal window

1
ping -c 3 192.168.5.7
2

3
rm -f /tmp/tag.bin /tmp/wifi.bin /tmp/mtd_write_tag
4
tftp -g -l /tmp/tag.bin -r tag-E2631.bin 192.168.5.7
5
tftp -g -l /tmp/wifi.bin -r wifi.bin 192.168.5.7
6
tftp -g -l /tmp/mtd_write_tag -r mtd_write_tag_armv7 192.168.5.7

2.3.1 写入分区：方案一，使用 cat 命令#

方案一只适用于已经确认驱动允许通过字符设备写入的设备。先写入 Tag，再写入 Wi-Fi：

Terminal window

1
cat /tmp/tag.bin > /dev/mtd2
2
sync
3

4
cat /tmp/wifi.bin > /dev/mtd3
5
sync

写入后立即在路由器端读回并校验：

Terminal window

1
rm -f /tmp/tag-readback.bin /tmp/wifi-readback.bin
2
cat /dev/mtd2 > /tmp/tag-readback.bin
3
cat /dev/mtd3 > /tmp/wifi-readback.bin
4

5
md5sum /tmp/tag.bin /tmp/tag-readback.bin
6
md5sum /tmp/wifi.bin /tmp/wifi-readback.bin

两个输入文件与读回文件的 MD5 必须分别一致。Tag 分区如果出现以下任一情况，应停止操作并改用方案二：

出现 can not create /dev/mtdblock2: Success 或类似写入错误；
命令返回但读回 MD5 不一致；

cat 对 NAND 的写入可能绕过必要的擦除、坏块和 ECC 处理；因此命令“没有明显报错”不等于写入成功。

2.3.2 写入分区：方案二，使用 MTD 写入工具#

方案二使用已经我自己编译好的 ARMv7 程序 mtd_write_tag_armv7。先确认程序架构和用法：

Terminal window

1
chmod +x /tmp/mtd_write_tag
2
/tmp/mtd_write_tag

应能看到类似用法：

1
Usage: /tmp/mtd_write_tag --yes /dev/mtdN file.bin
2
Example: /tmp/mtd_write_tag --yes /dev/mtd2 /tmp/tag.bin

确认输入文件为目标 Tag 分区大小后执行写入：

Terminal window

1
ls -l /tmp/tag.bin
2
cat /sys/class/mtd/mtd2/name 2>/dev/null
3
cat /sys/class/mtd/mtd2/size 2>/dev/null
4

5
/tmp/mtd_write_tag --yes /dev/mtd2 /tmp/tag.bin
6
sync

程序会按 MTD 的擦除块、写入页和坏块规则执行。出现 MEMUNLOCK warning: Operation not supported 或 fsync: Invalid argument 时，不要只根据警告判断成功或失败，必须继续做读回校验。

这里只在路由器端比较写入前后的 MD5：

Terminal window

1
md5sum /tmp/tag.bin
2

3
rm -f /tmp/tag-readback.bin
4
cat /dev/mtd2 > /tmp/tag-readback.bin
5
md5sum /tmp/tag-readback.bin

两次 MD5 一致，且程序没有报告擦除、写入或读回错误，才可认为 Tag 写入成功。若不一致，保留终端输出，不要重启设备，也不要继续写 Bootloader 或整片 NAND。该工具只针对 Tag 的 MTD 写入流程，不能未经验证地用于 Wi-Fi、Bootloader 或其他分区。

3. Web 本地上传分析研究(失败)#

3.1 接口和表单#

抓到的 Web 流程：

1
GET  /?_type=vueData&_tag=vue_nowversion_lua
2
POST /?_type=vueData&_tag=prepare_firmware_upgrade
3
POST /?_type=vueData&_tag=do_firmware_upgrade

multipart 字段名：

1
VersionUpload

核心表单头：

1
Content-Type: multipart/form-data; boundary=...
2
Content-Disposition: form-data; name="VersionUpload"; filename="firmware.bin"
3
Content-Type: application/octet-stream

3.2 SessionTimeout 的定位#

页面返回过 logintoken，响应头也返回过 X_XSRF_TOKEN。曾出现：

1
HTTP 200
2
IF_ERRORSTR = SessionTimeout

以及多种 token 组合均失败：

1
prepare same token  => SessionTimeout
2
prepare sessOnly    => SessionTimeout
3
prepare sessionOnly => SessionTimeout

后续在同一登录 Session 内获取页面 token、Cookie 和 XSRF token，并先调用 vue_loadprevent_data，曾得到：

1
prepare same:<page token> => SUCC

这只说明准备阶段通过，不说明上传和刷写一定成功。

3.3 升级管理器调试#

Telnet 下可以打开升级管理器日志并查看状态：

Terminal window

1
sendcmd cspd.cspd.upgrade_mgr setDebug 1
2

3
sendcmd cspd.cspd.upgrade_mgr show
4

5
sendcmd cspd.cspd.upgrade_mgr -p
6

7
sendcmd cspd.cspd.upgrade_mgr -l

show 中的 State、Location、TempDirName、FlashingPid 和 MediaPid 可帮助判断升级是否真正进入后端。研究中 Web 失败后常见：

1
State       :0
2
Location    :
3
TempDirName :
4
MediaPid    :

同时没有 /var/tmp/fw.bin，这更像请求未进入后端刷写，而不是固件已经写入。

3.4 请求体上限实验#

测试文件	现象	判断
约 300 KiB	100% 后 HTTP 200，`SessionTimeout`	能传完整请求，会话仍有问题，不进入后续校验升级流程
约 320 KiB	100% 后连接重置	接近/超过请求体限制
约 330 KiB	约 97% 后重置	multipart 边界也占空间
约 512 KiB	约 62% 后重置	设备端提前关闭连接
22,413,844 bytes 官方包	无法稳定上传	不适合该页面

300Kib测试

320Kib测试

/bin/httpd 中发现：

1
content length is beyond limit.
2
Http request body read fail.
3
Upload file fail for not enough space, g_nContentLength(%d) >= g_nAllowedSpace(%d)
4
fwrite fail when upload.
5
VersionUpload
6
/var/tmp/fw.bin
7
do_firmware_upgrade
8
my_upload_file

这证明有 body length、临时空间和写文件分支；字符串本身不能证明唯一的上限数值。

3.5 `/tmp` 空间与 Web 限制#

当时读取到：

1
/var/tmp 约 40960 KiB，可用约 40736 KiB
2
/tmp     约 20480 KiB，可用约 19456 KiB

官方包约 21.38 MiB，在 /var/tmp 理论上放得下，但仍被 HTTP 处理路径重置。磁盘空间够，不等于请求体限制够，也不等于升级进程会接受该文件。

3.6 Wireshark 过滤器#

只看 HTTP 上传：

1
ip.addr == 192.168.5.1 && ip.addr == 192.168.5.7 && tcp.port == 80

只看电脑到路由器：

1
ip.src == 192.168.5.7 && ip.dst == 192.168.5.1 && tcp.dstport == 80

只看重置/重传：

1
tcp.flags.reset == 1 || tcp.analysis.retransmission

早期过滤 udp 只能看到 DNS、多播或调试包，不能证明 HTTP 升级。抓包中由 192.168.5.1:80 返回 RST, ACK，与设备端连接关闭相符。

3.7 Web 结论#

进度 100% 只表示浏览器发完请求，不表示设备已经校验或写入。
SessionTimeout 和 ERR_CONNECTION_RESET 必须分层排查。
大于几百 KiB 的正式升级包应走 Telnet + TFTP + 本地 fw_flashing，不应继续反复提交 Web 请求。
隐藏页面是真实刷写路径，不是安全测试页面。

4. fw-flashing 与双槽启动#

4.1 参数和最小失败测试#

Terminal window

1
/bin/fw_flashing
2

3
/bin/fw_flashing -h

输出包含：

1
fw_flashing:no parameter
2
d:r:p:f:m:v:

确认 -f：

Terminal window

1
echo test > /var/tmp/fw-test.bin
2

3
/bin/fw_flashing -f /var/tmp/fw-test.bin
4

5
echo $?

输出：

1
fw_flashing name=/var/tmp/fw-test.bin,states.st_size =5
2
read magic failed!
3
GetVersionInfo error==========fw_flashing error==========

说明 -f 确实接受路径，并要求带固件 Magic/版本头。

4.2 官方包成功刷写#

电脑端确认：

Terminal window

1
dir fw.bin
2

3
certutil -hashfile fw.bin MD5

路由器获取并校验：

Terminal window

1
cd /var/tmp
2

3
rm -f /var/tmp/fw.bin
4

5
tftp -g -l /var/tmp/fw.bin -r fw.bin 192.168.5.7
6

7
ls -l /var/tmp/fw.bin
8

9
md5sum /var/tmp/fw.bin

本次包 MD5：

1
de682a3dce2b128cf7edeb8ac5f958a1

执行：

Terminal window

1
/bin/fw_flashing -f /var/tmp/fw.bin

关键输出：

1
RunningVerStartAddr:700000
2
RunningHeadHighAddr:2300000
3
g_ver_towrite=2
4
g_upgrade_startaddr=0x2300000
5
g_upgrade_endaddr=0x3f00000
6
firmware_size=22413312
7
firmware_offset=0x214
8
sect_size=0x20000
9
WriteVersion head success!
10
==========fw_flashing success==================

说明程序选择备用高槽、擦除并写入了包体，同时更新了版本头。

4.3 确认当前槽#

Terminal window

1
cat /proc/cmdline
2

3
cat /proc/zte/verinfo/versionstates
4

5
cat /proc/zte/verinfo/softVersion
6

7
cat /proc/zte/verinfo/othersoftVersion

槽位关键字段：

字段	含义
`currentverphyaddr`	当前运行物理起始地址
`backverphyaddr`	备用槽物理起始地址
`curverIsBad`	当前槽是否标坏
`backverIsBad`	备用槽是否标坏
`curverSerialNumber`	当前记录序号
`othersoftVersion`	备用槽版本记录

本次低槽运行时确认：

1
currentverphyaddr: 0x00700000
2
backverphyaddr:    0x02300000

另一次从高槽启动时，/proc/cmdline 尾部出现 0x2300000。两者一致时，才是较强的槽位证据；不能只看 root=/dev/mtdblock8。

4.4 已确认的检查方向#

从 /bin/fw_flashing 字符串、符号和运行输出来看，存在：

1
read magic failed!
2
GetVersionInfo
3
check_ver_board
4
invalid vid version!
5
CheckBootFile
6
CheckFile
7
Checkheader
8
CspUserMtdRead / Write / Erase
9
flash addr overflow
10
uImage
11
CRC
12
CspSwitchVersion

合理的校验链：

文件大小和可读性。
Magic、版本和升级头。
板型、VID、版本关系。
长度和目标槽范围。
uImage 头部/数据 CRC，具体分支由版本决定。
擦除、写入和写后读回。
写版本头、切换或等待下一次启动选择。

未找到明确 RSA 公钥验证调用。RSA 可能在 cspd、Web、BootROM 或其他库中，不能仅凭 fw_flashing 字符串判断。

5. 试错部分#

5.1 Tag 直接写失败#

尝试 cat、mknod、chmod 后仍 MD5 不一致。设备没有 mtd_debug、flash_erase、nandwrite，只有 boot_flashing、fw_flashing、upgradetest 等程序；这些程序没有暴露 Tag 写入接口。

最终只能自己编译使用 MTD ioctl 工具（mtd_write_tag）成功。

5.2 Web 反复失败#

1
升级准备失败：SessionTimeout
2
上传连接失败
3
net::ERR_CONNECTION_RESET

进度 31%、62%、97%、100% 后都见过失败。用小文件先拆分问题，确认大文件主要被 HTTP 路径限制后，停止继续提交 22 MiB 包，转为本地 fw_flashing。

5.3 `boot_flashing` 误用风险#

Terminal window

1
/bin/boot_flashing
2

3
/bin/boot_flashing -h

它要求特定带头的 Boot 文件，并直接涉及 /dev/mtd1。从 /dev/mtd1 读出的裸 1 MiB 备份不能直接作为其输入。

5.4 未验证自动回退#

已确认 currentverphyaddr、backverphyaddr、两个 IsBad 字段，但没有故意刷坏包测试回退。不要为了得到一个“确定答案”而破坏当前可启动槽。

6. 通用脚本（自行研究使用）#

6.1 目录#

1
common-tools/
2
  README.md
3
  zte_type4_config_tool.js
4
  enable_telnet_admin.bat
5
  zte_firmware_analyzer.js
6
  fw_slot_status.sh
7
  mtd_write_tag_armv7

点此下载

6.2 Type-4 配置工具#

Terminal window

1
node common-tools/zte_type4_config_tool.js inspect config.bin
2

3
node common-tools/zte_type4_config_tool.js decrypt config.bin config.xml --profile e2631
4

5
node common-tools/zte_type4_config_tool.js encrypt config.xml config-new.bin --profile e2631
6

7
node common-tools/zte_type4_config_tool.js enable-telnet config.bin config-telnet.bin --profile e2631 --user admin --password admin

其他机型必须显式提供已验证种子：

Terminal window

1
node common-tools/zte_type4_config_tool.js decrypt config.bin config.xml --key-seed MODELKeyXXXXXXXX --iv-seed MODELIvXXXXXXXX

6.3 固件分析工具#

Terminal window

1
node common-tools/zte_firmware_analyzer.js firmware.bin
2

3
node common-tools/zte_firmware_analyzer.js firmware.bin --signature-offset 0x37fdcc --signature-size 564

输出哈希、可打印头部、型号标记、uImage CRC 和指定签名区零字节数。签名区非零不等于签名有效。

6.4 写 Tag 最小清单#

Terminal window展开收起

1
cat /sys/class/mtd/mtd2/name 2>/dev/null
2

3
cat /sys/class/mtd/mtd2/size 2>/dev/null
4

5
tftp -g -l /tmp/mtd_write_tag -r mtd_write_tag_armv7 192.168.5.7
6

7
tftp -g -l /tmp/tag.bin -r tag.bin 192.168.5.7
8

9
chmod +x /tmp/mtd_write_tag
10

11
/tmp/mtd_write_tag --yes /dev/mtd2 /tmp/tag.bin
12

13
cat /dev/mtd2 > /tmp/tag_readback.bin
14

15
md5sum /tmp/tag.bin /tmp/tag_readback.bin

展开收起

只有工具报告成功且输入/读回 MD5 一致才继续。任何不一致都应停止并保存日志，不要马上重启；Tag 写入优先使用 2.3.2 的 MTD 工具方案。

创维盒子ADB动态密码在线计算器

Thu, 30 Jul 2026 00:00:00 GMT

免责说明

本工具及算法仅供技术学习与合法设备调试使用。请勿用于非法破解或侵犯他人设备隐私，使用者需自行承担相关法律责任。

说明#

创维盒子开启ADB调试时，部分型号会要求输入动态密码，该密码由MAC地址和屏幕显示的随机码共同计算得出。
本文公开的算法来源于开源项目，并搭建了在线计算页面，方便快速得到结果。

在线工具地址#

🔗 在线计算页面： https://skyworth-adb.zlion.top/

网页UI借助AI工具生成，算法核心来自开源项目 wiver53/skyworth-ADB。

动态密码算法详解#

动态密码的生成共分三步，下文以具体示例说明。

第一步：拼接原始字符串#

格式：

1
JSCMCC_SKYWORTH + [MAC 地址] + [随机码] + tianhuaxin@skyworth.com

假设设备信息如下：

MAC 地址：A1:B2:C3:D4:E5:F6
随机码：123456

拼接后的原始字符串为：

1
JSCMCC_SKYWORTHA1:B2:C3:D4:E5:F6123456tianhuaxin@skyworth.com

第二步：计算 MD5 哈希#

对上述完整字符串进行 MD5 运算，得到 32 位十六进制摘要。

例如上一步字符串的 MD5 结果：

1
e10adc3949ba59abbe56e057f20f883e

以上结果仅为示例，非真实计算结果。

第三步：计算最终动态密码#

将 32 位 MD5 字符串从中间一分为二，分别求和后相乘。

前半段：

1
e10adc3949ba59ab

后半段：

1
be56e057f20f883e

将每段中的十六进制字符转换为十进制数字后求和：

字符 3 → 3
字符 a → 10
字符 f → 15

得到两个总和后，将两者相乘，乘积即为最终的动态密码。

本地计算#

如果不想使用在线页面，也可以通过命令行计算。以下示例适用于 Linux/macOS：

Terminal window

1
# 1. 拼接字符串，请替换为实际的 MAC 地址和随机码
2
STR="JSCMCC_SKYWORTHA1:B2:C3:D4:E5:F6123456tianhuaxin@skyworth.com"
3

4
# 2. 计算 MD5
5
MD5=$(echo -n "$STR" | md5sum | cut -d' ' -f1)
6

7
# 3. 分割并求和相乘
8
python3 -c "
9
md5='$MD5'
10
half=len(md5)//2
11
s1=sum(int(c,16) for c in md5[:half])
12
s2=sum(int(c,16) for c in md5[half:])
13
print(s1*s2)
14
"

常见问题#

Q：为什么我的盒子输入密码后提示错误？#

请检查 MAC 地址和随机码是否与屏幕显示完全一致，尤其注意：

MAC 地址的大小写
MAC 地址中的冒号格式
随机码是否为最新显示的 6 位数字

Q：所有创维盒子都适用吗？#

该算法主要适用于国内运营商定制版，例如江苏移动创维盒子。其他型号可能存在差异，请以实际测试结果为准。

E2633刷入中兴官方AX3000 版本（TTL篇）

Mon, 20 Jul 2026 00:00:00 GMT

免责声明与使用约定

固件刷写、分区读写、Telnet、TTL、U-Boot 和 MTD 操作均可能造成数据丢失、设备变砖、网络中断、保修失效或其他不可预期后果。请对自己的设备和全部操作结果负责并自行承担风险。
教程中涉及的固件、商标、产品名称及第三方程序，其权利归各自权利人所有。如本文内容存在侵权、错误引用或其他权益问题，请联系作者核实；确认后将及时删除或修正相关内容。

说明#

由于是全分区整片写入，刷完后默认 WiFi 名称会变为 ZTE-Q2QHKu，密码为 bhdh3954。
所有内容仅适用于 256 MB RAM ➕ 128 MB ROM 版本。
本教程会覆盖你的所有分区，无法找回，若想保留，请先参考Telnet篇备份两个关键分区：tag、wifi。通过Telnet还原这两个分区后再重置一遍，所有信息就变成贴纸上的了，并且默认无密码。
若在TFTP传输中失败，可能是传输速度太慢，超出了MobaXterm未注册版本的开启时长限制，此问题自行解决。
鉴于部分设备有坏块的情况，会在写入128MB镜像时报错导致变砖，现在更新一下镜像，原128MB的镜像中末尾有大约13MB都是无效数据（FF），我裁切了10MB，现在镜像只有118MB了，最多容许你的设备有80个坏块（已经非常多了，正常机子几乎不可能有这么多坏块，可以在u-boot中输入nand bad 查看）

准备工作#

5元的USB 转 TTL 模块 CH340G 一个，最好带杜邦线，方便连接。
由编程器固件去掉 OOB 、并裁切10MB空间预留给坏块写入跳过的 118 MB 镜像。编程器固件来自 hzw521。
MobaXterm 等串口连接工具。
TFTP 服务工具（MobaXterm自带）。
网线一根。

操作步骤#

1. 拆机#

2. 连接 TTL 和网线#

使用网线连接电脑和路由器，参考下图连接 TTL：

TTL 接线参考

3. 进入 U-Boot#

连接好后，使用 MobaXterm 软件进行串口连接，波特率设置为 115200：

设置配置参考

路由器上电后马上按 1 中断系统启动，输入密码进入 U-Boot（密码来源见论坛）：

1
5cE080@fyBD

4. 配置电脑网络和 TFTP#

关闭防火墙，将电脑 IPv4 改为手动配置：

IP 地址：192.168.10.1
子网掩码：255.255.255.0

设置固件存放目录。此时先不要开启 TFTP 服务。

TFTP 目录配置参考

5. 在串口终端设置 IP#

在 u-boot 串口终端中输入：

Terminal window

1
setenv ipaddr 192.168.10.2
2
setenv serverip 192.168.10.1
3
ping 192.168.10.1

看到类似下面的提示即表示通信正常：

1
host 192.168.10.1 is alive

此时再启动前面配置好的 TFTP 服务。

6. 通过 TFTP 传输并刷写固件#

在串口终端中通过 TFTP 将固件传到 RAM：

Terminal window

1
tftp 0x43000000 e2631_no_oob_trim_tail_ff_10MiB.bin

传输完成后，确认下载大小必须为：

1
Bytes transferred = 123731968 (7600000 hex)

确认无误后，擦除整片 NAND：

Terminal window

1
nand erase 0x0 0x8000000

应当看到以下输出

1
NAND erase: device 0 whole chip
2
Erasing at 0x7fe0000 -- 100% complete.
3
OK

然后一次性写入：

Terminal window

1
nand write 0x43000000 0x0 0x7600000

应当看到以下输出

1
NAND write: device 0 offset 0x0, size 0x7600000
2
 123731968 bytes written: OK

7. 重启#

刷写完成后执行：

Terminal window

1
reset

此时还可以在串口终端中看到系统启动的日志：

1
Boot SPI NAND
2
start read bootheader
3
start read secondboot
4
non secure boot
5
Jump
6

7
enter bootloader...
8
crpm init enter
9
crpm init done
10
ddr init enter, rate is 1333 Mbps
11
5ddr init done
12
serial init start
13
serial init done
14
SPI NAND
15
non secure uboot
16
backup header!!
17
Jump
18

19
.............

展开收起

最后停在Starting kernel ...代表系统已经成功启动。

联想小新 Pro16 2021 AMD 黑苹果安装教程

Fri, 02 Jun 2023 00:00:00 GMT

本文档面向联想小新 Pro16 2021 AMD 版用户，整理黑苹果安装、EFI 调整与 OpenCore 启动项配置流程。 适用机型： 联想小新 Pro16 2021 AMD（5600H / 5800H） 适用系统： macOS Big Sur / Monterey / Ventura 13.x（取决于镜像与 EFI 支持）

1. 准备工作#

重要

开始前请先确认硬盘型号不在不兼容列表内，并备份 Windows 与重要数据。调整 ESP 分区和抹盘都有数据风险。

硬盘兼容列表参考：https://macoshome.com/hackintosh/hcourse/2476.html

1.1 下载所需文件#

文件	地址	说明
EFI	`https://wwbnc.lanzoub.com/b007up95be`，密码：`zlion`	5600H 与 5800H 使用不同 EFI，请按机型替换
macOS 镜像	`https://cloud.189.cn/t/BbyEFnE7FBJb`，访问码：`uzx8`	安装版本取决于镜像
DiskGenius	`https://www.diskgenius.cn/`	用于检查硬盘、调整 ESP 分区、复制 EFI

1.2 检查 BIOS#

开机按 F2 进入 BIOS。
关闭「快速启动」和「安全启动」。

1.3 调整 ESP 与 macOS 分区#

建议

Windows 默认 ESP 分区通常只有 100 MB。如果无法直接扩容，可进入微 PE 后使用 DiskGenius 调整分区。

如果 ESP 小于 200 MB，可从 C 盘左侧腾出约 100 MB，再合并到 ESP 分区。
单独划分一个用于安装 macOS 的分区，建议 60 GB 以上；示例环境分配约 160 GB。

图 2：ESP调整

2. 制作启动 U 盘#

2.1 写入镜像#

准备一个大于 16 GB 的 U 盘，使用 balenaEtcher 写入 macOS 镜像。

打开 balenaEtcher。
选择下载好的 macOS 镜像。
选择目标 U 盘。
点击 Flash，等待出现 Complete。

2.2 处理 EFI 文件#

使用 OCAT 打开 EFI/OC/config.plist。
取消勾选 Nootedred.kext，保存配置。

图 3：取消勾选 Nootedred.kext

打开 DiskGenius，选中 U 盘的 EFI 分区。
将调整后的 EFI 文件夹完整复制进去，最终路径应类似：

1
EFI(X:)/EFI/OC

3. 开始安装 macOS#

警告

抹掉分区会清空目标分区数据。请确认选择的是为 macOS 单独划出的分区，不要误选 Windows 分区。

插入启动 U 盘，开机按 F12。
选择 USB 启动项。
在 OpenCore 菜单中选择 Install macOS Big Sur 并按 Enter。
等待代码加载完成，进入 macOS 实用工具界面。

图 4：OpenCore 启动菜单

图 5：代码加载界面

打开「磁盘工具」。
选中之前划出的 macOS 分区，点击「抹掉」。
格式选择 APFS，完成后返回实用工具界面。
选择「安装 macOS」，按提示继续安装。

图 6：macOS 实用工具

提示

安装过程中可能会重启 1 到 2 次。如果重启后回到 Windows，请再次按 F12 进入 U 盘启动项，并选择 Installer 继续安装。

4. 调整 EFI 文件#

完成安装后，需要调整 EFI，避免每次启动都显示冗长代码，并为本机生成独立序列号。

打开最初未修改的 EFI 文件。
使用 OCAT 打开本机适配 EFI：

1
联想小新 Pro16 2021 5600H/EFI/OC/config.plist

找到 NVRAM 第三行，双击编辑并删除对应启动参数-v。

去掉启动界面跑码参数

图 7：正常开机无跑码

生成并写入本机专属序列号，避免多人共用同一套序列号。
保存修改后的最终 EFI。

图 8：OCAT 调整序列号

5. 设置 OpenCore 启动项#

设置完成后，就不需要每次插 U 盘进入 macOS。

回到 Windows。
使用 DiskGenius 打开硬盘 ESP 分区。
将最终 EFI 中的 OC 文件夹完整复制到：

1
ESP/EFI/

复制后，OC 应与原本的 Microsoft、Boot 文件夹并列。

图 9：硬盘 ESP 中的 OC 文件夹

在 DiskGenius 工具栏选择「设置 UEFI BIOS 启动项」。
点击「添加」，按以下路径选中 OpenCore.efi：

1
ESP/EFI/OC/OpenCore.efi

保存启动项。
将新增的 OpenCore 启动项移动到最上方，作为默认启动项。

图 10：添加 OpenCore UEFI 启动项

建议

日常默认进入 macOS；需要进入 Windows 时，开机按 F12 手动选择 Windows 启动项。

6. 补充注意事项#

2021 款小新 Pro16 存在网卡限制：自带有线网卡无法驱动，不能直插网线。
可通过 USB 网卡或手机 USB 网络共享上网，iPhone 通常无需额外驱动。
不要在 macOS 内直接在线更新系统大版本，否则可能导致无法开机或引导失效。
如需交流，可加入 QQ 群：https://qm.qq.com/q/y1tjknEfcG。

7. 故障排查#

问题	处理方式
OpenCore 菜单一闪进入 Windows	开机后尽快用方向键选择 macOS 安装项，或重新检查 U 盘启动顺序
安装中途重启回 Windows	再次按 `F12` 进入 U 盘，选择 `Installer` 继续安装
找不到 OpenCore 启动项	检查 `ESP/EFI/OC/OpenCore.efi` 是否存在，并重新添加 UEFI 启动项
macOS 无法联网	使用 USB 网卡或手机 USB 网络共享
更新后无法启动	不建议在线升级大版本；恢复原 EFI 或重新制作安装 U 盘排查

Zlion

Z500/Z503/Z507升级小方糖公版系统

说明#

准备工作#

操作步骤#

1. 开启Telnet#

2. 扩容分区#

3. 修改设备型号#

3.1 提取Tag分区#

3.2 修改Tag分区#

3.3 写入Tag分区#

4. 上传公版固件#

5. 重置#

设计遥控器：一款 Android TV 手机遥控 App 的设计实录

1. 为什么要重新设计遥控器#

2. 设计目标与约束#

2.1 产品功能范围#

2.2 技术约束#

2.3 设计目标#

3. 设计语言：为什么选 iOS 16 风格#

4. 信息架构：四个底部 Tab#

5. 遥控页：一块屏幕装下整个遥控器#

5.1 按键布局的取舍#

5.2 按键到协议的映射#

6. 触控板：从绝对坐标到相对位移#

6.1 第一版：绝对坐标（失败）#

6.2 第二版：相对位移 + 虚拟鼠标（成功）#

7. 浮动光标：倾斜手机即可移动光标#

7.1 传感器选型#

7.2 防抖设计#

7.3 TV 端光标渲染#

8. 设计规范落地清单#

9. 踩坑与经验#

10. 总结#

TCL 固件冻结 Google 相关进程的分析记录

1. 发现#

2. 确认结果#

3. 已进行的尝试#

3.1 临时停用 com.tcl.guard#

3.2 安装 Google 三件套#

3.3 修改 freeze 配置#

3.4 查询或调用 TCL 特殊接口#

3.5 修改系统组件或刷写固件#

4. 最终结论#

E2633转正官方版分析（Telnet篇）

1. Config.bin的加解密与Telnet开启#

1.1 Config.bin的加解密#

1.2 修改Config.bin开启Telnet#

2. 本机信息优化#

2.1 Tag 、Wifi 分区读取#

2.2 修改Tag分区信息#

2.3 使用 TFTP 将 Tag 和 Wi-Fi 分区传输到路由器中去#

2.3.1 写入分区：方案一，使用 cat 命令#

2.3.2 写入分区：方案二，使用 MTD 写入工具#

3. Web 本地上传分析研究(失败)#

3.1 接口和表单#

3.2 SessionTimeout 的定位#

3.3 升级管理器调试#

3.4 请求体上限实验#

3.5 /tmp 空间与 Web 限制#

3.6 Wireshark 过滤器#

3.7 Web 结论#

4. fw-flashing 与双槽启动#

4.1 参数和最小失败测试#

4.2 官方包成功刷写#

4.3 确认当前槽#

4.4 已确认的检查方向#

5. 试错部分#

5.1 Tag 直接写失败#

5.2 Web 反复失败#

5.3 boot_flashing 误用风险#

5.4 未验证自动回退#

6. 通用脚本（自行研究使用）#

6.1 目录#

6.2 Type-4 配置工具#

6.3 固件分析工具#

6.4 写 Tag 最小清单#

创维盒子ADB动态密码在线计算器

说明#

在线工具地址#

3.1 临时停用 `com.tcl.guard`#

3.3 修改 `freeze` 配置#

3.5 `/tmp` 空间与 Web 限制#

5.3 `boot_flashing` 误用风险#