查找使用哪個Checksum

與其他人一起，我們正在嘗試爲遊戲製作Savegameeditor，但我們遇到了一些問題。遊戲存檔文件包含一種校驗和，我們似乎無法找到哪個校驗和用於此目的。到目前爲止我們所知道的是：查找使用哪個Checksum

校驗和是32位
之間的9個不同的保存的遊戲，在遊戲存檔數據是，除了5個字節（它們分佈翻過文件），校驗一模一樣已被發現介於1834565 - 1851372之間，當被解析爲一個未知的長。請注意，每個保存的這5個字節保存的是一個增加的數字（大部分大約是+8），但校驗和不是lineair增加的。
校驗和似乎取決於位置，因爲當2字節切換時遊戲聲明文件已損壞
我嘗試了一些校驗和，得出結論認爲它似乎不是Sum32，addler32，DJB2和CRC32，因爲他們沒有一個似乎接近存儲遊戲中包含的校驗和。它似乎是最接近存儲遊戲中包含的校驗和的校驗和似乎只是將所有字節添加到無符號長整數，這會返回一個約爲2507737的值。

我想知道是否有更好的方法來找到哪些校驗和用於這些文件，或者如果有人知道任何提示找出使用哪個校驗和。我目前只是嘗試在C++程序中的不同站點上找到一些校驗和。也許很重要的一點是，遊戲是從2004年開始的，而在其他文件中，它使用DJB2作爲字符串哈希。根據其他人的.exe似乎使用CRC32檢查。

編輯1：一段時間後，我設法得到924個不同版本的同一個文件中，除了2個字節改變各保存，我也得到了這些文件的校驗和來看看它的變化是如何反應的，我就此列出了一份清單。（請注意，我無法手動對文件進行更改，遊戲只是爲它創建一個校驗和，每次我保存文件時，它都將+2添加到包含不同數字的無符號長整數中，這就是我創建列表的方式。）

見下這裏列表的一部分（50條記錄出的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

我仍然無法看到這些變化的字節，校驗和之間的模式，所以我在想，如果別人可能認爲這些之間的模式？或者可能是一種如何在它們之間找到模式的技術。如果有人可以幫我解決這個問題，我還可以發佈一個鏈接到完整列表（如Microsoft Excel或TXT格式）

來源

2011-09-04 LeopardGL

然後，也許它是一個真正的校驗和模數，起始值爲〜2507737 :-)嘗試交換對齊爲2的2,4,8字節的塊， 4和8字節邊界。 – xanatos

感謝您的回答，我試着交換更大的塊，不幸的是我仍然得到了聲明文件損壞的遊戲的相同錯誤，所以我認爲現在確定校驗和似乎取決於位置。雖然，我發現一個文件中每個文件只有2個字節不同，並且文件稍小，所以我可能會從該文件中獲得更多信息，只要知道更多信息，我會立即通知它。 – LeopardGL

不要忘記，有[許多CRC變體]（http://en.wikipedia.org/wiki/CRC32#Commonly_used_and_standardized_CRCs）。此外，你應該寫出二進制或十六進制的校驗和，以使任何類型的按位運算變得明顯。 – phihag

最簡單的方法可能是抓住像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);

在這個代碼中有一個單獨的校驗和算法，它使用了符號擴展而沒有用or 0xFFFFFF00完全消除它 - 你是否在你的搜索中考慮過這樣的操作？搜索空間太大，無法猜測它...

來源

2011-09-08 11:58:32

感謝您的回答，我的評論很晚，但我花了相當一段時間。通過觀察彙編，我發現了一些規則，似乎表明在文件開始時刪除頭文件，並且文件末尾的校驗和也可以工作，而且確實如此。所以通過刪除標題和校驗和，我實際上繞過了查找校驗和算法的需要。每個人都非常感謝你！ – LeopardGL

@LeopardGL恭喜！ :) –

查找使用哪個Checksum

回答

相關問題