逆向工程 on CloudLake

在浏览器里养一台计算器：TI-Nspire 在线模拟器从 0 到「长期使用」

Sat, 24 Oct 2026 00:00:00 +0000

一个 GPL 的 ARM 计算器模拟器、一个从 2016 年捞出来的 Palm 游戏、一台 1995 年的 Windows 95 机器，最后都被塞进了同一个网页里。

现在打开 cloudlake.eu.org/nspire，你会看到四张卡片：经典灰度 Touchpad、彩色 CX II CAS、一个彩蛋 Windows 95，以及长期使用的登录入口。下面这篇文章把这个平台从架构到踩坑完整讲一遍。

一、最后做出来的东西

三种「机器」共用一个页面：经典 Nspire Touchpad（灰度 320×240）、CX II CAS（彩色 16 位色）、以及通过 WiNspire 跑的 Windows 95
完整键盘 + 触摸板 + 文件传输：70 个键的屏幕键盘、触摸板滑动/点击、拖拽/整文件夹上传、目录浏览与下载
游戏一键启动：点一下就从服务器把 nPal（仙剑奇侠传）传进计算器并自动运行
长期使用模式：用户名登录，状态存服务器，每 2 分钟自动保存，下次登录直接接着用

经典灰度机的页面是同一个文件，只是换了镜像：

二、地基：把 Firebird 编译成 WebAssembly

Firebird 是一个开源（GPL-3.0）的 TI-Nspire 模拟器，桌面版基于 Qt。它模拟的是 ARM926 级别的 SoC、LCD 控制器、键盘矩阵、NAND flash 和 USB 控制器。

网页版做的事情是：

用 emscripten 把 Firebird core（约 33 个源文件）编译成 firebird.js（约 88 KB）+ firebird.wasm（约 230 KB）
页面把 flash 镜像（整块 NAND 转储，经典机 33 MB，CX II 132 MB）写进 Emscripten 的内存文件系统
可选加载 snapshot（gzip 压缩的 RAM + CPU 状态），实现「秒开」
用 paintLCD() 把 320×240 的帧缓冲画到 <canvas> 上

几个设计决定后来被证明是对的：

一个 emu.html 支持所有机型：机型差异全部收敛到 URL 参数 ?flash=...&boot=...&snap=...，页面代码是同一份。经典机、CX II、Windows 95、长期使用模式都复用这套加载逻辑。
镜像放服务器、状态放浏览器/账号：静态镜像走 Caddy 的 precompressed（brotli/gzip），经典 flash 压缩后约 12 MB，CX II 约 17 MB，浏览器缓存 30 天。
快照优先：冷启动 60 秒 vs 快照恢复几秒，体验差距巨大，所以后来能存快照的场景都尽量存。

三、让模拟器「能用」：键盘、触摸板、文件传输

只有画面没有输入，模拟器就是个屏保。这部分是平台真正的骨架。

3.1 键盘：70 键矩阵

Firebird 的键盘是 8×11 矩阵，网页端只暴露一个 setKey(row, col, state)。页面上用 DOM 画了 70 个键，按下时转成矩阵坐标注入。

唯一的小坑：OS 的键盘扫描有间隔，太快松开会漏键，所以前端给每次按键加了 最少 80 ms 的保持时间。

3.2 触摸板：从「只认方向键」到真正能推鼠标

这是整个项目最值得写的一段。TI-Nspire 的触摸板在 OS 里既当 5 向键用（菜单导航），又当鼠标用（图形、几何、Windows 95）。

原来的实现只会模拟「按触摸板边缘 → 方向键」，菜单能走，但 GUI 指针纹丝不动。原因是：OS 的指针用的是触摸板驱动算出来的相对位移（touchpad_rel_x/y），而页面从来没把连续滑动坐标送进去。

修复思路：

拖动时按 ~38 Hz 连续调用 setTouchpadNorm(x, y, contact=1, down=0)，让 Firebird 的 touchpad_set_state() 计算相对位移
轻点 = 按下脉冲（中心 = 左键，边缘 = 方向键；Ctrl + 轻点 = 右键）
混合回退：如果滑动了 220 ms、画面完全没变化（TI-OS 菜单只认方向事件），自动退化成方向键手势，这样拖动导航不丢

修复后的效果（拖动前 / 后，Win95 的鼠标从画面中心移动到右下）：

3.3 文件传输：把虚拟 USB 线变成拖拽上传

Firebird 的 USB Link 层允许宿主机和模拟器里的 OS 互传文件。我们在 WASM 里加了这些导出：

1
2
3
4


emuPutFile(local, remote) MEMFS → 计算器
emuGetFile(remote, dest) 计算器 → MEMFS
emuNewDir / emuDirList / emuDelete / emuMove
emuUsblinkProgress / Busy / Done / Abort

前端在此之上做了：

上传队列：串行传输、逐文件进度条、失败自动重试（OS 侧偶发返回负数错误码时，emuUsblinkAbort() + 重连再试）
整文件夹上传：<input webkitdirectory> + 拖拽目录时用 webkitGetAsEntry() 递归，保留相对路径，按层级 emuNewDir 自动建目录
只收 .tns 的 OS 限制：实测 OS 文档服务只接受 .tns，其它扩展名（.txt/.dat/.bin/.zip/.py/...）一律被拒；文件夹里的非 .tns 会在界面上标「跳过」，并提示先改名

四、踩过的最大的坑：页面「弹输入窗口」然后冻结

有一段时间用户反馈：装 Ndless 的时候浏览器弹出一个输入窗口，然后整个页面卡死。

追下去发现链路非常长：

Ndless 安装器在模拟器里触发了非法指令（Prefetch abort / Cannot set T bit）
Firebird 的异常处理会进入内置调试器
WASM 版的调试器输入函数还在读 stdin
Emscripten 的 stdin 兜底实现是 window.prompt("Input: ")
window.prompt 会阻塞页面主线程 → 整个模拟器看起来死了

修复是在 firebird/emscripten/main.cpp 里给 gui_debugger_request_input() 换成直接返回一条 c（continue），让异常路径走 EVENT_RESET 重启 OS，而不是等用户输入。

顺带修掉的还有一个自己引入的回归：点击画面曾经等于点触摸板中心，会误开文档/对话框。现在画面单击只负责取键盘焦点，点击请用触摸板区域。

五、nPal 移植：把 2016 年的 Palm 游戏跑进浏览器

nPal 是网友 ntzyz 把 PalmOS 时代的《仙剑奇侠传》 移植到 TI-Nspire 的项目。我们拿到的是 2016 年的 nPal 1.2 发布包，里面是一个 1.25 MB 的 sdlpal.tns。

5.1 旧包为什么会在 CX II 上弹「兼容性模式」

旧的 sdlpal.tns 是 PRG 容器（文件头 50 52 47 00），里面根本没有 Zehn 签名。Ndless r2022 会用旧加载路径跑它，于是：

读不到 Zehn 标志位表
supports_hww 保持 false
Ndless 弹出「Activating compatibility mode. This application hasn’t been updated to work with your hardware.」
走 320×320 的 LCD 兼容层，CX II 的原生 240×320 旋转屏适配失效

5.2 重新编译

用 Ndless r2022 SDK 重新编译 nPal 的 SDL 部分：

SDK 自带的 nSDL 1.1.1 已经改用新的 lcd_blit 屏幕 API
genzehn 打包时扫描 ELF 符号，发现 _genzehn_new_lcd_api 标记，自动写入 USES_LCD_BLIT = true 和 RUNS_ON_HWW = true
产物 sdlpal.tns 419,248 B（纯 Zehn，无 PRG 外壳），genzehn --info 能直接验证：

1
2
3


Application: sdlpal
This executable uses the new lcd_blit API.
This executable supports the HW-W 240x320 LCD.

另外两条工具链（官方 GCC 14.2 和 apt GCC 13）构建出的版本，在模拟器里逐帧逐像素完全一致，最后分发用官方工具链版。

5.3 资源文件与启动

nPal 的资源是 resources.bin.tns（23.9 MB）和 desc.dat.tns（16 KB）——它们本质上就是数据文件，只是 故意用 .tns 扩展名，这样才能通过 OS 的文档服务传进计算器。全部放进计算器的 /npal，运行 sdlpal.tns 即可。

在模拟器里看到的结果：

5.4 一键游戏启动

手动上传三个文件太麻烦，于是做了「快速启动游戏」：

服务器放 games.json 清单 + 每个游戏的文件（同时生成 .br/.gz 供 Caddy 预压缩）
页面选择 nPal → 依次下载 3 个文件 → 自动创建 /npal → 走 USB 上传 → 主程序最后上传，保证文件浏览器选中它 → 自动发回车运行
旁边还有「安装 Ndless」按钮：自动上传安装器+资源，再按固定节奏发 Enter 走完安装流程

实测（线上）：安装 Ndless 66 秒 + 启动游戏 59 秒，然后就是标题画面。

六、彩蛋：在计算器里跑 Windows 95

WiNspire 是 tiny386（x86 PC 模拟器）的 CX II 移植，以 Ndless 程序运行，Native 模式给 guest 16 MB RAM / 256 KB 显存。于是流程变成：

1

浏览器 → Firebird(WASM，模拟 CX II) → TI-OS + Ndless → winspire.tns(tiny386) → Windows 95

磁盘镜像是从 PCjs 的 Windows 95 RTM 演示机用它的 “Save HD” 导出的 68 MB raw image
把镜像改名成 disk.img.tns，和 winspire.tns、bios、vgabios、ini 一起上传到 /winspire
冷启动大约 4–5 分钟：SeaBIOS → Windows 95 开机画面 → 桌面

为了把「开机 4 分钟」变成「秒进桌面」，又做了预烘焙：

在模拟器里跑到 Win95 桌面
调用 saveSnapshot() 生成快照
关键：Firebird 的 NAND 修改默认只在内存里，必须调用新加的 saveFlash()（内部就是 flash_save_changes()）把修改块写回 flash.img，否则导出的镜像还是原样

最终页面加载 flash（brotli 后 17.2 MB）+ snapshot（33 MB，基本不可压缩），点开始几秒后直接是 Windows 95 桌面：

七、长期使用：用户名登录 + 状态持久化

短期玩一玩，刷新页面就重来；但总有人想「养」一台自己的计算器。于是加了长期使用模式：

登录页输入用户名（无密码，HMAC 签名 cookie 记身份）
一个用户名同一时间只能开一个窗口（心跳续锁，180 秒无心跳自动过期）
新用户从干净的 CX II 系统开始（默认镜像）
保存 = flash 镜像 + 内存快照：
- saveFlash() 把 NAND 修改写回 MEMFS 的 flash.img（138 MB）
- saveSnapshot() 生成 snapshot.bin（gzip 流）
- 浏览器里用 CompressionStream('gzip') 把 flash 压到约 19 MB，和快照（约 10–33 MB）一起 POST 到服务器
恢复 = 直接加载 flash + snapshot，从快照恢复现场
每 2 分钟自动保存一次；「保存」按钮手动存；「退出」先保存再注销

后端是一个 Python 标准库写的单文件服务（nspire-lt，systemd 托管），Caddy 把 /nspire/api/ 反代到它，数据落在 /var/lib/nspire-lt/users/<user>/。

实测完整流程（登录 → 启动 → 打开图形应用 → 保存 → 退出 → 再登录）：

1
2
3
4


first load (default image) 10s
saved: ... · 已保存 11:58:19
second load (with state) 10s
restore elapsed 9236 ms; diff vs saved-graph screen: 0 ← 恢复后画面与保存时逐像素一致

八、数据与性能

机型	flash 原始	首屏（br 压缩）	启动	备注
经典 Touchpad	33 MB	~12 MB	快照恢复极快	灰度 320×240
CX II CAS	132 MB	17.2 MB	冷启动 ~60 s	彩色 16 位色
Windows 95	132 MB + 68 MB 磁盘	~50 MB（含快照）	冷启动 4–5 分钟，快照秒开	双重模拟，慢
长期使用	每用户 flash + 快照	登录时下载	快照恢复 ~9 s	服务器存档

一些数字：模拟 USB 传输约 550 KB/s（23 MB 的 nPal 资源约 40–60 秒）；一次长期存档上行约 20–50 MB；长期模式每人磁盘占用约 30–50 MB（gzip 后）。

九、还欠着的

Windows 95 冷启动版：预烘焙时遇到 NAND 写回/flash 保存的边界问题，目前只保留快照直启入口
Ndless 冷启动激活状态：干净镜像冷启动后 Ndless 不是激活状态，需要在游戏面板点一次「安装 Ndless」（约 1 分钟）；长期使用模式里装好保存后，快照会保留激活状态
移动端触控（目前触摸板/鼠标事件主要按桌面调优）
音频：Firebird 的 PC 喇叭/声音还没接

结语

这个项目最花时间的部分，其实不是「把模拟器编成 WASM」——那是几小时的活。真正难的是层与层之间的接缝：

浏览器输入 → ARM 模拟器 → TI-OS 驱动 → Ndless → 游戏/Windows，每一层都有自己的假设。触摸板的「方向 vs 指针」、文件系统的「只收 .tns」、调试器的「读 stdin」、NAND 的「写缓存」，每一个都足以让整个平台看起来「坏了」。

把这些接缝一个个对上之后，才有现在这个能在浏览器里养计算器、打仙剑、开 Windows 95、还能下次登录接着用的东西。

入口：https://cloudlake.eu.org/nspire/
长期使用：https://cloudlake.eu.org/nspire/lt/index.html
技术栈：Firebird（GPL-3.0）+ emscripten/WASM + Hugo + Caddy + 一个 Python 小服务

拆开 TI-Nspire 的 .tns 看里面

Tue, 13 Oct 2026 00:00:00 +0000

这台机器上有一个真实的 TI-Nspire 开发环境：OS 3.9.0.463 classic Touchpad、Ndless、从源码构建的 ARM 工具链。

目录里躺着 1055 个 .tns 文件。

.tns 不是一个格式。它是一层 PRG\0 外壳，里面是 Zehn 容器——Ndless 自己的可执行容器格式。而这个格式没有公开文档。

这个项目把它读懂了，并且用「能不能逐字节重建」来证明。

自己解出来的格式

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


.tns 文件
├── 装载器桩 0 ~ 0x1EC 字节（常见；也有 0/480/604/616/632 字节的变体）
└── Zehn 容器
 ├── 头 32 字节 8 个小端 u32：
 │ "Zehn" / version=1 / file_size / reloc_count /
 │ flag_count / extra_size / alloc_size / entry_offset
 ├── 重定位表 reloc_count × 4 字节
 │ 低 8 位 = 类型，高 24 位 = 偏移
 ├── 标志表 flag_count × 4 字节（同样的 8/24 位切分）
 ├── 额外数据 extra_size 字节（名字/作者/声明等字符串住在这里）
 └── 代码 剩下的；若首个重定位是 FILE_COMPRESSED 则为 zlib 流

两个坑，我都先踩了

坑一：「Zehn」这个字符串会骗你

最直接的思路是——搜文件里 Zehn 这四个字节，从那里开始解。

但装载器桩里也出现了这个字符串。

只搜这 4 个字节会找到诱饵。真正的头必须同时满足三个条件：

version == 1
各表长度放得下（不越界）
file_size 确实落在文件范围内

光靠一个魔数是不够的。 得用那些字段之间的一致性来互相验证。

坑二：「能力」不等于「要求」

genzehn 的 --color-support 默认是 true。

它的含义是「支持 CX/CM 彩屏」，不是「需要彩屏」。

我一开始理解反了，于是每一个正常程序都被判成「需要彩屏，所以在这台黑白机上跑不了」——一个完全反向的结论，而且看起来非常合理。

正确判据必须看值为 0：0 才表示"不支持这类机器"。

这个坑值得单独说：当一个字段名叫 supports，人们会下意识把它读成 requires。

验证：逐字节重建

rebuild() 从解析出来的字段把容器重新拼回去，然后和原文件比字节。

1
2
3
4
5


$ python -m zehnscope --rebuild "E:\QA\nspire-dev"
11/11 containers rebuilt byte for byte

$ python tests/test_zehn.py
 ok all 100 containers rebuild identically

这比"解析没崩溃"强得多。

因为偏移、计数、位域切分、字节序、字符串在额外数据里的定位——任何一处理解错，字节就对不上。

它一次同时检验所有假设。

语料是 1055 个真实文件，不是精选样本

其中 100 个是真正的 Ndless 程序，955 个只是沿用了 .tns 扩展名的文档/资源（boot1.img.tns、Hitori 关卡、Liero 素材……）。

一个只见过"干净样本"的解析器，证明力弱得多。跨十年、多个工具链、8 种不同桩的 100 个真实容器，才是像样的考验。

手写一个 DEFLATE 解码器

Zehn 的压缩用 zlib。

但语料里没有一个压缩容器——光靠真实文件测不到这条路。

所以自己按格式造一个再读回来。

解码器是手写的 RFC 1951 + 1950：stored / fixed / dynamic 三种块、LZ77 回引用、Adler-32 校验。

然后对照系统 zlib，在 40 组样本上比对输出（10 种载荷 × 4 个压缩级别）。

一个实现自己和自己一致，说明不了什么。两个独立实现一致，才算证据。

一个被窄样本骗过的断言

tests/test_zehn.py 打印出来的实测结果：

桩大小	容器数
0x1EC (492)	53
0	17
632	11
480	8
616	6
604	5

17 个容器完全没有桩——容器就在文件偏移 0。

我最初写了一条「所有程序共用一个桩」的断言，在 14 个 samples-tns 上全部通过，在全语料上直接失败。

这正是把断言写在窄样本上会骗人的例子：样本越小，错误越自信。

兼容性判定：一个被推翻的直觉

compat.py 拿程序自己声明的能力和具体机器对判。

这台机器的约束很紧：classic 非 CX、320×240 黑白、Touchpad、Ndless r2016、64MB。

原本的直觉解释是：「SDK 是 r2022、设备是 r2016，所以自写的程序被拒载重启」。

但实测结论是：这 100 个程序里，没有一个声明 Ndless 版本窗口（NDLESS_VERSION_MIN / REVISION_MIN 全缺）。

也就是说 版本不匹配不会导致装载被拒。

那条"合理"的解释，直接被数据否掉了。真正的原因得往别处找——ut_read_os_version_index() 的地址哈希、sc_addrs_ptr 查表、或者 classic 上看门狗没关。

这是这个项目最值钱的一条：一个解释听起来越合理，越要拿数据去撞它。

还能往哪走

容器写入器：现在只会重建已有容器。接上 ELF 解析就能把任意 ARM ELF 打包成合法 .tns——包括 genzehn 那部分（扫 .rel.text、发 ADD_BASE/ADD_BASE_GOT、处理 GOT 回滚）
OS 镜像：boot1.img.tns / boot2.img.tns / diags.img.tns 不是 Zehn 容器，是 TI 的 OS/引导镜像，格式完全不同
syscall 面：把容器里的重定位和 syscall-list.h 的 ID 表关联，就能静态列出每个程序用到的 syscall，再和 r2016 的表做差集——那才是"为什么重启"的正确问法

看 100 个程序的容器报告 →

技术细节

文件	作用
`zehnscope/core.py`	容器解析 + 逐字节重建
`zehnscope/inflate.py`	手写 DEFLATE/zlib 解码器
`zehnscope/__main__.py`	CLI：inspect / `--rebuild`
`compat.py`	能力 vs 机型判定（含"能力≠要求"的说明）
`tests/test_zehn.py`	18 项断言

逆向工程真正的方法论，不是"猜对格式"。

是找到一种只有完全理解它才能通过的检验，然后不断撞上去。

逐字节重建就是这样一种检验。