直接原因是我看到了今年 PSP Homebrew Developer Conference 上 Precise Museum 做的报告，其中提到他们刚刚发布的《噗哟噗哟20周年纪念版》PSP版本的英化补丁在制作过程中遇到的一个问题：如果一个字库文件中的非全宽字符（即宽度不等于文件头中描述的最大宽度的字符）出现在字库的第一行以外的行，就会使这个字符无法正常显示。他们后来通过缩小字体的大小、重新排列字符使非全宽字符全都出现在第一行绕开了这个问题。

他们提到这件事引起了我的兴趣，因为我在 5 年前开始研究这个游戏的 Wii 版本的汉化的时候就遇到过这个问题，不过中文字符都是方形，简单重排一下字库文件，把少数的非方形字符放到前面很容易解决这个问题。不过后来噗哟群没找到人翻译，汉化版的工作就搁置了。

我电脑上正好已经装了 Ghidra 以及用于解析 Wii 可执行文件格式的插件，于是决定试试找出这个问题的根源。我之前的逆向经验仅有两个毫无难度的 Unity 游戏（一点混淆没有，符号表全在游戏里），因此这次稍微攒点逆向经验（真能攒到吗）。

背景：关于文件格式

这里需要先介绍一下这个游戏使用的字库和文本的文件格式。英文社区已经有人写了用于编辑这个游戏的大部分文件的工具（Puyo tools 和 Puyo text editor），从这些工具的源码中可以了解到文件格式的信息。下面我借用上文提到的报告视频中的示意图来介绍。

上图展示的是字库文件，即 FNT 文件的格式。文件头中给出了字库中所含字符的尺寸和个数，随后以列表的形式给出了每个字符的 UTF-16 编码和显示宽度。字符表后面直接接一个材质（贴图）文件（PSP版中为 GIM， Wii版中为 GVR）。值得注意的是，虽然字符表中规定了每个字符的宽度，但是这个宽度只用于显示字符串时确定下一个字的水平位置。在材质文件中，字符仍然以文件头中的尺寸整齐地排列。

每个 FNT 文件会配套一个 MTX 文件，里面存储游戏中用到的各种字符串。每个字符占 2 个字节，表示这个字符在 FNT 文件中的 index 。比如在图中的字库中，い的编码就是0000。

正文

准备工作

为了能解析 Wii 的可执行文件格式（dol），需要给 Ghidra 安装相应的插件。插件可以在此处下载。随后将游戏镜像中的可执行文件 main.dol 提取出来（Dolphin 模拟器就可以），加载进 Ghidra 里就可以开始分析了。

定位相关逻辑

可执行文件里显然没有任何符号表和调试信息。想要直接找到处理 FNT 文件的函数就像是大海捞针。十分幸运地是，通过在程序中搜索FNT字符串，我发现了可执行文件中“嵌入”了一对FNT文件和MTX文件，用于在游戏刚启动时显示创建存档等提示信息和错误信息。

直接跟随这里的XREF可以见到这样的函数（函数名是我改的）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

undefined4 * load_embed_text(undefined4 *param_1)
{
  uint size;
  uint size_00;
  undefined *puVar1;
  
  *param_1 = 0;
  param_1[4] = 0;
  param_1[5] = 0;
  param_1[6] = 0;
  param_1[7] = 0;
  param_1[8] = 0;
  param_1[9] = 3;
  param_1[10] = 0;
  param_1[0xb] = 0;
  param_1[0xc] = 0;
  param_1[0xd] = 0xffffffff;
  *(undefined2 *)(param_1 + 0xe) = 0;
  puVar1 = malloc_simple(0x8c);
  if (puVar1 != (undefined *)0x0) {
    FUN_800305e4(puVar1,0,1);
  }
  size_00 = x402c8;
  *param_1 = puVar1;
  puVar1 = malloc(size_00,0x20,0x20,0);
  size = DAT_803606ec;
  param_1[4] = puVar1;
  puVar1 = malloc(size,0x20,0x20,0);
  param_1[5] = puVar1;
  memmove((undefined8 *)param_1[4],(undefined8 *)ptr2fnt,size_00);
  memmove((undefined8 *)param_1[5],(undefined8 *)ptr2mtx,size);
  puVar1 = malloc_simple(0x34);
  if (puVar1 != (undefined *)0x0) {
    FUN_800315d8(puVar1,(undefined *)*param_1,(undefined *)param_1[4],size_00,1);
  }
  FUN_800308e4(*param_1,puVar1,0);
  puVar1 = malloc_simple(0x28);
  if (puVar1 != (undefined *)0x0) {
    FUN_80031abc(puVar1,*param_1,param_1[5],size);
  }
  FUN_80030a54(*param_1,puVar1);
  FUN_80030a5c(*param_1,0);
  memset_((int)(param_1 + 1),0,0xc);
  puVar1 = malloc_simple(0x50);
  if (puVar1 != (undefined *)0x0) {
    FUN_8001d3ac(puVar1,*param_1,DAT_802a2810);
  }
  param_1[1] = puVar1;
  *(undefined4 *)(puVar1 + 0x18) = 0;
  *(undefined4 *)(puVar1 + 0x1c) = 0;
  *(undefined *)(param_1[1] + 0x11) = 3;
  *(byte *)(param_1[1] + 0x10) = *(byte *)(param_1[1] + 0x10) | 1;
  FUN_8002f8cc(param_1,param_1[7]);
  return param_1;
}

注：这里的malloc memmove memset等函数并不是原来就叫这些名字，而是根据函数体内容和用法作出的推测（意外的是 LLM 能轻松地识别出这些经过优化过后的函数的功能）

这里注意到程序在把 FNT 文件复制到新分配的内存里之后对其调用了 FUN_800315d8：

1
2
3
4
5
6
7
8
9
10
11
12

int FUN_800315d8(undefined *param_1,undefined *param_2,undefined *param_3,uint size,int param_5)
{
  list_push_front((ListNode *)param_1,param_2);
  *(undefined **)(param_1 + 8) = &DAT_801a2944;
  *(undefined4 *)(param_1 + 0x20) = 0;
  *(undefined4 *)(param_1 + 0x24) = 0;
  *(undefined4 *)(param_1 + 0x28) = 0;
  *(undefined **)(param_1 + 0x2c) = param_2;
  param_1[0x30] = 0;
  parse_fnt((uint *)param_1,(uint *)param_3,size,param_5);
  return (int)param_1;
}

这里面调用的 parse_fnt 是实际用于解析FNT文件的函数，内容相当长，下面贴出一部分：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

void parse_fnt(uint *param_1,uint *fnt_base,int param_3,int param_4)
{
  ...
  param_1[4] = (uint)fnt_base;
  if (fnt_base == (uint *)0x0) {
    param_1[5] = 0;
    param_1[6] = 0;
    param_1[7] = 0;
    return;
  }
  uVar11 = fnt_base[1];
  fnt_base[1] = uVar11 << 0x18 | (uVar11 & 0xff00) << 8 | uVar11 >> 0x18 | uVar11 >> 8 & 0xff00;
  uVar11 = *(uint *)(param_1[4] + 8);
  *(uint *)(param_1[4] + 8) =
       uVar11 << 0x18 | (uVar11 & 0xff00) << 8 | uVar11 >> 0x18 | uVar11 >> 8 & 0xff00;
  uVar11 = *(uint *)(param_1[4] + 0xc);
  *(uint *)(param_1[4] + 0xc) =
       uVar11 << 0x18 | (uVar11 & 0xff00) << 8 | uVar11 >> 0x18 | uVar11 >> 8 & 0xff00;
  param_1[5] = 0;
  uVar11 = param_1[4] + 0x10;
  param_1[6] = uVar11;
  param_1[7] = 4;
  param_1[8] = uVar11 + *(int *)(param_1[4] + 0xc) * 4;
  for (uVar11 = 0; uVar11 < *(uint *)(param_1[4] + 0xc); uVar11 = uVar11 + 1) {
    puVar10 = (ushort *)(param_1[6] + param_1[7] * uVar11);
    uVar2 = *(ushort *)(param_1[6] + param_1[7] * uVar11);
    *puVar10 = uVar2 >> 8 | uVar2 << 8;
    puVar10[1] = puVar10[1] >> 8 | puVar10[1] << 8;
  }
  ...

注意到这里只是将 FNT 文件中的各个字段从小端序转换到 PowerPC 架构使用的大端序。另外，这个 parse_fnt 函数被两个不同的函数调用，说明加载游戏中其他字库时大概率也会调用这个函数。

考虑到可执行文件中嵌入的那段文本只有在新存档才会显示一次，对调试来说并不方便，我想要换成使用游戏主菜单对应的文本文件进行调试。因此我在 Dolphin 模拟器中对 parse_fnt 函数打断点，跳过了加载嵌入文本的断点，在进入主菜单瞬间成功触发断点。

触发断点之后就可以获得加载进来的 FNT 文件的内存位置。

parse_fnt 函数中似乎并没有切分图片中的字符的逻辑，因此我对 FNT 文件中的字符表打内存断点，看游戏什么时候会读取它们。

果然，几帧之后触发了内存断点，并且屏幕上播放文字时每出现一个字就会调用一次这个函数（在反编译结果上有一些小修改）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

void FUN_80030318(int *param_1,undefined2 param_2,uint charindex,undefined4 param_4,
                 undefined4 param_5,undefined4 param_6,undefined4 param_7)
{
  uint uVar1;
  int iVar2;
  int *piVar3;
  undefined2 *puVar4;
  uint charcnt_perline;
  int *iVar7;
  undefined4 local_38;
  undefined4 local_34;
  
  iVar7 = (int *)((int *)param_1[2])[4];
  iVar2 = FUN_80031784((int *)param_1[2],charindex);
  piVar3 = (int *)FUN_8001b238(param_5);
  (**(code **)(*piVar3 + 0x10))
            (piVar3,4,*(undefined4 *)(param_1[2] + 0x28),3,iVar7[2] & 0xffff,iVar7[1] & 0xffff);
  uVar1 = countLeadingZeros((uint)*(byte *)((int)param_1 + 0x12));
  (**(code **)(*piVar3 + 0x1c))(piVar3,param_4,uVar1 >> 5);
  piVar3 = (int *)FUN_80024ba8(param_1[1],piVar3);
  local_38 = param_6;
  local_34 = param_7;
  (**(code **)(piVar3[2] + 0x18))(piVar3,&local_38);
  *(undefined *)((int)piVar3 + 0x11) = *(undefined *)(param_1 + 4);
  charcnt_perline = 0x200 / (*(ushort *)(iVar2 + 2) + 1);   //!!!!!
  FUN_80028c68(piVar3,(iVar7[2] + 1) * (charindex - (charindex / charcnt_perline) * charcnt_perline)
                      * 0x1000,(iVar7[1] + 2) * (charindex / charcnt_perline) * 0x1000);
  puVar4 = (undefined2 *)malloc_simple(0xc);
  puVar4[1] = *(undefined2 *)(iVar2 + 2);
  *puVar4 = param_2;
  *(int *)(puVar4 + 4) = param_1[3];
  *(int **)(puVar4 + 2) = piVar3;
  param_1[3] = (int)puVar4;
  return;
}

通过查看寄存器和内存可以得知，iVar7指向的正是 FNT 文件的内容，在接近结尾的地方有一个非常可疑的 charcnt_perline = 0x200 / (*(ushort *)(iVar2 + 2) + 1) ，而正是这一行触发了内存断点，读取了某个字符的宽度值，用于计算字库中每行字符的数量。

通过多次触发断点，我发现了这个函数的第三个参数就是将要显示的字符在字库里的序号，将其命名为 charindex。iVar7[1] 和 iVar7[2] 分别是 FNT 文件中定义的单元格高度和宽度。可以发现，在触发断点的代码下一行，程序计算了将要从字库的哪个位置切出字符的显示图形，其中 (iVar7[2] + 1) * (charindex - (charindex / charcnt_perline) * charcnt_perline) 是水平位置，(iVar7[1] + 2) * (charindex / charcnt_perline) * 0x1000) 是垂直位置。

那么问题的原因就很明显了：由于程序员的疏忽，在计算每行字符数量的时候使用了每个字符的宽度，而不是实际上的文件头中规定的宽度，算出的每行字符数是错的，导致后面计算字符位置也算错了。第一行的非全宽字符逃过一劫，因为这些字符的 (charindex / charcnt_perline) 一定为0。

解决问题

找到问题的根源之后解决起来就简单了，只需要将 charcnt_perline = 0x200 / (*(ushort *)(iVar2 + 2) + 1) 改成 charcnt_perline = 0x200 / (iVar7[2] + 1) 即可。具体地，仅需将 0x800303f8 处的一条指令修改为 80 9a 00 08 即可修复此问题。手动用十六进制编辑器找到对应指令然后直接改就行了。

我制作了测试用的文本和字库（下图1），导入到游戏里，启动游戏以验证问题的解决（下图2）。

可以看到能正常显示第二行的英文字母了。有些字母下面被切了是因为我写的用来生成字库用的脚本对字符尺寸的处理有点问题。

总结 & 闲话

虽然我最后解决了 Wii 版上的这个问题，但是好像价值也不是很大，因为英文版那边已经有 workaround 了，汉化版这边甚至不用 workaround 虽然缺翻译导致汉化版可能会无限拖下去，这个问题属于是小问题。另外 PSP 版因为没有在可执行文件里嵌入字库，所以定位问题可能会更难，不过有 Wii 版的经验，应该能想办法找到类似结构的函数（？）

这应该是我第一次尝试逆向这种陌生架构的程序，意外地还挺顺利的。不过要是遇到混淆过的程序那可能就两眼一黑了。

UPDATE 2025.08.30 实际上运用 Wii 版的经验稍微找一下就能找到 PSP 版本的有问题的函数在0x000910a4。

事情的起因是我某天在刷 Fediverse 的时候看到了我所在的实例上有人发了这么一条帖子（现在找不到了，内容大概是）：

Meshtastic is modern Pictochat

这里提到的 Pictochat 指的是老任在 NDS 掌机上推出的聊天功能，可以与附近的掌机进行无线连接，并通过触摸屏画画来聊天。我恰好有一台 3DS ，它有一个类似的功能叫 Streetpass ，能在休眠状态下和附近的掌机联机，我觉得这个功能还挺酷的。因此我当时对这个 Meshtastic 起了点兴趣，简单了解了一下之后发现是一个开源的离网无线电通讯工具。不过我很快就忘记了这件事。

后来我在油管上又看到了 38C3 上有两个 talk 都介绍了 Meshtastic （这个和这个），其中提到节点的成本相当便宜（DIY成本在5-7刀，我在国内买零件应该会比他更便宜），于是就想试试。

正好 lyc8503 也感兴趣，就决定在学校尝试一下 Meshtastic 。他已经写了一篇博客介绍总体的探索过程，我在这里仅做一些我自己的补充和想法。建议先去看他的博客再看我的。

硬件选择与成本

我当时看完 talk 就去搜了一下 Meshtastic 支持的各种成品硬件（开发板），结果成品硬件的价格都在 100 元以上，远超我的预期。这下不得不自己组装了。

一开始使用的 ESP32 + SX1278（Ra-01） 组合的成本也达到了 40 元，这还没算上天线，也没有带屏幕。虽然有更便宜的 ESP32C3 ，但是我们把固件刷进去之后无法启动，而且没有任何信息输出，抓瞎了一会儿就放弃了。后来尝试的 nRF52840 + SX1268（E22-400MM22S） 的组合相对便宜，算上小天线也只有 20 元出头，但是射频模块其实是以拿样价 6 元购买的，如果原价购买则需要 20 元，算下来总成本也要将近 40 元。而且需要手动焊接。

另外，我还购买了 U-blox NEO-6M GPS 模块，成本为 11 元，可以为节点提供位置信息，虽然精度不高。

我的目标是尽可能压低成本，这样看下来 20 元每个节点应该已经是极限了。 不过Meshtastic群的群友似乎不太在意成本， 100 多的成品也买得很开心

更多距离测试

我的另一个目标就是想看看自制节点的极限传输距离。根据 Meshtastic 网站显示，目前地面上的距离纪录高达 331km ，国内的 Meshtastic 社群也有群友达到 10km 以上的传输距离。而在南京进行的几次实验都因为周围有很多建筑物遮挡而无法达到很远的距离（不到1km）。因此我去了乡下的一些地方尝试更远的距离。相对空旷的地形和较弱的噪声干扰应该能让传输距离有所提升。

V2 硬件的距离测试

使用硬件: nRF52840 + SX1268(焊接在小板) + 转接线连接的胶棒天线（即 lyc8503 文中的 硬件 Version 2）

将一个节点放置在四楼阳台上之后拿着另一个节点沿着门口的直路走。最远能达到大约 800m 的距离，再远就收不到消息了。地图上的位置和最远位置的信噪比如下。

从地图上看连线几乎没有建筑物遮挡（蹭着厂房的一角过去了，可能就是因为这个原因不能继续往外走），可惜还是没满 1km 。可能这个手搓的天线转接线的质量还是太幽默了。

V3 硬件的距离测试

使用硬件: nRF52840 + SX1268 + 转接板 + 胶棒天线 + (可选的) GPS 模块（即 lyc8503 文中的 硬件 Version 3）

升级了硬件之后，我去了另一个乡下地方进行测试。一个节点放置在3楼窗口，另一个节点四处移动。这个地方没有很长的直路，只能尽可能找空旷的方向走。但是我仍然没能找到理想的、完全没有建筑遮挡的长线段，最终在有少量房屋遮挡的线上测到了 1km 的距离。地图上的位置和信号测量记录如下。注意到箭头所指位置有少量房屋遮挡，但仍然能成功传输。这次实验的时候在移动的节点上尝试交换了长天线(24cm)和短天线(11cm)，但似乎两根天线的传输距离和信号质量并无明显区别。

V3 硬件的距离测试，第二次

去乡下还是没能找到足够平坦的地方，于是我决定再来一次测试，这次利用山的高度来绕过城市中的各种建筑物障碍。

使用硬件同上一次（只使用了短天线），把一个节点贴在家里的4楼阳台窗户上，拿着另一个节点去爬山。虽然一路上没有信号，但是到达山顶的一个建筑物之后成功收到了信号，此处距离我家 2.6km ，海拔比我家高 200m 左右 在这里放地图的话就把我家盒了，还是算了。

^山顶的节点。此处到我家的肉眼视线被树挡住了，但是电波能轻松穿过。

^四次 traceroute 的信号指标。甚至有一次是良好，应该还没到极限。

^连续多条消息被成功接收、发出的消息被成功 ACK 。

总结

上山测完这一次之后，总算是达到了我对这玩意传输距离的预期值。不过这应该还没达到极限。也许之后还可以进一步测试，但我不会分身术，不能同时移动两个节点，也不太能在山上放置节点之后再下来到处移动（毕竟公共场所）。上一次山只能获得 1 bit 的信息。之后有空再说吧。果然高度才是王道。

从 lyc8503 五月发的博客到现在也拖了快 3 个月了。这个 project 终于结束了。稍微感受了一下在现实中做嵌入式开发的感觉。我个人感觉能用上 Meshtastic 的场景还是不太多，现在能想到的只有：去偏远没手机信号的地方旅游，以及在空旷地区使用物联网设备（比如范围较大的农田）成本上应该比使用 4G 要低一点。在城市这种环境组网只是看起来有点酷（？），并且基础设施由自己控制而已。

本文章含有较多拍屏图片，因为 Live CD 不方便把截图传出来，请读者忍一下（。

前年的时候我把我家的一台旧电脑升级了下硬件改造成了服务器，持续运行至今没出过什么大问题，直到前两天——

红温的开始

我像往常一样连着 ssh 操作服务器，然后命令行突然没反应了，随后执行什么命令都报 输入/输出错误

再过一会儿， ssh 连接也没反应了，我前去查看服务器情况，插上显示器发现没有显示输出，电源也没有断，但是键盘完全无反应，只能硬重启。重启之后发现 BIOS 识别不到系统盘了。我想着可能是接触不良就把硬盘换了个 SATA 接口，启动之后识别到了系统盘并且正常启动了系统，但是没过多久就开始报满屏的 I/O Error 。

大事不妙。这块 SSD 很可能已经坏了。糟糕的是我没有对系统盘做任何备份，虽然上面没有什么重要数据，但是重装系统以及重新配置各种服务还是很烦的。

硬重启之后 BIOS 又识别不到硬盘了，必须断电一段时间才能重新识别到。我启动到 Live CD 试图把盘里的数据 dd 出来，结果读到 4GB 就读不出来了：

重启之后跳过这一块继续试图 dd ，但是在 8GB 多的地方又失败了，看来坏了不止一个地方。

至少分区表和超级块还在，不过这时候已经晚上11点了，如果继续的话我不知道要干到什么时候，就先睡了 （结果没睡好）

恢复数据

第二天起来查到了一个 ddrescue 工具，可以自动从坏掉的硬盘里读出尽量多的数据。于是就插上 Live CD 开干了。 ddrescue 运行的时候遇到 I/O Error 会等内核重置 SATA 链接之后跳过去继续读。花了约 1.5h 完成 Pass 1 之后已经成功读取了 240GB 中 239.897GB 的数据，看来还坏得不严重。

继续运行几个小时之后已经只剩 5MB 没有读出来了。我挂载上恢复出来的镜像先 fsck 了一遍，发现没有找到问题，看来文件系统是完好的，损坏的只有文件数据。ddrescue 还会输出一个 map 文件，里面有每一段读取成功/失败的范围，应该可以通过这个范围去寻找被破坏的数据属于哪个文件。

于是找到了superuser上的这个问答，发现可以使用 debugfs 命令来寻找被影响的文件，于是写了个脚本找出了所有损坏的文件。

万幸的是损坏的少量文件都是不重要的文件，只需要重新安装一下软件包就能恢复。

复活!

接下来就简单了，我正好有张几乎是空的 HDD ，直接划个分区出来，把恢复出来的镜像 dd 回去，重新安装 grub ，然后修一下受损的文件就好了。虽然在 HDD 上的系统可能会慢一点，但是我几乎不跑什么 IO 密集型负载，就先凑合着用了。

后记

血的教训：备份很重要，所有丢失了就很烦的数据都应该备份。虽然这次运气好能完全恢复数据，但是下次可不一定。此外这块 致态 SC001 Active SSD竟然用了一年多就坏了， SMART 信息显示写入才 15TB ，看来长江存储也不太能信（?）

从高中开始想搞的博客，咕了5年终于想起来做了。如你所见这是一个 retro 风格的主题，虽然只是表面上 retro ，但是我之后应该会做一个纯html，没有任何js和css的分站。

现在还没想好这里要写什么，想到了再说。首先排除课程笔记。

此帖也用作本站的 Changelog.