想找回“一扫一大片”的感觉，或者自由配置自己的武器？这里分享《无双大蛇2U》《无双大蛇3U》的PC版CE表、Switch金手指，以及一个同时支持两作PC／Switch存档编辑与转换的统一修改器。效果演示、实现原理和使用说明都在下文，下载地址在文末。
作者声明：本文应该是迄今为止，国内和国外互联网第一个，公开的，PC平台以及Switch平台在不修改游戏任何源文件（如PC端Linkdata.bin，Switch端RomFS等）情况下实现无双大蛇2U和无双大蛇3U的，武器攻击范围扩大的非mod成果。本文主旨在于技术分享和探讨，请勿引战。
PC版：
无双大蛇3U效果演示：
无双大蛇2U效果演示：
Switch版：
无双大蛇3U效果演示：
无双大蛇2U效果演示：
【前言：一个想把旧体验带回来的故事】
Up主最早在《无双大蛇Z》中迷上了修改武器攻击范围后“一扫一大片”的感觉。很爽，对当时忙于学习、没有太多时间玩游戏的我来说，这是一种提高效率、减少重复刷关的办法。
时隔十几年后，接触了《无双大蛇2》和《无双大蛇3》，直接修改伸长已经无法重现这种效果。《无双大蛇3》原版曾有某大神在3DM论坛或者游侠网论坛有发贴做出过突破方案（原帖已不可考，此贴亦是本文的灵感和技术来源，再次感谢这位大佬），可到了3U后，旧CT因为地址偏移失效；自此之后3U也一直没有新的同类修改（或只是被一些up作为私人财产，不愿发布），且Linkdata等资源修改器的发布也迟迟不见踪影，使得以前通过修改人物动作模组的修改方式也无法达成。
Up主并不懂逆向，这个项目的工作流程其实很简单，只是在游戏中尝试，然后把自己的判断告诉ChatGPT/Codex：如武器数值应该可以修改，真正的限制可能是在游戏运行时加上的。于是我负责打开游戏、按照指示操作CE并反馈现象，它负责分析代码和制作脚本。
我先从3U开始。成功的将武器属性上限修改到128（具体技术细节请参考下文），我又尝试了映射到更高的999和65535，现在的CT中已经整合了这个功能；这个从无双大蛇3留下的愿望终于在无双大蛇3U实现了。
本来事情到这里已经结束，我又想试一下2U。
2U比预想中更曲折。2U武器范围修改做出来以后，火、冰、雷的攻击特效又让因为命中目标的大幅增加和高等级的属性特效导致画面不断白闪。我试过降低等级、限制状态和拦截特效，最后才发现，真正的问题是大量敌人同时触发了不安全的元素视觉。
最终测试时，已验证看到攻击完整扫过远处敌人，画面不再发白，元素效果也仍然存在。
这是另一种游戏的方式，修改以后游戏也不再是原来的游戏，但我相信这样的CT并不会让那些自己辛辛苦苦，夜以继日打出来的玩家的努力变得没有价值，也不是为了取代原版平衡，而是增加了一种可能性，我想要把这种可能分享给同样需要它的人。
我认为最好的状态是：
你可以知道这种方法而不去用，
但不能没有这样的方法。
最后，淘宝贩子你能不能别整合我的CT？
如果你只想使用工具，可以直接看文末的“工具与使用”和下载部分；如果也好奇这些效果为什么不能只靠改大一个数值实现，下面就是我们的研究过程。
————————————————
【下篇：研究正文】
下面的技术部分由AI根据我们的实验过程和代码记录整理撰写，主要是给有兴趣研究的人提供一些基础信息，文字比较生硬，也不算好读。看不懂不是你的问题，不影响使用工具，直接跳到后面的使用说明和下载部分就好。技术描述也可能存在疏漏，欢迎指出，具体仍以代码和实际验证结果为准。
一次攻击如何命中远处的敌人
——《无双大蛇2 Ultimate》《无双大蛇3 Ultimate》的伸长机制、三维命中链与Switch ARM64移植研究
【摘要】
在《无双大蛇》系列中，玩家通常把“伸长”理解成一个可以直接增大的武器属性。然而在《无双大蛇2 Ultimate》和《无双大蛇3 Ultimate》中，把武器记录中的伸长等级改到127、255，甚至在界面外构造更大的数值，都不必然带来相应的攻击范围。本文以两款游戏的PC版和Nintendo Switch版为对象，追踪从武器存储、运行时属性查询、倍率公式、目标候选预筛选、精确碰撞、招式扫描到元素视觉表现的完整链路。
研究发现，两代游戏呈现相似现象，却采用了不同的限制机制。3U的主要瓶颈是分布在武器构建、复制、比较、读取和显示等多条路径中的20级运行时软上限；解除这些上限后，可以把raw127所代表的第128档映射为999或更高的32位运行值。2U没有同样的一组统一软上限，其攻击范围由伸长有效等级、0.05倍率公式、约1200单位的候选距离，以及至少四类命中路径共同决定。只修改其中任何一层，都会造成“数值已经很大，但部分人物、招式或斜坡仍然无效”的现象。
在解决范围以后，超大规模命中又暴露出元素视觉密集触发导致的白屏问题。本文进一步证明，元素的战斗效果与视觉选择可以分离：将成功选中的表现固定为安全类型4，可以保留冻结、雷击、灼烧和伤害，同时消除白闪。上述机制随后在Switch ARM64构建中重新定位。移植过程同时揭示了动态NRO签名、平台保留寄存器、运行时装备索引和存档序列化之间的差异。
研究将攻击范围拆成了数据、公式、候选、碰撞和表现几个环节。稳定修改需要逐层定位限制，记录验证结果，并为每一处改动保留恢复方法。
【关键词】
无双大蛇；伸长；攻击范围；Cheat Engine；ARM64；Atmosphère；碰撞检测；运行时映射；Nintendo Switch
————————————————
【一、问题从一个看似简单的矛盾开始】
这项研究最初并没有宏大的目标。问题只是：既然武器属性在内存里确实可以改大，为什么游戏中的实际效果仍然像20级或10级？
在3U中，Cheat Engine能够读到高于正常面板上限的原始值，游戏却仍按20级表现。我们据此推测，武器记录中的数值在进入战斗计算时又被限制了一次，也就是运行时的“软上限”。
追踪很快指向WO4U.dll中反复出现的0x13。游戏采用零基准等级，0x13对应面板20级。这一常量被编译进武器构建、记录复制、属性比较、战斗读取和菜单显示等多条路径，导致改大的原始值在后续环节中反复被压回20。
3U的成功很容易诱导出第二个假设：2U大概也只是藏着另一组类似上限。后来的研究恰恰证明，这个推断是错的。2U呈现出几乎相同的表面现象，却没有采用同一套内部机制。正是这次反证，把项目从“寻找一个上限”推进成了对完整攻击管线的研究。
本文的核心问题因此变为：一个已经写进武器的高等级属性，究竟要经过哪些环节，才能变成对远处敌人的一次真实命中？
————————————————
【二、研究对象与方法】
PC部分使用《无双大蛇3 Ultimate》Steam 1.0.0.9和《无双大蛇2 Ultimate》Steam 1.0.0.1。前者主要分析WO4U.dll，后者分析WO3U.exe。Switch部分使用3U 1.0.13和2U中文版1.0.2，并分别绑定准确Title ID、Build ID和模块哈希。
研究采用静态与动态相结合的方法。静态分析用于确认结构字段、调用图、立即数和分支关系；动态实验则由作者在游戏中控制变量，逐步改变等级、系数、人物、队伍位置、地形和招式，再把现象反馈给Codex完成下一轮定位和脚本实现。
验证分为三步：写入前核对目标版本的原始指令；写入后逐字节回读，并确认能够完整恢复；最后在游戏中设计对照实验，检查实际结果。例如，把同一个人物从队伍1号位换到2号位，可以区分“队伍位置识别错误”和“人物招式走了另一条碰撞路径”；把映射值从999降到20而白屏仍存在，则可以排除“贴图只是按999倍放大”的解释。CE中的红叉只能说明脚本已启用，后续检查仍需逐项完成。
研究过程中也保留了失败样本。未完成跳转、模拟器与实机差异、错误资源类型和错误结构推断并没有被从记录中删除，因为这些失败同样构成对机制的证据。
————————————————
【三、3U：从20级软上限到999运行时等级】
3U的武器等级以有符号Byte保存，并采用零基准语义。原始0x00对应等级1，0x13对应等级20，0x7F对应等级128。如果继续写入0x80，0F BE一类有符号扩展会把它解释成－128。因此，在不改变存档结构的前提下，0x7F是原始字段中最安全的正数上限。
一开始，我们只改了一处0x13。结果有时战斗像是生效了，菜单却仍显示20；有时进入合成或复制界面以后，数值又被压回去。继续追踪才发现，编译器把同一个上限散布到了多条相互独立的路径中。最终稳定CT使用30组AOB特征定位50处立即数，并在写入前逐项assert原码。只有这些构建、复制、比较、读取、应用和显示路径一起由0x13提高到0x7F，第128档才成为一个在整个游戏流程中一致存在的等级。
要从128进一步提高到999，需要避开Byte的容量限制。我们选择游戏已经完成“raw＋1”的位置，此时等级位于eax、ebx或edi等32位寄存器中。脚本在7条转换路径中执行同一个条件：如果转换后的等级等于0x80，就用一个4 Bytes配置值替换；否则保持原等级。配置默认999，也可以由玩家改成其他数值。
这一设计使保存值和战斗值彻底分离。武器和存档仍然只保存raw127，运行时才把第128档解释为999。低等级武器不会被改变，没有装备的属性也不会凭空出现。它同时解释了为什么第二步必须依赖第一步：如果0x13软上限仍在，程序根本走不到“等级等于128”的映射入口，CT便会通过assert拒绝启用。
研究随后遇到斩属性的例外。通用映射已经把上游等级送到999，斩的实际效果却仍然像10级。追踪表明，斩在完成普通斩或复合斩的原版计算以后，还会在WO4U.dll＋0x18070F接受最后一次10级封顶。到达该点时，ESI＝0x12标识斩，EBX已经保存包括复合属性折半在内的最终计算结果。修复只让斩绕过最后的max 10选择，让EBX继续进入后续流程。这样既取消上限，又保留了原版纯斩与复合斩之间的公式关系。
3U的结果厘清了面板值、原始值和战斗值之间的关系：它们分别受不同环节控制，修改时需要沿数据流检查每一处约束。
————————————————
【四、2U：相似现象背后的另一套机制】
把3U的经验带到2U以后，我们最先寻找的也是统一软上限，但没有发现同样的一组0x13或10级路径。2U的武器原始等级是无符号Byte，本身可以保存到255。面板仍常显示10，却不能据此断定战斗值被统一封顶。
武器记录提供了第一条线索。其＋0x08是武器代码，＋0x0A是属性槽数，＋0x0B是附加攻击，＋0x0C至＋0x13保存8个属性ID，＋0x14至＋0x1B保存8个原始等级，＋0x1C是相性。伸长的记录ID为0x06，但战斗系统查询它时使用内部效果ID 0x17。
通用属性查询函数位于RVA 0x241230，返回端为0x241354。函数在EBX中累计有效等级，再以mov eax,ebx返回。2U的运行时映射因此采用以下条件：EBX为0时返回0；EBX非零时返回配置值，默认为999。映射仅作用于武器上已有的属性。
即便如此，伸长仍没有达到预期。继续追踪效果0x17的调用者以后，原公式被还原为：
最终伸长倍率＝1＋运行时伸长等级×0.05
这个发现解释了为什么同样的等级在两代游戏中表现不同，也给出了比“所有属性9999”更干净的方案：把伸长系数独立暴露成Float配置。玩家可以让伸长使用很高的系数，而火、冰、雷、斩等属性仍维持较低运行等级。
但实验再次出现矛盾。只把公式放大，画面和理论攻击形状已经很夸张，远处敌人却仍然没有稳定受击。我们由此意识到，公式决定的只是攻击体“可以有多大”，并不决定哪些敌人会被送进碰撞检测。
真正的第二道门位于候选预筛选。PC 1.0.0.1在RVA 0xD3D20计算攻击者与目标三轴坐标差的绝对值之和，并与1200.0比较：
候选距离＝｜ΔX｜＋｜ΔY｜＋｜ΔZ｜
超过1200的对象会在精确碰撞以前被排除。因此只改伸长公式，就像把一张网做得很大，却仍只允许1200以内的对象走进撒网区域。
脚本按攻击来源结构中的玩家标记分流：玩家攻击跳过1200距离淘汰，敌人和AI友军保留原比较。生命、阵营、重复命中与后续精确碰撞检查照常执行，因此扩大的是玩家攻击可检测的候选集合；最终命中仍由后续流程决定。
逐层测试很好地展示了这三层之间的关系：只改系数，距离不明显；临时把攻击尺寸固定到约9倍，仍不明显；加入玩家1200绕过后，攻击立刻变远；恢复真实伸长系数1.0并保留1200绕过，范围仍然存在。2U由此推翻了最初的“另一组统一软上限”假设，并建立了“有效等级—公式—候选集合”的三层模型。
但这个模型很快又被新的反例推翻了一部分。
————————————————
【五、从一维伸长到三维命中：斜坡与人物差异迫使模型升级】
1200绕过以后，马超的攻击已经能打得很远。然而作者在斜坡上发现，范围内实际受击的人明显减少；切换到马岱或辉夜姬以后，某些招式又像完全没有生效。最初这很像伸长存在冷却，或者只有第一下读取了高等级。连续监听却表明，玩家标记和伸长倍率都持续存在，所谓“冷却”更可能是不同move进入了不同的碰撞路径。
我们先尝试同时放大攻击包围盒的X、Y、Z跨度，结果伸长整体失效，下游精确相交算法拒绝了改变后的形状。这让我们注意到，候选包围盒、精确几何相交和接触点输出各有用途，需要分别处理。
研究方向于是从“扩大形状”转为“观察失败发生在哪里”。在PC版中，马超等通用招式会经过RVA 0xD4927的公共精确相交返回点。到达这里以前，游戏已经完成阵营、生命、攻击槽和重复命中过滤。对玩家攻击而言，如果自然相交失败，脚本把已经构造的目标世界坐标写入接触输出，再把结果提升为成功；自然成功和非玩家失败都保持原状。马超实测不但打得更远，斜坡上的命中也恢复完整。
继续追踪发现，外层扫描还会检查精确相交之后的返回结果。RVA 0xD4A95保存命中分发的结果码，部分招式返回2至4时，外层会在0xD4A9D提前结束本轮扫描。玩家路径把这些“提前结束”结果改成继续扫描以后，“范围内只打到一小部分人”的现象得到解释。
辉夜姬仍然是例外。六路计数器显示，她的招式通过D6000和D73E0登记0x1F0字节攻击体，再由A4E40消费，完全绕开前两条补点。她的精确相交判断位于0xA5E1E。一次纯监听中，17315次玩家判断只有107次自然相交，17208次以形状不相交结束。直接内存实验在确认玩家来源以后，把已构造的目标碰撞体中心复制到接触输出，再提升失败结果。作者随即确认辉夜姬攻击距离明显变长。
PC端至此已经找到三类路径：通用精确相交、扫描控制和登记攻击体。后来的Switch移植又暴露了一条遗漏的分支。
在Switch 2U实机实验中，马超和司马昭有效，王元姬与辉夜姬无效。把司马昭从队伍1号换到2号后，超长效果也随他移到了新位置。这排除了“脚本只识别第一名操作角色”的解释。无断点路径计数随后发现，辉夜姬一套攻击在main＋0xBF2F4命中4869次，而前三类候选路径均为0。该点位于另一条主相交调用的结果归一化处。
第四条补点仍遵循同一原则：自然成功不动；没有攻击来源不动；非玩家失败不动；只有玩家精确相交失败时，才把已经存在的16字节目标形状复制到接触输出并返回成功。补丁不包含人物ID表。作者先确认辉夜姬“拉长了”，又确认王元姬也拉长。至此，早期的“三路径完整”被修正为“四路径完整”。
到这里，攻击范围的轮廓逐渐清楚：候选生成、不同攻击体系统、精确相交、接触点构造和扫描控制共同决定了一次攻击能命中谁。人物之间的效果差异，恰好帮助我们找出了隐藏的处理分支。
————————————————
【六、范围成功以后，为什么画面开始发白】
当一次攻击能够命中远处大量敌人以后，另一个问题迅速出现：火、冰、雷等属性会让画面不断白闪。最直观的解释是，999或9999把元素贴图放大了。但两个实验否定了这个判断。
第一，把运行时映射从9999降到20，伸长范围随之缩小，白屏却仍存在。第二，把火、冰、雷的等级单独压到1，白屏仍没有消失。继续追踪后发现，基础元素的一条上层路径本来就会把等级钳到10；因此映射20和999在视觉入口前都可能已经变成10。
接下来要检查的是单次命中数量，以及每个目标使用的视觉表现。PC 2U的元素选择函数位于RVA 0x1AE50。它依次检查五种基础元素，把有效类型放进临时列表，再随机选择一个表现；没有元素时返回－1。高伸长让不安全表现编号在极短时间内被创建数百次，最终造成白闪。
修复放在视觉选择完成之后：成功选出表现时，把返回类型固定为实测安全的4；无元素时仍返回－1。测试中攻击范围完整，白屏消失，冻结、雷击、灼烧和元素伤害也得以保留。
这个结果说明，元素状态、伤害与视觉资源可以分别控制。范围扩大后，视觉调用量也会随之增加，因此表现层的稳定性成为修改方案的一部分。
————————————————
【七、从x86-64到ARM64：在Switch上重新定位与验证】
PC机制验证完成以后，项目转向Switch。移植的第一条原则是：可以移植问题和语义，不能移植RVA、AOB或机器码。
Switch 3U的main是GaiaLauncher_JP.nss启动器，Ultimate内容由它动态加载Gaia_JP.nro。武器访问、炼成、斩和奖励逻辑都位于Gaia中，因此需要先找到这个模块，再定位PC版对应的功能；单独分析main或subsdk0无法覆盖这些逻辑。
Gaia_JP.nro的武器记录与PC语义相近：记录大小0x24，十个属性ID位于＋0x05至＋0x0E，十个有符号raw位于＋0x0F至＋0x18。核心条件映射在Gaia_JP＋0x177890重新实现：raw127时返回999，其他raw逐条复现原版负值处理、20级封顶和加一逻辑。
最初的LayeredFS方案在Citron中可以工作，却在真实Switch启动时报错。问题出在加载校验：GaiaLauncher_JP.nrr保存了允许加载的NRO哈希，并带有RSA-PSS签名。修改NRO以后，更新哈希表可以通过模拟器的加载检查，却无法重新生成零售机信任的签名。纯IPS自安装也受到动态NRO页权限限制。最终采用Atmosphère dmnt，在Gaia已经映射以后进行运行时安装。
启动器的main＋0x3AF80保存Gaia模块记录。由该记录减去映像大小0x1D2A000，可以得到本次会话的Gaia基址。旧安装器还依赖main＋0x3AF68指向的源NRO缓冲区；Citron保留它，真实Switch却可能已经释放，导致“模拟器全部有效，实机完全没作用”。最终v3只检查已映射Gaia中的不可变指令，并把16个钩子拆成四段一次性安装器，再用金手指菜单直接控制功能。
这套v3包括原生炼成编辑、当前武器十属性、当前马匹、raw127→999、斩上限解除、有名武将奖励和宝箱奖励。用户在真实Switch上确认整套方案可以工作，验证覆盖了动态模块发现、身份核对、分段安装和菜单状态控制这一整套流程。
Switch 2U则是另一种情形。战斗主体直接位于静态main NSO中，因此不需要动态NRO安装链。但日版1.0.0和中文版1.0.2虽然Title ID相同，Build ID、模块哈希和指令布局都不同。所有机制仍需在中文版ARM64中重新定位。
在中文版1.0.2中，伸长最终等效系数位于main＋0x262F6C。原流程读取0.01并在后续乘5，形成0.05；补丁改为读取同页已有的0.2，后续乘法不变，最终得到1.0。1200候选比较位于0xF5F94，前三条命中路径位于0xF83C4、0xF8450和0xC4570，第四条位于0xBF2F4。全属性非零→999的统一返回点位于0x262950。元素表现则不能只改选择器：日用v8.5保留0x1350C的原版选择逻辑，在最终视觉层处理不安全表现，并对特定逻辑效果使用仅作用于渲染的保护，使表现层处理不替代元素状态判定。
这些地址与PC毫无数值上的对应关系，但它们在调用关系、寄存器语义和实验结果上重现了同一个分层模型。跨架构移植因此成为对PC结论的一次独立验证。
————————————————
【八、从崩溃定位运行时与存档数据的边界】
这项研究中最有价值的几个结论，恰恰来自“看起来已经成功”的版本为什么会崩溃。
PC三维补丁的第一版在CE分配失败以后，红叉没有出现，却已经向两个入口写入了指向0和0x60的未完成跳转。游戏能够恢复，是因为及时根据原始指令窗口逐字节写回。此后所有高风险补丁都改成事务式安装：先核对原码，写完并回读代码洞，最后才发布入口；关闭时先恢复入口，再释放跳板。
一次同时监听五个高频碰撞点的Frida实验触发0xC0000409，导致WO3U.exe退出。考虑到这些热路径每帧会被调用数万次，后续诊断改用极小的原生计数钩子，减少插桩负担。
Switch批量武器功能则暴露了平台ABI问题。早期ARM64核心把表地址放进x18，返回游戏前没有恢复。Citron可能暂时容忍，真实Horizon环境却可能依赖这个平台保留寄存器，结果是执行当下正常，进入复杂菜单以后才崩。
修复x18以后，问题仍然存在。进一步追踪发现，每名武将的16槽武器库存之外，还保存了一个当前装备槽索引。旧核心清空5至15槽，却没有把仍指向这些槽的索引同步回0至4，所以人物在战场中还能活动，一打开武器页解析空记录就退出。这个时点恰好成为定位根因的证据。
另一次错误来自算术推断：角色步长0x6C0除以对象步长0x40等于27，我们一度将后11组布局相似的对象也视为持久武器槽。实测失败后撤回了这一判断。后续只保留具有序列化和访问链证据的前16槽；后11组对象的用途仍需单独确认，单凭结构容量无法判定其库存语义。
最终，全武将五武器功能从运行时金手指中拆出，改成离线SVDT注入器。Switch 2U存档中的武器表位于文件偏移0xC800C，共145名武将、每人16槽、每条0x1C字节。运行时的装备索引并不序列化进SVDT，加载完成后游戏会在main＋0x2844C0原生清零。因此离线工具只需修改武器记录正文，不必伪造会话索引，也不会继承运行时的悬空引用。
工具分工也随之明确：CT或金手指处理战斗中的范围与属性规则，离线编辑器处理需要长期保存的武器配置。离线核心后来整合成统一GUI，支持逐把编辑，以及按选定武将和范围批量处理。2U支持自定义全145人五武器模板；3U使用独立的武器表，为177名有效武将匹配秘武、真武和金色特典。
同一个程序还提供跨平台转换。2U处理PC与Switch的存档布局差异；3U的PC存档包含两个独立AES-128-CBC区块，需要分别验证、解密并重组正文，反向转换时再重新封装。输出后重新读取并验证目标结构，转换始终另存新文件。支持范围限定为同一款游戏的PC↔Switch迁移，2U与3U各自处理。不同DLC组合和具体进度仍需在目标游戏中验证。
这些经历让验证流程更具体了：模拟器测试之后安排实机回归，内存结构通过序列化与访问链确认用途，脚本启用后继续核对每个入口和代码洞。每个阶段都有自己的检查项。
————————————————
【九、统一模型：一次远距离命中要通过七层】
结合两代PC版和两个Switch构建，可以把最终模型写成一条顺序管线。
第一层是原始武器数据。它决定武器拥有哪些属性，以及raw值是多少。3U的raw是有符号Byte，2U是无符号Byte。
第二层是界面与构建路径。菜单、复制、合成和商店可能使用与战斗不同的限制。3U必须同步修改多条0x13路径，才能避免数据在不同页面之间再次被压回20。
第三层是运行时有效等级。3U把第128档条件映射为32位值；2U把通用查询的所有非零结果映射为配置值。这里解决“战斗公式实际收到了多少”。
第四层是属性专用公式。伸长把等级转换成空间倍率，斩则在自己的函数末尾还有10级封顶。通用映射不会自动消除这些独立规则。
第五层是目标候选集合。2U的约1200距离会在精确检测以前排除远处对象。候选之外的敌人，攻击体再大也没有意义。
第六层是招式与碰撞路径。通用攻击体、扫描结果码、登记攻击体和主相交路径必须分别覆盖。斜坡和人物差异正是在这一层出现。
第七层是表现。大量真实命中会增加视觉系统的调用次数；元素安全类型负责调整表现资源，伤害与状态继续沿原流程计算。
沿着这七层检查，就能逐步解释前面的异常现象：当高数值没有产生预期效果时，先追踪它在哪个后续环节被限制，再决定修改位置。
————————————————
【十、讨论：这些修改真正改变了什么】
1200预筛选、扫描提前结束和不同攻击体路径，反映了性能、碰撞精度与招式系统之间的工程取舍。候选筛选减少了昂贵的精确相交计算，不同招式也可以使用各自适合的攻击体实现。玩家观察到的范围边界，正是这些规则叠加后的结果。
数值提高到65535以后，各系统仍有各自的约束：神速受动作上限影响，元素可能引发密集视觉效果，斩有独立封顶，尚未加载的敌人也无法命中。为了兼顾范围和游玩稳定性，功能需要分开控制：伸长使用独立系数，其他属性保持较低等级；保留元素战斗效果，单独处理视觉选择；扩大玩家路径，同时让敌人保留原规则。
Switch版采用不同的ARM64地址和指令，我们仍在对应的数据流环节中找到了有效等级、倍率、候选、碰撞和表现层。这为PC上的分层解释提供了跨架构证据，也明确了移植时的工作顺序：先追踪功能和数据流，再重新定位地址与指令。
本文也存在边界。第一，超大范围只能作用于游戏已经生成并保持活动的单位，不能命中尚未加载的敌人。第二，不同版本必须重新验证Build ID和原始指令。第三，Switch 3U菜单控制v3已经得到真实Switch确认，而Switch 2U当前四路径日用整合版仍应区分Citron验证与最终实机回归。第四，本文没有对所有武将、所有move建立形式化覆盖证明；第四路径正是因为反例人物才被发现，未来仍应允许新的反例修正模型。
————————————————
【十一、结论】
本文从“为什么把伸长改大仍然没有效果”这一问题出发，最终得到三个主要结论。
第一，3U和2U的表面现象相似，底层机制不同。3U的主要问题是运行时软上限和属性专用封顶；2U则是有效等级、倍率公式、候选距离和多类命中路径共同作用。
第二，一次远距离命中需要经过多层处理。原始数据、运行时等级、公式、候选、精确碰撞、扫描控制和视觉表现都需要覆盖，人物、招式与地形也应纳入测试。
第三，修改器的可靠性依赖可复现、可验证、可恢复的流程。PC端需要唯一AOB、完整原码assert和事务式代码洞；Switch端需要严格绑定Title ID与Build ID，重新定位ARM64语义，并分别通过离线审计、模拟器和真实硬件验证。
研究从找回《无双大蛇Z》中“一扫一大片”的体验开始，逐步整理出两代游戏如何把武器属性转化为真实命中的过程。修改器让这份体验可以分享，机制记录则为后续研究留下了可继续追踪的线索。
————————————————
【附录A：准确目标身份】
PC 3U：
《无双大蛇3 Ultimate》Steam 1.0.0.9
进程：WO4.exe
主要模块：WO4U.dll
PC 2U：
《无双大蛇2 Ultimate》Steam 1.0.0.1
进程／模块：WO3U.exe
Switch 3U：
版本：1.0.13
Title ID：0100E8500AD58000
main完整Build ID：07650FD5E5E2B82C91CF789148D8AEE3312CC3DE
Atmosphère Build ID：07650FD5E5E2B82C
Gaia_JP模块ID：D12CECBB191318C870F1F1B589DD35DD674F7A70
Gaia_JP原文件SHA256：976D5DA96E139B98792393DCDA71868D213635604323B222330331672ACF8EE6
Switch 2U中文版：
版本：1.0.2
Title ID：0100153006300000
完整Build ID：C632B6C8CD8250B1A172748943CE50B7
Atmosphère Build ID：C632B6C8CD8250B1
模块：OR2U_NX_md.nss
原NSO SHA256：B33405A9F9C3A8BC78C95F7E3DE422817DCC6F3D47E5D1E0E173046C3334496C
————————————————
【附录B：主要定位点】
PC 3U：
属性软上限：30组AOB、50处0x13→0x7F
raw127条件映射：7条转换路径
斩最终封顶函数：WO4U.dll＋0x180590
斩补丁点：WO4U.dll＋0x18070F
通用／专属素材账本：RVA 0x29BEB0
直接素材入库：RVA 0x213460
宝箱update调用：RVA 0x6D2104
宝箱奖励函数：RVA 0x6D24B0
PC 2U：
通用属性查询：RVA 0x241230
通用返回端：RVA 0x241354
伸长调用：RVA 0x2F8B1
伸长乘法：RVA 0x2F8DA
1200常量：RVA 0xAE0744
1200比较：RVA 0xD3D20
通用相交补点：RVA 0xD4927
扫描结果补点：RVA 0xD4A95
登记攻击体补点：RVA 0xA5E1E
元素选择函数：RVA 0x1AE50
元素安全返回点：RVA 0x1AF02
当前装备武器安全捕获：RVA 0x32ADD6
Switch 3U：
Gaia模块记录：main＋0x3AF80
Gaia基址：qword(main＋0x3AF80)－0x1D2A000
武器属性访问器：Gaia_JP＋0x1776C0
raw条件映射入口：Gaia_JP＋0x177890
代码洞：Gaia_JP＋0xE698B0起
斩最终封顶：Gaia_JP＋0xB88C8
有名武将奖励：Gaia_JP＋0x2A35D0
宝箱结算调用：Gaia_JP＋0x70C17C
宝箱原生结算：Gaia_JP＋0x70C1A0
Switch 2U中文版1.0.2：
伸长系数读取：main＋0x262F6C
1200候选比较：main＋0xF5F94
通用相交：main＋0xF83C4
扫描继续：main＋0xF8450
登记攻击体：main＋0xC4570
第四主相交：main＋0xBF2F4
全属性有效等级返回：main＋0x262950
元素选择器：main＋0x1350C（日用v8.5保留原版；安全处理位于最终视觉层）
当前武器页面捕获：main＋0x341EA4
前三路径代码洞：main＋0x6C9580..0x6C962F
全属性映射洞：main＋0x6C9630..0x6C9643
六槽道具洞：main＋0x6C9650..0x6C9743
第四路径代码洞：main＋0x6C9780..0x6C97A7
————————————————
【附录C：第四路径核心伪代码】
原位置：Switch 2U main＋0xBF2F4
原指令：and w8,w0,#0xff
and w8,w0,#0xff
cbnz w8,done
cbz x24,done
ldrb w9,[x24,#0x138]
and w9,w9,#3
cbz w9,done
ldp x9,x10,[x29,#-0xF0]
stp x9,x10,[x29,#-0x100]
mov w8,#1
done:
返回main＋0xBF2F8
其语义是：自然命中保持；敌方失败保持；只有玩家自然相交失败时，补齐接触输出并返回成功。
————————————————
【附录D：复现与移植检查表】
复现PC CT时，应先取得准确版本的运行时模块转储；确认AOB唯一；记录完整原指令窗口；验证活跃寄存器语义；先安装并回读代码洞，最后发布入口；关闭时先恢复入口，再释放代码洞。不要在仍有红叉时直接关闭CE。
复现Switch补丁时，应先登记Title ID、完整Build ID、Atmosphère BID、区域和更新版本；对用户自己的NSO／NRO记录模块ID、段表和SHA256；禁止照搬PC或其他Switch版本的偏移；每个ARM64钩点必须核对原始4字节指令；所有分支必须落在完整指令边界；模块未加载、指针为空或身份不符时必须零写入；Citron通过以后仍需真实Switch回归。
建议的最小范围测试集包括：一名通用路径角色、一名曾走遗漏路径的角色、平地、斜坡、普攻、多个C技、登记攻击体类招式，以及有元素和无元素两类武器。
————————————————
【工具与使用：把研究结果变成自己的玩法】
一、PC版CE表：修改正在运行的游戏
两作各有一份综合CT。2U面向Steam 1.0.0.1，包含武器编辑、运行时属性映射、独立伸长系数、1200候选限制绕过、三维／不同招式路径扩展和元素视觉安全处理，并整合装备属性保持、资源和角色等日用功能。3U面向Steam 1.0.0.9，包含武器属性突破20、可调高等级映射、斩有效等级上限解除，以及永恒模式素材和宝箱奖励扩展。具体开关、依赖关系和实验性条目请按CT中的说明使用。
二、Switch金手指：在指定构建上控制运行时效果
2U金手指适用于中文版1.0.2，功能按菜单编号说明如下。
01｜玩家超远伸长与三维命中扩展：把伸长等效系数从0.05提高到1.0，绕过玩家攻击的1200候选距离筛选，并覆盖已定位的四类命中路径。作用同时涵盖X、Y、Z方向，改善斜坡和不同招式的命中差异，包含辉夜姬、王元姬曾经遗漏的路径。当前武器必须带有非零等级的伸长；范围只作用于已经生成并保持活动的敌人。
02｜元素防白屏：处理大范围攻击时容易遮住镜头的炎、冰、雷复杂附着特效，保留元素伤害和冻结、雷击、灼烧等状态。适合与01一起开启。画面中的部分复杂特效会减少，元素的战斗判定仍沿原流程执行。不要与旧版元素补丁叠加；切换版本或执行关闭项后，建议完整重启游戏，清理已经生成的旧特效。
03｜武器属性运行时强化：武器已有的非零属性按999级送入计算，神速单独使用300；等级为零或未装备的属性保持原状。原始武器记录与面板数字可能保持不变，各属性后续的公式和动作规则也仍会影响最终效果。配合01使用时，先给武器装上伸长。
04｜玩家骑马加速与转向增强：目标效果为直线移动速度2倍、普通转向速度10倍，仅针对玩家坐骑。此项仍需单独核验：旧版曾存在骑手指针识别错误，v8.6已有修正候选，实机效果仍待确认。请按包内版本说明使用，暂不将它列为已验证稳定功能。
05｜经验值卷轴Buff效果常驻：持续维持经验值卷轴的掉落增益状态及其计时器，让战斗中原本会结束的卷轴效果持续生效。需要刷经验时开启，停用时执行对应DISABLE；角色的具体等级与累计经验仍按游戏原有流程增长。
06｜全武将友好度拉满：一次性将145名武将之间的友好度写为999。启用INSTALL后，进入阵地／宴席等会读取友好度的页面触发写入；完成后执行DISABLE HOOK恢复读取函数。该项会改变可保存的数据，关闭钩子不会还原原来的友好度，务必先备份存档。
开关用法：ENABLE用于启用，DISABLE用于恢复对应钩子的原指令。同一功能的两项不要同时勾选；停止周期写入与恢复原指令是两个步骤，请按包内README操作。全武将五武器生成、道具解锁等持久数据编辑交给统一存档修改器处理。
3U面向1.0.13，包含原生炼成编辑、当前武器十属性、当前马匹、raw127→999、斩上限解除，以及武将和宝箱奖励。需按README在本次启动后执行分段安装，再使用金手指菜单控制功能。两作都必须核对Title ID与Build ID，不能只凭游戏名称选文件。
三、统一存档修改器：编辑、批量配装与跨平台转换，一次完成
这是一个在Windows上运行的EXE，同时识别2U／3U的PC和Switch存档，不需要另找一个转换器。可以在GUI中修改单把武器的属性与等级，也可以选择任意武将、武器范围批量处理。附加攻击及相性／上手度等参数可按界面支持的范围自定义，并不要求使用固定满值模板。
2U提供自定义全武将五武器模板和58种道具处理；五把武器的属性、等级也由用户指定。3U提供按人物匹配的秘武、真武和金色特典武器方案。
攻击力需要区分成长和固定底数：面板“60＋19”的前后两段由不同字段控制。工具编辑可保存的成长与附加攻击；武器主表的固定基础攻击另行处理，不能直接当作单把武器的存档字段。v2.1的2U毕业相性为179200，3U五星上手度为44800。填写数值时，还应分别确认字段容量和游戏原生满值。
同一修改器内置PC↔Switch转换：2U对应SAVEDATA.BIN与SVDT，3U对应SAVEDATAU.BIN与SVDTU。支持上述目标版本；未知格式不会按猜测强行写入，转换输出保留输入原档。
配武器、批量生成武器或转移存档，使用统一修改器即可。超远攻击、运行时高等级或斩上限解除，需要另行开启对应平台的CT／金手指；这些运行时规则在离线修改存档后仍会保留。
使用前请关闭游戏并完整备份存档，先处理副本，再通过自己的存档管理工具导回。统一修改器位于Switch整合包的“PC存档修改器”目录，程序在电脑上运行，同时支持PC和Switch存档。具体验证范围、已知问题与操作顺序，以包内README为准。
【下载】
PC端：无双大蛇2U／3U CE整合包
链接: https://pan.baidu.com/s/14HBkAkLC7N7DlTnNs0d_rw?pwd=w3e6 提取码: w3e6
Switch金手指＋统一存档修改器（内置PC↔Switch转换，Windows EXE）
链接: https://pan.baidu.com/s/1n31Xrsp0eUmW-RxOHlvEZg?pwd=a6kp 提取码: a6kp
本项目新增的分析脚本、补丁、金手指和存档工具代码由ChatGPT／Codex生成并迭代；我负责需求与思路、游戏操作和实机测试、反馈现象、整理发布。整合的第三方功能归原作者，不属于本项目AI生成代码。
分享包不提供游戏本体、DLC、密钥或个人存档，只提供修改工具、金手指、代码与研究资料。
本文中的修改只面向单机研究与娱乐，请勿用于联网或影响其他玩家。
