1、hcb文件结构
a) 开始4个字节，指示entry的地址在文件中的偏移，相当于一个二级指针。

b) 从开始4个字节之后到entry之前，存储游戏的指令, 此外游戏的文本也包含在指令里面，个人感觉像代码段和数据段的混合，后面称为执行段。fvp本身相当于一个虚拟机，有自己的指令集，每条指令的作用前人已经整理出来了，见下图。结构体里的三项分别表示单字节的指令码，指令和操作数的类型, 除了string和字符串的长度相关，以外其他所有指令都是固定的长度。

c) entry, 指示虚拟机的入口地址。在上面的执行段里面，指令并不是单独的，而是多条指令拼在一起来实现一个功能，也就是函数，在这里entry指示的应该是主函数的起始地址。

d) entry后6个字节，不清楚干嘛的，总之封包的时候保持就行，这里称为魔术字

e) 在魔术字之后，对应标题，第一个字节为标题的字符串的字节长度，后续为内容，以00结尾

f) 最后是fvp系统的函数，比如音频相关和天气特效之类的，在代码段通过指令码0x3+占用两个字节的序号直接调用。这里最开头的两个字节表示fvp系统函数的数量(选中部分前的94 00)，然后就是这0x94个函数，每个函数的第一个字节没搞明白，第二个字节是函数名的长度，剩下的就是函数名了。这部分也可以原封不动封回去。

2、hcb解包与封包
上面有提到，游戏的文本都在执行段里面，而执行段的指令都是连续的，因此可以按顺序去解析，从而得到每一条指令，当然也可以拿到所有的文本，那就达到了解包的目的了，接下来就是替换文本和重新封包了。
按解包的思路，可以按文本指令把执行段拆分开，可以简单表示成“（其他指令 * ki + 文本指令 * 1) * n + 其他指令 * m”的形式。修改文本如果导致了文本长度的变化，那么之后的所有指令的地址都会受到影响，
在上面的划分中，同一括号内指令的地址受到的影响是一样的，最后的文本指令长度变化只会影响后续的括号，可以通过迭代得到后续指令的新地址，从而把文本以外的指令都完全还原。
但是，有些指令是会涉及地址的，对于这些指令，后面跟的操作数也需要修改，包括0x2的call(内部函数调用)，0x6的jmp(无条件跳转)，0x7的jmpcond(条件跳转)和0x0C的32位整数压栈。call、jmp、jmpcond后面跟的一定是某条指令的地址，而0xc仅在它的下一个指令为0x3(syscall)，并且对应的函数名为ThreadStart的时候，对应的操作数才是指令的地址。
上面的解包思路是只适用于原版的hcb，汉化组版本有些文本和指令的顺序和原版对不上。但是，最终的效果是一样的，这里可以找几个地方的指令对比分析下，搞懂的话就能把汉化组版本的文本提出来了。

3、字体
封包之后按主楼贴吧老哥的教程改了exe，打开之后发现改不了字体，用fvploader自带的字体功能的话倒是有字体了，不过选不了我习惯用的，所以ida看了一下Font相关函数的引用

10行的字符集用的是0xa2，这里应该改成0x86，需要改汇编，用ida的话会比较方便，当然直接hook也行。
不会用这类工具的话可以随便找个16进制编辑器打开exe，搜索8A 4C 24 58，改成B1 86 90 90

然后是第一张图里面EnumFontFamiliesExA的回调函数Proc，可以看到7行有个神秘乱码，转了码发现是那三个字是日本语，这样和从中文操作系统获取出来的结果比起来肯定是不匹配的，同样需要改汇编把strcmp的前面的否定去掉。
可以用16进制编辑器搜05 9C 00 00 00 8A 10 3A 11 75, 把最后的75改成74就行

4、立绘加载崩溃
这个问题fvploader可以完美解决，不过我挺好奇的就看了下原因

这里是用立绘的名字去二分查找，二分查找是需要有序的，问题出在lstrcmpiA上。这个函数会根据区域去判断字符串的大小关系，立绘文件里的字符串是在日文环境下排好序的，但是在中文环境下不应该是同样的顺序，所以找不到文件报错崩溃。这里最直接的办法是把这个函数hook了，或者自己在exe里面增加一个按日文环境比较字符串的函数，然后这边改下汇编call过去就行。

链接：https://pan.baidu.com/s/1dLb8sKM-0tNOUMtxoTa5Fg?pwd=rrii
提取码：rrii
这是我提原文本和重封包的脚本，需要安装python3
提取文本
python extract_text.py hcb文件名
封包
python repack.py hcb文件名 文本文件名

施工完毕，摸了

sdl，tql，不过实际上星空hd已经有其他大佬汉化过了

看见代码就头疼

那么有兴趣把鸟鸟hd也移植了吗，欢迎入群加入f社大家庭