申 请 I D：ISO639-1（续）

1、申 请 I D：ISO639-1 2、个人邮箱：Kawasaki@T∧∧d.com 3、原创攻略：浅浅浅谈pascal汉化入门（续） 大家嚎！

本文是上篇的恢复和补充总结， 上篇原文地址：https://www.52pojie.cn/thread-1874523-1-1.html，排版有点乱，上篇部分内容跳页了，将就看，
其中上篇部分关于1、2、3阶汉化划分、以及软硬汉化的说明，给排版挤到第2页了，没会员资格的第2页内容看不到，在做个简单描述，图就补不了。这次发成1段
软汉化：挂载ini,chs,lng等汉化包实现的汉化，涉及的工具参见上篇介绍；
硬汉化，汉化直接写道exe中的处理，完成后就1个exe，没有其他文件，涉及的工具参见上篇介绍；软、硬汉化都是可以互化的，具体参见上篇介绍


对于硬汉化，依据可视化汉化、非标汉化及工具寻址范围的不同，人为划分3个阶段。
1.1阶汉化，可视化汉化（低阶底层通用寻址），汉化的对象为通用开发平台的软件厂商，1阶涉及的具体工具参见上篇介绍
2.2阶汉化，可视化标准汉化，借助工具，完成第1阶段没有汉化的部分，寻址范围从第1阶段的上限开始，到2阶段所用工具所支持寻址访问的上限结束，定义为汉化作者的代码、窗体、函数等自定义资源，相对1阶段为高阶寻址汉化，2阶涉及的工具参见上篇介绍
3.3阶汉化，就是非标汉化，基本全在HEX编码处理环境中进行，对可视化无法访问的而留下的全部未汉化的地方做汉化，eg：IMAGE_IMPORT_DESCRIPTOR类的结构要转换寻址方式才能访问，否者无法直接看到，3阶就处理非标汉化，常见手法包括偏移、挪移、直替，寻址算法依据所处理的软件平台使用的内存寄存器指令寻址方式的不同，以Delphi为例，又划分：RVA、EA、..


一般汉化到第3阶段，基本都是对非标资源汉化，好处理的，第1、2阶段都用工具解决了，剩下的“硬骨头”，大都是没法在标准资源工具提供的操作中直接看到的，就是大部分需要Hex寻址，要使用不同寻址手法进一步计算转换对应编码，才能访问，否则，看都不给直接看，改个p。简单说，3阶汉化，也就是Hex偏移寻址、转换编码，实现汉化处理。


3阶汉化，有好多手法，前边的偏移、挪移，直替，只是常见的3个手法，是手法，不是算法，手法可以选择用N多种不同的算法去实现，手法描述比算法(寻址)描述简单多了，1种算法可能只能固定对应适用某个软件开发商所用支持平台某一阶段的编译器解释编译出来的，人厂商后台升级了架构编译器，原先的算法就不好用了，就需要针对新的编译器更新对应的新算法去实现访问解码，不然会发现老的算法直接拿上去会给你惊喜..，手法不需要，不同手法的核心思想可以使用不同软件开发商所提供的各种不同语言编码规范的产品。思路一样，依据页面对齐原理，换个算法（寻址），去实现汉化就可以不换思路手法，手法不依赖厂商的对应的某种具体寻址算法，厂商升级了编译器架构更新了寻址方法，那跟着换个算法就可以，其核心思路还是原来的，不用改手法，更新换算法就可以。


3阶，对应的Delphi常见算法有RVA、EA，结合前文简单讲讲RVA的算法，涉及偏移量，计算偏移量，有多种手法，前文的RVA偏移替换，（ps：Relative Virtual Address，相对虚拟地址，也叫节表。相对于模块基址的地址偏移量。可以理解为内存偏移，指从某个基准位置（ImageBase，PE文件装入内存后的起始地址。具体实现时判断这个地址是否在PE头还是存中于文件的区段中，在PE头，文件偏移和内存偏移相等；存在于文件的区段中，用公式换算。一般汉化的pe资源中是.text头代码）开始的相对地址，或者说在内存中相对于PE文件装入地址的偏移位置。）
具体操作：鼠标悬停修改起始点得到实偏移，通过16位入口实偏移地址用点睛偏移量转换器算出入口地址对应的RVA，对调替换修改后对应的起始入口地址，就完成内存寄存器Hex地址偏移载入的汉化替换。实际汉化说的RVA，指向节区头成员 VirtualAddress 指的是虚拟内存中相应节区的起始地址，它以 RVA 的形式保存在结构体中，RVA偏移操作时就是计算RAW文件偏移（Fill Offset,16进制文件编辑器打开后的地址为文件偏移地址。PE文件存储在磁盘上时，相对于文件头的偏移位置（硬盘偏移）），替换PointerToRawData（节在文件中所处的偏移）是节在文件中的起始入口位置，替换这个地址为汉化修改后的对应入口地址，内存寄存器运行时自动调取载入，实现汉化。


还有随后流行的EA寻址，（ps ：EA，直译有效地址（或者叫逻辑地址）寻址，16位长度，通过偏移基址寻址偏移量变址相对寻址，前四位是段的起始地址 后四位是 在本段内的偏移地址 就是偏移量 ,计算数据存储的实际地址20位的物理地址=16位的段基地址*16（就是相当于左移一位）+偏移地址（16位的偏移量）。公式：EA=基址+（变址*比例因子）+位移量，相对RVA更高级，但网上介绍很少，有啥好处？可以解开RVA无法访问的寻址？访问:IMAGE_IMPORT_DESCRIPTOR类的结构要将RVA地址转化成VA（进程在虚拟地址空间中的的绝对地址,直译虚拟地址，0x00000000~0xFFFFFFFF ，地址范围0000 0000 ～ FFFF FFFF），用VA寻址才能解码，都是用工具(点睛高版提供EA支持，v1.O6版始支持直接EA换算)计算寄存器偏移地址。
RVA和EA的关系：RVA 是当PE 文件被装载到内存中后，某个数据位置相对于文件头的偏移量。将 RVA 的值加上文件被装载的基地址，就可以找到数据在内存中的实际地址或者说EA（有效地址）。EA，Effective Address，有效地址，16位无符号数，即存放在运算数据或运算结果的存储器的位置，实际是相对某个段的段地址的偏移量或“相对地址”，表示操作数所在单元到段首的距离即逻辑地址的偏移地址。


解释一下，RVA偏移是先出现的，对于宝蓝Delphi6-7的指令寄存器HEx寻址计算，后来，O8年左右，Bland推出Delphi 8升级，估计同时后台优化升级了新版的编译器架构，和原来的编译器寻址方式不太一样，放在汉化实践中，RVA偏移就过时了，寻址时不好用，于是就跟着更新出来对应的EA偏移汉化处理算法，去处理Delphi 8指令编译器架构开发的汉化项目，较个真说，RVA、EA偏移在汉化实际实践中都一样，EA没啥高大上，不是比RAV更接近真理的存在，不过是跟随新版本的指令编译器同步寻址方式的对应处理算法，只是比最早的RVA偏移的出现时间晚了一些，估计寻址速度和范围实现跟相对更优化一些，现实中做项目汉化的不用去关心这个，有现成的工具可用就直接用，没有现成的工具，就自己写个算法实现，或者换个处理手法，对于厂商更新指令计算器寻址的改变，影响有，但不大。实践中选择哪种算法，要灵活对待，现实用RVA偏移发现不灵，那就换EA偏移或者其他偏移寻址方法，根据不同的具体情况去选择对应的寻址算法。
先实际操作，RVA、EA偏移都是过程，不是结果，没法直接用，使用时还要手工计算或借助工具2次计算偏移量，需要地址编码转换处理后换算，得出实际对应的入口地址，用于汉化，人开发商每年升级N次开发平台，对应的寻址算法也要同步对应更新，像Delphi8后，推出的Delphi 9、X、XII，...Net（终极形态,巨硬家定的标准）的对应新算法？抱歉，唔知。作者不是Delphi PAscal Coder，不感兴趣也不关心，接手处理的仅为Delphi7的项目，实际实践用到的上限决定就到Delphi7，至于Delphi 8及其后续开发平台的项目都没接触过，自然谈不上有多高的见解，实际中用不上的东西，谁会去研究？至于EA偏移之后的新的寻址算法，反正作者木用到，不知道，也不急。浅谈入门，研究不到那么深层次，因为没有接触到，谈谈最简单的，至于EA算法的实际应用，那个哪位有心得，欢迎匿名跟进，楼下写写。或者说当前最新版的Delphi用的哪些新的寻址算法，有知道的也可以说说，欢迎讨论。


算法说了，浅浅谈手法，3阶Hex处理的手法常见有偏移、挪移，直替后边另行描述。注意偏移、挪移也不算什么标准，就是为了便于描述而人为定义这样写，具体说：
偏移是发现1处需要汉化处理的地方，那就根据页面块对齐原理，找前边或后方相邻的充O的空白处插入要汉化的项目，具体实现可以把Hex编码前提、压缩挤出空间或者干脆找页面空白的地方替换充0的编码为需要汉化的编码，注意对应编码长度不要溢出，然后重新修改入口调用地址就可以完成汉化；
挪移，相对高级一些，就是资源中，发现有好几处调用的都是指向相同的同一段代码，那复用对应处理，资源中多次指向同一段代码段的调用处理就是挪移，具体实现，挪移，去看前文人原作者写的，直接拉到原文的最后几行，很详细；挪移，去看Athena开发者汉化论坛的回复，这前边都有提过。人早先写过了，跟着描述1次，就是那啥。。，再继续写，写出来算不算抄袭都另说，另外，具体相对应说明的图也就不上了，大家靠想象自行脑补，想象不出来和作者无关，有条件的去找 C SHARP（.NET C#  Coder中的1支，别找错了）或者汇编C的程序员给讲讲具体技巧和注意事项，3腿那啥不好找，活人有的是。


---------------------以下内容，请谨慎阅读。若心跳加怪，血压升高引起不适，请右上角或像管理员投诉
浅谈入门，怎么简单怎么来，偏移、挪移3阶计算说了，给大家讲点简单的,Hex直替。
本着 秉承咋简单咋处理的思想，不走门，换个思路，不在对源目标加载运行后的内存做寄存器寻址运算，换个角度，放弃内存寄存器物理寻址（Physical addressing），破窗而入，转向对文件的物理磁盘Hex编码直接操作，直接修改源代码实际编码，对目标Hex物理磁盘文件存储编码直替处理：即直接对文件的硬盘物理地址下手，修改原始资源物理存储编码，直接汉化编码替换处理，绕过运行时内存虚拟加载偏移量对应地址编码转换，减少计算量降低Hex寻址处理难度。
用小白能听懂的话，所谓“直替”，就是借助工具简单粗暴直接修改替换exe原始代码。直替，全称HEX编码直替，绕捷径，简单暴力，很急功近利的手法，擦边踩红线的外道·禁术，选这个，是不是对原作者有想法，不知道，估计大部分，都不认识原作者。是否和作者有仇，当然也就无法判定。
直替，还是基于页面块对齐原理，处理过程主要借助依赖工具实现，超级简单，没有什么可写的，没多高的技术门槛,选好工具就可以。偏移、挪移，前边都有人写了，再跟着写一遍？没得可写，去咬打火机？声明：介绍方法，不代表推荐、支持或者反对，抵制，代入一下唐妞不等式：描述，不等于同认同或说不认同，同样不代表赞成或不赞成，没有任何个人观点。用、或不用，客观存在，就在那客观存在。


工具选择：https://www.bilibili.com/rEAd/cv4630462/,选顺眼的用，安装包最好不小于6OMb，越大越好没特别推荐。ps：取证自带存盘时exe自动重构，替换时自动编码长度比对提示。用于直替操作很好用。


另外，直替不是标准汉化手法，不像偏移、挪移，没有保留exe原始编码，低情商：原作者:我吃柠檬，西八，你礼貌吗？直接做的代码替换，相当于资源破解的一种。可实现范围，涵盖包括但不限于exe的各种可编码的对象，咋用，仅限用来回显汉化？...其它，PE Explorer、eXeScope,软汉化用来制作汉化包高阶寻址很好用。PE+IcoFX组合能用来替换ico图标，也可以对图片可视化资源做处理汉化，64位的pe32+换Restorator+IcoFX。换ico、汉化图片，选哪个，在于使用者..
继续，3阶操作重新划分Hex处理先后顺序 ，继续减低处理难度：
将未汉化的原始exe      定  为    0
1阶汉化处理后得到的exe  为    1
2阶汉化处理后得到的exe  为    2
一般2阶汉化后 ，还有部分项目没汉化，标注剩余所有还未汉化的地方，3阶处理，但处理对象不是 2，是未汉化原始exe 0  ，用 0  做3阶的Hex，然后得到处理结果在重新进行一次1阶、2阶汉化处理，完活收工。


入门级别处理顺序： 0  、1   、2（丢弃）、  0（Hex，3阶）、  new  1、 new  2 ，成品


简单解释2点： 1、这不是标准，仅为诸多参考方法的1种。正常人的思考顺序 0、1、2、3：2阶处理后，直接对 得到的汉化结果 继续进行3阶，但此时的Hex处理的寻址难度，属于阿伟找杰哥，迎男而上了；2、实际汉化时面对的情况千变万化，错综复杂，选择 0 做Hex寻址，通过重复工作量换取降低Hex的寻址难度。并非适合所有场合，若2阶汉化完成时，全部Hex寻址完成，只剩下因为编码地址长度超限到导致汉化失败的情况，不用跳转回0，直接对得到的 2 继续Hex处理，减少时间，避免重复工作量。


此外，直替手法并非万能，对应要求Hex编码的ascii码长度限制不能超过原资源的ascii码的编码长度，码长不够的可以用 充0 补齐，但不允许替换修改后的编码长度超过原始编码的长度，否则即使重构exe，也会有失败的风险: eg：原始编码 为  Rgb ，可换 3位ascii编码的长度，就是1个汉字+一个0位编码的长度，类似还有  Hex  ，Feb ，等等，此时保证页面对齐考虑RVA或其他处理随便。
ps：处理替换Hex时编码长度，常见的Delphi平台所开发的exe存储编码类型使用ascii编码，其码长：1个汉字=2个英文字符的长度，1个日文字符（片假名）=2个英文字符，另外，不算空格，根据你用的统计工具的不同，有时候1个韩文字符的长度等于2个英文字符的长度，有时候，1个韩文字符=1个英文字符的长度，1个韩文占2英文字符长度，一个韩文字符通常由2到4个字母组成，一个音节通常由2至3个字符组成，换算时编码要注意；当然还有使用unicode类型编码，1个汉字=3个英文字符的长度。其实也没啥用处，专业工具支持码长超限提示。


综述，汉化，到了非标HEX偏移寻址阶段，没有哪个手法是万能通吃，根据汉化目标的内存寄存器编译器定义的寻址方式，不同场合灵活选择不同算法寻址汉化。


附录,
RVA与RWA的关系                                                                                                        https://www.cnblogs.com/gd-luojialin/p/11306329.html
RVA和RAW的转换                                                                                                        https://blog.csdn.net/dyxcome/article/details/91405973
RVA转化成Offset VA                                                                                                http://www.cppblog.com/rawdata/archive/2009/01/04/71117.html
常见的数据寻址方式                                                                                                https://www.cnblogs.com/l20902/p/10610945.html
十种寻址方式                                                                                                                https://blog.csdn.net/lixiaoting9181/article/details/109846970
计组——十种数据寻址方式                                                                                        https://blog.csdn.net/vavid317/article/details/120553807


-------------以下不用看，@版块管理员
1.若有侵权，直接删，不用犹豫。
2.本次还是不申请会员资格，不用审核，不用回复审核结果，谢谢，另外，解释一下：那个域名邮箱不存在于3次元，瞎写的，因为打一开始没打算申请会员。

3.不申请会员的原因解释一下：
作为16年前全民汉化时代遗留下来的炒冷饭，没有啥现象级的新发现或说划时代的研究结果，还是依据页面块对齐实现原理，以前的1点没变，
不管这次写多少种实现算法描述，RVA、EA？EVA，CIA，MBA、DNA、写的再多，原不原创，也就这？
放眼全网，少儿组编程水平，还是6岁一下幼儿级别；放专业汉化论坛，估计吃那啥要坐小孩那桌，就这？拿这个换会员资格申请，大家都在看，多少双眼睛在盯着，匿了，匿了

Hmily

申 请 I D：ISO639-1
https://www.52pojie.cn/thread-1874523-1-1.html

你咋又发了一遍，上次就回复你说了邮箱有问题，你都没回复，这次一样邮箱有问题，你没注意到吗？

bian96

Hmily 发表于 2024-2-12 11:05
你咋又发了一遍，上次就回复你说了邮箱有问题，你都没回复，这次一样邮箱有问题，你没注意到吗？

ta在结尾部分写了：

2.本次还是不申请会员资格，不用审核，不用回复审核结果，谢谢，另外，解释一下：那个域名邮箱不存在于3次元，瞎写的，因为打一开始没打算申请会员。