查找使用了哪个校验和

发布于 2024-12-02 15:02:57 字数 3369 浏览 4 评论 0原文

我们正在与其他一些人一起尝试为游戏制作一个保存游戏编辑器，但我们遇到了一些问题。保存游戏文件包含一种校验和，我们似乎无法找到用于此目的的校验和。到目前为止我们所知道的是：

校验和是 32 位
在 9 个不同的保存游戏之间，除了 5 个字节（分布在文件中）之外，保存游戏数据完全相同，校验和被发现在 1834565 - 1851372 之间，当解析为 unsinged long 时。请注意，每次保存这 5 个字节都会增加一个数字（主要是 +8 左右），但校验和不会线性增加。
校验和似乎与位置相关，因为当切换 2 个字节时游戏会声明文件已损坏
我尝试了一些校验和，得出的结论是它似乎不是 Sum32、addler32、DJB2 和 CRC32，因为它们都不是似乎接近保存游戏中包含的校验和。似乎与保存游戏中包含的校验和最接近的校验和似乎只是将所有字节添加到无符号长整型中，它返回约 2507737 左右的值。

我想知道是否有更好的方法来查找这些文件使用了哪个校验和，或者是否有人知道任何提示来找出使用了哪个校验和。我目前只是尝试在 C++ 程序的不同站点上找到的一些校验和。也许还需要知道的是，该游戏是 2004 年的，在其他文件中它使用 DJB2 进行字符串哈希。根据其他人的说法，.exe 似乎正在使用 CRC32 检查。

编辑1：一段时间后，我设法获得了同一文件的 924 个不同版本，除了每次保存时有 2 个字节不同之外，我还获得了这些文件的校验和，以了解它对这些更改的反应，我列了一个关于这个的清单。，我无法手动更改文件，游戏只是为其生成校验和，每次保存文件时，它都会向包含变化数字的无符号长整型添加 +2，这就是我创建列表的方式。）

（请注意下面列表的一部分（924 条记录中的 50 条）：

>         The bytes         Checksum (as Hex and unsigned long)
>         -----------------------------
>         0x 0 0x18 0x 0    0x13DFA 81402
>         0x 0 0x19 0x 0    0x13F76 81782
>         0x 0 0x1A 0x 0    0x1406D 82029
>         0x 0 0x1B 0x 0    0x14114 82196
>         0x 0 0x1C 0x 0    0x13EC5 81605
>         0x 0 0x1D 0x 0    0x13790 79760
>         0x 0 0x1E 0x 0    0x143C1 82881
>         0x 0 0x1F 0x 0    0x13ED0 81616
>         0x 2 0x18 0x 0    0x13D02 81154
>         0x 2 0x19 0x 0    0x13ABD 80573
>         0x 2 0x1A 0x 0    0x14271 82545
>         0x 2 0x1B 0x 0    0x13E39 81465
>         0x 2 0x1C 0x 0    0x140FC 82172
>         0x 2 0x1D 0x 0    0x13FFE 81918
>         0x 2 0x1E 0x 0    0x1413B 82235
>         0x 2 0x1F 0x 0    0x13A5F 80479
>         0x 4 0x18 0x 0    0x138F2 80114
>         0x 4 0x19 0x 0    0x141AE 82350
>         0x 4 0x1A 0x 0    0x13E91 81553
>         0x 4 0x1B 0x 0    0x13F67 81767
>         0x 4 0x1C 0x 0    0x13C6C 81004
>         0x 4 0x1D 0x 0    0x13F4E 81742
>         0x 4 0x1E 0x 0    0x13BB8 80824
>         0x 4 0x1F 0x 0    0x1398D 80269
>         0x 6 0x18 0x 0    0x146C0 83648
>         0x 6 0x19 0x 0    0x139B5 80309
>         0x 6 0x1A 0x 0    0x13FAC 81836
>         0x 6 0x1B 0x 0    0x13E71 81521
>         0x 6 0x1C 0x 0    0x14162 82274
>         0x 6 0x1D 0x 0    0x13D55 81237
>         0x 6 0x1E 0x 0    0x13BE8 80872
>         0x 6 0x1F 0x 0    0x13B72 80754
>         0x 8 0x18 0x 0    0x142FE 82686
>         0x 8 0x19 0x 0    0x13E07 81415
>         0x 8 0x1A 0x 0    0x14923 84259
>         0x 8 0x1C 0x 0    0x13D3E 81214
>         0x 8 0x1D 0x 0    0x14420 82976
>         0x 8 0x1E 0x 0    0x13BEE 80878
>         0x 8 0x1F 0x 0    0x145F5 83445
>         0x 8 0x1F 0x 0    0x145F5 83445
>         0x A 0x18 0x 0    0x13CB6 81078
>         0x A 0x19 0x 0    0x142FB 82683
>         0x A 0x1A 0x 0    0x13EB2 81586
>         0x A 0x1B 0x 0    0x13C14 80916
>         0x A 0x1C 0x 0    0x13915 80149
>         0x A 0x1D 0x 0    0x14100 82176
>         0x A 0x1E 0x 0    0x14310 82704
>         0x A 0x1F 0x 0    0x13B34 80692
>         0x C 0x18 0x 0    0x142AE 82606
>         0x C 0x19 0x 0    0x14091 82065

我仍然看不到这些不同字节和校验和之间的模式，所以我想知道其他人是否可能看到这些之间的模式？或者也许是一种如何找到它们之间模式的技术。如果有人可以帮助我解决这个问题，我还可以发布完整列表的链接（Microsoft Excel 或 TXT 格式）

原文

Together with some other people we are trying to make a Savegameeditor for a game, but we came accross some problems.
The savegame files contain a kind of checksum,of which we can't seem to find which checksum is used for this. Till now all we know is:

The checksum is 32 bit
Between 9 different saved games, where the savegame data is exactly the same except for 5 bytes (which are spread accross the file), the checksum has been found to be between 1834565 - 1851372, when parsed as an unsinged long. Note that each save those 5 bytes each save are an increased number (mostly by around +8), but the checksum isn't lineair increased.
The checksum seems to position dependent, as the game declares the file as corrupt when 2 bytes are switched
I tried some checksums, and came to the conclusion that it didn't seem to be Sum32, addler32, DJB2 and CRC32, cause none of them seemed to come close to the checksums included in the savegames. It seems to be that the checksum which comes the closest to the checksum included in the savegames seems to be just adding all bytes to an unsigned long, which returns a value around ~2507737.

I was wondering if there is a better way to find which checksum is used for these files, or if someone knows any tips to find out which checksum is used. I'm currently just trying some checksums which I found on different sites in a C++ program. Maybe also important to know is that the game is from 2004, and in other files it used DJB2 for string-hashes. According to other people the .exe seems to be using a CRC32 check.

Edit 1: After some time I managed to get 924 different versions of the same file, except 2 bytes which vary each save, and I also got the checksums of these files to see how it reacted on those changes, and I made a list about this. (Note that I cannot manually make changes to the file and the game just makes a checksum for it, every time I saved the file it added +2 to the unsigned long containing the varying number, so that's how I created the list.)

See a part of the list below here (50 records out of 924):

>         The bytes         Checksum (as Hex and unsigned long)
>         -----------------------------
>         0x 0 0x18 0x 0    0x13DFA 81402
>         0x 0 0x19 0x 0    0x13F76 81782
>         0x 0 0x1A 0x 0    0x1406D 82029
>         0x 0 0x1B 0x 0    0x14114 82196
>         0x 0 0x1C 0x 0    0x13EC5 81605
>         0x 0 0x1D 0x 0    0x13790 79760
>         0x 0 0x1E 0x 0    0x143C1 82881
>         0x 0 0x1F 0x 0    0x13ED0 81616
>         0x 2 0x18 0x 0    0x13D02 81154
>         0x 2 0x19 0x 0    0x13ABD 80573
>         0x 2 0x1A 0x 0    0x14271 82545
>         0x 2 0x1B 0x 0    0x13E39 81465
>         0x 2 0x1C 0x 0    0x140FC 82172
>         0x 2 0x1D 0x 0    0x13FFE 81918
>         0x 2 0x1E 0x 0    0x1413B 82235
>         0x 2 0x1F 0x 0    0x13A5F 80479
>         0x 4 0x18 0x 0    0x138F2 80114
>         0x 4 0x19 0x 0    0x141AE 82350
>         0x 4 0x1A 0x 0    0x13E91 81553
>         0x 4 0x1B 0x 0    0x13F67 81767
>         0x 4 0x1C 0x 0    0x13C6C 81004
>         0x 4 0x1D 0x 0    0x13F4E 81742
>         0x 4 0x1E 0x 0    0x13BB8 80824
>         0x 4 0x1F 0x 0    0x1398D 80269
>         0x 6 0x18 0x 0    0x146C0 83648
>         0x 6 0x19 0x 0    0x139B5 80309
>         0x 6 0x1A 0x 0    0x13FAC 81836
>         0x 6 0x1B 0x 0    0x13E71 81521
>         0x 6 0x1C 0x 0    0x14162 82274
>         0x 6 0x1D 0x 0    0x13D55 81237
>         0x 6 0x1E 0x 0    0x13BE8 80872
>         0x 6 0x1F 0x 0    0x13B72 80754
>         0x 8 0x18 0x 0    0x142FE 82686
>         0x 8 0x19 0x 0    0x13E07 81415
>         0x 8 0x1A 0x 0    0x14923 84259
>         0x 8 0x1C 0x 0    0x13D3E 81214
>         0x 8 0x1D 0x 0    0x14420 82976
>         0x 8 0x1E 0x 0    0x13BEE 80878
>         0x 8 0x1F 0x 0    0x145F5 83445
>         0x 8 0x1F 0x 0    0x145F5 83445
>         0x A 0x18 0x 0    0x13CB6 81078
>         0x A 0x19 0x 0    0x142FB 82683
>         0x A 0x1A 0x 0    0x13EB2 81586
>         0x A 0x1B 0x 0    0x13C14 80916
>         0x A 0x1C 0x 0    0x13915 80149
>         0x A 0x1D 0x 0    0x14100 82176
>         0x A 0x1E 0x 0    0x14310 82704
>         0x A 0x1F 0x 0    0x13B34 80692
>         0x C 0x18 0x 0    0x142AE 82606
>         0x C 0x19 0x 0    0x14091 82065

I still cannot see a pattern between those varying bytes, and the checksum, so I was wondering if someone else maybe sees a pattern between those? Or maybe a technique of how to find patterns between them. If someone can help me out of this, I can also post a link to the full list (as Microsoft Excel or TXT format)

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

惟欲睡 2024-12-09 15:02:57

事实上，最简单的方法可能是使用 OllyDbg 之类的调试器，找到校验和代码，然后反向-设计它。并不是说这容易，因为它可能会相当困难。但在我看来，仅仅通过查看数字来逆向工程即使是简单的校验和也几乎是不可能的，除非你有一个高功能的自闭症朋友，具有超人的观察模式的能力——也许即使如此。

当然，您可能很幸运拥有一款使用标准的、众所周知的校验和来检测损坏的游戏。但如果他们的目标是防止篡改（这很有可能），那么如果他们有任何线索，他们就不会使用标准校验和。

这是我自娱自乐的来自crackme的校验和算法：

checksum Algorithm

我当然不可能猜到这段代码通过查看其输出：

uint sum = 0;
for (uint i = 0; i < 478; i++)
    sum = rol((((buf[i + 22] | 0xFFFFFF00u) + i) ^ (478 - i)) - sum + 0x272E4745u, 3);

此代码中有一个单独的校验和算法，该算法使用符号扩展，而不用 或 0xFFFFFF00 完全消除它 - 您会在搜索中考虑这样的操作吗？搜索空间太大了，无法猜测......

The easiest way may, indeed, be to grab a debugger like OllyDbg, locate the checksumming code, and reverse-engineer it. Not to say that it's easy, because it is probably going to be rather hard. But in my opinion reverse-engineering even simple checksums just by looking at the numbers is bordering on impossibility, unless you have a high-functioning autist friend with superhuman abilities to see patterns – perhaps not even then.

You may of course be lucky to have a game which uses a standard, well-known checksum, to detect corruption. But if their goal was to prevent tampering (and that's fairly likely) then they wouldn't have used a standard checksum if they have any clue.

Here's a checksum algorithm from a crackme I'm entertaining myself with:

checksum algorithm

I certainly couldn't have guessed this code just by looking at its outputs:

uint sum = 0;
for (uint i = 0; i < 478; i++)
    sum = rol((((buf[i + 22] | 0xFFFFFF00u) + i) ^ (478 - i)) - sum + 0x272E4745u, 3);

There is a separate checksum algorithm in this code which uses sign-extension without completely obliterating it with an or 0xFFFFFF00 - would you have considered such an operation in your search? The search space is just too huge to guess it...

回复收藏 0 原文

~没有更多了~