Anti-cheat idea...

[oldunis]

I've chearched the forum and found nothing about this:

Why couldn't the server md5 the client.... simple?.... or not ?

[tbot]

I've chearched the forum and found nothing about this:

Why couldn't the server md5 the client.... simple?.... or not ?

I wonder how you would do that...

I think sending the entire executable to the server just for creating a hash of it is going to create a incredibly lot of useless network traffic (apart from the fact the the 'sending' part could be cracked to send the original exe).

However, this post did make me think and the current protection can be made so much better just by letting the server send a random value which is padded to whatever needs to be CRC'ed. The value which is sent back will then also appear to be random, thus masquerading the way the hash was created.

[OpiuM.]

well, see the problem with that is, its a small file, also...

its a free mod....

so they could re-download it.

[oldunis]

well, since one of the cracked mta i've seen had the same size of the original one, i've thought that the guy who created that might have just changed 2-3 small variables.... so if the client hashes (that's the word i was searching for ) itselfs, it would be easier to know that it's cracked... no?

Hum opium, i don't get it... what would it change if they would re-download it?

Oh, and the digital signature of mtaclient.exe (md5) is 51 B9 31 2D AD 4A B5 9A 21 FD F1 B1 89 27 D0 55.... not a very long string to send

[orappa]

But couldn't they just crack the client and send the correct string to the server?

[tbot]

Oh, and the digital signature of mtaclient.exe (md5) is 51 B9 31 2D AD 4A B5 9A 21 FD F1 B1 89 27 D0 55.... not a very long string to send

In your first post you were talking about the 'server' hashing the client, which requires the server to have the executable (thus the client should sent itself over).

What you mention now is the client hashing itself and sending just the hash. This is about what the client does right now (it might not actually hash itself, it does hash the files which are modified when using mods). The problem with this method is that the code which generates the hash can be replaced with code which just returns the correct hash, no matter whether the file was modified.

In a worst-case scenario for the crackers they could always create a proxy which replaces the wrong hash with the correct one.

With the idea I posted however, there is no 'correct' hash, since it depends on the value the server sends. Therefore it's much harder to decode the hashing mechanism. Even when it fails it can be made more complex by, for example, making a handshake protocol with multiple hashes and multiple random values. Eventually the crackers won't be able to crack it (though it actually is possible, will always remains so, but there is a limit on things a human can achieve).

[oldunis]

But couldn't they just crack the client and send the correct string to the server?

Well, if it is cracked the client must have been modified. And the hash too...

In your first post you were talking about the 'server' hashing the client, which requires the server to have the executable (thus the client should sent itself over).

Well, i did wrongly explain myself

What you mention now is the client hashing itself and sending just the hash. This is about what the client does right now (it might not actually hash itself, it does hash the files which are modified when using mods). The problem with this method is that the code which generates the hash can be replaced with code which just returns the correct hash, no matter whether the file was modified.

But how will he do it...??? Is it possible to change it?

With the idea I posted however, there is no 'correct' hash, since it depends on the value the server sends. Therefore it's much harder to decode the hashing mechanism. Even when it fails it can be made more complex by, for example, making a handshake protocol with multiple hashes and multiple random values.

Hum, i don't get what your saying... For example, if you hash "test" with md5 (php...) it will generate the same thing on and on... this is what most of scripts uses to encrypt password...

[orappa]

Sorry, I didn't explain myself fully. I was saying that someone could hack the client, but still send the old string. tbot's idea is good though.

[tbot]

Hum, i don't get what your saying... For example, if you hash "test" with md5 (php...) it will generate the same thing on and on... this is what most of scripts uses to encrypt password...

Let me put it a little more clear.

When a client wants to connect it sends a signal to the server. When the server recieves that signal it sends a random number back (and remembers it).

The hash code that will be generated is not merely the hash code of the file, but augmented with the random number. So let's say the correct hash is the MD5 of the string "test", if you do nothing with it, it's static, and thus easy to crack.

Now we take the random number (e.g. 5325), and append it to the string that needs to be hashed, making "test5325", and hash that. You will find that the hash is totally different. The client sends the hash, and the server will know it's correct because it remembered the random number (and can create the correct itself the same way).

The next time someone connects the random number will be different, and so will the hash, creating a handshake which seems random.

[oldunis]

ooooh... i get it...

Well, it's a great idea... any mods or devs saw this?