Anti-cheating project

[zinco 0]

I only say crc because that is what is currently being used. I have heard that md5 will take much longer and more cpu to check them but then the program i use to check md5 returns results faster than crc.......at least locally. i would be more than happy to help with a project that uses md5. I will collect both. I need help collecting the international versions.

[Lobanak 0]

Here are some infos about CRC and md5sum I found in the net:

Quote[/b] ]

CRC32 is designed to detect transmission errors. It is a 32-bit checksum.

MD5 is used to detect document modifications. It is a 128-bit checksum.

The odds that two documents (such as the original one and the fraudulently

modified one) will have the same CRC32 is 1 in 2^32, or roughly 1 in 4

billion. If you are using a CRC32 and do not understand the math, you can

simply make your modification, then try 4 billion different documents

(cycling an unused 4-byte block, for example), and you will probably find

one that has the same CRC32 as your original document. You can do better if

you understand the math.

If you are using an MD5 and make a modification and you don't understand the

math, you will need to try at most 2^128, or 2^127 on average, different

documents before you find another that has the same MD5. This is a

prohibitive amount of time. Despite a recent posting to RISKS to the

contrary, doing a search of 2^127 different keys is beyond current

computational resources, and likely to remain so for the forseeable future.

(That is, at least a million years.) Of course, you could do better if you

understood the math, but right now nobody does.

Link: http://cert.uni-stuttgart.de/archive/forensics/2003/01/msg00014.html

answer:

Quote[/b] ]

A CRC check is a very simple check originally designed to check

the transmission of bit-serial data in an environment where there

is a risk of noise affecting the data. The characteristics of

such noise is that it tends to be "bursty", affecting short

sequences of bits. A CRC check can be implemented cheaply in

hardware when the data is in bit-serial form using "xor" gates

and an n-bit shift register; in this case a 32-bit shift register.

Given a bit sequence that has been changed it is sufficient to

change no more than 32 bits elsewhere to compensate and get the

shift register back into the state it would have had without

the pair of corresponding changes. Given a disk image where

there is likely to be a fair amount of "slack space" finding

a location to form the "compensating" change is not difficult.

Given that no more than 32 bits need to be changed, that the

computations are fairly simple, and that the "slack space" is

likely to be fairly close to the data that is changed and you

have a situation where it is fairly easy to patch a disc image

protected only be CRC32.

So, a CRC does what it's designed to do well; but it's only designed

to check for *accidental* changes to the data. It *is* practical

to intentionally modify data protected by a CRC.

A cryptographically strong hash functioin like the one used in MD5

is far harder to "crack". I can't really comment on just *how*

much harder it is because I'm not an expert but all the advice

is that it's very much stronger. The hash function is harder to

compute (and hence takes more time); the hash value generated is

longer so more trials have to be made in a "brute force" attack.

We wouldn't use MD5 in password files if it was easy to crack;

we wouldn't use CRC32 is password files if we were sane!

Link: http://cert.uni-stuttgart.de/archive/forensics/2003/01/msg00017.html

Greets

[CiA]Lobanak

[zinco 0]

So the next question is......is it possible for us to use a program external to the server but running on the server to check and compare the md5 values of clients.

Also i am not sure how this works....when crc checks a client file is it checking the exact file in the ofp directory or is it cached somewhere on the client side?

 

if i have a

ofp/res/addons/g36a.pbo  and a

ofp/mods/addons/g36a.pbo  and this one is modified and i use a shortcut to use both folders and i file check the standard one which one will the game use.

in other words file check doesn't generate a message because i am only checking res/addons and it is not modified but the game uses the modified one.  is this possible?

[Certa 0]

Quote[/b] ]CRC check is a bad checksum. You should collect md5sum of all files.

CRC are not bad but this case we should use MD5.

Compare

25e60a0b25c3bbe1e1cc9f955e588588

and

25e60a0b25c3bbe1e1cc9f955e585588

or compare

e372a75f

with

e372a75f

Using the eye...

Use MD5 (or even better SHA1 or others) for encryption or when document verification must be accurate. Actually, In a commercial product I wrote, the user had the option of byte to byte comparison for 100% accuracy in case MD5 would fail (there are some known flaws with MD5 and only the future can tell if there are more). It was a server product for extremely large file servers and an invalid checksum match could be fatal for the company running the server. In the case, a byte to byte compare wasn't a big investment or processing loss.

In the case of OFP it's all about a couple of thousand files in total. A wrongly matching checksum could in worst case...ruin a players evening?... The risk of having two files with the same name and same checksum but different contents is still negligible (especially if you check file size too) unless it's trojan hacked to match.

Continue to use CRC32 if you like it for manual compare. Use MD5/SHA when doing machine comparison, the stakes are high or when the base is tens of thousands of files. For an anti-cheat server/client use MD5 or SHA to make trojan hacks harder.

Put the two different checksums into a context, they are used differently.

[Lobanak 0]

So the next question is......is it possible for us to use a program external to the server but running on the server to check and compare the md5 values of clients.

That's the thing I wanna do with the anti-cheating project and the tools. But not found enough coders to do this.

Greets

[CiA]Lobanak

[benu 1]

Quote[/b] ]CRC check is a bad checksum. You should collect md5sum of all files.

CRC are not bad but this case we should use MD5.

As was written above crc IS bad, as a checksum. It is good for finding transmission errors. I found an article describing how to get 2 different files two have the same crc sum. So it is not the case of "trying 4 billion documents" anymore but more if you want them to have the same crc or not. The only similar thing i know about md5 is that is possible to get 2 files to have similar starts and endings. This could fool users who look at the start and end only (i happen to do that myself sometimes ) but not machines comparing those values.

An interesting question is how to check how the game was started. Especially command line options like -mod....

[bn880 5]

I just wanted to drop in and say, I would have offered to assist in any way possible to write some applications for this project, but I don't have the time or money (same difference) to dedicate to it. (it would take a while just to get started...)

I do believe a project like this is a worthwile venture.

[Certa 0]

Quote[/b] ]An interesting question is how to check how the game was started. Especially command line options like -mod....

Use the anti-cheat client to start OFP. Better control over parameters.

But I see some big trouble identifying the actual files used. An encrypted data stream or cheaters with machine language hacking skills are not the weak links. The weak link is to identify the actual files being used.

The cheater could always connect to the server with a different process and directory tree since it's possible to run ofp twice on a machine.

That means the client must monitor all processes and be able to identify ofp processes.

The cheater could then instead use two computers on his LAN to fool the client.

The client must make sure the monitored ofp process is the one actually connected to the server and not just a dummy. Here it's getting tricky. Perhaps by checking the dynamically open UDP-ports and comparing to what the server side see from the IP (not very reliable).

etc..

[Lobanak 0]

The client locks the files, checks them with md5sum, start ofp and only ofp executable is able to read the files

You start the client and ofp with 'client ofp.exe -mod=... ...'. So the client handles the start of ofp.

If you wanna connect to a server, the client connects to the server, tells the checksums and when all is ok, server opens slot for connection, else no slot opened. Also client itself is checked with md5sum to see if it is modified. If yes, no slot opened.

So all files only checked once at OFP start and not every time you connect to a server (only the checkfile system do this). You also cannot overwrite a file, cause locked.

The ideas for the tools have most things in, so I think nothing is missing.

Greets

[CiA]Lobanak

[Scope-SWAF- 0]

Sounds very very good Lobanak

[zinco 0]

i am not a coder but i will help if i can.

[zinco 0]

It would be nice to know what bis's plans are for ofp2 in this regard. and to know what kinda changes are in 1.92.

[Certa 0]

Quote[/b] ]The client locks the files, checks them with md5sum, start ofp and only ofp executable is able to read the files

It's impossible to only allow certain processes reading the files. This can be achieved in some extents on NT based systems by degrading the potential cheater to user and taking over his computer (a bit extreme). The issue is having a legal dummy copy of OFP on the harddrive letting the client examine that while playing using another copy on the same harddrive or using a second computer.

Quote[/b] ]when all is ok, server opens slot for connection, else no slot opened.

I don't see how this is done either unless you get BIS to add new code or you prefilter UDP packets by IP. But this is not the issue either since the checksums are going to check out fine when using two ofp folders.

It's like installing an iron door when the window is still made of fragile glass. The problems remain. Not trying to ruin your idea but truying to make it solid. It's damn hard if not impossible.

[zinco 0]

It would be nice if bis would add some code in a patch so that it would be much easier for something to be implemented. if we (mouse in my pocket...u guys) were specific about what we needed maybe it wouldn't be a big deal for them to do it. just something to make it easier on us but would not cost them any resources.

[zinco 0]

1.92 - Fixed: Event handler "init" is now launched on all machines in MP game

Will this help the cause any?

[lilleblol 0]

Hehehe seems like help is difficult to find. I am no great programmer but yesterday i made a simple ammo trainer cheat detection script. It detects launch of law, at4, aa, carl and 93kl. It is not so robust now and have some bugs that make it detect cheating when a teammate is close to the rocket or the rocket pass close by.