posted @ 2011-06-18 12:48 CrHackOS 阅读(3019) | 评论 (11)编辑 收藏

  多年前写的日志,其中的思路可能对汉化或者其他一些工作有借鉴作用,在这里再贴一遍。
  有时候我们要修改/替换某些脚本系统里面的字符串,而这些字符串与指令都是以穿插的形式存放在脚本编译后生成的二进制文件的内部。如果修改的长度小于等于原来的长度,那就可以直接在上面修改了,不足的用空白字符什么的补完就行了。但是碰到超出原来长度的就没那么简单了,因为那些二进制指令代码里面可能存在各式各样的跳转指令,一旦改动了文件长度就会导致运行异常。
  当然,你可以通过分析 exe 来搞懂那些指令的意思,至少要把所有与位置有关的指令格式搞出来。那需要不停的调试,得到所有与位置相关的指令格式后,写一个 HEX2TXT 的程序,然后再写一个 TXT2HEX 的程序。这些程序很难有通用性,而且调试也要花一定的时间和精力,毕竟东西是人家的,人家想怎么改就怎么改,研究这个也没有什么太大的意义。
  很容易想到的就是用外挂的文本库实现运行时的替换,当然我这里说的不是那种根据原始字符串来匹配查找新字符串的替换(因为某人说了,在不同的环境下,相同的语句可以有不同的意思,所以存在一对多的情况)。因为无法把超出原来长度的字符串放进去,所以我们得改变一下思路,把其他东西放进去。
  很简单,把数字放进去就可以了,因为 4 个字节的整数可以表示 4G 的范围的数,所以那样的东西放进去一定可以满足空间长度的需要。而这些数字表示的就是外部文本库里对应文本的编号索引。好了,现在我们需要一个导出原始文本和偏移的工具和一个把翻译文本的索引号写回去的工具就可以了。由于都是简单的操作,所以这些工具将有很大的可能是通用的。
  接下来就在 exe 上做文章了,根据具体系统的不同,有不同的改法。大致上就是在他读取完字符串的后面再加上我们的根据索引来替换文本的程序段了。这个比调试一整个 VM 要简单的多了。

posted @ 2011-06-14 16:52 CrHackOS 阅读(241) | 评论 (0)编辑 收藏

  多年前写的日志,其中的思路可能对汉化或者其他一些工作有借鉴作用,在这里再贴一遍。
  如果包文件或图片里用了他们自己设计的压缩算法,想要回过去,但又不想分析他的程序,除了利用他算法里的一些简单的编码方式做伪压缩外,还可以使用替换压缩算法的方法。
  一般来说,那些自己设计的压缩算法都是弱压缩(字典不大或考虑性能因素),我们可以使用一些现成的压缩算法来替换,只要保证压缩后的大小比他原来的大小小即可。这样做有一个好处就是不需要重新生成包文件了,只要在原来的文件位置上覆盖即可,不需要修改其他文件的偏移。
  当然不是全部换成我们的算法了。只要在我们想要修改的文件数据块前加一个标志,然后 hook 了他的解码入口处,check 一下标志来决定使用那种解码即可,方便有效。至于压缩算法嘛可以使用 zlib,外挂一个 dll,也可以使用日本佬写的那几个 LZHUF/LZARI,都是相对的 call,可以直接植入 exe,虽然滑窗小了点效果还是不错的,压 3M 的高度图(24 位的灰度 BMP 文件)比 zlib 大了几十 K 而已。顺便补充一下,aPLib 也是很好的选择,只是小得有点让人受不了。

posted @ 2011-06-14 16:41 CrHackOS 阅读(196) | 评论 (0)编辑 收藏

仅列出标题
共2页: 1 2