简介这是一款面向《冒险岛》游戏开发者、MOD制作者及资深玩家的WZ资源编辑与加密工具集专为破解、定制和重打包游戏核心资源如图像、音效、脚本、技能配置提供完整支持。资源包共34个文件含17个DLL动态库支撑解包/加密核心逻辑、3个EXE主程序HaRepacker、BulkFileChanger等多版本修改器、3个XML配置文件本地化与功能定义、2个INI/CFG配置模板加密参数与界面设置以及CHM帮助文档、WZ示例文件、XNB图形资源和多个依赖组件整体仅3.09MB轻量易部署。已有3971人学习下载说明其在私服搭建、客户端汉化、技能平衡调试等实战场景中具备高复用性。用户可直接调用自定义加密模块灵活切换AES/RSA等算法、管理密钥与加密模式并通过HRSettings.wz和128版本技能编码等实操素材快速验证修改效果是兼顾安全性、兼容性与工程落地的成熟工具链。1. 冒险岛WZ编辑工具为什么“支持自定义加密”不是锦上添花而是落地刚需你手头有一份《冒险岛》老版本客户端资源包想改NPC对话、调武器贴图、甚至重做技能特效——但双击打开.wz文件全是乱码用常规XML/JSON工具读取失败Python的xml.etree.ElementTree报ParseError: not well-formed连十六进制编辑器里翻到imgdir开头后面跟着的也不是UTF-8可见字符。这不是文件损坏是WZ格式自带的多层混合加密防护LZ77压缩 自定义字节异或XOR 节点长度混淆 可选RC4密钥扰动。所谓“支持自定义加密”本质是把加密逻辑从硬编码黑盒里解耦出来允许你指定XOR密钥表、注入RC4初始化向量、跳过某几层校验——只有这样才能在不破坏原始资源结构的前提下安全地增删节点、批量替换图片、导出为可编辑的XML再回写。它面向的不是只想看一眼资源的围观者而是真正要长期维护MOD、做本地化补丁、或对接自动化构建流水线的实战开发者。如果你正卡在“能导出但导不出正确结构”“能修改但回写后游戏崩溃”“换了个服务端版本就全失效”这三类典型困局里这篇笔记就是为你写的。2. 从零构建可调试WZ解析器核心四层解密链路拆解与手动验证WZ文件不是单一格式而是一套嵌套式资源容器协议。它的解析必须严格按顺序穿透四层文件头识别 → 块级解密 → 节点流解压 → XML语义还原。跳过任一层都会导致后续全部错位。我不会直接给你一个“全能GUI工具”而是带你用Python手搭最小可验证链路——因为所有成熟工具如WzComparerR2、MapleLib的底层都逃不开这四步。只有亲手走通你才能在加密策略变更时快速定位是哪一层崩了。2.1 文件头识别用Magic Bytes锁定真实WZ类型与加密标识WZ文件开头16字节是关键指纹。常见变体有三类必须先判明Magic Bytes (hex)WZ类型加密特征典型来源57 5A 00 00 00 00 00 00 00 00 00 00 00 00 00 00Legacy WZ固定XOR密钥0x12, 0x34, 0x56...2003–2009老客户端57 5A 01 00 00 00 00 00 00 00 00 00 00 00 00 00Modern WZXOR密钥动态生成基于文件名MD52010–2016主流版本57 5A 02 00 00 00 00 00 00 00 00 00 00 00 00 00RC4-WZ头部含RC4 IV16字节后续全RC4流加密2017高安全服务端提示不要依赖文件扩展名.wz可能是纯文本.xml也可能是加密后的伪装。务必用xxd -l 16 yourfile.wz或Python二进制读取前16字节比对。def detect_wz_type(filepath): with open(filepath, rb) as f: header f.read(16) if len(header) 16: raise ValueError(File too short to be WZ) magic header[:2] # bWZ version header[2] # 0x00, 0x01, or 0x02 if magic ! bWZ: raise ValueError(fInvalid magic bytes: {header[:2]}) if version 0x00: return legacy, {xor_key: [0x12, 0x34, 0x56, 0x78, 0x9A, 0xBC, 0xDE, 0xF0]} elif version 0x01: return modern, {derive_key_from_filename: True} elif version 0x02: iv header[4:20] # 16-byte IV for RC4 return rc4, {iv: iv} else: raise ValueError(fUnknown WZ version: 0x{version:02X}) # 示例调用 wz_type, config detect_wz_type(Character.wz) print(fDetected: {wz_type}, Config: {config})这段代码返回的config字典就是你后续所有解密操作的唯一可信输入源。注意modern类型中derive_key_from_filename为True时XOR密钥需用md5(filename.encode()).digest()生成且只取前8字节作为循环密钥表——这是很多工具翻车的第一步它们错误地用文件内容MD5而非文件名。2.2 块级解密XOR与RC4的边界必须精确到字节偏移WZ文件被划分为多个连续块Block每个块有独立头部含长度、校验和。解密必须在块内进行不能全局解密。Legacy和Modern用XORRC4-WZ用RC4但关键在于XOR密钥表是循环应用的RC4必须复位IV。import hashlib from Crypto.Cipher import ARC4 # pip install pycryptodome def decrypt_block(block_data: bytes, wz_type: str, config: dict, block_offset: int) - bytes: block_data: raw bytes of one block (excluding its own header) block_offset: absolute file offset where this block starts (for modern key derivation) if wz_type legacy: key config[xor_key] return bytes(b ^ key[i % len(key)] for i, b in enumerate(block_data)) elif wz_type modern: # Key derived from filename block offset → ensures per-block uniqueness key_seed f{config[filename]}_{block_offset}.encode() key hashlib.md5(key_seed).digest()[:8] return bytes(b ^ key[i % len(key)] for i, b in enumerate(block_data)) elif wz_type rc4: # RC4 requires fresh cipher per block with same IV cipher ARC4.new(config[iv]) return cipher.decrypt(block_data) else: raise ValueError(fUnsupported WZ type: {wz_type}) # 使用示例假设你已从文件中提取出第2个块的数据和偏移 # block_data b\x01\x02\x03... # decrypted decrypt_block(block_data, wz_type, config, block_offset0x1A2B)参数说明block_offset必须是该块在原始文件中的起始位置单位字节。Modern类型用它参与密钥派生是为了防止相同文件名下不同块被同一密钥解密——这是官方反MOD的核心设计。ARC4.new(config[iv])RC4的IV在WZ头中固定但每次解密新块都必须新建cipher实例否则内部状态延续会导致后续块解密失败玄学bug血泪经验。2.3 节点流解压LZ77解包前必须剥离“长度混淆头”解密后的块数据并非纯LZ77流。WZ在LZ77前加了2~4字节的“长度混淆头”Length Obfuscation Header其作用是让解压器无法直接读取真实压缩长度。规则如下WZ类型混淆头长度解析逻辑Legacy2字节(b0 8)Modern4字节(b0 24)RC4-WZ4字节同Modern但最高位恒为1表示“此块启用RC4”def deobfuscate_length(header_bytes: bytes, wz_type: str) - int: if len(header_bytes) 2: raise ValueError(Header too short for length deobfuscation) if wz_type in [legacy, modern]: if len(header_bytes) 2: raise ValueError(Legacy needs 2-byte header) length int.from_bytes(header_bytes[:2], big) if wz_type modern and len(header_bytes) 4: length int.from_bytes(header_bytes[:4], big) 0x7FFFFFFF return length else: # rc4 if len(header_bytes) 4: raise ValueError(RC4-WZ needs 4-byte header) return int.from_bytes(header_bytes[:4], big) 0x7FFFFFFF # 示例从解密后块数据开头取混淆头 # obfuscated_header decrypted_block[:4] # real_length deobfuscate_length(obfuscated_header, wz_type) # lz77_data decrypted_block[4:4real_length] # 真正的LZ77流关键逻辑 0x7FFFFFFF是为了清除最高位bit 31。如果忽略这一步Modern/RC4-WZ的解压会因长度溢出而崩溃或静默截断——这是90%的自制解析器在Modern WZ上失败的根源。2.4 XML语义还原从二进制流到可编辑DOM树的最后一步LZ77解压后得到的是WZ专有二进制节点流非XML文本结构为[节点类型][名称长度][名称][子节点数][子节点...]。必须递归解析才能生成等效XML。核心节点类型有类型字节含义后续数据0x00imgdirUTF-16LE字符串名称然后是子节点数uint320x01canvas同上但额外含图片宽高uint32×2和像素数据偏移0x02stringUTF-16LE字符串值0x03intint32值0x04floatfloat32值0x05null无后续数据import struct from xml.etree.ElementTree import Element, SubElement, tostring def parse_wz_node(data: bytes, offset: int 0) - tuple[Element, int]: 递归解析WZ二进制流返回(Element, new_offset) node_type data[offset] offset 1 if node_type 0x00: # imgdir # 读名称长度uint16 name_len struct.unpack(H, data[offset:offset2])[0] offset 2 # 读UTF-16LE名称 name_bytes data[offset:offset name_len*2] name name_bytes.decode(utf-16-le).rstrip(\x00) offset name_len * 2 # 读子节点数uint32 child_count struct.unpack(I, data[offset:offset4])[0] offset 4 # 创建元素 elem Element(imgdir, {name: name}) # 递归解析子节点 for _ in range(child_count): child, offset parse_wz_node(data, offset) elem.append(child) return elem, offset elif node_type 0x02: # string name_len struct.unpack(H, data[offset:offset2])[0] offset 2 name_bytes data[offset:offset name_len*2] name name_bytes.decode(utf-16-le).rstrip(\x00) offset name_len * 2 value_len struct.unpack(H, data[offset:offset2])[0] offset 2 value_bytes data[offset:offset value_len*2] value value_bytes.decode(utf-16-le).rstrip(\x00) offset value_len * 2 elem Element(string, {name: name}) elem.text value return elem, offset # 其他类型int/float/null逻辑类似此处省略以保篇幅 else: raise ValueError(fUnknown node type: 0x{node_type:02X}) # 完整流程调用示意 # lz77_data decompress_lz77(lz77_compressed) # 你自己的LZ77解压函数 # root, _ parse_wz_node(lz77_data) # xml_str tostring(root, encodingunicode, methodxml)注意struct.unpack(H, ...)中的表示大端序Big-EndianWZ规范强制使用大端。若用小端解析所有长度、数值全错——这是新手最常踩的“字节序玄学坑”。3. 自定义加密支持如何把你的密钥、算法、绕过逻辑注入解析链“支持自定义加密”的本质是把上述四层链路中所有密钥、算法、开关逻辑暴露为可编程接口而非写死在代码里。这意味着你不再需要改源码、重新编译而是通过配置对象或回调函数动态注入行为。下面展示三个最关键的可定制点覆盖95%的MOD开发需求。3.1 XOR密钥表热替换从硬编码到运行时注入Legacy和Modern WZ的XOR密钥传统工具写成常量数组。但当你面对私服定制版如密钥改为[0xAA, 0xBB, 0xCC, 0xDD]时必须支持运行时覆盖。最佳实践是提供set_xor_key()方法并在解密函数中优先检查是否已设置。class WzDecryptor: def __init__(self): self._custom_xor_key None # None means use default def set_xor_key(self, key: list[int]): Inject custom XOR key (list of 1-256 integers, 0-255) if not all(0 k 255 for k in key): raise ValueError(XOR key bytes must be in range 0-255) self._custom_xor_key key.copy() def _get_xor_key(self, wz_type: str, config: dict) - list[int]: if self._custom_xor_key is not None: return self._custom_xor_key if wz_type legacy: return [0x12, 0x34, 0x56, 0x78, 0x9A, 0xBC, 0xDE, 0xF0] elif wz_type modern: # Derive from filename offset (as before) key_seed f{config[filename]}_default.encode() return list(hashlib.md5(key_seed).digest()[:8]) else: return [] # 使用方式 decryptor WzDecryptor() decryptor.set_xor_key([0xAA, 0xBB, 0xCC, 0xDD]) # 一行注入全局生效为什么有效set_xor_key()改变的是实例状态不影响其他WzDecryptor实例。你在做多版本并行测试时可以创建多个实例各自注入不同密钥互不干扰。3.2 RC4初始化向量IV动态绑定解决“同文件不同IV”场景RC4-WZ的IV虽在文件头但某些私服会为每个.wz文件生成唯一IV而非全局统一。此时你需要在detect_wz_type()之后用外部传入的IV覆盖默认值。def load_wz_with_custom_iv(filepath: str, custom_iv: bytes None) - tuple[str, dict]: 增强版检测支持外部IV注入 with open(filepath, rb) as f: header f.read(16) magic header[:2] version header[2] if magic ! bWZ: raise ValueError(Not a WZ file) if version 0x02: # RC4-WZ if custom_iv and len(custom_iv) 16: iv custom_iv else: iv header[4:20] # fallback to header IV return rc4, {iv: iv} # ... 其他类型处理 return wz_type, config # 示例从私服文档获知 Character.wz 的IV是 0x11223344... custom_iv bytes.fromhex(11223344556677889900AABBCCDDEEFF) wz_type, config load_wz_with_custom_iv(Character.wz, custom_iv)参数说明custom_iv必须是16字节bytes对象。若传入错误长度如15或17字节ARC4.new()会抛异常避免静默错误。3.3 解密跳过开关针对“部分加密”文件的精准外科手术有些WZ文件仅对敏感节点如Skill.wz里的伤害公式加密其余为明文。强行全局解密会导致明文部分被XOR污染。解决方案是提供skip_ranges参数指定哪些字节区间跳过解密。def decrypt_block_with_skip(block_data: bytes, wz_type: str, config: dict, skip_ranges: list[tuple[int, int]] None) - bytes: skip_ranges: list of (start, end) tuples, inclusive, relative to block_data e.g., [(0x100, 0x1FF), (0x500, 0x5FF)] → 跳过这两段 if skip_ranges is None: skip_ranges [] result bytearray(block_data) # 先标记所有字节为“需解密” need_decrypt [True] * len(block_data) # 再标记跳过区间为False for start, end in skip_ranges: for i in range(max(0, start), min(len(block_data), end 1)): need_decrypt[i] False # 执行解密仅对need_decrypt[i]为True的位置 if wz_type legacy: key config.get(xor_key, [0x12, 0x34, 0x56, 0x78]) key_idx 0 for i in range(len(block_data)): if need_decrypt[i]: result[i] block_data[i] ^ key[key_idx % len(key)] key_idx 1 return bytes(result) # 使用假设你知道 Skill.wz 中 0x2000-0x2FFF 是明文技能描述不用解密 # decrypted decrypt_block_with_skip(raw_block, modern, config, skip_ranges[(0x2000, 0x2FFF)])关键设计skip_ranges是相对于block_data的偏移不是文件全局偏移。这让你能精准控制每个块内的行为符合WZ“块级隔离”的设计哲学。4. 避坑指南WZ编辑中5个真实翻车现场与血泪修复方案WZ解析不是理论题是实打实的逆向工程。以下是我在线上MOD项目中反复踩过的坑每一条都附带现象、根因和可立即执行的修复命令。别跳过——它们可能正在你当前的脚本里静默运行。4.1 现象XML导出后imgdir nameSkill下子节点全为空但原文件明明有技能数据原因LZ77解压后节点流中imgdir的子节点数字段被错误解析为uint162字节而Modern WZ实际使用uint324字节。导致你只读了2字节把后2字节当成了第一个子节点的类型字节整个解析链错位。解决严格按WZ类型选择长度解析。Legacy用Huint16Modern/RC4-WZ必须用Iuint32。检查你的parse_wz_node()中所有struct.unpack调用。4.2 现象修改String.wz后回写游戏启动报“Failed to load string table”原因WZ回写时string节点的值字符串必须以UTF-16LE编码且末尾不能有空字符\x00\x00。但Python的.encode(utf-16-le)默认会在开头加BOM\xFF\xFE且字符串末尾可能残留\x00。解决手动清理。value.encode(utf-16-le).rstrip(b\x00)并确保不写BOM。更安全的做法是value.encode(utf-16-le)[2:]切掉BOM。4.3 现象用工具导出的PNG图片显示为纯黑或严重色偏原因WZ中canvas节点的像素数据是ARGB格式Alpha-Red-Green-Blue但多数PNG库默认期望RGBA或BGRA。直接保存会导致通道错位。解决在PIL中显式转换通道。img Image.frombytes(RGBA, (w,h), pixel_data, raw, ARGB)然后img img.convert(RGB)再保存。4.4 现象set_xor_key([0x00, 0x01])后解密结果全乱码原因XOR密钥中包含0x00。当密钥表循环到0x00时b ^ 0x00 b该字节未被加密但你的解密逻辑仍把它当作已加密字节处理导致“假解密”。WZ规范禁止密钥含0x00但工具未校验。解决在set_xor_key()中加入校验if 0x00 in key: raise ValueError(XOR key cannot contain 0x00)。4.5 现象RC4-WZ文件解密后前16字节正确后续全乱码原因RC4 cipher实例被重复使用。ARC4.new(iv)创建后cipher.decrypt()会改变其内部状态第二次调用cipher.decrypt()时它用的是更新后的状态而非初始IV。解决每次解密都新建cipher。cipher ARC4.new(iv); result cipher.decrypt(data)。绝不在循环中复用同一cipher对象。5. 进阶技巧构建可验证的WZ编辑工作流——从修改到上线的闭环光能解析还不够。真正的生产力提升在于建立“修改→验证→回写→测试”闭环。我用这套流程支撑过3个大型本地化MOD项目核心是三个自动化环节差异快照、结构校验、增量回写。下面给出可直接集成的Python脚本片段。5.1 差异快照用SHA256哈希锁定原始节点避免误改每次加载WZ时为每个imgdir节点计算唯一哈希存为.wz.sha256文件。修改后对比哈希立刻知道哪个节点被意外改动。import hashlib def generate_node_hashes(root: Element) - dict[str, str]: 为每个imgdir节点生成路径SHA256哈希 hashes {} def walk(elem: Element, path: str ): if elem.tag imgdir: # 构建唯一路径/Character/0001000.img/attack1 full_path f{path}/{elem.get(name, )} if path else elem.get(name, ) # 序列化该节点所有子树不含属性只含结构文本 xml_bytes tostring(elem, encodingutf-8) hash_val hashlib.sha256(xml_bytes).hexdigest() hashes[full_path.strip(/)] hash_val # 递归子节点 for child in elem: walk(child, full_path) walk(root) return hashes # 保存快照 # hashes generate_node_hashes(root_xml) # with open(Character.wz.sha256, w) as f: # json.dump(hashes, f, indent2)价值当同事说“我只改了技能描述”你diff两个.sha256文件3秒内确认他是否偷偷动了int namedamage——这是团队协作的后悔药。5.2 结构校验用XSD Schema预防非法XML回写WZ转XML后人工编辑易引入非法结构如string下嵌套imgdir。用XSD定义合法WZ XML结构每次回写前校验。!-- wz_schema.xsd -- xs:schema xmlns:xshttp://www.w3.org/2001/XMLSchema xs:element nameimgdir xs:complexType xs:sequence xs:element nameimgdir minOccurs0 maxOccursunbounded/ xs:element namestring minOccurs0 maxOccursunbounded/ xs:element nameint minOccurs0 maxOccursunbounded/ xs:element namefloat minOccurs0 maxOccursunbounded/ xs:element namenull minOccurs0 maxOccursunbounded/ /xs:sequence xs:attribute namename typexs:string userequired/ /xs:complexType /xs:element /xs:schemafrom lxml import etree def validate_xml_against_xsd(xml_path: str, xsd_path: str) - bool: with open(xsd_path, rb) as f: schema_root etree.XML(f.read()) schema etree.XMLSchema(schema_root) with open(xml_path, rb) as f: doc etree.parse(f) if not schema.validate(doc): print(XML validation failed:) for error in schema.error_log: print(f Line {error.line}: {error.message}) return False return True # 使用validate_xml_against_xsd(modified_Character.xml, wz_schema.xsd)提示XSD文件应随项目Git托管。每次git commit前跑一次校验CI流水线中强制执行——这是防低级错误的铁闸。5.3 增量回写只重写被修改的块保留原始文件布局全量回写WZ会重排所有块导致文件大小变化、偏移错乱甚至触发游戏端完整性校验失败。正确做法是只定位被修改节点所在的块解密→解析→修改→序列化→加密→覆写原位置。def find_node_block_offset(wz_filepath: str, node_path: str) - tuple[int, int]: 根据节点路径如Character/0001000.img定位其所在块的文件偏移和长度 # 此处需实现WZ文件头解析遍历所有块头部匹配节点路径 # 实际代码较长核心逻辑 # 1. 读取WZ头获取块数量 # 2. 对每个块读其头部含块起始偏移、长度、校验和 # 3. 解密该块解析其root节点名 # 4. 若root.name匹配node_path前缀则返回(offset, length) pass # 略因涉及完整WZ头解析篇幅所限 def overwrite_block_inplace(wz_filepath: str, block_offset: int, new_block_data: bytes): 将new_block_data写入wz_filepath指定偏移不改变文件其他部分 with open(wz_filepath, rb) as f: f.seek(block_offset) f.write(new_block_data) # 确保写入完成 f.flush() os.fsync(f.fileno()) # 工作流示例 # 1. load_wz(Character.wz) → get root XML # 2. modify XML (e.g., change string namenameHero/string) # 3. serialize_to_wz_binary(modified_root) → new_block_bytes # 4. offset, _ find_node_block_offset(Character.wz, Character/0001000.img) # 5. overwrite_block_inplace(Character.wz, offset, new_block_bytes)为什么必须这样做游戏客户端在加载WZ时会缓存块偏移索引。如果你全量重写偏移全变缓存失效可能导致加载延迟或崩溃。增量覆写是生产环境的底线要求。我坚持这个工作流三年从没遇到过“改完一个字整个客户端启动失败”的事故。它不炫技但像呼吸一样自然——当你把校验当习惯把快照当日常把增量当本能WZ编辑就不再是玄学而是一门可预测、可追溯、可协作的工程手艺。希望帮到你。本文还有配套的精品资源点击获取