首先感谢YZB大佬给我的邀请码，以及提供了一份研究资料以下是这几天分析的数据游戏的主要文本在MAIN.BIN, OPTION.BIN以及SYSTEM目录下的STATICPRESS.BIN（美版为STATICPRESSUSA.BIN）FONTDATA中有17个PVR文件，内容看起来是所有用到的日文文字，SHIFT-JIS码表。
MAIN.BIN：NPC对话菜单，人物属性界面文字等。其中在0X18023C开始是文字形式的码表，内容与PVR图片索引匹配
OPTINO.BIN：游戏内NPC图鉴的说明文字
STATICPRESS.BIN：加密（压缩？）存放游戏内装备，物品等的说明文字，以及NPC对话等。美版STATICPRESSUSA.BIN在文件尾端有部分未加密文本，内容是装备，物品及技能等的说明
在常规的1ST_READ.BIN中没能找到文本信息，可能是我太菜了。
由于我是初学者，现在遇到的几大问题，还望大佬们帮忙回答：1. CDI能否直接替换里面的文件，还是说只能提取并修改后重新打包？2. 像本游戏这种用PVR存储文字的方式，汉化是不是同时需要修改文本内容，BIN内码表，PVR图片码表3. PVR是可以用PS配合插件的形式修改吗？4. 我尝试过直接用WINHEX修改CDI的文本内容，日文改中文后，不在码表内的会变成绿色方框。美版修改英文为中文后，内容变成空白截断。根据之前的帖子判断，似乎还是用日版汉化容易些？5. 关于STATICPRESS.BIN的解密或解压，如果是WINDOWS程序我还能尝试用OD之类的跟一下解压解密过程，但是DC配合模拟器有相关的反汇编工具吗？
目前有些迷茫和焦虑，不知道下一步先往哪里开始了。。。
更新1：在YZB大佬的指点下，有一些进展，如下图目前完成汉化：进度保存，加载，部分NPC商店菜单，个人属性菜单。怪物的名称和介绍，技能的名称和介绍。物品的名称和属性，以及装备的属性和名称因为在STATICPRESS中加密存放，目前还是束手无策

 

1  cdi 镜像因为文件有edc ecc校检，所以不能直接替换文件，汉化dc游戏的最好方法当然是重构镜像，不管是gdi或者cdi都是如此
找几篇做直读的教程看一下就行了，其实很简单

2 如果按照原游戏的编码方式可以不用修改bin内码表，只需要修改pvr字库图以及文本即可，当然如果原字库数不够，那码表当然也要修改了

3 有ps用的pvr插件，论坛搜索一下就有了

4 当然是日版容易汉化，美版只有26个字母，一个字节的编码就足够了，如果以美版来汉化的话，需要修改汇编程序的地方更多

5 dc模拟器没有调试器，你可以用od或者ce配合nulldc模拟器来调试（先定位那些寄存器以及pc pr值在内存什么位置，然后用od或者ce设置读写中断来定位），当然还需要ghidra或者ida来查看主程序中中断代码的具体流程

这个游戏比较麻烦，主要是STATICPRESS.BIN这个文件加密比较复杂点，我没具体看过，你可以先把那些不是加密的文本翻译完最好才做这个难的

简单看了一下字库索引，当调出菜单的时候字库是按下面的方法寻字的，当然剧情对话也许不走这里......

字库索引表在MAIN的0x180e00处，每4个字节一个索引，其中前2个字节为字符编码，后2个字节为坐标

其中2字节的坐标 又分为 横坐标高4bit 和纵坐标低4bit，以及一个字节的字库页数，代表字库文件名OUTF_VOA1-17

因为字库名是从01开始的，所以一个字节的字库页数的值需要加1

比如某个字符E8D3=勒,  可以在0x182868那里查到D3E8 2710  
其中D3E8是高低字节翻转后的编码，27的高4bit为2，低4bit为7，0x10为字库页面，因为是16进制，转成10进制就是16，然后字库页面是从01开始不是从0开始，所以应该需要加上1，那就是16+1=17
所以可以推算出这个字在OUTF_VOA17.pvr这个文件 的横坐标第0x2行，纵坐标第0x7列

ps：忘记说了，还有7个特殊的编码
8190   
8140    
8197   
81a5   
81a4   
8194     
8147
估计是表示换行 空格  换页 颜色 声音之类的特殊编码

测试版当然可以发出来，这个你随意就好，不过一般人都是等着正式版才玩的，测试版想有反馈信息，除非遇到该游戏的fans差不多

解密问题，得过段时间有空闲了才能认真看看，你可以做完其他的先，不过这个游戏才1k7个字，够用了吗？目前用到第几张字库了？

第一个4字节是加密的索引区，后面开始每8个字节一组，前4字节是文本加密区，后4字节是文本指针区，后面以此类推

字库有点悬啊，剧情还没翻译就剩200个字来了.....

话说这17张字库图是否打出过文本来的？
嫖了一眼，解密的文本也不是明文，还是2字节组合的1字节字库页面索引，1字节的 横纵坐标

这是第一个解密的文件，应该是剧情的文本，不过不是日文编码，是直接用2字节来定位字库的

第一个字节表示字库页面（同样要+1来表示第一个文件），后面字节高4bit为纵坐标，低4bit为横坐标，好像刚好和前面解析的字库索引相反

另外还有一些控制符
FF 00  换行？
FF 01  ？？
FF 02  ？？
FF 03  这个读取以后需要跳过一个字节
FF 04  ？？
............
FF F0  结束

附件这个文件不保证准确性，需要导出文本才能知道是否完全准确

放上第一个文本的2个截图，对应附件文件的第一个文本

会写程序就好办了，我再看看汇编代码，明天发算法给你

首先解密第一组加密的文本，第一个0x9c指针为需要用到的解密表，这个表已从内存dump出来了，应该是通用的，下载附件就可以了

从第一个指针区0x65240开始，读取一个4字节指针，然后该指针加上文本区首地址也就是130，所以第一段加密文本就是从130开始的

在0x130处，从0x6d开始解密，过程如下

0  先初始化一个int 变量r0=0xffffffff

1  初始化一个int   变量r14=0x17D（0x17D为常量值）

2  判断r0的值是否为ffffffff
   是的话读取文本加密区一个字节（0x6d)（这个地址每次递增+1），并且初始化r0=7
   不是的话直接到第3步

3  判断该字节的第r0 bit位是0还是1（其实就是从最高bit到最低bit，一共8次）
   为0，则从(r14*0xc)+4的解密表里面读取一个int到r14（变量）
  
   为1，则从(r14*0xc)+8的解密表里面读取一个int到r14（变量）
  

4  r0--，递减

5  判断r14的值是否大于0xff，如果是，则返回到第2步

6  r14的值小于等于0xff，把r14以字节的显示写入到解密地址

7  判断解密完的最后2个字节是否为fff0，不是的话跳到第1步，是的话结束循环


以上就是一段文本的解密流程，一段文本可能是一句话也可能是N句话

因为原文里面是针对每一段文本单独加密的，所以如果需要汉化的话最好也是对每一段文本做单独处理，这样后期加密导入打包的时候也方便点，10楼那个附件是整合在一起解密的，只能做参考处理

8次以内都需要判断，其实就是读一个字节然后依次从最高位开始判断，判断一次就去解密表里面读取表内的数值r14是否大于100，r14大于100就继续判断下一个bit位，然后用这个r14继续从里面读一个新的r14出来，以此类推，直到r14的值小于100，才是真实的数据，期间如果r0用完则重新在加密区那里再读取一个新的字节，继续从最高bit位继续判断

while (r0 != 0xffffffff) 这个循环错了

并不是r0递减到0的时候就结束一个字节的解密循环，而是当if (r14 <= 0xff)的时候，结束这个字节的解密，直接写入到解密的数组里面，然后重新初始化r14=0x17d，但是这个时候如果r0还没用完的话，还要继续使用加密字节剩下的bit位，直到最后解密的2个字节为ff f0

另外最后2字节你可以直接从解密的数组里面获取也可以的
byteWrite[byteOut-2]          byteWrite[byteOut-1]

搞定就好，解密汇编源码入口在mani的0x99762这个位置

另外根据观察，解密后的文本的头2个字节不是文本，是角色名ID，id表从mani的0x19e564位置开始，每4个字节一组（需要减去偏移量8C1C0000），所以第一个名字实际位置在8c33ad18-8C1C0000=17AD18这个位置

头2字节不需要判断，直接默认跳过也可以，不过导入文本的时候得保留，所以最好导出文本的时候保留这2个字节，反正main里面的文本那里你还是要翻译的


使用ida工具就可以了

cpu选择sh4，不是sh4b，MAIN.BIN的偏移地址选择8c1c0000即可