WZ编辑工具：自定义加密与读写流程全方位解析

简介这款冒险岛WZ编辑工具主要面向玩家、MOD作者和本地研究者用来查看、修改WZ资源并支持自定义加密。WZ文件是冒险岛的核心资源载体涵盖图像、音频、脚本与数值配置借助工具可替换角色皮肤、调整地图布局、修改怪物属性甚至尝试二次开发。资源包共34个文件约3.09MB以dll运行库、exe主程序、xml配置、config与ini设置文件为主另含chm帮助文档与txt说明整体为便携式工具套件下载后即可调用。目前已有3973人学习下载过。自定义加密是主要亮点支持AES、DES、RSA等常见算法可配置密钥管理、加密模式与强度增强资源安全压缩包内同时附带版本修改器、技能编码表和批量文件更换工具便于进行本地资源实验、WZ结构研究或加密方案测试适合中高级玩家与开发者对想研究WZ封装格式的人尤为实用。1. 冒险岛WZ编辑工具在解决什么读、改、写回一环都不能断冒险岛WZ编辑工具听起来是小众里的冷门需求但我可以很明确地告诉你凡是碰过客户端汉化、本地化适配、资源替换的人最后几乎都会被同一个问题卡住——WZ不是普通的图片包它是一棵带加密的二进制树。市面流传的编辑器多半只能打开特定版本换一个地区客户端解密逻辑就失灵这就是为什么“支持自定义加密”会成为一把真正的钥匙。它解决的矛盾很具体你能打开文件、能看懂结构不代表你能改得回去。改贴图、改文本、改属性值都需要把数据读出来之后再按完全相同的顺序和加密规则写回任何一步跟原文件头不一致游戏启动就会直接报错。这篇文章会把读取、编辑、写回、自定义加密四件事拆开讲清楚适合正在做本地化、客户端资源定制或者想自己做一套跨版本编辑脚本的开发者。2. 拆WZ文件格式怎么判断加密、怎么把整棵树读进内存2.1 头部三件套加密标志、文件长度、版本号决定后面所有操作WZ文件头虽然只有几十字节但它决定了后面每一步该怎么走。我一般在拿到一个陌生WZ文件时不会急着去翻结构而是先看三个字段加密标志、文件长度、版本标识。加密标志通常出现在文件开头未加密版本是一个值加密版本是另一个值这个标志同时告诉你要不要调用解密函数。读头部时有一种很常见的翻车是有些工具只判断文件扩展名不判断内容。结果把加密版WZ当普通二进制直接解析后面的目录树全是乱码。我见过太多人卡在“一打开就报错”这一步最后发现只是头部判断写死了。头部读取的最小代码可以这样写import struct def read_wz_header(path: str) - dict: with open(path, rb) as f: head f.read(64) # 前两个字节第一个是版本标志第二个是加密标志 version_flag head[0] encrypt_flag head[1] # 从偏移4开始读4字节是解压后的文件长度小端序 file_size struct.unpack_from(I, head, 4)[0] # 从偏移8开始读4字节是WZ文件头自身长度通常为64或128 header_size struct.unpack_from(I, head, 8)[0] return { version_flag: version_flag, encrypt_flag: encrypt_flag, file_size: file_size, header_size: header_size, }这段代码的意图是先把头部前64字节读进内存用结构性读取替代一次性字符串切割。encrypt_flag决定后面所有数据块是否走解密分支header_size决定目录树读取的起始偏移不同客户端可能差异很大。仅靠这两个字段就能区分大多数版本差异。读到这里你可能已经想到既然头部信息有限那后面的列表目录才是关键。加密标志不能只当标志用还要和版本号配合某些版本的头部顺序是先文件长度再版本号读取时需要用条件判断去兼容。这就是为什么我不建议直接硬编码偏移而是先做一次头部结构探测再决定解析流程。2.2 解密函数一个异或加轮转就能把二进制从黑匣子拉出来WZ的加密不像现代算法那样复杂它本质上是一套基于异或和位轮转的变换。这个加密有一个特点它不是为了防破解而是为了让十六进制阅读器无法直接看到字符串内容。理解了这一点你就明白为什么工具必须支持自定义加密——不同客户端不仅密钥表不同轮转方向和位偏移也可能不同。解密时最常见的做法是逐字节处理先对字节做异或再按位左移或右移最后与另一个掩码异或。反过来写入时顺序刚好相反。一个足够灵活的解密函数应当把密钥表、旋转方向、位偏移都作为参数而不是写死在函数体里。def decrypt_data(data: bytes, key: bytes, rotate_dir: str left, bit: int 3) - bytes: out bytearray(len(data)) key_len len(key) for i in range(len(data)): b data[i] ^ key[i % key_len] # 第一步与循环密钥异或 if rotate_dir left: b ((b bit) | (b (8 - bit))) 0xFF else: b ((b bit) | (b (8 - bit))) 0xFF b ^ 0x43 # 第二步固定掩码异或 out[i] b return bytes(out)这个函数的价值在于密钥key和方向rotate_dir是外部传入的意味着同一套代码可以适配多类客户端。key常见长度是8字节有些地区版本会用16字节0x43这个常量是常见选择但需要根据目标版本调整。如果解密结果仍然不像明文优先检查rotate_dir和bit这两个参数。2.3 属性树解析从根节点开始递归读完整张资源树头部解完接着就是WZ的核心列表目录。这个目录是一棵树根节点下有若干目录节点目录节点下再挂属性节点。属性节点类型很多常见的是Canvas用于存图片、UOL用于引用其它节点、Int/String等用于存数值和文本。Socket层不统一所以解析要充分考虑多类型分支。解析顺序不能乱每个节点先读名称长度再读名称字节名称是UTF-16小端编码。接着读一个节点类型码类型码决定后面跟着什么内容。如果是属性节点还要继续读数据类型码。所有节点递归前进直到所有子节点读完。def parse_node(f, offset: int, depth: int 0): # 读取名称前2字节是名称字节长度后面是UTF-16LE编码 name_len struct.unpack_from(H, f.read(2), 0)[0] name f.read(name_len).decode(utf-16-le, errorsreplace) # 读取节点类型码0x00为目录0x01为属性 node_type struct.unpack(B, f.read(1))[0] if node_type 0x00: child_count struct.unpack(I, f.read(4))[0] children [] # 递归解析所有子节点 for _ in range(child_count): child, offset parse_node(f, offset f.tell(), depth 1) children.append(child) return {name: name, type: dir, children: children}, offset else: data_type struct.unpack(B, f.read(1))[0] value read_data_by_type(f, data_type) return {name: name, type: prop, data_type: data_type, value: value}, offset这段代码最值得注意的地方是名称长度是字节数不是字符数中文字符每个占2字节节点类型是单字节读取顺序是“名称类型”不要先读类型再读名称否则解析错位。实际操作中我还会加一个depth上限防止异常文件造成无限递归。解析完成后整棵树可以序列化成JSON中间格式方便后续编辑。3. 真正的编辑替换贴图、文本与写回流程3.1 改一块Canvas先解出原始数据再把新PNG重新加密回去Canvas是WZ里最常见的图片类型读取Canvas的过程和你直接改一张PNG完全不同。工具需要先从数据区读出PNG字节然后再读取一段加密的位图数据这段位图数据和PNG配套使用。直接替换PNG但不处理位图部分游戏里依然会显示旧图或直接崩掉。正确做法是把原Canvas的PNG数据保存到文件编辑完新PNG之后把新PNG数据写回同时把对应的位图数据一并重算。位图数据不是随意生成的它需要按PNG内容做加密变换。我的做法是把New PNG按指定尺寸重新编码再套用与文本解密相反的方向重新加密。def replace_canvas(node, new_png: bytes, width: int, height: int, key: bytes): # 新的PNG数据直接替换原节点里的PNG字段 node[png_data] new_png # 位图部分需要按宽高重新生成并加密 bitmap_raw build_bitmap_from_png(new_png, width, height) node[bitmap_data] encrypt_data(bitmap_raw, key, rotate_dirright, bit3)这里build_bitmap_from_png的具体实现取决于目标客户端支持的像素格式有的用BGR565有的用ARGB8888这需要读者按自己客户端确认。替换Canvas最常见的结果就是花屏或透明图变黑图根源基本都是像素格式不匹配。因此在做Canvas替换之前我会先用原始文件导出一张小图做实验确认工具解析出的像素格式和你手里PNG的字节序一致。3.2 写回流程偏移占位、两段写入控制好节点名编码编辑完成后写回WZ这是整个流程里最不能出错的一步。读WZ时可以边读边算偏移但写WZ必须反过来先把整棵节点树序列化到内存把所有数据段收集起来才能算出每个数据段在文件里的最终偏移。偏移一变头部和列表目录里的指针全部要同步更新。我通常采用两段写入第一段是文件头和序列化后的列表目录第二段是数据区。但问题是列表目录里需要写入数据段偏移而数据段偏移要等数据区布局完成后才知道。解决办法是先用占位值布局数据区计算偏移后再回头填目录。def build_wz(root, out_path: str, key: bytes): segments collect_all_segments(root) # 收集所有数据段保持顺序 layout layout_segments(segments) # 计算每个数据段相对偏移 header write_wz_header(layout.total_size, len(layout.segments)) with open(out_path, wb) as f: f.write(header) serialize_directory(f, root, layout) # 目录区用layout里的真实偏移 for seg in layout.segments: f.write(seg.data) # 最后统一写入数据区这段流程里最容易翻车的是collect_all_segments的顺序。数据段的排列顺序必须和目录区的偏移表对应一旦顺序错乱目录区明明指向了正确偏移但读出来的数据类型不对。写回后如果游戏启动时只报内存错误不报文件错误优先怀疑段顺序。3.3 改动前先做三件事哈希、备份、可回滚的中间格式编辑工具最大的后悔药成本在改动前。我没有哪一次是把原文件直接拿来改的第一件事永远是备份和哈希。哈希的意义不是备份本身而是让你在写回后能快速确认“改动范围是否只有目标部分”以及事后排查是不是自己误改了其它节点。中间格式这里是指JSON。WZ解析成JSON后目录结构会展开成可读格式文本节点直接是字符串数值节点直接是数字修改相对直观。把JSON当作中间层还有一个好处可以写一个独立脚本对JSON做批量替换再统一写回。cp original.wz original.wz.bak sha256sum original.wz original.wz.sha256 python -m wztool dump original.wz --output dump.json python -m wztool build original.wz.bak --from dump.json --output modified.wz sha256sum modified.wz这一步的顺序是刻意的先备份再验证改动。如果dump出的JSON和预期差异很明显说明解析参数错了此时就不要继续往下改而是先回查头部版本。哈希放在最后能让你对“本轮改动是否覆盖了不该碰的区域”心里有数。这个习惯救过我很多次尤其是改到一半换版本的时候。4. 自定义加密不重写算法把密钥表与旋转参数做成配置4.1 三要素拆解密钥表、旋转方向、加密覆盖范围支持自定义加密的工具不能把解密逻辑全部写死。解密一个WZ文件实际上涉及三个可变点密钥表、旋转方向、加密覆盖范围。密钥表通常是8字节或16字节的常量数组不同客户端差异明显旋转方向决定位操作是左移还是右移加密覆盖范围则控制哪些数据块需要解密。例如文件头中某些字段可能始终是明文列表目录需要解密而数据区中位图部分用的是另一套加密规则。这就是为什么工具需要把这些点暴露成参数而不是躲在函数内部。理解了这三个维度再去看现有编辑器报的“不支持的版本”本质就是三要素里某一个和你手头的文件不匹配。4.2 用加密配置驱动工具流程一份JSON控制加解密的全部行为我推荐的工程做法是所有加解密行为由一份配置文件驱动。这样工具本身只负责读取配置并执行遇到新的客户端版本时不需要改代码只需要在配置里新增一套参数。这个折中方案兼顾了代码可维护性和版本适配速度。{ version: custom_1, encryption: { enabled: true, header_encrypt: false, list_encrypt: true, data_encrypt: true, key_table: [2, 3, 5, 7, 11, 13, 17, 19], rotate_direction: left, rotate_bits: 3, mask: 67 } }这个配置文件把前面所有可变项都收拢到了一处。“header_encrypt”为false表示文件头部字段直接读取“list_encrypt”为true表示目录树部分需要走解密rotate_bits决定每次位移多少位。实际适配新版本时我一般会先用小文件反复试三要素直到JSON里导出文本变成可读内容为止。这一步测通了后面解析流程就不用再动。4.3 自定义加密的边界客户端只认它编译进去的那套还原逻辑需要特别提醒的是自定义加密能解决的是工具侧适配问题不代表你可以任意换密钥表写回。客户端在启动时会用自己写死的解密函数去读WZ你的写回规则必须和客户端里的解密规则完全一致否则游戏一定启动失败。这就是为什么“自定义加密”不是让你发明新算法而是让你能配置出与目标客户端匹配的那套参数。有一次我收到一个改了密钥表的新版本包打开后文件头识别正常但所有字符串全是乱码。排查了很久才发现问题出在rotate_bits原工具用3位目标客户端用4位。这说明密钥表正确还不够旋转参数差一位整体解密就会完全失效。因此配置加密时不要把旧参数直接套用要用目标客户端的一组原始数据做验证。5. 避坑打开、改完、启动三个阶段最容易踩的五个坑5.1 打开阶段版本判断错、中文路径、头字节被替换现象工具打开WZ报错但同一文件用其它查看器能正常读。原因多半是工具只按固定偏移读头部目标文件头部版本号不同导致后续解析错位。解决方法是先做头部探测把读取到的版本标志和加密标志打印出来再走对应分支。不要跳过这一步直接解析。现象把工具和WZ文件放在带中文的路径下导出正常写回后文件损坏。原因是部分解析框架按平台默认编码打开文件中文路径导致读写编码不一致。解决方法是所有文件操作都显式指定encodingutf-8或直接用二进制模式打开路径也用英文目录先行规避。5.2 改完与启动缓存误判、位图加密、密钥配错现象文本修改后重新打包进游戏看到还是旧文本。这不一定是写回失败。很多客户端在首次启动后会生成资源缓存后续优先读缓存。解决方法是先清空缓存目录再启动否则你会白白排查自己的工具。这一个坑把不少人的方向带偏过我一开始也以为是加密写回有问题结果只是缓存没清。现象替换图标后出现花屏。常规原因是新PNG的像素格式与原Canvas不匹配或者位图数据没有重新加密。仅替换PNG字段、保留旧位图数据是最常见的翻车操作。解决方法是替换的同时重建位图数据并且确认色彩通道顺序。现象所有字符串解密成乱码但目录树能正常显示。这通常是密钥表正确、旋转参数错误两种错位组合在一起会造成一种“好像解析对了但内容不对”的假象。解决方法是逐项打印解密三要素不要同时修改多个参数一次只改动一个变量用已知明文节点做校验。6. 验证与习惯改完一份WZ的最小烟测流程写回成功不等于能用真正的验证必须走一遍游戏启动流程。我个人的最小烟测习惯分两级第一级是不启动游戏只做结构校验和内容抽查。结构校验是让工具重新解析刚生成的文件看节点树是否完整名称是否全部可读这能及时暴露偏移和编码问题。内容抽查是检查你改的节点确认新值确实存在于文件中。二级验证就要启动客户端了。通常我会选三个抽查点登录界面上随机出现的提示文本、技能说明、一张小尺寸图标。这三个点覆盖文本读取、属性读取、贴图读取三条链路只要这三处正常说明三类核心数据都还原成功。跑完这轮我会把加密配置保存下来作为下次同类文件的默认配置。养成习惯之后我还会在改文件前先跑一遍“导出JSON对比”这是排除黑匣子问题最好的办法。如果JSON都能导出且结构清晰基本可以认定工具侧没问题后续问题通常出在写回或客户端侧。改了这么久WZ我最大的一个体会是这类工具不怕功能少就怕参数不透明。把加密参数显式暴露出来比封装成黑盒要可靠得多。希望帮到你。本文还有配套的精品资源点击获取