Shiyan

Firefly 博客接入 Pages CMS：浏览器里写文章，不用本地环境

Sat, 12 Sep 2026 00:00:00 GMT

本文档面向使用 Firefly（Astro）主题、仓库托管在 GitHub 的博主，涵盖 Pages CMS 的接入步骤、.pages.yml 逐段讲解与踩坑记录。 适用主题： Firefly（Astro 内容集合架构，其他 Astro 博客同样适用） 适用平台： app.pagescms.org（浏览器内操作，无需本地环境）

一、Pages CMS 是什么#

Pages CMS 是一个架在 GitHub 仓库之上的在线内容管理后台：登录后选好仓库和分支，它把仓库里的 Markdown 文章渲染成可视化的编辑界面，写完点保存就是一次 Git 提交。

对静态博客来说，这条链路非常舒服：

浏览器里写作

Pages CMS 保存

GitHub 自动 commit

部署平台构建

网站更新

浏览器里写作

Pages CMS 保存

GitHub 自动 commit

部署平台构建

网站更新

不用开电脑上的编辑器，不用敲 git 命令，手机、平板、别人的电脑都能写；部署平台（Vercel / Cloudflare Pages / EdgeOne 等）本来就会在收到提交后自动构建，所以「保存」约等于「发布」。

建议

如果你在本地已经有一套顺手的写作流程，Pages CMS 也不冲突：出门在外用 CMS 补一篇，回来 git pull 接着写就行，两边操作的是同一个仓库。

二、接入三步走#

2.1 仓库根目录新建 `.pages.yml`#

这是 Pages CMS 的唯一配置文件，它读取内容集合、字段、媒体目录全靠它。一份能直接用的完整配置在第四节，抄进去先跑通，再看第五节的逐段讲解按需调整。

2.2 建好媒体上传目录#

配置里会把上传图片的目录指到 public/images，空目录 Git 不会跟踪，先放一个占位文件：

Terminal window

1
mkdir -p public/images
2

3
touch public/images/.gitkeep

2.3 打开 CMS 确认#

登录 app.pagescms.org（用 GitHub 账号授权），选中你的仓库和分支，左侧就会出现配置里定义的内容集合和 Media 面板。侧边栏 Admin 里的 Configuration 页面显示的就是 .pages.yml 本身，以后想改配置也可以直接在这个输入框里改，保存即提交。

提示

Pages CMS 按分支读配置，确认页面地址里的分支和你部署用的分支一致（Firefly 默认是 master）。

三、避坑前置：字段必须覆盖 front matter#

这一节是整篇文章最重要的一句话，先说结论：

警告

CMS 编辑器里没有的字段，保存时会被直接从 front matter 里删掉。

Pages CMS 保存一篇文章时，是按 .pages.yml 里定义的字段列表重新生成 front matter 的。我在接入过程中就实际中过招：旧配置里没有定义 author 字段，用 CMS 保存一次文章后，front matter 里的 author: 世琰 就没了。

所以动手之前，先翻一下自己文章的 front matter，把所有想保留的键都在配置里给出对应字段——包括 author、password、series 这类低频字段。Firefly 主题自带的字段全集见 src/content.config.ts，照着抄不会漏。

四、完整配置（可直接抄）#

1
# Pages CMS 配置，字段与 src/content.config.ts 的 Astro 内容集合一一对应；
2
# 留空的字段保存时会被自动省略，交给 Astro 的 zod 默认值处理，不会写出 null / ""。
3

4
media:
5
  input: public/images        # 上传的文件存到仓库的这个目录
6
  output: /images             # 写进文章里的 URL 前缀
7
  rename: random              # 上传时随机重命名，避免中文文件名和重名覆盖
8

9
content:
10
  # ── 文章 ─────────────────────────────────────────────
11
  - name: posts
12
    label: 文章
13
    type: collection
14
    path: src/content/posts
15
    format: yaml-frontmatter
16
    filename:
17
      template: '{year}-{month}-{day}-{primary}.md'
18
      field: create           # 新建文章时弹出文件名输入框，自己起名
19
    view:
20
      fields: [title, published, draft, category]
21
      primary: title
22
      sort: [published]
23
      default:
24
        sort: published
25
        order: desc
26
    # 集合会把目录里的图片也当成条目列出来，把已有配图的文件名列进来即可
27
    exclude: [cover.png, hero.png, my-cover.png]
28
    fields:
29
      - name: title
30
        label: 标题
31
        type: string
32
        required: true
33
      - name: published
34
        label: 发布日期
35
        type: date
36
        required: true
37
      - name: updated
38
        label: 更新日期
39
        type: date
40
        default: ''           # 不自动填今天，需要时再手动选
41
      - name: draft
42
        label: 草稿
43
        type: boolean
44
        default: false
45
      - name: description
46
        label: 摘要
47
        type: text
48
      - name: image
49
        label: 封面图
50
        type: image
51
      - name: category
52
        label: 分类
53
        type: string
54
      - name: tags
55
        label: 标签
56
        type: string
57
        list: true
58
      - name: pinned
59
        label: 置顶
60
        type: boolean
61
        default: false
62
      - name: lang
63
        label: 语言
64
        type: string
65
        description: 留空跟随站点默认
66
      - name: author
67
        label: 作者
68
        type: string
69
      - name: comment
70
        label: 开启评论
71
        type: boolean
72
        default: true
73
      - name: password
74
        label: 访问密码
75
        type: string
76
        description: 留空则不加密
77
      - name: passwordHint
78
        label: 密码提示
79
        type: string
80
      - name: series
81
        label: 系列名
82
        type: string
83
      - name: seriesOrder
84
        label: 系列序号
85
        type: number
86
      - name: sourceLink
87
        label: 原文链接
88
        type: string
89
      - name: licenseName
90
        label: 许可证名称
91
        type: string
92
      - name: licenseUrl
93
        label: 许可证链接
94
        type: string
95
      - name: body
96
        label: 正文
97
        type: rich-text
98

99
  # ── 动态（说说 / 微博式短内容）────────────────────────
100
  - name: dynamic
101
    label: 动态
102
    type: collection
103
    path: src/content/dynamic
104
    format: yaml-frontmatter
105
    filename: '{year}-{month}-{day}-{hour}{minute}{second}.md'
106
    view:
107
      fields: [published, pinned, location]
108
      primary: published
109
      sort: [published]
110
      default:
111
        sort: published
112
        order: desc
113
    fields:
114
      - name: published
115
        label: 发布时间
116
        type: date
117
        required: true
118
        options:
119
          time: true
120
          format: 'yyyy-MM-dd HH:mm:ss'
121
      - name: pinned
122
        label: 置顶
123
        type: boolean
124
        default: false
125
      - name: location
126
        label: 位置
127
        type: string
128
      - name: body
129
        label: 内容
130
        type: rich-text
131

132
  # ── 独立页面（about / friends / guestbook）────────────
133
  # 路由在主题里是写死的，禁用新建 / 重命名 / 删除
134
  - name: spec
135
    label: 独立页面
136
    type: collection
137
    path: src/content/spec
138
    format: yaml-frontmatter
139
    operations:
140
      create: false
141
      rename: false
142
      delete: false
143
    view:
144
      fields: [title, description]
145
      primary: title
146
    fields:
147
      - name: title
148
        label: 页面标题
149
        type: string
150
      - name: description
151
        label: 页面描述
152
        type: string
153
      - name: body
154
        label: 页面内容
155
        type: text           # 纯文本源码模式，防止富文本弄乱 JSX
156

157
  # ── 项目展示（可选，不需要就整段删掉）────────────────
158
  - name: projects
159
    label: 项目
160
    type: collection
161
    path: src/content/projects
162
    format: yaml-frontmatter
163
    filename:
164
      template: '{primary}.md'
165
      field: create
166
    exclude: [images]
167
    view:
168
      fields: [title, published, status, order]
169
      primary: title
170
      sort: [published]
171
      default:
172
        sort: published
173
        order: desc
174
    fields:
175
      - name: title
176
        label: 项目名
177
        type: string
178
        required: true
179
      - name: published
180
        label: 发布日期
181
        type: date
182
        required: true
183
      - name: draft
184
        label: 草稿
185
        type: boolean
186
        default: false
187
      - name: order
188
        label: 排序权重
189
        type: number
190
        description: 越大越靠前
191
      - name: description
192
        label: 描述
193
        type: text
194
      - name: image
195
        label: 封面图
196
        type: image
197
      - name: status
198
        label: 状态
199
        type: select
200
        options:
201
          values: [planning, developing, published, archived]
202
          placeholder: 未设置
203
      - name: tags
204
        label: 标签
205
        type: string
206
        list: true
207
      - name: lang
208
        label: 语言
209
        type: string
210
      - name: link
211
        label: 相关链接
212
        type: object
213
        list: true
214
        fields:
215
          - name: label
216
            label: 名称
217
            type: string
218
          - name: icon
219
            label: 图标
220
            type: string
221
            description: Iconify 图标名，如 fa7-brands:github
222
          - name: value
223
            label: 链接地址
224
            type: string
225
      - name: body
226
        label: 详情
227
        type: rich-text

展开收起

提示

我的仓库里 exclude 实际排除了 30 个历史配图文件名，上面为了可读性缩成了示例。把你自己 src/content/posts 目录下的图片文件名列全就行。

五、配置逐段拆解#

5.1 media：图片传到哪、URL 长什么样#

键	含义
`input`	上传的文件在仓库里的实际存放路径
`output`	写进文章 front matter / 正文里的 URL 前缀
`rename`	上传重命名策略：`random` 随机名 / `safe` 拼接原名的安全字符 / `false` 保留原名

Firefly 的封面和正文图片同时支持相对路径、/ 开头的 public 路径和远程 URL，所以 input: public/images + output: /images 是最省事的组合：所有图片统一进 public，写进文章的就是 /images/xxx.png，本地和线上都能直接访问。

5.2 filename：新文件的命名规则#

{year} {month} {day} {hour} {minute} {second}：创建时间，零填充；
{primary}：列表视图的主字段（一般是标题），会做 slug 化处理；
field: create：新建时弹出文件名输入框。

文章的文件名（去掉扩展名）就是 URL 的一部分，所以发布后尽量别再改名。动态这类短内容用纯时间戳命名，完全不用操心。

5.3 view：列表怎么排#

fields 是列表里显示的列，primary 是主标题列，default.sort + order 控制默认排序。文章按发布日期倒序，符合直觉。

5.4 exclude：把图片从条目列表里藏起来#

Pages CMS 的集合会递归列出目录下的所有文件——包括 png。不处理的话，文章列表里会混进一堆「空条目」。exclude 按精确文件名匹配（不支持通配符），把已有配图的文件名列进去就好；新图片一律走 Media 上传到 public/images，别再往内容目录里放。

5.5 operations：给危险操作上锁#

create / rename / delete 三个开关控制集合的新建、重命名、删除。独立页面的路由在主题里是写死的（about.astro、friends.astro、guestbook.astro 分别读固定文件），误删一个页面就是 404，所以全部禁用。

5.6 date 字段的 options#

1
- name: published
2
  type: date
3
  options:
4
    time: true                        # 带时间选择器
5
    format: 'yyyy-MM-dd HH:mm:ss'     # 写入文件的格式（date-fns 语法）

default: '' 可以阻止日期字段自动填当前时间——updated 用得上，需要时再手动选。

六、踩坑记录#

6.1 日期必须保持「裸格式」，否则构建直接炸#

Firefly 的内容 schema 里 published 是 z.date()，Astro 解析 front matter 时只把不带引号的日期识别成 Date：published: 2026-09-12 没问题，published: "2026-09-12" 会变成字符串，构建报错。

Pages CMS 的 date 字段默认写裸日期，正常用不会出事。风险点在于绕过 CMS 手改文件：在 GitHub 网页上编辑时手一抖给日期加了对引号，下次部署就炸。这是静态博客 + 任何 CMS 组合的共性坑，遇到构建失败先查日期。

6.2 空字段不会写出 null，但必填字段别空着#

CMS 保存时会自动省略值为空的键，正好符合 Astro schema 的默认值语义，image、updated 这类可选字段留空即可。但 title、published 这种 schema 里没有默认值的字段一定要填——配置里给它们标了 required: true，保存时 CMS 会先拦一道。

6.3 纯中文标题生成不了文件名#

{primary} 生成文件名时会做 slug 化，纯中文标题 slug 化后是空字符串。所以文章的 filename 模板用日期打头、并在新建时弹出输入框让你自己起名（中英文都行，Firefly 对中文文件名的 URL 处理是正常的）。

6.4 MDX 文件别用富文本编辑器#

friends.mdx 这类 MDX 文件里可能有 JSX 注释和组件语法，富文本编辑器（Tiptap）往返一遍很可能弄乱结构。所以配置里独立页面的正文用 type: text——一个纯文本框，所见即所得地编辑原始 Markdown，保存时一个字节都不会动。

6.5 复杂 Markdown 建议切到 source 模式#

文章正文的富文本编辑器右上角可以切换 editor / source 两种模式。日常写段落、插图用 editor 方便；写 callout（> [!NOTE]）、复杂表格、大量代码块时切到 source 模式，保存的是原始 Markdown，最稳。

6.6 「via Pages CMS」的提交会规范化文件格式#

用 CMS 保存过的文件会被重新序列化：front matter 的行内数组会变成块列表、表格对齐会被重排、多余的空行会被整理。这些都是合法的等价改写，git diff 大不代表内容变了。但如果两个配置的字段列表不一致，就会有第三节的「字段被删」问题——这就是为什么字段要配全。

七、日常使用#

7.1 写一篇新文章#

侧边栏 → 文章 → 右上角新建；
弹出文件名输入框，填一个 2026-09-12-my-post 风格的名字；
填标题（必填）、发布日期默认今天，标签是一行一个；
正文用富文本编辑器写，需要图片就点工具栏的插图按钮直接上传，图会传到 public/images 并插入 /images/xxx.png；
保存。此时 GitHub 上多一个 commit，部署平台开始构建，一两分钟后线上可见。

7.2 草稿流程#

没写完的文章把「草稿」勾上（draft: true），主题不会把它渲染进列表和详情页，可以放心保存占位。写完取消勾选再保存即发布。

7.3 改独立页面#

关于页、友链、留言板都在「独立页面」里，正文是原始 Markdown 源码模式，改完直接保存。新增独立页面需要先在主题里加路由，光建 md 文件没用，所以配置里禁掉了新建。

建议

本地改完东西想用 CMS 写作之前，记得先 git pull，反之 CMS 上写完回来也要先 pull——两边是同一个仓库，别让自己处在冲突状态。

八、故障排查#

症状	可能原因	处理
保存了但网站没更新	部署平台还在构建，或构建失败	去部署平台看构建日志
构建失败，报 `z.date()` / Invalid date	日期被写成了带引号的字符串	检查该文 front matter 的日期字段
构建失败，报某字段类型错误	手改文件时 front matter 格式错了	对照 `src/content.config.ts` 检查
Media 面板打不开 / 上传失败	`public/images` 目录不存在	建目录并提交 `.gitkeep`
文章列表里出现图片「条目」	`exclude` 没覆盖到新图片	补 exclude，或把图移去 `public/images`
改了 `.pages.yml` 没生效	看错了分支，或页面是旧缓存	确认分支一致后刷新页面

注意

构建失败时部署平台上的还是上一个成功版本，网站不会白屏，但你的修改也不会生效。修好 front matter 再推一次即可。

九、结语#

整套方案的本质是把「能改仓库文件的 GitHub 账号」变成一个带表单校验和媒体库的写作后台：配置成本只有一份 .pages.yml，收益是随时随地可写、格式有 CMS 兜底、提交历史照样干净。

如果你也在用 Firefly，欢迎直接抄第四节的配置；踩到别的坑欢迎来留言板交流。

文档版本： 2026-09-12 适用主题： Firefly（Astro 内容集合架构） 适用平台： app.pagescms.org / Vercel / Cloudflare Pages / EdgeOne Pages 等自动部署平台

个人主页重写：Vue 3 毛玻璃 Bento + 洛雪音源

Sat, 12 Sep 2026 00:00:00 GMT

在线访问： www.zlion.top ｜ 开源仓库： Zlion-Y/homepage 布局思路最初参考了 imsyy/home（MIT License，已存档），在此致谢——除此之外没有搬它的代码，依赖也全部换掉了。

主页效果：壁纸背景 + 毛玻璃卡片

为什么自己写一份#

想要的东西其实很简单：站点导航 + 一言 + 时钟 + 天气 + 音乐。imsyy/home 的布局我很喜欢，但它已经归档不再维护，而且 Element Plus、Pinia、APlayer、Swiper 一整套对一个导航页来说太重了。于是用 Vue 3 + Vite 重写了一份：唯一运行时依赖就是 vue 本身，构建产物 gzip 约 60KB（JS 52KB + CSS 9KB）。

功能一览#

毛玻璃 Bento 布局：一言、时钟、天气长卡、网站列表小卡自由拼装，移动端自动降级单列
一言：Hitokoto API，失败自动兜底本地语句，点卡片换一句
实时时钟：农历 + 节日倒数
实时天气长卡：uapis 聚合接口，免 Key、按访客 IP 自动定位到县级（IPv6 正常），湿度/体感/AQI、未来几天高低温双曲线，可固定城市
博客更新卡：自动拉取博客 RSS 展示最新 3 篇文章，卡头带 GitHub / 邮箱等社交图标
网站列表：一行 3 个紧凑卡片，config.js 里加站点自动扩展
二级「探索更多」面板：点左上角 Logo 进入，桌面一屏六卡——
- 每日新闻（60s API）
- 多平台热榜（微博/B站/V2EX/IT之家等，平台与顺序可配置）
- 音乐播放器（下一节重点）
- Epic 限免
- 程序员历史上的今天
- 站点监控（访客浏览器直连探测自己各站点，绿红点 + 响应耗时，60 秒自动刷新，无需第三方监控服务）
动效：卡片悬停 3D 倾斜 + 光泽、自定义圆点光标 + 点击涟漪、卡片错峰浮起
细节：极光渐变背景随昼夜变色、支持自定义壁纸/随机壁纸 API、页脚建站天数、站名 7 款手写字体一键切换

所有卡片都能在 config.js 里开关与排序。

音乐播放器：多源自愈 + 洛雪音源#

播放器本身#

多 Meting 源并发竞速拉歌单，谁先返回用谁，单源故障无感
每首歌自动在多个源之间探测可用播放链接，断链/过期自愈，全败自动跳下一首
歌单本地缓存 6 小时，进面板秒开；预载但不自动出声，点了播放才响
歌词同步滚动居中，点歌词行跳转进度

为什么要接洛雪音源#

公共 Meting 接口有个绕不过去的边界：VIP / 版权受限曲目拿不到完整直链——它给的是一段能正常播的 30 秒试听片段，不报错、很难察觉。于是把本地的洛雪音源解析搬到 serverless 上，让「点播放」这件事有一个更可靠的后端。

请求链路#

1
浏览器                       Vercel 边缘
2
   │
3
   │ ① 拉歌单（多源并发竞速）
4
   ├──────────────────────────────► 公共 Meting × N
5
   │ ◄── 谁先返回用谁
6
   │
7
   │ ② 取直链（同源，无 CORS）
8
   ├──────────────────────────────► /api/url
9
   │                                  │
10
   │                                  ├─ 命中 CDN 缓存？直接返回（不进函数）
11
   │                                  │
12
   │                                  └─ 未命中 → 函数内并发多音源解析
13
   │                                                  │
14
   │                                                  ├─ 按成绩分波对冲
15
   │                                                  ├─ 赢家一出即掐断其余
16
   │                                                  ├─ 直链探活
17
   │                                                  └─ 连续失败熔断
18
   │ ◄── 完整直链 ────────────────────────────────────┘
19
   │
20
   │ ③ 解析不到 → 自动降级回 Meting（开着也不影响原本能用的）
21
   ▼
22
<audio> 播放

展开收起

落到代码里，几个关键设计：

自定义音源脚本跑在 Vercel 函数里（api/ + lib/，跟主页一起部署），多音源按成绩分波对冲、赢家一出即掐断其余、直链探活、连续失败熔断
前端调同源的 /api/url：不需要额外域名、证书、CORS 配置，也不用再养一台服务器
直链缓存在 CDN 边缘（15 分钟），命中缓存的请求根本不进函数，不消耗调用次数
解析不到时自动降级回 Meting，开着也不影响原来能用的情况

config.js 里两个开关：

1
musicSource: "proxy",    // "meting" = 只走公共 Meting；"proxy" = 走自带的 serverless 解析
2
musicQuality: "320k",    // 128k / 320k / flac / flac24bit

音源脚本放 sources/ 一起部署；也可以配 SOURCE_URLS 环境变量指向在线脚本——改完远端脚本请求一次 /api/health?refresh=1，函数立刻重装全部音源，连重新部署都不用。部署后打开 /api/health 能看到装上了哪些音源、各自的平台与失败原因。

提醒：函数默认跑在香港（hkg1，离国内接口最近），实测与国内出口的成功率一致；但这类「直链解析」本身在灰区，建议自用、别公开分发。

部署#

平台托管（推荐）#

Vercel / Netlify / Cloudflare Pages 均可，Framework 选 Vite，根目录 ./、输出目录 dist、构建命令 npm run build，零环境变量（免 Key 接口的好处）。

Deploy with Vercel

本地开发#

Terminal window

1
git clone https://github.com/you-github-name/homepage.git
2
cd homepage
3
npm install
4
npm run dev     # http://localhost:5173，配置热更新

全部配置化：只改 `src/config.js`#

个性化集中在一个文件，改完 push 即自动重新部署。常用的几项：

配置项	说明
`siteName` / `pageTitle` / `greet` / `desc` / `motto`	站名、标签页标题、问候语、一句话介绍、打字机轮换标语
`siteFont`	站名手写体，内置 7 款开源字体一键切换
`logo`	留空用内置「Z」徽章，填图片路径/URL 整体替换
`siteStart` / `author` / `repo`	建站日期（页脚运行天数）、署名、署名链接
`homeCards`	主页各卡片开关（greet / blog / hitokoto / clock / weather / siteLinks）
`panelCards`	二级面板卡片排列：数组顺序 = 排列顺序，删掉某项 = 隐藏该卡
`musicPlaylist` / `musicSource` / `musicQuality`	歌单 ID、直链来源、音质
`weatherCity`	天气城市 adcode，留空 = 按访客 IP 自动定位
`bgApi`	背景：留空极光渐变 / 放 `public/images/background.jpg` / 填随机壁纸 API
`hotPlatforms`	热榜平台与顺序
`siteMonitors`	站点监控卡的目标站点列表
`socialLinks` / `siteLinks`	社交图标、网站列表

换成你自己的站点，改 siteLinks 和 socialLinks 就行。

TODO#

更多卡片支持（欢迎 PR / Issue 讨论）
卡片位置自定义（拖拽排序 / 布局记忆）
音乐卡 AMLL 歌词动效（逐字点亮、弹性动画、灵感封面背景）

致谢#

imsyy/home——布局灵感来源；
CuteLeaf/Firefly——音乐播放器多源自愈设计参考；
uapis.cn、60s API、hitokoto.cn——免 Key 数据接口；
Lucide——图标。

项目为 vibe coding 实现，若侵犯了您的权益请联系我删除。觉得有用的话，去仓库点个 Star 就是对我最大的支持～

fileserver：单文件自建文件服务器（GO）

Wed, 09 Sep 2026 00:00:00 GMT

本文档面向想在服务器 / NAS / 路由器上自建文件分享服务的用户，涵盖功能介绍、三种部署方式、安全设计与介绍页站点。 适用版本： fileserver v1.3.5 适用系统： Linux（amd64 / arm64 / armv7 / armv5 / mipsle / 386）/ Windows / macOS 适用平台： 云服务器 / 本地虚拟机 / NAS / 软路由 / Docker

一、为什么要再造一个文件服务器#

网盘限速、第三方工具要装 Docker 拉一堆镜像、老 NAS 上连 Node 都跑不动——fileserver 就是为了解决这些场景：一个可执行文件，拷过去就能跑。

它的定位很简单：

单个二进制文件：Go 编写、零第三方库，前端页面经 go:embed 直接编译进二进制，无任何运行时依赖；图片缩略图、文本预览、统计图全部在浏览器端渲染，弱机服务器只负责透传字节流
8 个平台开箱即用：从 x86 云服务器到 mipsle 架构的老路由器，总有一个包能跑
核心功能齐全：目录管理、分片断点续传上传、限时限次分享链接、WebDAV 直连、回收站、一键自更新

配套介绍页#

仓库之外还有一个独立的介绍页站点，把「这东西是干什么的、能干什么、怎么装」在一页里讲完，比翻 README 快得多：

介绍页： storage.zlion.top

页面结构大致是：

1
介绍页 (fileserver.zlion.top)
2
├─ 首屏       一句话定位 + 一键部署命令 + Release 下载入口
3
├─ 功能总览   分片上传 / 分享链接 / WebDAV / 相册视图 …逐项配截图
4
├─ 部署方式   直接运行 / 一键脚本 / Docker 三条路径并列对比
5
├─ 安全设计   PBKDF2、AES-GCM、路径越权防护等实现说明
6
└─ 常见问题   反代 127.0.0.1、413、别名冲突 …就地给排查方向

定位上它是「软件的门面」，承担三件事：讲清楚是什么（省得用户读完 README 还在猜）、给出最快的上手路径（首屏就放 curl 一键部署）、沉淀文档（安全设计、故障排查这些正文不适合塞进 README 的内容）。介绍页与本文内容同源，改动软件时两边一起更新。

二、功能总览#

功能	说明
文件管理	上传、删除（进回收站）、重命名 / 移动、新建文件夹、勾选批量操作
分片上传	≥8MB 自动分片断点续传：失败只补缺失分片，服务重启自动重建会话，对网页端无感
文件夹上传	「上传文件夹」递归上传整个目录结构；把文件夹直接拖进页面同样整体上传
相册视图	图片文件夹一键切换缩略图网格，浏览器端懒加载，点击直接预览
媒体 / 文本预览	图片 / 视频 / 音频浏览器内直接播放（支持拖动）；txt / md / 源码 / 配置直接查看
搜索排序	全盘递归文件名搜索、按名称 / 大小 / 时间排序、按类型与大小筛选，选择自动记忆
大目录优化	分页拉取 + 前端虚拟滚动，万级文件目录也只渲染可见行
分享链接	有效期（1 小时 ~ 30 天 / 永久 / 自定义）+ 下载次数（1/5/20/不限）双限制
自定义别名	分享链接可设自定义尾段（如 `/s/发布会-materials`），对外发布更好看，原 token 链接兼容
防盗链	按分享开启 Referer 校验，拒绝其他网站的页面引用，直访与下载工具不受影响
分享密码	PBKDF2 哈希校验，密码 AES-GCM 加密存储，管理端可查看
直链 / 确认页	直链打开即下载（媒体文件内联展示）；确认页模式先展示文件信息与预览再计数
分享管理	筛选、批量撤销、行内快速编辑有效期 / 密码 / 别名 / 访问方式，一键复制、扫码访问
下载统计	分享管理页展示最近 30 天下载 / 失败趋势图（canvas 客户端绘制）
访问日志	每条分享记录最近 50 次访问（IP / UA / 成败原因），行内展开查看
回收站	删除先进回收站，可逐条或勾选批量恢复 / 彻底删除，超期自动清理
WebDAV	`/dav/` 挂载文件根目录，Salt Player 等播放器与移动端文件管理器可直连
一键自更新	自动下载对应架构二进制 → 校验 → 原子替换 → 自动重启，也可本地上传更新包
安全与会话	查看活跃会话、远程踢出、网页改密立即生效并踢出其他会话
深色模式 / PWA	深浅主题跟随系统或手动切换；支持「添加到主屏幕」独立窗口运行
移动端适配	卡片式列表、贴底批量栏、底部抽屉弹窗，按触控目标重新设计
防爆破	同一 IP 5 分钟内认证失败 10 次自动封禁 15 分钟
定时清理	过期分享记录自动清理，保留时长可视化配置

三、大文件分片上传#

家用宽带上传几个 GB 的文件，最怕的就是传到 90% 断网重来。大文件（≥8MB）自动走分片通道：前端把文件切成 4MB 的分片逐个上传，服务端顺序追加落盘，完成后同盘原子改名——中途断网只补缺失的分片，已经传上去的字节不会浪费。

是

否

选择 ≥8MB 大文件

init：服务端建立分片会话

前端按 4MB 逐片上传追加

是否中断

按服务端实际进度校正偏移

只重传缺失分片

complete：校验长度后原子改名生效

是

否

选择 ≥8MB 大文件

init：服务端建立分片会话

前端按 4MB 逐片上传追加

是否中断

按服务端实际进度校正偏移

只重传缺失分片

complete：校验长度后原子改名生效

会话对客户端完全透明：普通小文件仍走一次性请求，分片文件在完成前对文件列表、搜索、WebDAV、ZIP 打包全部不可见，不会外泄半成品。

四、分享与浏览的几处细节#

4.1 相册视图#

管理图片目录时点「相册」，列表切换为缩略图网格——服务端依旧只返回原图字节，由浏览器懒加载，不增加服务器负担。翻图点开即看，不用先下载到本地。

4.2 分享别名#

创建分享时可自定义链接尾段，把默认的随机 token 换成可读的短词：

1
默认：  https://files.example.com/s/a7f3c9e21b8d4f06
2
别名：  https://files.example.com/s/发布会-materials

发到网站 / 公众号里体面得多。别名全局唯一，原 token 链接保持兼容；别名段同样计入有效期与下载次数限制，不额外开权限口子。

4.3 防盗链#

对公开外发的链接可单独按分享开启 Referer 校验：其他网站的页面引用直接返回 403，而直接在浏览器打开链接、用 IDM / aria2 这类下载工具拉取都不受影响——防的是被别站白嫖流量，不是防真实访客。

五、快速开始#

5.1 直接运行#

从 Releases 下载对应架构的二进制，赋予执行权限后运行：

Terminal window

1
chmod +x fileserver
2

3
./fileserver --port 16666 --dir /data/files --user admin --pass 你的密码

打开 http://服务器IP:16666 即可使用。不设 --user/--pass 时无认证，仅建议纯内网使用。

5.2 常用启动参数#

参数	默认值	说明
`--port`	`8080`	监听端口
`--dir`	无	文件根目录（也可启动后在网页里选）
`--data-dir`	`./data`	配置与分享记录存放目录，必须持久化
`--user` / `--pass`	无	管理端账号密码
`--max-upload-mb`	`0`	单文件上传上限（MB），0 不限制，对分片上传同样生效
`--trust-proxy`	`0`	反向代理场景置 1

同名环境变量（PORT、ROOT_DIR、AUTH_PASS 等）同样生效，命令行优先。

建议

--data-dir 务必放在持久目录，分享记录存在里面的 shares.json，目录丢了链接全部失效；加密分享密码的主密钥 .masterkey 也在这里，迁移服务器时一并带走。

六、三种部署方式怎么选#

介绍页里把三条路径并列放在一起，选哪条看你的环境：

有 systemd 的 Linux

已跑 Docker

临时试用 / 特殊平台

你的环境

一键脚本

识别架构 · 注册自启

Docker Compose

数据卷持久化

直接运行

下载二进制手起

网页访问 :16666

有 systemd 的 Linux

已跑 Docker

临时试用 / 特殊平台

你的环境

一键脚本

识别架构 · 注册自启

Docker Compose

数据卷持久化

直接运行

下载二进制手起

网页访问 :16666

6.1 一键部署到 Linux（推荐）#

部署脚本自动识别 CPU 架构、从 Release 下载二进制、放行防火墙、注册 systemd 开机自启：

Terminal window

1
curl -fsSL https://raw.githubusercontent.com/Zlion-Y/fileserver/main/install-remote.sh -o install-remote.sh
2

3
sudo bash install-remote.sh --dry-run
4

5
sudo FS_USER=admin FS_PASS=你的密码 bash install-remote.sh

提示

--dry-run 只预览将要执行的操作，不改系统，建议先跑一次确认。

装好后的常用运维操作：

需求	命令
换目录 / 端口	`sudo DIR=/mnt/disk/share PORT=9000 bash install-remote.sh`
指定版本安装	`sudo VERSION=v1.3.5 bash install-remote.sh`
升级到最新版	重跑安装即可，自动继承已有配置与密码
查看日志	`journalctl -u fileserver -f`
卸载	`sudo bash install-remote.sh --uninstall`

配置文件在 /etc/fileserver.env，改完 systemctl restart fileserver 生效。

6.2 Docker 部署#

Terminal window

1
cp .env.example .env
2

3
docker compose up -d

docker-compose.yml 默认只监听 127.0.0.1:16666，由 Nginx / Caddy 反代后对外。数据落在 ./files 与 ./data，容器重建不丢。

警告

Docker 场景升级请重新构建镜像，不要在容器内替换二进制；未注入 --build-arg VERSION 时版本为 dev，网页会禁用一键更新。

七、一键自更新是怎么工作的#

个人服务器最烦的就是升级：登服务器、找架构、下载、替换、重启。fileserver 把这整套做成了一个按钮：

通过

失败

网页点击一键更新

服务端查询 GitHub 最新 Release

按当前架构下载对应二进制

校验二进制魔数

原子替换旧文件

中止并报错

自动重启新版本

网页展示版本更新日志

通过

失败

网页点击一键更新

服务端查询 GitHub 最新 Release

按当前架构下载对应二进制

校验二进制魔数

原子替换旧文件

中止并报错

自动重启新版本

网页展示版本更新日志

服务器连不上 GitHub 也没关系：本地下载好二进制，从网页直接上传更新包（上限 256MB），校验通过后同样替换重启。

八、WebDAV：播放器直连#

服务地址即 http://<主机>:<端口>/dav/，认证同管理端账号密码。Salt Player、foobar2000、常规移动端文件管理器都能直连，音乐 / 视频流式播放支持拖动进度条；通过 WebDAV 删除的文件同样进回收站，防误删。

说明

未实现 LOCK/UNLOCK（Class 2），Windows 资源管理器「映射网络驱动器」不受支持；常规播放器与文件管理器不受影响。

九、安全设计#

口令哈希：管理端与分享密码均用 PBKDF2-HMAC-SHA256（管理端 10 万轮 / 分享端 5 万轮），旧版单次 SHA-256 记录校验通过后自动就地升级，无需用户操作
密码加密存储：分享密码以 AES-GCM 加密落盘，主密钥独立文件存放；config.json（管理密码哈希）、shares.json（加密密码与访问日志）、主密钥文件均以 0600 权限落盘，泄露不再连带交出密码
改密踢会话：修改管理员密码后立即踢出其他所有登录会话，被盗会话不会永久有效
续传授权：下载断点续传必须持有真实下载后签发的 ticket Cookie，伪造 Range: bytes=1- 无法绕过一次性链接的次数限制
路径越权：所有路径参数做根目录校验 + 符号链接兜底，../ 逃逸与 root 内软链指向外部均无效
防盗链：按分享开启 Referer 校验，外站页面引用返回 403，直访与下载工具不受影响
上传限制：MAX_UPLOAD_MB 对普通与分片上传同样生效；分片临时文件对列表 / 搜索 / WebDAV / ZIP 不可见，半成品不会外泄

十、注意事项与故障排查#

重要

公网部署务必设置 AUTH_USER / AUTH_PASS，否则任何人都能管理你的文件。

反代注意

反向代理场景需设置 TRUST_PROXY=1，否则生成的分享链接会是 http://127.0.0.1:...；Nginx 需放开 client_max_body_size 0 并关闭 proxy_buffering。

常见问题排查：

现象	排查方向
分享链接打开 404	`shares.json` 是否随 `--data-dir` 丢失；文件是否被移动或删除
链接提示下载次数用完	限次已耗尽，可在分享管理里快速编辑重新放开
链接打开提示「禁止引用」	该分享开启了防盗链，外站引用被拒；从原页面打开或直访即可
别名提示已被占用	别名全局唯一，换一个或留空使用随机 token
反代后链接是 127.0.0.1	未设 `TRUST_PROXY=1`，或反代来源不在环回 / 内网信任范围
上传大文件失败 413	触发了 `MAX_UPLOAD_MB` 限制，或 Nginx 未放开 `client_max_body_size`
大文件上传中断	直接重传即可，分片续传只补缺失部分，无需从头再来
一键更新报错	服务器连不上 GitHub，改用网页上传更新包方式
忘记管理密码	在配置中改 `AUTH_PASS` 后重启；网页改过密码的话删除 `config.json` 中的 `authPassHash` 字段即可回退到启动参数密码

在线体验： fileserver.zlion.top<446> ｜ 介绍页： fileserver.zlion.top ｜ 开源仓库： Zlion-Y/fileserver 文档版本： 2026-09-22 软件版本： fileserver v1.3.5 适用平台： 云服务器 / 本地虚拟机 / NAS / 软路由 / Docker

中兴巡天AX3000 (E2631) 主线 Linux 内核移植全记录

Mon, 31 Aug 2026 00:00:00 GMT

本文档面向嵌入式开发与路由器逆向爱好者，完整记录中兴巡天 AX3000（E2631）从固件解密、SoC 逆向、交叉编译到主线内核上板验证的全过程，并给出 mihomo（Clash.Meta）全功能适配的配置与开源复现方式。 适用系统： Windows 10/11（MSYS2 构建） / WSL2（可选提速） 适用平台： 中兴 ZTE ZXHN E2631（巡天 AX3000，ZX279128S）

Zlion-Y

e2631-mainline-zx279128s

Description not set

—

NOASSERTION

一、项目背景与目标#

E2631 是中兴巡天 AX3000 千兆双频路由器，采用自研 ZX279128S SoC，运营商定制固件、源码不开放，内核特性老旧，既没有 TPROXY / nftables 等现代防火墙能力，也无法直接运行 mihomo（Clash.Meta）。网上流传的 openwrt-e2631 镜像只能通过 U-Boot 导入，实际只有镜像头能被识别为 OpenWrt，内核根本无法启动。

因此本项目决定走一条完整链路：固件解密 → SoC 逆向 → 串口/U-Boot 打通 → 主线内核编译 → 上板验证 → mihomo 适配 → 开源发布。

固件解密

SoC 逆向

串口 / U-Boot 打通

交叉编译主线 6.18.38

上板验证

mihomo 全功能适配

开源仓库发布

固件解密

SoC 逆向

串口 / U-Boot 打通

交叉编译主线 6.18.38

上板验证

mihomo 全功能适配

开源仓库发布

最终成果：主线内核 6.18.38 已在真实硬件上从 U-Boot 启动到交互式 busybox shell，TPROXY / TUN / nftables / zram 等特性全部验证通过，mihomo 可跑在 armv5 软浮点二进制下，且全部源码、工具、一键编译脚本已开源，可以直接拉取复现。

二、硬件规格与 SoC 逆向#

2.1 硬件规格#

项目	规格
SoC	中兴 ZX279128S（双核 Cortex-A9 rev1 @ 1GHz）
内存	256MB DDR3-1333（U-Boot 实测 256MiB；DTS 当前写 128MB 占位，可按需调整）
闪存	128MB SPI NAND（AMD/Spansion HYF1GQ4UTACAE）
有线	千兆 PHY（GEPHY ×4，驱动待移植）
无线	MT7916 WiFi（走 PCIe，驱动待移植）
USB	无对外 USB 口（dwc2 / dwc3 驱动已验证，DT 保持禁用）
调试串口	ZTE 定制 PL011 @ 0x94404000

重要

这台机器没有 USB 口，后续所有调试、部署、镜像搬运都只能依赖 TFTP 和串口，这是整个调试方案设计的出发点。

2.2 CPU 能力（最重要的事实）#

由 cat /proc/cpuinfo 实测，CPU features 为：

1
half thumb fastmult edsp thumbee tls

对照 ARMv7 完整特性集，结论如下：

特性	支持情况
ARMv7（Cortex-A9）	✅ 支持
Thumb / ThumbEE	✅ 支持
EDSP（增强 DSP 指令）	✅ 支持
TLS（线程本地存储）	✅ 支持
VFP 浮点单元	❌ 不支持（无硬件 FPU）
NEON SIMD	❌ 不支持
硬件整数除法 idiv	❌ 不支持

注意

无 VFP / NEON / idiv 意味着：

所有二进制必须软浮点编译（-mfloat-abi=soft），用 -mfpu=vfp 或 hard-float 的二进制会直接非法指令崩溃；
除法、浮点运算全部走软件库，CPU 占用高，跑加密代理时会出现明显的 CPU 瓶颈；
内核编译时必须强制 -marm，避免工具链默认 Thumb 模式带来的启动问题。

2.3 串口 IP 逆向#

E2631 的调试串口是 ZTE 定制的 PL011 兼容 IP，基地址 0x94404000，earlycon=zteuart 可输出引导日志，periphid 为 0x001feffe。它与标准 PL011 的寄存器偏移不同（与 ZX279133 是同一 IP）：

寄存器	标准 PL011 偏移	E2631（ZTE 定制）偏移
DR（数据寄存器）	0x00	0x04
FR（标志寄存器）	0x18	0x14
IBRD	0x24	0x24
FBRD	0x28	0x28
LCRH	0x2C	0x30
CR	0x30	0x34
IFLS	0x34	0x38
IMSC	0x38	0x40

提示

早期主线内核没有这个 ZTE 定制 earlycon 的适配，需要为 zteuart 编写 earlycon 驱动（已包含在项目的 patches 中）。串口物理参数为 3.3V TTL，115200-8-N-1。

2.4 与 SR1010 的外设差异#

本项目基于 cnjn 的 SR1010 主线移植（linux-mainline-zte-zxslc-sr1010），但 E2631 的外围方案与 SR1010 不同，SoC 周边芯片不能直接照搬：

外设	SR1010	E2631
有线 PHY	与 E2631 不同	GEPHY（千兆）
WiFi	与 E2631 不同	MT7916（PCIe）
SPI NAND	与 E2631 不同	HYF1GQ4UTACAE（128MB）
UART IP	同源	同源（ZTE 定制 PL011）

所以设备树、网卡/PHY 驱动、闪存驱动都需要针对 E2631 单独适配，这也是”待办与未来工作”一章里列出的主要缺口。

三、固件获取与解密#

3.1 加密与密钥#

原厂固件的 kernel 分区使用 AES-128-ECB 加密，密钥常量为 E263111559d0dfde。解密后即得到标准 uImage（ih_load 为 0x40008000，这也是后面 XIP 陷阱的根源）。

3.2 分区布局#

128MB SPI NAND 上的功能分区（具体偏移以固件 dump 为准）：

分区	内容	备注
bootloader	U-Boot	串口可交互，命令未被完全阉割
kernel	加密内核	AES-128-ECB 解密后为 uImage
rootfs	只读根文件系统	JFFS2
kmodule	内核模块 + 用户态程序	JFFS2
配置区	出厂配置 / 无线参数	—

3.3 kmodule 解包与 vendor 运行库#

把 kmodule 分区按 JFFS2 解包后，拿到两样关键资产：

busybox v1.17.2（原厂用户态，后续 initramfs 直接复用）；
uClibc 0.9.33.2 运行库（libc.so.0 / libm.so.0 / libresolv.so.0 等）。

警告

vendor 的库文件在打包时被记录成了符号链接（直接拷出来是”不是 ELF 文件”），需要解析 .symlink 文件还原真实内容，才能用于构建 initramfs。

四、串口与 U-Boot 引导#

4.1 进入 U-Boot#

上电后立即连续按 1 进入引导菜单，输入密码 5cE080@fyBD，回车后停在 U-Boot 命令行（自动启动已被停止）。原厂 U-Boot 支持 tftp / bootm / md / mw 等常用命令，可以直接用来引导主线内核。

Terminal window

1
# 电脑端准备一个 TFTP 服务器（仓库里的 e2631-tools/tftpd2.py 即可）
2

3
# 串口里配置网络并下载内核
4
setenv serverip 192.168.1.100
5

6
setenv ipaddr 192.168.1.1
7

8
tftp 0x43000000 uImage-e2631.img
9

10
bootm 0x43000000

4.2 XIP 陷阱（本项目最大的坑）#

注意

绝对不要在 0x40008000 加载内核。

uImage 头的 ih_load 就是 0x40008000。如果 tftp 直接下到这个地址，bootm 会认为镜像”已经就位”，走 XIP（就地执行）路径跳过搬运，64 字节的 uImage 头直接压在内核入口上，结果就是静默崩溃——串口没有任何输出。

另外 0x42000000 区域是 U-Boot 自用区，大文件传输会失败，也要避开。

正确姿势：tftp 0x43000000 → bootm 0x43000000，bootm 会把镜像搬到 0x40008000 再跳转。

4.3 完整引导链路#

上电

立即按 1 进菜单

输入密码 5cE080@fyBD

停在 U-Boot 命令行

tftp 0x43000000 下载 uImage

bootm 0x43000000

搬运镜像到 0x40008000

解压并跳转内核

earlycon=zteuart 输出启动日志

解包嵌入式 initramfs

init 挂载 console

spawn busybox sh

上电

立即按 1 进菜单

输入密码 5cE080@fyBD

停在 U-Boot 命令行

tftp 0x43000000 下载 uImage

bootm 0x43000000

搬运镜像到 0x40008000

解压并跳转内核

earlycon=zteuart 输出启动日志

解包嵌入式 initramfs

init 挂载 console

spawn busybox sh

五、Windows 交叉编译环境#

5.1 环境组成#

项目在纯 Windows 上完成了整个内核构建，环境如下：

组件	版本/说明
MSYS2	提供 make 4.x 与 POSIX 工具链
Arm GNU Toolchain	10.3（mingw 版），交叉编译内核
Zig	0.14（arm-linux-musleabi 静态），编译 initramfs 的 init 等用户态程序
Git	管理源码树与行尾

建议

同一套源码在 WSL2（Ubuntu）里用完整 GCC 交叉编译，速度明显快于 MSYS2，cpio 打包也更省心。仓库同时提供 build.sh（Linux/WSL）和 build.bat（Windows/MSYS2），二选一即可。

5.2 Windows 构建的强制限制#

重要

make -j4 是上限：MSYS2 下 -j8 会触发 make 段错误；
必须强制 -marm：mingw 工具链默认编 Thumb，会导致内核启动异常；
源码树必须保持 LF 行尾：clone 时 CRLF 污染了约 9 万文件，fixdep 解析依赖文件会出错，需要 CRLF 补丁。

构建命令（对应 build.sh / build.bat 的核心）：

Terminal window

1
make ARCH=arm CROSS_COMPILE=arm-none-eabi- zx279128s_e2631_defconfig
2

3
make ARCH=arm CROSS_COMPILE=arm-none-eabi- -j4

5.3 踩过的编译坑（均已修复并固化在仓库）#

问题	现象	处理
CRLF 污染	fixdep 依赖文件解析错误	全树转 LF + 补丁
Thumb 默认编译	内核启动异常	强制 `-marm`
make -j8 段错误	编译中途崩溃	限 `-j4`
ntfs3 需要 gcc11 flag	编译报错	禁用 `CONFIG_NTFS3_FS`
syncconfig 交互式提示	GCC_PLUGINS / DWARF 卡住构建	禁用 / 固定选项
initramfs_data.S 被误删	构建失败	git 恢复，重建脚本不再删除 .S
uapi netfilter 头文件是 stub	xt_mark.c 等编译失败	从 git 恢复真实内容并修复索引
busybox 用 zig 构建时 make 崩溃	段错误	改用 vendor busybox + uClibc 库

六、内核配置要点（mihomo 全功能适配）#

6.1 关键特性（全部 `=y` 并已上板验证）#

内核特性	配置项	用途
TUN 虚拟网卡	`CONFIG_TUN`	mihomo TUN 模式
TPROXY 透明代理	`CONFIG_NETFILTER_XT_TARGET_TPROXY` + `CONFIG_NF_TPROXY_IPV4/IPV6`	透明代理核心
socket 匹配	`CONFIG_NETFILTER_XT_MATCH_SOCKET`	按 socket 分流
nftables	`CONFIG_NF_TABLES` + nft_tproxy / nft_socket / nft_compat	现代防火墙规则
iptables-legacy	`CONFIG_IP_NF_IPTABLES_LEGACY` + `CONFIG_XTABLES_LEGACY`	兼容原厂规则集
conntrack / NAT	`CONFIG_NF_CONNTRACK` + MASQUERADE / REDIRECT / MARK	代理流量转发
策略路由	`CONFIG_IP_ADVANCED_ROUTER` + `ip rule fwmark`	按 fwmark 分流
IPv6	`CONFIG_IPV6`	双栈代理
zram	`CONFIG_ZRAM`	内存压缩，缓解 256MB 压力

6.2 netfilter 配置丢失的修复#

内核默认配置做”平台精简”时会把 netfilter 相关选项丢掉，需要在 olddefconfig 之后显式重新打开：

Terminal window

1
make ARCH=arm CROSS_COMPILE=arm-none-eabi- olddefconfig
2

3
scripts/config -e NETFILTER -e XTABLES_LEGACY -e IP_NF_IPTABLES_LEGACY
4

5
make ARCH=arm CROSS_COMPILE=arm-none-eabi- olddefconfig

6.3 嵌入式 initramfs#

提示

最初的方案是把 initrd 打成 uImage 传给内核，但 uImage 的 64 字节头会被内核误读，导致根文件系统无法挂载。最终改用 CONFIG_INITRAMFS_SOURCE，把 cpio 直接编进内核，干净可靠。

initramfs 内容（由 e2631-tools/initramfs-src/ 构建）：

init：musl 静态编译，O_RDWR 打开 console、TIOCSCTTY 接管终端、spawn busybox sh；
busybox v1.17.2（vendor 版，经 uClibc 库支撑）；
uClibc 0.9.33.2 运行库（经 .symlink 修复后的真实 ELF）；
设备节点：console / null / tty / ttyAMA0(204<64>) / zero / random（pack2.py 递归 cpio 打包）。

七、上板验证#

7.1 启动结果#

主线内核 6.18.38 从 U-Boot 引导成功，earlycon=zteuart 输出完整启动日志，最终进入交互式 busybox shell。板上实测日志：

1
=== E2631 mainline bring-up init reached userspace ===
2
[init] kernel booted, zteuart console OK
3
[init] Features : half thumb fastmult edsp thumbee tls
4
[init] handing console to busybox shell
5
/ # iptables -t mangle -L PREROUTING    # 正常
6
/ # ip rule add fwmark 1 lookup 100     # 正常
7
/ # busybox cat /proc/net/ip_tables_targets
8
...
9
TPROXY
10
TPROXY
11
MASQUERADE
12
REDIRECT
13
...

7.2 特性验证命令#

Terminal window

1
# 验证 TPROXY / REDIRECT / MASQUERADE / MARK 等目标已编进内核
2
cat /proc/net/ip_tables_targets
3

4
# 确认 CPU 特性（无 VFP / NEON / idiv）
5
cat /proc/cpuinfo
6

7
# 确认内存识别
8
cat /proc/meminfo

/proc/net/ip_tables_targets 中能看到 TPROXY 等目标，说明透明代理内核路径完整可用；策略路由（ip rule fwmark）也已在板上实测通过。

八、mihomo 适配与部署#

8.1 二进制选择#

由于 CPU 无 VFP / NEON / idiv，mihomo 必须使用 armv5 软浮点 二进制：

1
mihomo-linux-armv5      # GOARM=5，软浮点

警告

不要用 armv7 或 hard-float 的 mihomo 包，否则在无 FPU 的 A9 上会直接非法指令崩溃。

8.2 内核侧已就绪#

mihomo 需要的内核能力已全部 =y 编入（见第六章）：TUN、TPROXY（v4/v6）、xt_socket、nftables（nft_tproxy/socket/compat）、iptables-legacy、conntrack、NAT、策略路由、IPv6、zram。无需任何外部内核模块。

8.3 部署与预期#

部署方式：通过 tftp / 串口把 armv5 二进制与配置文件拷入，挂到 TUN 或 TPROXY 模式即可。注意这台机器没有 USB，所以文件传输只能走网络或串口。

CPU 瓶颈提示

无硬件 FPU / NEON，SS / SSR 节点的加解密全部由 CPU 软算，1GHz 双核 A9 + 256MB 内存跑满速代理时 CPU 会明显吃满（“CPU 爆缸”风险）。这是硬件上限；软件层面已尽量做到极致——特性齐全、软浮点、无非法指令崩溃。

九、开源仓库与复现#

9.1 仓库结构#

仓库 Zlion-Y/e2631-mainline-zx279128s 本身就是完整的内核源码树（Linux 6.18.38 + E2631 平台适配全部落树），不再需要单独拉基础树再套补丁。默认分支 main：

1
e2631-mainline-zx279128s/                       # 完整内核源码树（GitHub）
2
├── arch/arm/boot/dts/zte/zx279128s-e2631.dts       # E2631 板级设备树
3
├── arch/arm/configs/zx279128s_e2631_defconfig      # 精简 defconfig（initramfs 已内嵌）
4
├── initramfs-e2631.cpio.gz                         # 嵌入式 initramfs（busybox + uClibc + init）
5
├── e2631-tools/
6
│   ├── tftpd2.py          # 简易 TFTP 服务器（UDP 69，服务父目录）
7
│   ├── pack_uimage.py     # uImage 打包（load/entry 0x40008000）
8
│   ├── serial_ctl.py      # 串口驱动（驱动 U-Boot 用）
9
│   ├── bootflow2.py       # 脚本化 tftp + bootm 串口序列
10
│   ├── mkconfig.sh        # MSYS2 构建步骤
11
│   ├── cleanbuild3.sh     # MSYS2 清理重建
12
│   ├── mihomobuild.sh     # mihomo 相关构建
13
│   ├── initramfs-src/     # init.c + pack2.py
14
│   └── README.md
15
├── upstream-series/                             # cnjn 的 ZX279133 16 补丁集（6.18.38 基线，参考）
16
├── research.md                                 # 内核版本调研笔记
17
├── README.md / README_EN.md / README           # 中英文说明 + 内核自带 README
18
├── build.sh                                    # Linux / WSL 一键编译
19
├── build.bat                                   # Windows / MSYS2 一键编译
20
└── .github/workflows/build.yml                 # CI：main + v* tag + 手动触发

展开收起

编译产物由 CI 直接发布到 GitHub Release：v0.1.1 已包含 uImage-e2631.img（约 13.3MB，zImage + DTB 拼接，DTB 在末尾），可直接下载后 tftp 引导。

9.2 复现步骤#

Linux / WSL（树内直接构建，无需套补丁）：

Terminal window

1
git clone https://github.com/Zlion-Y/e2631-mainline-zx279128s.git
2

3
cd e2631-mainline-zx279128s
4

5
./build.sh

Windows（MSYS2，首次运行自动装 MSYS2 与交叉工具链，再树内构建）：

Terminal window

1
git clone https://github.com/Zlion-Y/e2631-mainline-zx279128s.git
2

3
cd e2631-mainline-zx279128s
4

5
build.bat

GitHub Actions：fork 后 push（或手动 workflow_dispatch）即可，产物在 Actions 页面 / Release 下载。

编译产物 uImage-e2631.img 按第四章的姿势引导：

Terminal window

1
tftp 0x43000000 uImage-e2631.img
2

3
bootm 0x43000000

提示

树内构建要点：make zx279128s_e2631_defconfig 通过 CONFIG_INITRAMFS_SOURCE 把 initramfs-e2631.cpio.gz 一并编入；设备树用单目标编译（make zte/zx279128s-e2631.dtb），不走 make dtbs 批量入口。

9.3 CI 与 Release#

build.yml 触发条件：main 分支 push、v* tag push、手动 workflow_dispatch；并显式声明 permissions: contents: write 以便创建/更新 Release。流程为：装依赖 → 装 Arm GNU Toolchain 10.3（arm-none-linux-gnueabihf-）→ zx279128s_e2631_defconfig → zImage → 单目标 zte/zx279128s-e2631.dtb → e2631-tools/pack_uimage.py 打包 → 上传 artifact → 在 tag 上挂到 Release。

当前状态：v0.1.1 已发布（2026-08-31），Release 附件 uImage-e2631.img 为 Actions 验证产物（zImage + DTB），可直接下载引导。

提示

后续发新版：git tag v0.1.2 后 git push origin v0.1.2，Actions 会自动构建并更新 Release，无需手动传附件。

9.4 参考项目#

项目	用途
cnjn/linux-mainline-zte-zxslc-sr1010	SR1010 主线移植，本项目的基础（6.18.38 + ZX279133 平台支持）
xuejian1354/toolchains	官方 ZX27912X 交叉工具链
1234205a/zte-sr1010-research	原厂固件分析方法论

提示

仓库内 research.md 记录了内核版本调研结论：6.18.38 是 6.18 LTS 稳定线的第 38 个补丁版本（2026-07-04 发布，LTS 预计 EOL 2028-12），同线当前最新为 6.18.45；cnjn 分支基于 6.18.38 官方基线加入 ZX279133 平台支持。树内 upstream-series/ 保留了该 ZX279133 16 补丁集（6.18.38 基线）作为参考。

十、待办与未来工作#

项目	说明	状态
有线网卡驱动	三件套：GEPHY（4 个千兆 PHY）、`zx279128s-mdio` 控制器、TM/NPP/PP 包处理引擎；参考原厂 `tm.ko`（1.2MB）/ `switch.ko`（223KB）逆向，cnjn 的 ZX279133 MDIO 补丁（0008）可作控制器写法参考	⏳ 下一个目标
第二核 SMP	原厂 enable-method `zte,zx279128-smp`，需逆向上核流程（推测类似 A9 的 NDPGFCR / freeze 寄存器）	⏳ 未移植
SPI-NAND + 透明解密	ZTE SPIFC 控制器 + Denali NAND；flash 分区带 AES-128-ECB 透明解密（密钥由 `zte_token` 派生）；本移植不碰 flash，不含任何原厂密钥	⏳ 未移植
PCIe host（MT7916 WiFi）	`zte,ZX279127-pcie` 未移植；`mt7916e` 驱动已编入内核，PCIe 通了 WiFi 即用	⏳ 未移植
时钟树	topcrm / lsp0crpm / lsp1crpm 用 fixed-clock 占位；A9 PERIPHCLK 500MHz 实测可用，外设时钟精度未逐一校准	⚠️ 占位
DW MMC	SD 控制器在原厂 DT 里就是 disabled	⚠️ DT 已写
USB host	dwc2 / dwc3 驱动已验证，但本机型无对外 USB 口、控制器时钟未接，DT 保持禁用	⚠️ 禁用
OpenWrt / ImmortalWrt 移植	需先补齐网卡与闪存驱动	⏳ 规划中

提示

已完成且已上板验证的项还包括：L2C-310 / GIC / 全局定时器（单核 1000 BogoMIPS）；DTS 中 NAND / SPIFC / PCIe / MDIO / GEPHY 节点已描述但未启用；原厂网络命令 ip / iptables / ip6tables / ebtables / tc / dnsmasq / curl 已打包进 initramfs。

十一、总结#

链路已全部打通：固件解密 → SoC 逆向 → U-Boot 引导 → 主线 6.18.38 → busybox shell → mihomo 适配 → 开源发布；
关键经验：XIP 加载陷阱、0x42000000 禁区、强制 -marm、-j4 上限、CRLF 行尾、嵌入式 initramfs、armv5 软浮点；
硬件上限：无 VFP / NEON / idiv，代理加解密是 CPU 软算，跑满速会有明显瓶颈，但已做到不非法指令、特性齐全；
可复现：源码、设备树、配置、工具、双平台一键脚本、CI 全部在仓库中，拉下来就能编，改完还能继续编。

文档版本： 2026-08-31 适用系统： Windows 10/11（MSYS2 构建） / WSL2 适用平台： 中兴 ZTE ZXHN E2631（巡天 AX3000）

TCL/雷鸟电视 ADB 安装拦截排查与永久放行

Fri, 28 Aug 2026 00:00:00 GMT

本文档记录一次针对 TCL 电视（mt5879 方案，Android 11）「ADB 无法安装应用，必须先禁用安装器」问题的完整排查过程与最终解法。 适用设备： TCL 电视（mt5879_cn 方案，Android 11，其他 TCL/雷鸟机型可参考） 适用人群： 会使用 ADB 的电视用户 / 运维玩家

1. 问题现象#

TCL 电视通过 Wi-Fi ADB 连接后，安装应用直接报错：

Terminal window

1
adb connect 192.168.5.6
2

3
adb install xxx.apk

报错内容：

1
adb.exe: failed to install xxx.apk: Failure [INSTALL_FAILED_VERIFICATION_FAILURE]

只有先禁用系统安装器 com.android.packageinstaller 才能安装；但安装完成后必须重新启用，否则电视无法开机。整个流程繁琐且有翻车风险。

警告

com.android.packageinstaller 是开机关键组件，任何时候都不要让电视在「安装器被禁用」的状态下重启。

2. 排查过程#

2.1 缩小范围：排除 TCL 安全守护#

先怀疑的是 TCL 安全守护 com.tcl.guard，但实测它的启停与拦截无关；只有禁用 com.android.packageinstaller 才能放行安装，说明拦截逻辑在安装器应用自身。

2.2 复现拦截并抓取日志#

保持安装器启用状态，安装一个真实 APK 并抓取系统日志：

Terminal window

1
adb logcat -c
2

3
adb install -r xxx.apk
4

5
adb logcat -d > block.log

日志中出现关键线索：

1
Start proc com.android.packageinstaller for broadcast
2
  {com.android.packageinstaller/com.android.packageinstaller.verifier.VerifierReciver}
3
Foreground service started ...: service com.android.packageinstaller/.verifier.StrategyService
4
Config:Grabber:InstallConfig: Currrent content from Db is ：[{"enable":"true","strategies":[...]}]
5
D ConfigProvider: feature:content://com.tcl.providers.config/InstallConfig

拦截者浮出水面：TCL 在系统安装器里内置了一个验证组件，其策略来自一个内容提供者。

2.3 拉取安装器 APK 分析#

Terminal window

1
adb shell pm path com.android.packageinstaller
2

3
MSYS_NO_PATHCONV=1 adb pull /system/priv-app/PackageInstaller/PackageInstaller.apk .
4

5
unzip -o -q PackageInstaller.apk -d apk

提取 dex 字符串确认：

com.android.packageinstaller.verifier.VerifierReciver 监听 android.intent.action.PACKAGE_NEEDS_VERIFICATION，持有 android.permission.PACKAGE_VERIFICATION_AGENT 权限（全系统仅它持有）；
StrategyService 每次安装时从 content://com.tcl.providers.config/InstallConfig 读取策略 JSON。

查询该配置：

Terminal window

1
adb shell content query --uri content://com.tcl.providers.config/InstallConfig

1
Row: 0 project_id=InstallConfig, config_content=[{"enable":"true","strategies":[
2
  {"name":"safeStrategy","enable":"true","priority":"0"},
3
  {"name":"blackListStrategy","enable":"true","packages":[],"priority":"1"},
4
  {"name":"thridStrategy","enable":"false","packages":[...],"priority":"2"},
5
  {"name":"launcherStrategy","enable":"true","packages":[],"priority":"3"},
6
  {"name":"overDueStrategy","enable":"true","packages":[],"priority":"4"},
7
  {"name":"pmStrategy","enable":"true","priority":"5"}]}]

重要

组件级禁用（pm disable-user com.android.packageinstaller/.verifier.VerifierReciver）会被系统拒绝（Shell cannot change component state），但 shell 对这个配置提供者有写权限——这就是突破口。

3. 拦截机制原理#

enable=true 且策略生效

enable=false 无策略可用

adb install

PackageManagerService 创建安装会话

发送 PACKAGE_NEEDS_VERIFICATION 广播

VerifierReciver 接收

StrategyService 启动

读取 InstallConfig

verifyPendingInstall 拒绝

INSTALL_FAILED_VERIFICATION_FAILURE

不返回拒绝裁决

安装继续，Success

enable=true 且策略生效

enable=false 无策略可用

adb install

PackageManagerService 创建安装会话

发送 PACKAGE_NEEDS_VERIFICATION 广播

VerifierReciver 接收

StrategyService 启动

读取 InstallConfig

verifyPendingInstall 拒绝

INSTALL_FAILED_VERIFICATION_FAILURE

不返回拒绝裁决

安装继续，Success

要点：

组件	作用
`com.android.packageinstaller`	TCL 改造的系统安装器，同时是开机关键组件
`.verifier.VerifierReciver`	接收系统安装验证广播
`.verifier.StrategyService`	按策略决定放行/拒绝
`com.tcl.providers.config/InstallConfig`	策略配置存储，shell 可读写

4. 永久放行方案#

把 InstallConfig 的总开关改写为 false，验证器读不到可用策略即放行。安装器全程保持启用，开机无影响，重启后依然生效。

电脑 / 手机两个渠道任选其一

下面给出电脑（PowerShell）和手机（甲壳虫 ADB）两种写法，效果完全相同，选一个执行即可，不要都执行。手机端有一个前置条件：先在甲壳虫里连接电视并确认设备在线。连接断开后输入的任何命令都会报 no devices/emulators found，且报错会被界面吞掉——这是「命令没生效」最常见的原因。

电脑（PowerShell）——第一条改配置：

Terminal window

1
adb shell content update --uri content://com.tcl.providers.config/InstallConfig --bind config_content:s:false

电脑（PowerShell）——第二条重启验证器：

Terminal window

1
adb shell am force-stop com.android.packageinstaller

手机（甲壳虫 ADB）——第一条改配置：

Terminal window

1
content update --uri content://com.tcl.providers.config/InstallConfig --bind config_content:s:false

手机（甲壳虫 ADB）——第二条重启验证器：

Terminal window

1
am force-stop com.android.packageinstaller

建议

两个渠道的命令都设计成零引号：false 值不含引号和冒号，解析器读到它同样走「解析异常 → 无策略 → 放行」路径，效果与完整 JSON 等价。电脑端也用同款零引号写法——Windows PowerShell 5.1 与 7 给外部程序传参的行为不同，带多层引号的长命令在 5.1 上会丢引号导致写入坏数据，零引号写法在两个版本行为完全一致。每条命令执行前都确认设备在线。

验证写入结果：

Terminal window

1
adb shell content query --uri content://com.tcl.providers.config/InstallConfig --projection config_content

输出应为（电脑 / 手机端相同）：

1
Row: 0 config_content=false

之后安装直接：

Terminal window

1
adb install xxx.apk

提示

content 命令的 --bind 参数按冒号分段解析，任何含 JSON 的命令里冒号都必须转义——这也是第 5 节恢复命令比解锁复杂的原因。解锁因为用了零引号的 false 值，两个渠道都天然免疫此问题。

5. 恢复原始拦截#

想恢复 TCL 原始策略时，把配置写回完整的原厂策略数组即可。

注意

恢复必须写回下面完整的策略 JSON。只写 {"enable":"true"} 这种短形式，解析器照样按异常处理，拦截并不会恢复。恢复命令含引号和转义，若在手机端执行失败，改用电脑端即可（不影响已解锁状态）。

电脑（PowerShell）——本地生成恢复脚本 → 推送到电视 → 执行（三行按顺序，PowerShell 5.1 和 7 均实测可用）：

Terminal window

1
Set-Content -NoNewline -Encoding Ascii $env:TEMP\restore.sh 'content update --uri content://com.tcl.providers.config/InstallConfig --bind ''config_content:s:[{"enable"\:"true","strategies"\:[{"name"\:"safeStrategy","enable"\:"true","priority"\:"0"},{"name"\:"blackListStrategy","enable"\:"true","packages"\:[],"priority"\:"1"},{"name"\:"thridStrategy","enable"\:"false","packages"\:["com.dangbeimarket","com.shafa.market","com.ant.store.appstore"],"priority"\:"2"},{"name"\:"launcherStrategy","enable"\:"true","packages"\:[],"priority"\:"3"},{"name"\:"overDueStrategy","enable"\:"true","packages"\:[],"priority"\:"4"},{"name"\:"pmStrategy","enable"\:"true","priority"\:"5"}]}]'' --where "project_id=''InstallConfig''"'

Terminal window

1
adb push $env:TEMP\restore.sh /data/local/tmp/restore.sh

Terminal window

1
adb shell sh /data/local/tmp/restore.sh

手机（甲壳虫 ADB）：

Terminal window

1
content update --uri content://com.tcl.providers.config/InstallConfig --bind 'config_content:s:[{"enable"\:"true","strategies"\:[{"name"\:"safeStrategy","enable"\:"true","priority"\:"0"},{"name"\:"blackListStrategy","enable"\:"true","packages"\:[],"priority"\:"1"},{"name"\:"thridStrategy","enable"\:"false","packages"\:["com.dangbeimarket","com.shafa.market","com.ant.store.appstore"],"priority"\:"2"},{"name"\:"launcherStrategy","enable"\:"true","packages"\:[],"priority"\:"3"},{"name"\:"overDueStrategy","enable"\:"true","packages"\:[],"priority"\:"4"},{"name"\:"pmStrategy","enable"\:"true","priority"\:"5"}]}]' --where "project_id='InstallConfig'"

恢复后同样重启验证器：

Terminal window

1
am force-stop com.android.packageinstaller

验证：查询命令同第 4 节，输出应为 [{"enable":"true","strategies":[...]}]。

原始配置全文（备份用）：

1
[{"enable":"true","strategies":[{"name":"safeStrategy","enable":"true","priority":"0"},{"name":"blackListStrategy","enable":"true","packages":[],"priority":"1"},{"name":"thridStrategy","enable":"false","packages":["com.dangbeimarket","com.shafa.market","com.ant.store.appstore"],"priority":"2"},{"name":"launcherStrategy","enable":"true","packages":[],"priority":"3"},{"name":"overDueStrategy","enable":"true","packages":[],"priority":"4"},{"name":"pmStrategy","enable":"true","priority":"5"}]}]

6. 兜底方案：禁用-安装-恢复#

若上述配置方案因固件更新失效，可回退到传统方案：禁用安装器 → 安装 → 恢复。

Terminal window

1
adb shell pm disable-user com.android.packageinstaller
2

3
adb install -r xxx.apk
4

5
adb shell pm enable com.android.packageinstaller

注意

禁用后务必确认恢复：adb shell "dumpsys package com.android.packageinstaller" 输出 enabled=1 才是启用状态（enabled=3 为禁用）。电视在安装器禁用状态下重启可能无法开机。

核心兜底逻辑（PowerShell 脚本要点）：

Terminal window

1
try {
2
    adb shell pm disable-user com.android.packageinstaller
3
    adb install -r $apk
4
}
5
finally {
6
    adb shell pm enable com.android.packageinstaller
7
}

try/finally 保证即使安装失败、甚至 ADB 中途断线，恢复命令也会执行。

7. 故障排查#

Q：写入命令报 Binding not well formed？

JSON 里的冒号转义错了位：手机端恢复命令的冒号必须写成 \:（单反斜杠），写成 \\:（双反斜杠）反而会报这个错。电脑端恢复用「本地脚本 + push」方式，转义已内置，无需手改。解锁则永远可以用零引号写法，天然免疫此问题。

Q：手机端命令执行了但毫无反应？

甲壳虫与电视的连接已断开。先在 app 里重连 192.168.5.6:5555 并确认设备在线，再执行命令；每条命令执行前都确认在线。

Q：写入成功但仍报 INSTALL_FAILED_VERIFICATION_FAILURE？

验证器进程缓存了旧配置，强制重启它：

Terminal window

1
adb shell am force-stop com.android.packageinstaller

Q：过了一段时间又被拦截了？

TCL 云端配置同步可能覆盖了本地配置，重新执行第 4 节的写入命令即可。可先用第 4 节的查询命令确认当前配置内容。

Q：adb devices 显示 unauthorized？

在电视屏幕上找到「允许 USB 调试」弹窗，勾选「一律允许」并确认；若电视无弹窗，重插网络 ADB 连接触发。

文档版本： 2026-09-05 适用设备： TCL 电视 mt5879_cn 方案（Android 11），其他 TCL/雷鸟机型可参考 适用平台： Wi-Fi ADB / USB ADB

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 相关进程的发现、确认结果、失败尝试，以及 2026-08-29 的续篇：freeze 配置写入打通与三件套闪退根因定位。
适用设备： TCL tcl_mt5879_cn 适用系统： Android 11 / API 30，固件 V729 连接方式： ADB over Wi-Fi

结论（2026-08-29 更新）

Google 三件套 APK 可以被系统识别并安装，但无法正常运行。闪退根因已定位：ADB 安装的 APK 位于 /data，拿不到 signature|privileged 级权限，进程在初始化阶段必然崩溃，与冻结机制无关（A/B 实测确认）。此前卡住的 freeze 配置写入也已打通，但它解决不了三件套的闪退。

1. 发现#

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

2. 确认结果#

freeze 配置是一个键值集合，完整结构如下：

1
[
2
  {"name": "enable", "value": "true"},
3
  {"name": "debug", "value": "false"},
4
  {"name": "tcl_fastHibernate", "value": "true"},
5
  {"name": "tcl_fastHibernateTimeout", "value": "1500"},
6
  {"name": "tcl_fastHibernateDebug", "value": "false"},
7
  {"name": "freezeProcessList", "value": ["..."]},
8
  {"name": "fastFreezeProcessList", "value": ["..."]}
9
]

freezeProcessList 中确认包含以下 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 下载服务和即时应用安装服务。

修正（2026-08-29）

最初把 freezeProcessList 理解为「待冻结名单」。但名单里同时存在 com.tcl.settings、com.android.bluetooth、com.google.android.tvlauncher 等 TCL 自家核心应用——冻结它们电视自己就无法工作。它更可能是免冻结白名单，即名单内进程受保护。该语义尚待反编译确认，但对本文结论无影响（见第 4 节，闪退与冻结无关）。

同时确认：

冻结实现位于 tcore apex 内的 tcl-service.jar，核心类为 com.android.server.am.appfreeze.FreezeManager、TclFreezeConfigUpdater，系统服务名为 tguard。
com.tcl.guard 是 TCL 的守护组件，会参与进程管理。
com.tcl.providers.config 是 TCL 配置提供者，不应当作为普通应用随意停用。
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` 配置（2026-08-29 已打通）#

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

突破

失败原因是 content 命令的 --bind 参数按冒号分段解析，JSON 里的每个 : 都必须转义成 \:（Git Bash 中写作 \\:）。转义后写入成功：

Terminal window

1
J=$(cat /data/local/tmp/freeze.json)
2

3
E=$(echo "$J" | sed 's/:/\\\\:/g')
4

5
content update --uri content://com.tcl.providers.config/freeze --bind "config_content:s:$E" --where "project_id='freeze'"

用同样的方法可以查询和回写配置（原始配置已备份）。同一技巧也解决了另一台 TCL 电视的 ADB 安装拦截问题，见《TCL/雷鸟电视 ADB 安装拦截排查与永久放行》。

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. 闪退复现与根因定位（2026-08-29 续篇）#

4.1 实验环境#

在另一台同固件的 TCL 电视（tcl_mt5879_cn，192.168.5.6:5555）上完成：

使用 MindTheGapps 11.0.0-arm-ATV（匹配 Android 11 + armeabi-v7a + Android TV）。
通过 ADB 安装 GoogleServicesFramework.apk 与 PrebuiltGmsCorePano.apk（即 com.google.android.gms），均安装成功。

4.2 触发方式#

国内固件开机后没有任何东西会拉起 GMS：没有 Play Store 和 setup wizard 作为触发源，且 ADB 安装的包处于 stopped 状态，收不到开机广播。需要主动拉起 GMS 的可用 Activity（如 com.google.android.gms/.ads.settings.AdsSettingsActivity）。

4.3 现象：崩溃-重启死循环#

进程以前台（TOP）状态被反复拉起、随即死亡，约 300ms 一次：

崩溃循环

注意这不是冻结——冻结只会暂停进程，不会杀进程；这里的进程死因是自身初始化抛异常。

4.4 根因：signature|privileged 权限缺失#

从 dumpsys dropbox --print data_app_crash 拿到完整堆栈，两个包各死于一个系统权限：

闪退根因

GSF 的崩溃堆栈（GoogleSettingsProvider 初始化）：

1
java.lang.RuntimeException: Unable to get provider
2
    com.google.android.gsf.settings.GoogleSettingsProvider:
3
    java.lang.SecurityException: You need MANAGE_USERS permission to: get the profile parent
4
        at com.google.android.gsf.settings.GoogleSettingsProvider.onCreate(GoogleSettingsProvider.java:158)
5
        at UserManager.getProfileParent(UserManager.java:3564)

GMS 的崩溃堆栈（Application 初始化）：

1
java.lang.RuntimeException: Unable to create application co.g.App:
2
    java.lang.SecurityException:
3
    addOnPermissionsChangeListener: Neither user 10094 nor current process
4
    has android.permission.OBSERVE_GRANT_REVOKE_PERMISSIONS

MANAGE_USERS 与 OBSERVE_GRANT_REVOKE_PERMISSIONS 都是 signature|privileged 级权限，只能授予 /system/priv-app 内、且在 privileged-permissions 白名单中的应用。ADB 安装的 APK 位于 /data，永远拿不到这两个权限，于是 provider / Application 初始化必然抛 SecurityException，系统反复拉起 → 无限闪退。

/system/priv-app 应用

ADB 安装的 /data 应用

拉起 GMS/GSF 界面

进程启动

初始化 ContentProvider / Application

持有 signature 级权限?

正常初始化

SecurityException

进程死亡

系统重新拉起

/system/priv-app 应用

ADB 安装的 /data 应用

拉起 GMS/GSF 界面

进程启动

初始化 ContentProvider / Application

持有 signature 级权限?

正常初始化

SecurityException

进程死亡

系统重新拉起

4.5 A/B 验证：与冻结无关#

控制变量实验——同一台电视、同一组 APK、只切换 freeze 配置：

freeze enable	现象
`true`（原始值）	拉起即闪退，300ms 崩溃循环
`false`（冻结关闭）	完全相同的闪退，堆栈一致

结论：三件套的闪退与冻结机制无关，是确定性的权限缺失，ADB 层面无解。

5. 对冻结机制的再认识#

freeze 配置可被 shell 读写（冒号转义突破后），配置修改在重启后依然生效。
开机时 FreezeManager 确实按配置工作（日志可见 doUnFreeze、FreezeNameList: policy : freezeProcessList ... inSpecifyList : true/false）。
但 freezeProcessList 的语义存疑：名单内含大量 TCL 核心应用，更接近免冻结白名单；且三件套的死亡方式（前台状态主动死亡）与冻结（暂停不杀）行为特征不符。
国内固件开机后不会自发拉起 GMS，「开机闪退」在这台电视上不会自发发生——只有主动打开依赖 Google 服务的界面才会触发。

6. 最终结论#

TCL 固件确实存在进程冻结机制（FreezeManager / tguard），配置可读写，但其语义更接近白名单，且与三件套闪退无关（A/B 实测确认）。
三件套闪退的根因是 signature|privileged 级权限缺失（GSF 缺 MANAGE_USERS，GMS 缺 OBSERVE_GRANT_REVOKE_PERMISSIONS），ADB 安装的 /data 应用拿不到这些权限。
在不 root、不修改系统分区的前提下，三件套无法正常工作——修复必须将 GMS/GSF 放入 /system/priv-app 并加入特权权限白名单。
ADB 能做到的极限：安装成功（需先解除 TCL 的安装拦截，见《TCL/雷鸟电视 ADB 安装拦截排查与永久放行》）、配置接口自由读写；无法赋予系统特权。
com.tcl.guard 只是守护组件之一，停用它不能改变任何结果。

文档版本： 2026-08-29 记录状态： freeze 配置写入已打通；闪退根因已定位（权限缺失），ADB 层面无解

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端是否只检测设备型号，仅猜测）

Tag 分区与 Wi-Fi 分区性质不同，处理方式也不同：

分区	内容	修改方式
Tag（mtd2）	裸结构化记录 + CRC32	`setmac` 逐参数改，或 `mtd_write_tag` 整区写入（2.2）
Wi-Fi（mtd3）	JFFS2 文件系统，内含 `caldata`	用备份文件在挂载点写回（2.3）

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 分区（mtd3）是 JFFS2 文件系统，开机已经挂载在 /wlan，里面只有 caldata 一个文件（196,608 字节）。备份时直接读这个文件 —— 恢复时原样写回即可，不需要任何解包步骤：

Terminal window

1
cat /wlan/caldata > /tmp/caldata-backup.bin

若 /wlan 没有挂载

先执行 mount -t jffs2 /dev/mtdblock3 /wlan，再按上面的命令备份。

确认电脑的 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/caldata-backup.bin -r caldata-backup.bin 192.168.5.7

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

2.2 修改 Tag：setmac 命令与 mtd_write_tag 工具#

Tag 分区（mtd2）是裸结构化数据加 CRC32 校验，Tag 中同时存在主 MAC、第二 MAC、MAC 前缀、D-SN、S/N、型号和 Wi-Fi 信息。按场景有两种修改方式：

方式	原理	适用场景
方法一：`setmac` 命令（推荐）	固件自带命令逐参数修改，自动完成 NAND 擦除并重算 CRC32	改型号、MAC 等单个字段
方法二：`mtd_write_tag` 工具	自编译 MTD 写入工具，把改好的 Tag 整区镜像一次擦写写入	整区替换，或 `setmac` 不可用的设备

方法一：setmac 命令（推荐）#

设备固件自带 /bin/setmac，它通过 libtagparam.so + libmtduserapi.so 直接读写 Tag 分区，内部会自动完成 NAND 擦除并重算 CRC32 —— 不需要离线改文件，也不需要自编译任何工具。

用法：

Terminal window

1
setmac                        # 无参数时打印帮助
2
setmac show2                  # 列出全部具名参数
3

4
setmac <action type> <para_id> [<hex string para_val>]

action type 含义：

值	动作
`1`	set，写入参数
`2`	get，读取参数
`3`	del，删除参数
`4`	format，格式化整个 Tag 区（危险，勿用）

查看当前参数：

Terminal window

1
setmac show2

输出示例：

1
===============Current Status of TagParam===============
2
Mac[ID: 256] is set to AA BB CC DD EE FF
3
OUI[ID: 768] is set to AABBCC
4
DeviceSerialNumber[ID: 512] is set to XXXXXXXXXXXXXXXXX
5
WirelessNetName[ID: 1024] is set to Example-SSID
6
WlanPass[ID: 1296] is set to ExamplePass
7
...
8
==============

常用参数 ID：

参数	ID	参数	ID
`Mac`	256	`WirelessNetName`	1024
第二 MAC	257	`WirelessNetName5G`	1028
`DeviceSerialNumber`	512	`WlanPass`	1296
`OUI`	768	`WlanPass5G`	1328
运营商代码	1793	型号	33024

型号不在 show2 列表里

setmac show2 只列出它”具名”的那批参数，型号（ID 33024）不在其中，但可以用 ID 直接读写。所有 get 的返回值都是十六进制，需要自己解成 ASCII。

改型号（E2633 转 E2631）#

Terminal window

1
# 1. 读当前型号
2
setmac 2 33024
3
#   2633 设备预期返回：5a58484e204532363333   ( "ZXHN E2633" )
4

5
# 2. 写入 E2631
6
setmac 1 33024 5A58484E204532363331
7

8
# 3. 回读验证
9
setmac 2 33024
10
#   预期返回：5a58484e204532363331

十六进制可以交给设备自己算，不用手推：

Terminal window

1
printf 'ZXHN E2631' | hexdump -v -e '1/1 "%02x"'
2
# 5a58484e204532363331

常见形式对照（把末尾 33 改成 31）：

型号字符串	hex
`ZXHN E2633`	`5A58484E204532363333`
`ZXHN E2631`	`5A58484E204532363331`
`ZTE E2633`	`5A5445204532363333`
`E2633`	`4532363333`

长度要一致

型号字段长度为 10 字节（ZXHN E2631）。setmac 对长度有校验，改型号时请与读取值保持等长，否则可能被拒绝，或破坏后续记录结构。

只改型号时，其余字段（MAC、S/N、OUI、Wi-Fi）全部保持原值 —— 这正是”其他信息都还是自己贴纸上的”。若需单独修正 MAC：

Terminal window

1
setmac 2 256                       # 读当前主 MAC
2
setmac 1 256 AABBCCDDEEFF          # 主 MAC（2.4G）
3
setmac 1 257 AABBCCDDEE00          # 第二 MAC（5G）
4
setmac 1 768 AABBCC                # OUI = MAC 前三字节
5
setmac show2                       # 回读确认

改完重启。Tag 在启动阶段被读取（initwifi 会调用 setwlanmac 把 MAC 应用到无线接口），cspd 与 Web 页面也会重新读取：

Terminal window

1
reboot

风险提示

setmac 4 会格式化整个 Tag 分区，MAC、S/N、OUI、Wi-Fi 信息全部清空，不要执行。
setmac 3 <id> 删除单个参数，同样危险。
改型号或 MAC 属于改变设备身份，会影响 TR-069 上报、APP 绑定与 Web 显示；操作前建议先用 setmac show2 记录全部原值，并顺手备份：
Terminal window
```
1
mkdir -p /wlan/bak && cat /dev/mtd2 > /wlan/bak/tag-backup.bin
```

方法二：mtd_write_tag 整区写入（备选）#

mtd_write_tag 是自己编译的 ARMv7 MTD 写入工具，点此下载 mtd_write_tag_armv7（common-tools 包内也附带，见 6.1 节）。它按 MTD 的擦除块、写入页和坏块规则执行整区擦写，适合需要整区替换（例如离线改好整个 Tag 镜像），或 setmac 不可用的设备。该工具只针对 Tag 的 MTD 写入流程，不能未经验证地用于 Wi-Fi、Bootloader 或其他分区。

若需要离线生成改好的 Tag 镜像，可使用脚本改型号为E2631：把 tag-backup.bin 重命名为 tag.bin，与脚本放在同一级目录，双击脚本即可得到 tag-E2631.bin，其他信息仍是自己设备贴纸上的。

Tag分区信息

Tag 结构（离线自行修改镜像时，需要自己重算 CRC32）：

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

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

先把改好的 Tag 镜像和工具通过 TFTP 传入路由器（192.168.5.7 是电脑的 TFTP 地址，请按实际网络修改）：

Terminal window

1
ping -c 3 192.168.5.7
2

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

上面脚本生成的是 tag-E2631.bin，传输时按实际文件名填写 -r 参数即可。

先确认程序用法：

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

出现 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。

2.3 恢复 Wi-Fi 分区：用 2.1 的备份文件写回#

Wi-Fi 分区（mtd3）是 JFFS2 文件系统，开机时挂载在 /wlan，里面只有一个 caldata 文件（196,608 字节）。它与 Tag 性质完全不同：

	Tag（mtd2）	Wi-Fi（mtd3）
内容	裸结构化记录 + CRC32	JFFS2 文件系统
是否挂载	否	是，挂在 `/wlan`
能用 `setmac`	能	不能
能用 `cat` 裸写	不可靠	不行

为什么不能用 cat 写： cat 文件 > /dev/mtd3 会被直接拒绝，写请求根本不生效：

1
# cat /tmp/wifi.bin > /dev/mtd3
2
/bin/sh: can't create /dev/mtd3: No child processes
3
# echo $?
4
1

在 E2631（192.168.5.2）上实测：完整 1 MiB 分区镜像、仅 4 字节内容、追加模式 >>，三种写法返回同一错误；先 umount /wlan 再写也照样失败；写入前后 cat /dev/mtd3 | md5sum 完全相同，分区内容零变化。权限与 MTD 标志均正常（/dev/mtd3 为 crw-r--r--，/sys/class/mtd/mtd3/flags = 0x400，即 MTD_WRITEABLE）。

所以”把自己那份原样写回、MD5 一致”是个假象：写操作从未生效，读回的又是分区原有内容，两者当然一致 —— MD5 相同完全不能证明写入成功。

NAND 的另一个坑

E2631 用的是 SPI NAND，编程时只能把位从 1 变成 0，要把位从 0 变回 1 必须先整块擦除（128 KiB）。这是裸写普遍不可靠的根本原因；不过在这台设备上，cat 连提交写入请求这一步都过不去。

为什么不能用 setmac： 它依赖 libtagparam.so，只认 Tag 分区。

正确做法：恢复挂载点里的 caldata，擦除、ECC、坏块跳过、磨损均衡全部交给 JFFS2。

先确认挂载状态：

Terminal window

1
mount | grep wlan
2
ls -l /wlan/

正常应看到：

1
/dev/mtdblock3 on /wlan type jffs2 (rw,relatime)
2
----------    1 Z500_w9b root        196608 Jan  1  1970 caldata

把 2.1 备份的 caldata-backup.bin 传回设备：

Terminal window

1
tftp -g -l /tmp/caldata -r caldata-backup.bin 192.168.5.7

写回挂载点：

Terminal window

1
cp /tmp/caldata /wlan/caldata
2
sync
3

4
md5sum /tmp/caldata /wlan/caldata

两个 MD5 必须一致。随后让驱动重新加载校准数据：

Terminal window

1
rmmod mt7916
2
insmod /lib/modules/mt7916.ko

mt7916 通常被 tm、plat_zxylzb_9128S 等模块引用，rmmod 会直接失败，此时 reboot 即可。

不要裸写 /dev/mtd3

Wi-Fi 分区是已经挂载的活动 JFFS2 文件系统。对它裸写不只是”写不进去”：一旦部分块真的被写坏，JFFS2 的节点头与校验会错乱，可能导致下次挂载失败、整个分区读不出来 —— 比 Tag 写坏更难恢复。

3. Web 本地上传分析研究#

注意（2026/08/29更新）

中兴官方系统自带Web本地上传升级界面：http://192.168.5.1/supgrade.html 由@cnjn研究发现，以下内容仅作研究分享。

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，只有 fw_flashing、upgradetest 等程序；这些程序没有暴露 Tag 写入接口。

最终是自己编译 MTD ioctl 工具（mtd_write_tag）完成写入的。

后来才发现，官方固件本身就自带 /bin/setmac（见 2.2 节），它通过 libtagparam.so + libmtduserapi.so 自动完成擦除并重算 CRC32 —— 改 Tag 用一条命令就够了，不需要自编译任何工具。mtd_write_tag 仍然可用，适合需要整区替换或 setmac 不可用的场景。

5.2 Web 反复失败#

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

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

5.3 未验证自动回退#

已确认 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 和指定签名区零字节数。签名区非零不等于签名有效。

创维盒子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（tag包含SN/MAC等信息是远程控制的关键，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 盘排查

Shiyan

Firefly 博客接入 Pages CMS：浏览器里写文章，不用本地环境

一、Pages CMS 是什么#

二、接入三步走#

2.1 仓库根目录新建 .pages.yml#

2.2 建好媒体上传目录#

2.3 打开 CMS 确认#

三、避坑前置：字段必须覆盖 front matter#

四、完整配置（可直接抄）#

五、配置逐段拆解#

5.1 media：图片传到哪、URL 长什么样#

5.2 filename：新文件的命名规则#

5.3 view：列表怎么排#

5.4 exclude：把图片从条目列表里藏起来#

5.5 operations：给危险操作上锁#

5.6 date 字段的 options#

六、踩坑记录#

6.1 日期必须保持「裸格式」，否则构建直接炸#

6.2 空字段不会写出 null，但必填字段别空着#

6.3 纯中文标题生成不了文件名#

6.4 MDX 文件别用富文本编辑器#

6.5 复杂 Markdown 建议切到 source 模式#

6.6 「via Pages CMS」的提交会规范化文件格式#

七、日常使用#

7.1 写一篇新文章#

7.2 草稿流程#

7.3 改独立页面#

八、故障排查#

九、结语#

个人主页重写：Vue 3 毛玻璃 Bento + 洛雪音源

为什么自己写一份#

功能一览#

音乐播放器：多源自愈 + 洛雪音源#

播放器本身#

为什么要接洛雪音源#

请求链路#

部署#

平台托管（推荐）#

本地开发#

全部配置化：只改 src/config.js#

TODO#

致谢#

fileserver：单文件自建文件服务器（GO）

一、为什么要再造一个文件服务器#

配套介绍页#

二、功能总览#

三、大文件分片上传#

四、分享与浏览的几处细节#

4.1 相册视图#

4.2 分享别名#

4.3 防盗链#

五、快速开始#

5.1 直接运行#

5.2 常用启动参数#

六、三种部署方式怎么选#

6.1 一键部署到 Linux（推荐）#

6.2 Docker 部署#

七、一键自更新是怎么工作的#

八、WebDAV：播放器直连#

九、安全设计#

十、注意事项与故障排查#

中兴巡天AX3000 (E2631) 主线 Linux 内核移植全记录

一、项目背景与目标#

二、硬件规格与 SoC 逆向#

2.1 硬件规格#

2.2 CPU 能力（最重要的事实）#

2.3 串口 IP 逆向#

2.4 与 SR1010 的外设差异#

三、固件获取与解密#

3.1 加密与密钥#

3.2 分区布局#

3.3 kmodule 解包与 vendor 运行库#

四、串口与 U-Boot 引导#

4.1 进入 U-Boot#

4.2 XIP 陷阱（本项目最大的坑）#

4.3 完整引导链路#

五、Windows 交叉编译环境#

5.1 环境组成#

5.2 Windows 构建的强制限制#

5.3 踩过的编译坑（均已修复并固化在仓库）#

2.1 仓库根目录新建 `.pages.yml`#

全部配置化：只改 `src/config.js`#

6.1 关键特性（全部 `=y` 并已上板验证）#

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

3.3 修改 `freeze` 配置（2026-08-29 已打通）#