Anti-Cheat proposal

Make suggestions for improving one of the best games on the net!
User avatar
FiringSquad
Sergeant
Sergeant
Posts: 847
Joined: Thu Jan 26, 2006 5:53 pm
Location: Ireland

Post by FiringSquad » Mon Sep 15, 2008 7:26 pm

JeffM wrote:what prevents a moded client from computing it's own validation value based off of faked info then just sending a CRC that works with the faked info at the end?
The same "validation value" that is used to encrypt the results for the binary code queries, is also used to tag messages to the server with a verifier. That's why both things are checked. Only a valid client can produce both valid encrypted results from the binary content queries and verifiably valid messages to the server that match a single key-value which is only posted at the end.

User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5187
Joined: Fri Dec 13, 2002 4:11 am
Location: https://github.com/OmniTanks
Contact:

Post by JeffM » Mon Sep 15, 2008 7:38 pm

what prevents a modded client from querying an unmodded client binary for it's validation value and using that for it's own messages? If the server is also using it's own copy of a valid binary file (from disk) to verify this key, then it should be simple to have the client do the same thing to extract the key from it's own valid binary.

What I don't get is how you can ensure that only a valid client can produce both? when it sounds like it's just information that can be read from a valid client. Are you not just testing to see that the Have a valid client on disk, not that they are using it?
ImageJeffM

User avatar
TheRisingSun
Private First Class
Private First Class
Posts: 12
Joined: Sat Jan 12, 2008 6:34 pm

I sure like it

Post by TheRisingSun » Mon Sep 15, 2008 7:45 pm

The Idea sounds very good in my opinion.
I read the whole thing and had to take a 10 minute break after to cool my brain down, but I understand the way u wanted to go.
Thats exactly what I mentioned the other day in a game, well close to that, cuz Iam not a programmer, but the Idea is the same.
But same as you I didn't keep the open source issue in mind.
Thats a big problem and it's therefore even more sad, that people abuse this "free" game to cheat on it.
What I just don't understand is, why can't the servers check the bzfiles and data you log in with and verify they are not modified in the "delicious" sections?
I see that people just have to remove or add lines to make a client work "different" .
So why can't we equip the servers with the ability to "verify" the non haxed client?
Or even a way the people may figure out, but think of that: The first time we set up a safe trap that we lay on the servers we would catch ALL the hacker and cheater when they log in the first time.
Because they wouldn't know, that the servers are equipped with a "detector".
After that they may change it, but we will have some more proof.
And if that proof matches the accusations, then thats an immediate 1 week ban to 1 year ban.
And because it wouldn't be a file to download and the server owners would implement it on the official servers, it is nothing more but a addon to the server function and shouldn't break a single rule.
To take FSs idea on again, whats wrong with adding the lines he mentioned in that open source style, so everybody can see and edit them, but.... ?!
...when people modify or delete them, wouldn't that be a proof for cheating already, when the server asks for those lines?
I cannot see why a "checkcode" like adobe or even CRC hurts a rule.

User avatar
joevano
General
General
Posts: 1863
Joined: Sat Jun 18, 2005 1:08 pm
Location: South Bend, Indiana, USA

Post by joevano » Mon Sep 15, 2008 8:04 pm

Because the modified client "knows" what an unmodified client looks like,the cheater modifies the "checkcode" routine to send a response back that says, basically, "I am unmodified". Cheater wins, coders waste their time.

All the code is open, so everyone can see anything (PS that is why it is called open-source). If you can see it, you can see exactly HOW it works, and then you can code something to return the "valid" responses. It just cannot be done the way it is proposed.
There is nothing worse than aggressive stupidity. -- Johann Wolfgang von Goethe
"How many legs does a dog have if you call his tail a leg? Four. Calling a tail a leg doesn't make it a leg." -- Abraham Lincoln

User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5187
Joined: Fri Dec 13, 2002 4:11 am
Location: https://github.com/OmniTanks
Contact:

Post by JeffM » Mon Sep 15, 2008 8:09 pm

TheRisingSun
because the internet does not allow for the server to look at files on the client's computer. To do that would require some program to be running on the cient computer to report back the info about the bzflag game. This "cheker" would have to send it's data over the intenet back to the game server.

There would be nothing preventing a cheater from replacing this checker with a modified version t hat simply reported that every client was "good" even if it had been modified.

The"Idea" always sounds good, but once you actually look at what you have to do to implement it,and what it really does, it quckly becomes appearant that it is not worth it.

Basically no mater what you do, anything send from the client computer can be modified, even on a clean bzflag client ( packet mod ). There are many tools out there to do this.

Applying CRCs to files on disk is very different from trying to verify if the thing that is generating network traffic has been "modded"
ImageJeffM

User avatar
FiringSquad
Sergeant
Sergeant
Posts: 847
Joined: Thu Jan 26, 2006 5:53 pm
Location: Ireland

Post by FiringSquad » Mon Sep 15, 2008 9:38 pm

There are ways around this. Like I said, it's not full-proof, just extremely difficult. Hopefully to the point that it becomes unfeasible.

I'll try to clarify by imagining a scenario as if I am the hacker.

First attempt:
I have a valid client running and also my cheat client:
My cheat client starts communicating with the server using a key I generate.
The server asks me to test my binary code and I send that query to the valid client.
I get a response from the client but I can't use it because it is encrypted with a key that I will not know until the client quits.
Ok. Tell the client to quit and read the key. Now decrypt the address and re-encrypt it using my key instead and send this to the server.
Continue sending messages.
Now after maybe 15 minutes I'm asked to verify my binary again with a different range.
If I restart the good client then it will use a different random key. I'm caught.

Second attempt:
Write a program to query a valid client and record the results.
When all valid queries are made make the client quit and decrypt the results.
But remember that ranges of binaries are tested. How can you anticipate what ranges might be asked.
If you try to record the results for every possible range then you would have to wait an extremely long time and your hard-disk would fill up before your analysis was complete.
Won't work.

Third attempt:
I load a valid client and then dump the completely loaded executable to a diskfile. A trivial task Note: This is not the same as an exe file.
Now I examine the file and locate the offsets for every exported function and match them up to their equivalent sourcecode. (An extremely difficult task, certainly involving several months of painstaking effort with every chance of making a mistake. If you think this is simple, then you have never examined binary on a large scale without a symbol table.)
Now I have an index into my memory dump.
Now I develop a cheat client. Relatively easy.
I handle code binary checks by performing the appropriate test on the memory dump using my indexes instead of the actual memory.
Assuming you have not made any mistakes generating your index, this method will work, but how can such effort be justified?
I don't believe anyone with the appropriate expertise would be so single-minded and if they are well I feel sorry for them.
Either way, it would have to be done all again when the next official build is released.

Fourth attempt:
IMO This is the one most likely to succeed.
You modify the binary of an official build to use a key you give it instead of generating its own.
You use this client to handle binary code checking and relay the results back to the server yourself in the knowledge that it is using the same key-code you are using to perform its checks.
So long as the modified portion of the binary is not tested you will not be caught, but if it is then you will be found out.
There are many ways to combat this but it does not make sense to get too deep into this if indeed restricting league users to a particular build (especially one without complete sources) goes against the license.

To show you what I meant by Binary check, here's some pseudocode:

Code: Select all


extern Function1(char *Str);
extern Function2(int *Num);
extern Function3(char *Str, int *Num);
...
extern FunctionXYZ(char *Str, int *Num);

uint64 PerformBinaryCheck(uint32 Func1, int32 Func1Offset, unit32 Func2, int32 Func2Offset)
{
	char *Ptr1;
	char *Ptr2;

	switch (Func1)
	{
		1: Ptr1 = (char *) Function1; break;
		2: Ptr1 = (char *) Function2; break;
		...
	}
	switch (Func2)		// Should not be done this way with repeated code. Maybe #define
	{
		1: Ptr2 = (char *) Function1; break;
		2: Ptr2 = (char *) Function2; break;
		...
	}

	Ptr1 += Func1Offset;
	Ptr2 += Func2Offset;

	return EncodedCRC(Ptr1, Ptr2);
}

User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5187
Joined: Fri Dec 13, 2002 4:11 am
Location: https://github.com/OmniTanks
Contact:

Post by JeffM » Mon Sep 15, 2008 9:41 pm

so the valid client has to be running?

how does the server verify that? is it running it's own client code as well to verify it? or can the keys be pulled from a binary file on the disk?
ImageJeffM

User avatar
FiringSquad
Sergeant
Sergeant
Posts: 847
Joined: Thu Jan 26, 2006 5:53 pm
Location: Ireland

Post by FiringSquad » Mon Sep 15, 2008 9:49 pm

donny_baker wrote:Because the modified client "knows" what an unmodified client looks like,the cheater modifies the "checkcode" routine to send a response back that says, basically, "I am unmodified". Cheater wins, coders waste their time.

All the code is open, so everyone can see anything (PS that is why it is called open-source). If you can see it, you can see exactly HOW it works, and then you can code something to return the "valid" responses. It just cannot be done the way it is proposed.
If you think it's that easy then you haven't been listening. It's one thing to examine source code. It's an entirely different thing to examine binaries. It would involve examining raw binary code that has been optimised by the compiler to such an extent that it bears little relation to the original source code.

OK, once you locate the code that performs the binary check, you will have some chance of calculating the function addresses, but before you dismiss this as a trivial exercise, you should try to do it.

I have done such things, examining raw binary and trying to reverse engineer it and it is a very difficult thing indeed.

User avatar
FiringSquad
Sergeant
Sergeant
Posts: 847
Joined: Thu Jan 26, 2006 5:53 pm
Location: Ireland

Post by FiringSquad » Mon Sep 15, 2008 9:59 pm

JeffM wrote:so the valid client has to be running?

how does the server verify that? is it running it's own client code as well to verify it? or can the keys be pulled from a binary file on the disk?
The server does not verify it. This will not allow a server to identify a cheat. It will provide a tool for an admin to verify a client after it was used.

The way I envisaged it being used is that the server would have a config file containing valid ranges to be queried. The server then uses this information to generate a query. It broadcasts this query to a client and records the response. It also records the validation value trailing each message from the client and the final sign-off that informs the server the key that was used.

If an admin gets an accusation about a player, then they can examine the replay to find out the appropriate client. An admin with this supported platform then runs the official version and checks if they give the same responses as the player under investigation.

If the results differ then the player is not using a supported client.

It will not be able to say that a thin client or whatever was used. Just that the build is not supported.

User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5187
Joined: Fri Dec 13, 2002 4:11 am
Location: https://github.com/OmniTanks
Contact:

Post by JeffM » Mon Sep 15, 2008 10:08 pm

how does the server get that config with valid ranges? what are the ranges?
ImageJeffM

User avatar
joevano
General
General
Posts: 1863
Joined: Sat Jun 18, 2005 1:08 pm
Location: South Bend, Indiana, USA

Post by joevano » Mon Sep 15, 2008 10:59 pm

FiringSquad wrote:
donny_baker wrote:Because the modified client "knows" what an unmodified client looks like,the cheater modifies the "checkcode" routine to send a response back that says, basically, "I am unmodified". Cheater wins, coders waste their time.

All the code is open, so everyone can see anything (PS that is why it is called open-source). If you can see it, you can see exactly HOW it works, and then you can code something to return the "valid" responses. It just cannot be done the way it is proposed.
If you think it's that easy then you haven't been listening. It's one thing to examine source code. It's an entirely different thing to examine binaries. It would involve examining raw binary code that has been optimised by the compiler to such an extent that it bears little relation to the original source code.

OK, once you locate the code that performs the binary check, you will have some chance of calculating the function addresses, but before you dismiss this as a trivial exercise, you should try to do it.

I have done such things, examining raw binary and trying to reverse engineer it and it is a very difficult thing indeed.
Sure I have, YOU have not been listening. The function you propose doesn't have to be reverse engineered, because the source code MUST be available for download. If the source code is available then the cheater has all he needs to send false responses. He can look at the raw binary of a valid client, and then figure out the response. Not distributing the source code violates the BZFlag license and therefore could not use BZFlag code.
There is nothing worse than aggressive stupidity. -- Johann Wolfgang von Goethe
"How many legs does a dog have if you call his tail a leg? Four. Calling a tail a leg doesn't make it a leg." -- Abraham Lincoln

User avatar
FiringSquad
Sergeant
Sergeant
Posts: 847
Joined: Thu Jan 26, 2006 5:53 pm
Location: Ireland

Post by FiringSquad » Mon Sep 15, 2008 11:30 pm

JeffM wrote:how does the server get that config with valid ranges? what are the ranges?
This is beginning to get a little technical given that it will not be implemented but...
The simplest method would involve asking the client (when run with the appropriate switch and passphrase) to output the routine numbers sorted according to their addresses. If the addresses follow their layout in the source, then any value in between is fair game.

Of course the code in between the routines will contain branch-islands and constant values, packing bytes etc., but these are locked in at compile time and will not alter between runtimes.

It is not necessary to create a complete valid set of ranges. Rather just enough so that it can not be predicted. It can begin with just one or two ranges and grow as results from different ranges can be shown to be consistent on the supported platforms (even though they do not agree with each other).

The compiler can also be used to assist in this endeavor by producing useful reports during linking, but this would differ depending upon compiler and would involve more specialist knowledge.

User avatar
FiringSquad
Sergeant
Sergeant
Posts: 847
Joined: Thu Jan 26, 2006 5:53 pm
Location: Ireland

Post by FiringSquad » Mon Sep 15, 2008 11:38 pm

donny_baker wrote:Not distributing the source code violates the BZFlag license and therefore could not use BZFlag code.
Like I said way back here
FiringSquad wrote:
JeffM wrote:1) we can not distribute closed source binaries, it's against the license.
That's enough for me. Not feasible then. :(
Since then I have agreed that it cannot be implemented.
donny_baker wrote:If the source code is available then the cheater has all he needs to send false responses. He can look at the raw binary of a valid client, and then figure out the response.
You obviously have never tried it before. Statements like that are like babies. They can be fun to make, but they're hell to deliver.
After optimisation the finished binary is very very different from the original source code.
Remember you will not have any symbol tables to work with, just references to anonymous routines, the majority of which are just shared pieces of compiled code.
Last edited by FiringSquad on Mon Sep 15, 2008 11:41 pm, edited 1 time in total.

User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5187
Joined: Fri Dec 13, 2002 4:11 am
Location: https://github.com/OmniTanks
Contact:

Post by JeffM » Mon Sep 15, 2008 11:41 pm

so you are talking about in memory(ram) ranges and looking for local address space stuff. THat could get tricky on some systems/optimizations

That means to compare it on the administrator side you'd need the exact same build ( OS, runtime, compiler, etc..). And if you did have a modded client that produced valid looking ranges there would be no indication to the admins to manually verify it with there own client. Even if they did you could never be 100% sure that it was a modded client, or just some weird OS config they have that dosn't quite match yours.

I still say that if the data from the ranges is predicable as you say it should be, it would not be too hard for a modded client to fake them using data cleaned from a running client ( say to a modded server making the requests).

It is an interesting idea but not something that is feasible for what we do. For other projects sure it could work. The work required on the back end to even a hint of valid data out of it is not something server owners would be willing to do (or even able to do given the platform restrictions ).

It would take a large amount of work to implement, and I still feel that the time would be better spent on other methods. But thank you for taking the time to explain it.
ImageJeffM

User avatar
FiringSquad
Sergeant
Sergeant
Posts: 847
Joined: Thu Jan 26, 2006 5:53 pm
Location: Ireland

Post by FiringSquad » Mon Sep 15, 2008 11:53 pm

Well I'm glad that it was interesting at least.
I really enjoy playing BZFlag and frankly I don't get the mentality that thinks winning by cheating can be rewarding.
Nevertheless, I'm fairly certain that I witness it regularly and certainly the accusations start to fly once anyone reaches a certain skill level or suffers from any form of lag.
Shame. It detracts from an otherwise very enjoyable way to spend some time.

Thanks for your input all.
I guess it's time to put this thread to bed, certainly it's way past my bed-time.

:-)

User avatar
Mucho Maas
Private First Class
Private First Class
Posts: 515
Joined: Tue Sep 21, 2004 5:14 pm

Post by Mucho Maas » Tue Sep 16, 2008 12:00 am

Just a silly question about LGPL/GPL. If I were to add/change code, and obfuscate the code I'd write, and then publicize the obfuscated code + compiled binaries, would that be in violation?

Not that obfuscated code would make anything safer in any of the above regards, but I was just wondering...


and hi to CBG making an appearance, haven't seen you since ....
"meet the new fo0 , same as the old f0o ... no no no .. don't get fo0'ed again ... " - The Who

User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5187
Joined: Fri Dec 13, 2002 4:11 am
Location: https://github.com/OmniTanks
Contact:

Post by JeffM » Tue Sep 16, 2008 12:49 am

Foo
as long as it compiles and is the same code you used to build the binary versions, yes. There is no clause about readability.
ImageJeffM

smoooth
Private First Class
Private First Class
Posts: 81
Joined: Sun Aug 05, 2007 6:13 pm

Post by smoooth » Tue Sep 16, 2008 3:00 am

I see there is no way to beat cheaters by changing anything in bzflag code; as long as it stay open source... which we all want it to do. Cheaters, as long as they can read the code, will find a way around it.

Only hope of keeping league play clean is:

Coding
1) Build a seperate closed source program that could somehow verify the things we need; hopeful but many issues with providing binaries for various systems
2) Reduce client responsibilities and place everything on the server side; still some problems here

Enforcement
3) Increase the number of bans for any kind of suspicious behavior: SUPER TIGHT RULES
4) Allow ALL modifications and provide all enhancements to everyone so that no one has an advantage. (this is not preferred; would turn into hax league)


The EASIEST solution is to provide enforcement. This can be done with proper rules and administration of those rules. It has to be thought through thoroughly. As far as I know; no one is doing this. I would be glad to develop something if admins would commit to changes. I don't want to develop something if they are dead set of never changing anything.

smoooth

User avatar
joevano
General
General
Posts: 1863
Joined: Sat Jun 18, 2005 1:08 pm
Location: South Bend, Indiana, USA

Post by joevano » Tue Sep 16, 2008 8:21 am

smoooth wrote:The EASIEST solution is to provide enforcement. This can be done with proper rules and administration of those rules. It has to be thought through thoroughly. As far as I know; no one is doing this. I would be glad to develop something if admins would commit to changes. I don't want to develop something if they are dead set of never changing anything.

smoooth
The project writes the game and provides some services (the forum, list server, and a few others). We do not host any maps. Rules and rule enforcement is a server owner thing, and is decided by each server owner. The project does not and can not dictate how someone runs their server. So this is an impossibility as well.
There is nothing worse than aggressive stupidity. -- Johann Wolfgang von Goethe
"How many legs does a dog have if you call his tail a leg? Four. Calling a tail a leg doesn't make it a leg." -- Abraham Lincoln

User avatar
A Meteorite
Private First Class
Private First Class
Posts: 1786
Joined: Thu Apr 28, 2005 12:56 am
Location: California, U.S.
Contact:

Post by A Meteorite » Tue Sep 16, 2008 8:27 am

smoooth wrote:The EASIEST solution is to provide enforcement. This can be done with proper rules and administration of those rules. It has to be thought through thoroughly. As far as I know; no one is doing this. I would be glad to develop something if admins would commit to changes. I don't want to develop something if they are dead set of never changing anything.

smoooth
Just so you know, BZFX has been working on this for some time now with the adoption of the CAN project. While still in development, our goals are pretty ambitious and would likely help solve many administration issues currently faced.

Feel free to talk to us in #bzfx on Freenode.

As for complete anti-cheat protection... bottom line is you can't trust data from the client, no matter how arcane or obfuscated it is. Someone could easily fake packets with some tool, link into an official client somehow for real values, or just dupe the messages in the hacked client.

What's really needed is a completely authoritative server (which hopefully a lot of that is implemented in for 3.0).
Image
Owner @ BZFX
Core Admin @ CAN

Email me: bzmet…@gmail.com

User avatar
Mucho Maas
Private First Class
Private First Class
Posts: 515
Joined: Tue Sep 21, 2004 5:14 pm

Post by Mucho Maas » Tue Sep 16, 2008 9:28 am

A Meteorite wrote: What's really needed is a completely authoritative server (which hopefully a lot of that is implemented in for 3.0).
If you are talking about moving hit detection to the server, I am suspecting that the main thing it will do is shifting lag around...from a "that was through!" to a "I dodged that!".

Even if you consider the ping of the dodging tank server side when calculating collisions, you will still have those affects. But would be great to test it out though. But I suspect it will change a lot how the game feels.
"meet the new fo0 , same as the old f0o ... no no no .. don't get fo0'ed again ... " - The Who

User avatar
joevano
General
General
Posts: 1863
Joined: Sat Jun 18, 2005 1:08 pm
Location: South Bend, Indiana, USA

Post by joevano » Tue Sep 16, 2008 9:41 am

The talk is to move all of the detection to the server, at some point in the future. This will be much better than you think. Yes, you will still have the same issues with lag (maybe in a somewhat reduced fashion, maybe not), but lag is not the real issue. The biggest issue with shots and cheaters is hit detection. The client (the cheaters) handles this now, and that is why it can be hacked. If shot detection is moved to the server, they will not be able to avoid being hit by not sending a "I died" message. The server will send a "You died" message and they will die or the server will know that they are cheating. This is probably a little over simplified but I think you will get the idea.
There is nothing worse than aggressive stupidity. -- Johann Wolfgang von Goethe
"How many legs does a dog have if you call his tail a leg? Four. Calling a tail a leg doesn't make it a leg." -- Abraham Lincoln

ts
Dev Monkey
Dev Monkey
Posts: 970
Joined: Fri Jan 14, 2005 6:26 pm

Post by ts » Tue Sep 16, 2008 11:58 am

Firing Squad, I do not think this could be reliable, even with closed source. Mac O X for example puts the libs at random positions. BZFlag could be put in RAM around the "fragment" so ranges are not guaranteed to be correct. Even the code part could grow at runtime in Mac OS X (I really don't mean the data part. Mac OS X uses the Harvard architecture.) and growing code part implies that data part in code can be manipulated.

I'm not sure whether addresses could even change during runtime. There are systems allowing hot plug RAM. Are there systems allowing hot unplugging RAM? What happens with addresses when BZFlag is moved from RAM to HD (and back to RAM again)?

Foo, I do not think that will happen as that kind of decision strategy does not fit BZFlag very well. I'm not saying that there couldn't be other funny side effects, though.
GU league: http://www.guleague.org/
An introduction to TCP: http://www.lafkon.net/tc/

User avatar
FiringSquad
Sergeant
Sergeant
Posts: 847
Joined: Thu Jan 26, 2006 5:53 pm
Location: Ireland

Post by FiringSquad » Tue Sep 16, 2008 2:47 pm

ts wrote:Firing Squad, I do not think this could be reliable, even with closed source. Mac O X for example puts the libs at random positions. BZFlag could be put in RAM around the "fragment" so ranges are not guaranteed to be correct. Even the code part could grow at runtime in Mac OS X (I really don't mean the data part. Mac OS X uses the Harvard architecture.) and growing code part implies that data part in code can be manipulated.

I'm not sure whether addresses could even change during runtime. There are systems allowing hot plug RAM. Are there systems allowing hot unplugging RAM? What happens with addresses when BZFlag is moved from RAM to HD (and back to RAM again)?
Logical addresses within the binary code are fixed. This has to be the case since otherwise programs would crash. Physically, yes anything is possible, but the binary check uses the logical addresses so that the physical location is irrelevant.

In fact object orientation depends upon code addresses remaining static, since they are stored within the data object themselves.

There are some schemes that allow binary code to be modified during runtime in order to improve efficiency but this is specially hardcoded in the program and ties it in to specific processors and is never performed by code generated by compilers.

User avatar
blast
General
General
Posts: 4780
Joined: Fri Mar 21, 2003 3:49 pm
Location: playing.cxx
Contact:

Post by blast » Tue Sep 16, 2008 3:02 pm

As for the authoritative server, it doesn't imply "moving" logic as much as "copying" it. The client would still likely report their own deaths. The server could be running a simulation of the game, and could determine if someone should have or shouldn't have died.
"In addition to knowing the secrets of the Universe, I can assure you that I am also quite potty trained." -Koenma (Yu Yu Hakusho)

Image

Post Reply