前言：在翻译好的文章《想当个破解者？》的前言里，我提到过自己有做一个实操的计划，不过如果只是重复作者的过程，实在没什么意义。然后我忽然想到，为什么不能找别的游戏资源，重复这个过程呢？于是我试着拿十六进制编辑器看了看《ウィズ アニバーサリィー》（下称Wiz）的游戏资源，发现确实有些意思，所以拿出来当个实例参考。虽然实际要解包的话我们可以直接用GARbro或者crass，这些工具操作起来方便省事，效果还不错。不过呢，若是要积累经验，实际上手操作效果肯定会更好的。

在展示具体的操作过程之前，不妨先介绍一下Wiz吧。它是FAVORITE社（下称F社）的第二部作品，全名如标题处所示。之所以选择这个游戏，其实只是 我随便找了一个(划) 和它的文件有一定关系。Wiz是比较早期的作品，图片分辨率并不那么高，于是相关封包的大小也不算大，更主要的原因，请看下图。
除了可执行文件（.exe文件）和相当于说明书的文本文档文件（.txt文件之外），游戏资源主要储存在.bin文件中。此处还有一个.hcb文件，事实上这是F社的游戏引擎Favorite View Point（下称fvp）使用的脚本文件，游戏的脚本就在其中。不过具体的分析之后再说。
此外，我们留意到游戏的OP是直接放在文件夹里的，所以我们多少也可以猜到fvp在读取游戏资源文件时，并不强求资源被封装在.bin文件中，这一点当公理来用，无需证明。

第一部分：直接提取：
我们先动一动哪个文件好呢？注意到有一个只有12M大小的graph2.bin，拿来当个试验品应该不至于太麻烦。那么拖进十六进制编辑器（这里我使用的是wxMEdit）看看：【图一】
由于我们以GBK编码查看内容，右侧会出现一些无意义的汉字字符。稍微瞥一眼，可以看到一些很像是文件名的东西：
ali_h04c ali_h04d ... rol_e08f
最后一个文件名后方有“hzc1”会是文件名，还是文件头呢？我们可以稍微做一次思想验证：如果是文件名，则理论上只会出现一次，若为文件头，则理论上出现次数等于文件数。按下Ctrl+F调出查找界面，输入hzc1，看看出现了几次：【图二】
出现次数为6，那么它不是文件名，而应该是文件头。但为什么是六次而不是十次呢？不妨换成十六进制字符串再找一次：【图三】
出现次数10，符合文件名数目，那么它就是文件头。所以，我们大概可以判断从DB开始的部分都是.hzc文件了，至于这个文件具体怎么解决之后再说。接下来再看看文件名前边的字符内容：【图四】
教程里的范例《CROSS†CHANNEL》的归档文件每八个字节为一部分，这里明显不同，否则开头的0A 00 00 00 5B 00 00 00不论怎么解释都不好使。那么大胆猜测此处的.bin文件每四个字节为一部分。注意到0A 00 00 00在视为小端序整数时值为10，正好是存储的文件数目。保险起见打开另一个文件看看什么情况：【图五】【图六】
这里打开了存储bgm的.bin文件。“OggS”很显然是ogg文件的文件头。这说明Wiz的背景音乐的音频使用ogg格式存储，并且完全没有加密或者压缩。此外，可见一共有31个音乐文件，和bgm.bin开头的1F 00 00 00的数值一致。综上，我们可以判断.bin文件的前四个字节确实是在声明存储的文件个数。
（未完待续）

不过别的部分呢？我们还是回到那个只存储了10个文件的.bin文件。文件名之前的全部字节都搬出来四个一组地放好：
0A 00 00 00 5B 00 00 00 00 00 00 00 DB 00 00 00
BC EB 11 00 09 00 00 00 97 EC 11 00 2C 08 13 00
12 00 00 00 C3 F4 24 00 B9 99 11 00 1B 00 00 00
7C 8E 36 00 33 9E 0B 00 25 00 00 00 AF 2C 42 00
75 05 15 00 2E 00 00 00 24 32 57 00 67 DD 14 00
37 00 00 00 8B 0F 6C 00 FC FC 14 00 40 00 00 00
87 0C 81 00 DC 2C 15 00 49 00 00 00 63 39 96 00
3C 06 15 00 52 00 00 00 9F 3F AB 00 AC 23 15 00
回忆一下教程内容：这一部分文件头可能会包含文件签名、索引大小、文件条目列表（文件名，起始位置，文件大小，等等）。第一行第一个确认是文件字数，之后的部分呢？观察发现，到第一行第四个的DB 00 00 00正好是我们第一个hzc文件的偏移（同理，注意到D9 01 00 00 也是第一个ogg文件的偏移）。然后跟着的是0011EC97的位置：【图一】
没错，正是hzc文件的文件头。所以以此类推，从DB 00 00 00开始，每隔两组数字即出现下一个文件的索引。wxMEdit可以显示当前选定的字符的位置，于是我们看看两个hzc文件头间隔了几个字符（这个信息给我们看的，所以当然是十进制数）：
1174679 - 219 = 1174460 = 0x11EBBC
这个是第一个hzc文件的大小，也正好是第五组小端序整数表示的值。以此类推。是不是还剩下一些比较小的数？这些，我们不妨直接说出来，除了5B 00 00 00以外，表示的是文件名相对于“开始写入文件名的位置”的偏移。而0x5B=91 则是∑[文件数]*[文件名+1]，最后的+1是算上了0x00，这个位置是当作间隔符来用的。
那么我们可以总结.bin文件的文件头究竟是怎么构成的了：
1.四个字节的小端序整数，记录包含的文件数目
2.四个字节的小端序整数，记录文件名总长度（包括0x00的间隔符）
3.每个文件占12个字节三个四字节小端序整数，记录了：
3.1文件名相对于开始写入文件名位置的偏移
3.2文件本身相对于归档文件开头的偏移位置
3.3文件大小
4.列出所有文件名，以0x00为分隔
如无意外，我们可以推断“开始写入文件名位置”应当是4+4+12x（假设x为第一个小端序整数也即文件数），而“开始写入文件”则在4+4+12x+y的位置。写入的文件可能被压缩但没有加密，可能有“hzc1”“OggS”“RIFF”这三种文件头（分别对应压缩过的图片文件.hzc文件，未压缩的音频文件.ogg文件，未压缩的音效文件.wav文件）。知道了这些，我们就可以自己写一个解包程序，或者直接让D指导代劳：【图二】
然后运行一下。这里我们用cmd即可：
Win+R，cmd，python 网页链接 输入待解包文件名网页链接 输入输出路径output
已提取：output\网页链接 ……
已提取：output\网页链接 好，提取完成。为验证效果，开游戏试试。一般来说标题界面bgm是02.ogg，总之听一听（读者可以用GARbro解包之后对比效果）。
很好，完全一致，说明我们的解包程序是成功的。换个游戏试试？这次用樱花摸鱼的文件看看行不行。结果是也能行。妙哉妙哉。不过输入两次还是太麻烦了，干脆改一改：
input_file = input("输入待解包文件名：")
output_dir = input_file.replace(".bin","")
这回方便多了。
（未完待续）

原本的教程里说“一个成功工具的金牌标准是能对归档文件进行封解包处理，所得的新归档文件是原文件的完美复制品”，诚然如是，所以我们用同样的道理让D指导写个封包的工具。然后我们可以把这两部分整合一下：【图一】
然后随便运行两次，得到新的graph2.bin文件，可以看到更改日期确实是最新的了。
改名为test.bin，和原本的graph2.bin放一块，开cmd执行“comp graph2.bin test.bin”，结果显示是成功的
完美！至此我们可以放言：我们已经得到了一个有着金牌标准的F社bin文件初级解包工具了。
下一部分我们会着眼于处理hzc文件，试图得到原始的图片文件。欲知后事如何，且听下回分解～

手机排版是真麻烦...有些格式和内容丢了
这篇教程写的很不错。首先，贴吧重在分楼，每楼围绕一个小步骤写，比较合适。而他也确实如此。
第二，选的素材也很不错。文件名——文件偏移——文件内容的结构，对多数gal文件有一定的普适性。
整体步骤流畅，细节也讲的很清楚。