1

I dont want to ask for help without showing how far I came by myself, so this is what I have so far:

The file of interest is an encrypted/obfuscated .bin script, which cotains information on certain weaponstats eg. damage or accuracy. It is part of an older computergame. The raw file containts only hexvalues, which I "converted" to their Characters using extended ASCII. The output wasnt satisfying at all, untill I found out, that it was obfuscated using single byte XOR. Since there are only 256 different possible ways I went manually through all of them and had success with Key 42. This is what the decrypted script looks like:

enter image description here

I made my own small Tool, which decrypts the file hex -> ascii -> xor decrypt and saves the changes with hex <- ascii <- xor encrypt. So right now I am able to manipulate some weaponstats and save the file into its previous format.

When I try to start the game with my manipulated file it appears a CRC checksum error and it wont start. I was aware about this and did some research already, the checksum used is definitely CRC32 and I found out, that you can force a files checksum to any value by appending 4 bytes, but it obviously wont work due to the file format:

enter image description here

The CRC32 checksum is now similar to the untouched file, but the game cant read it and doesnt start and this is where Im stuck.

So what to do now? In theory I should be able to make some changes with getting the same checksum using gaussian elimination, but I really need some help to point me into the right direction. It would be enough to change 1 hex-value as a first try and see what to change next to get the same CRC checksum. From there I could think about changing stuff, which makes sense in terms of manipulating weapons. So what if I change the very first hex-value in the file "16" to "17", what do I have to change next to get the old checksum back? Is that the right attemp? I am quiet new to all this, but I dont want to give up yet.

This folder contains the original file (items.bin) .txt to show in browser, an at 2 values maniuplated one and the plain text script. Original checksum is '3DD1ECB7'

Thanks in advance.

dontjudge
  • 11
  • 1
  • 4
  • Easiest would be to find where the original CRC is stored and modify that to match the new one. – Steve Peltz May 15 '15 at 19:03
  • That should be alot easier, but I got stuck there aswell. I actually found the file, which should store the filepaths along with their crc checksum, but they are encrypted/obfuscated and I couldnt manage to read it. I tried single byte XOR, but I doubt its only the 8 characters for the checksum. http://i03.imgup.net/helpp48c4.PNG

    I add the file to here: http://www.mc-rp.net/crc/crc/ Seems like I have 2 approaches now, but Im stuck on both of them. Maybe some of you have trained eyes and can guess what stands behind this just by taking a look. I cant think of how this should end in 3DD1ECB7.

     – dontjudge May 15 '15 at 23:05
  • 4
    I'm voting to close this question as off-topic because this is a perfect question... for the reverse engineering site. It doesn't involve cryptography (neither CRC nor encoding is encryption). – Maarten Bodewes May 16 '15 at 00:48
  • If the CRC values in the file are XORed with a constant value, it would be an example of why you don't ever re-use a random pad. Take the CRC of a couple files, XOR them with the bytes following or preceding the path, see if you get the same four-byte sequence. – Steve Peltz May 16 '15 at 07:49

2 Answers2

3

One fundamental property of CRCs is that if you exclusive-or in the bit representation of the polynomial (which, for standard CRC-32, would be 0x0104C11DB7) anywhere in the message, you don't modify the CRC.

So, the obvious thing for you to try is to exclusive-or that value (and similar, for example, the bit-reversed version of above) and see if that modified version has the same CRC.

Once you have verified the CRC polynomial (and the order in which bits are processed), then it is fairly straight-forward to perform arbitrary changes.

poncho
  • 147,019
  • 11
  • 229
  • 360
0

It's also possible to obtain an arbitrary CRC32 by overwriting four consecutive bytes of the file (at any location of your choice) with the appropriate values. This paper should have everything you need (see in particular the C code at the end).

fkraiem
  • 8,112
  • 2
  • 27
  • 38