Getting A Very Exciting News——成功破解Weapon.pdx文件

visionoflove

这个Weapon文件也是加密比较复杂，用了多种加密方式

第1-2行应该是涉及到2个加密方式,应该都是ASCII加减法

第1行
P00001 2
加密
L,,,,-{.

原理ASCII减4
空格={
0=,
1=-
2=.
3=/
4=0
5=1
6=2
7=3
8=4
9=5
P=L

第2行
3 1
加密
*v(

原理ASCII减9
原始=加密
=v
0='
1=(
2=)
3=*
4=+
5=,
6=-
7=.
8=/
9=0

第7-8行加密方法和第1-2行一样

第9行P00002 3 1
N....0}1}/

原理ASCII减2
0='
1=(
2=)
3=*
4=+
5=,
6=-
7=.
8=/
9=0

是的,兵棋兵种一直在更新,这个weapon文件应该是每个版本新增的兵种的加密方式就会改一改，但是我在想，难道efedit和East Front程序对每一种加密方式都是自动解密成符合解密文件的数据形式，还是说是一遍一遍硬算出的，又或者程序员直接设置每个P0序列号所对应的加解密方式？

您问的问题非常核心，也非常有洞察力。在游戏开发中，尤其像您提到的兵棋游戏，随着版本的更新和新内容的加入，加密方式确实可能会进行调整。

关于 EFEdit 和 East Front 这类程序如何处理多种加密方式，最主要且效率最高的可能性是：

程序员直接设置每个P0序列号所对应的加解密方式。
这在游戏开发中是最常见的做法。开发者会在游戏程序（或其相关工具如 EFEdit）内部硬编码（Hardcode）或者配置（Configure）一个映射表或逻辑树。当程序读取 weapon 文件或其他数据时，它会首先解析 P0 序列号（例如 P00005、P00007、P00857 等），然后根据这个序列号去查找对应的解密算法、偏移量、密钥或特定的处理函数。 [1, 3]

具体机制可能包括：

条件语句： if P0 == "P00005" then use Algorithm_A; else if P0 == "P00007" then use Algorithm_B; 这种最直接的方式。

查找表：程序内部有一个数据结构（比如数组或哈希表），键是 P0 序列号，值是对应的解密函数指针或加密参数。

版本控制： P0 序列号的一部分可能直接代表了文件版本，而每个版本都有其固定的加密策略。 [1]

为什么采用这种方式？

效率高：程序无需“猜测”加密方式，直接根据ID调用已知解密逻辑。

可控性强：开发者可以精确地为每个数据块或版本选择最合适的加密方法。

增加逆向工程难度：如果只有少数几个规则，破解者很快就能发现。但如果规则多样且分散在代码中，甚至与数据ID关联，那么要完全解密所有数据就需要更多的工作量。

从游戏程序运行的角度来看，解密是“自动”的。
一旦上述映射关系建立，当游戏加载数据时，它并不会“一遍一遍硬算”来猜测加密方式，而是根据预设的逻辑“自动”地选择并执行正确的解密步骤。比如，它读到P00005，就“知道”接下来要用“数字按位置减去不同值，空格映射|”的规则来解密，对玩家和程序本身而言，这个过程是无缝且自动的。 [1, 2]

“一遍一遍硬算出的”这个说法，更适用于逆向工程和破解者。
游戏开发者绝不会让游戏程序在运行时去“硬算”或“暴力破解”自己的加密数据。这会导致极高的性能开销，是不可行的。
您所观察到的各种复杂的加密模式和不规则的偏移量，正是游戏开发者为了阻止或延缓外部逆向工程师（例如MOD制作者或作弊者）通过“一遍一遍硬算”（即尝试各种可能的加密算法、偏移量、密钥等）来解密文件而设计的。逆向工程师往往需要通过静态分析（查看代码、数据结构）和动态调试（运行程序并观察其内存、寄存器变化）来推导出这些加密规则。 [3, 4]

总结：

游戏程序和 EFEdit 这样的工具最可能是通过程序员预先设置的P0序列号与解密规则的映射表来实现对不同加密兵种数据的自动解密的。这种设计既保证了数据处理的效率，又增加了外部人员破解的复杂性。您的观察——“P00序列号与加密方式之间的关联”——正是这种内部映射机制的体现。

我想了一下，也许这个加密解密是按照行数来定的也可能啊，一共11672行，还好吧，303701个字符

您的观察非常有价值。如果文件总共有 11,672 行、303,701 个字符，并且您怀疑加密方式与行号有关，那么这可能意味着程序在读取数据时会根据行号来选择不同的加密或解密策略。

可能的加密策略
按行号选择加密方式：

行号映射：程序可能会根据行号（例如，第 1 行使用加密方式 A，第 2 行使用加密方式 B）来选择不同的加密算法。

行号模运算：例如，程序可能会使用 line_number % N 的结果来决定使用哪种加密方式。

行号影响加密参数：

偏移量或密钥变化：程序可能会根据行号来调整加密算法的参数，例如改变偏移量或密钥。

加密模式切换：例如，前 1000 行使用一种加密方式，接下来的 1000 行使用另一种，依此类推。

如何验证这一点
您可以尝试以下方法来验证加密是否与行号有关：

选择特定行进行分析：从文件中提取特定的行（例如，第 1 行、第 1000 行、第 2000 行等），并观察它们的加密方式是否一致。

编写脚本进行批量分析：使用 Python 等编程语言编写脚本，自动读取文件的每一行，分析其加密方式，并记录结果。

如果您能提供文件的部分内容或更详细的信息，我可以帮助您进一步分析加密方式。

visionoflove

以下是修改WEAPON的具体表格，可以修改武器数据。可以修改具体兵种的攻击力了。

记得weapon.pdt文件只对JTCS uninviewer生效，weapon.pdx用我的表格WEAPON最终对比分析打开，找到对应的行进行修改。

我只破解了EF的武器库，WF和RS的武器库原理都是一样的，都是通过空格加密成固定值，其他字符每一行进行ASCII加减法。