Important Message

You are browsing the archived Lancers Reactor forums. You cannot register or login.
The content may be outdated and links may not be functional.


To get the latest in Freelancer news, mods, modding and downloads, go to
The-Starport

Anti-Cheat engine

Here SysOps can list their MultiPlayer server info and users can send feedback to their SysOps. Or just talk about the MultiPlayer servers they play on. This is not about MultiPlayer in general - please use the MultiPlayer Forum for that!

Post Wed Aug 27, 2003 1:11 am

Anti-Cheat engine

I have some idea for a while now, on how to create better cheat protection. I will explain it here and if i`ll get positive comments i will start working on this.
Here is draft:
The anti-cheating enghine is splited to two codes one on server side(server task) and one on client(client task). Both are background tasks/services.
Upon connection to server, server task will connect clients task. client task in result will check "Freelancer" data files that are relevant for modding. Sum up every file with MD5 or CRC32(or with others codecs) and send the info to the server task. Server task will make decision if to allow that client or not.
Few drawback of that engine:
1. Bandwidth overheat (I prefer non cheater server better than that)
2. Long connection time. (i can stand it)
3. The engine can be cheated, however everything can be encrypted and both task can be Key/Update changed. This leaves only few "hardcore hackers" which are needed to ban manually. There is also few things that I wont say here, also to protect from hacking.

For now i think i can make it with c/c#. help needed


Well.... Anyone interested?

Moby

Post Wed Aug 27, 2003 1:47 am

i would gladly be a tester...

Regards
OOO Danmark OOO
Freelancing.da.ru

Cloak Is For Newbies

Post Wed Aug 27, 2003 10:29 am

Any flaws or comments?

Guys FL will die and fast if we wont eliminate cheating.

Moby

Post Wed Aug 27, 2003 2:25 pm

Well I for one really like this idea. Sounds like it could eliminate a LOT of the current cheating (by which I mean MODing on unMODed servers). This is just a thought (I have no idea if it would work or not), but I would like it to check the integrity of the client program itself. This could further reduce cheating by eliminating those who get around it by tampering with it.

One more thing. There are those stupid players who take revenge on a server when they get banned for "accidentally" entering with an active MOD. One player started loads of threads to complain...which explains why everyone flamed him. Then that retard player who went by CyberTemptation and Logitech_Is_Back, who spawned THOUSANDS of weapons (diamondbacks, I think) outside Manhattan. Turned out he was banned and was taking it out on the server...he was like "boo hoo, Stinger bans for no reason" and "waa waa, I just forgot to deactivate the MOD". Well, HE was the stupid one that didn't bother checking.

Now, if your program could prevent stuff like that from happening, I would LOVE to see it developed.

Post Wed Aug 27, 2003 3:04 pm

Great idea and I would also like to try it.

1. If the extra bandwidth is needed only during connection time, then it should be fine. Even that could be throttled but result in a longer connect time.
2. I, too, can wait.
3. Unfortunently this is true but then the hacking would not be a simple case of installing FLMM and adding the mods of choice. If someone goes to this trouble they really do need to get a life!

I have some concerns and questions though. Presumably you compare the files that the client has but the server doesn't, the ones that are modded. I think these are the ini files (if I am incorrect or slightly off, please correct me). Therefore the server would have to have these files as well to compare with the client. Some type of distribution would have to be in place for these client files as well, maybe TLR. The comparisons, as you say, are done upon connection and the client booted if any discrepensies are found. My question is what happens after? I realize a lot of Micro$oft products lock out the files they are accessing and not merely make a copy of the file in memory to make changes to that. If those same game-altering ini files (the ones that mod a FL game) can also be locked out during an FL game OR are only accessed during the startup of FL, then this may work and hence not a concern. Then after the connection and before logging out from the server modders couldn't alter the ini files that mod because they couldn't access them or altering them would do nothing because they are not used until FL is restarted. I have never used FLMM but does it do it's thing before you run FL or during?

The beauty of this setup is it would force clients on modded servers to stick to the server's mod, a great thing that modded server sysadmins have complained about as well. As we ALL know any single player who is different (mods vs non-modded, mod A vs mod B, etc.) from any other player will increase traffic and hence cause lag for EVERYONE.

One drawback I just thought of, what files are compared and how far do you go? Just ini's and it should be quick (<15 secs max) but if any other data or code is compared, forget it. It would take too long. Have to check but how big in bytes are all the relevant ini files?

Unfortunently my C programming skills are as rusty as a Massachusetts bridge! But I could beta test it. Good luck!

---------------
Earendil
SysAdmin of Boston Freelancer server

Post Thu Aug 28, 2003 3:04 am

I've been thinking about it, and I believe this is how it would (or should) work.

When you connect, the client-side program will check the .ini files to obtain a set of variables. These values are then sent to the server. The server-side program then checks to make sure it matches. The server-side program would only use the scan when the server is starting up, then it uses those values for any players that join (for the comparrison).

If you had a "default" option which uses preset values, it means you wouldn't need to use the scan at all, providing it's an un MODed server. This will help if you don't actually have FL installed (there's an option to only install the server files). Unfortunately, I don't know how it would work for a MODed server without the game installed.

Anyway it was just a thought, but I hope it helps.

Post Tue Sep 02, 2003 9:35 pm

hrm, maybe you guys should get ahold of FLMM's programmer(s); see if they can have FLMM send data to the client regarding which mods its running so that the client side antimod util ('a punkbuster for fl', if you will...) can send information regarding which are loaded into FL.

that will stop all the "inexperienced" cheaters who illegally-mod on servers simply by activating mods by FLMM (eg. the speed 1000 mod)...and there are prolly a lot of them.

I bet even the experienced modders who use homemade cheats use FLMM to swap em.

dont forget to add support for detecting trainer exe's that may be running.

regarding extra lag: wouldnt there be little point to keeping the client running, once FL has connected to a server? The server side anticheat util should at least remotely stop sending data the moment the client has been "authenticated" with the serverside util...theres no point i think, as far as i know you cant modify Freelancer's INIs or EXEs ingame...i might be wrong, however.

-- Gregster2K

Edited by - Gregstar2k on 02-09-2003 22:40:53

Post Sat Sep 06, 2003 5:38 am

ideas

1. serverside trainer detector(blocks memory hacking) used in conjunction with 1.1 patch. does scans for un-natural changes in a players stats/equipment in realtime.

2. crc checker. you load it via a dll if possible in freelancer.ini(dont know if this will work). the dll will create a crc id of a list of main files dynamically which will be shared in an auth session with the server when joining. only used during connection.

3. automated admin control. autobans user ids after 3 detections(requires 1.1 patch). good for servers without a monitoring admin. small background process possibly in a dll that is loaded through freelancer.ini with no dependancies so it can be applied as a game patch.

just some ideas.

"Great Spirits have always encountered violent opposition from mediocre minds. The mediocre mind is incapable of understanding the man who refuses to bow blindly to conventional prejudices and chooses to express his opinions courageously and honestly." -Albert Einstein

Post Sat Sep 06, 2003 4:34 pm

Those are some good ideas, but there's a problem with the first one.

FLServer was not designed to look for those things, so a lot of the data required would not be readily avaliable. So you would have to upload it every time there was a scan. Then if it's real-time, all players have to be scanned constantly, and that means quite a lot of bandwidth. So if a large number of players (20-30) are on, it would cause a LOT of lag. Not to mention a killer for anyone with a dial-up connection.

However, you can eliminate the problem by simply making it part of the client-side program. That way, it only uses bandwidth when it's reporting something. In other words, non-cheaters are almost unaffected (as it should be). I know that someone could tamper with it, but this is the reason for an earlier suggestion. When the player connects, the server-side program could do a check to make sure the client-side program hasn't been changed.

That way, in order to cheat, you would have to edit the client-side program so it wouldn't report the changes...AND do it in a way that the tampering isn't detected. So if this program is done the way I picture it, you would eliminate all but the most hardcore hackers/cheaters. I know there will probably be loopholes and cheats that won't be detected, but that's what updates are for, right?

Edited by - Braxton on 06-09-2003 17:52:17

Post Mon Sep 08, 2003 1:15 am

Brief update. I working on the client and server sides, nothing to show off with yet, except time measures:
EQUIPMENT directory only the ini files as main target for cheaters: 1mg 0.3sec for checking and transmit, 2k of network traffic.
DATA directory: 731mg 160sec only for checking, 450k of traffic(can be compressed).

Presumably you compare the files that the client has but the server doesn't, the ones that are modded. I think these are the ini files (if I am incorrect or slightly off, please correct me). Therefore the server would have to have these files as well to compare with the client.

Signatures files are enough for checking the client. However you will need the files to create signature list.

The comparisons, as you say, are done upon connection and the client booted if any discrepensies are found. My question is what happens after?


Hope they dont, I checked the files seems like readable.

When you connect, the client-side program will check the .ini files to obtain a set of variables.

Obtaning the variables is not simple task. Just to check if everything is going by plan and not to overheat anything. Signature checking is enough. This solution can be good for limiting cheating or setting boundary. I think its pointless for now.


Edited by - Moby on 08-09-2003 02:19:27

Post Mon Sep 08, 2003 6:03 pm

the thing about working with clientside stuff is you have to make it required for connection. the server will have to prevent anyone without it from connecting otherwise it will be useless.

"Great Spirits have always encountered violent opposition from mediocre minds. The mediocre mind is incapable of understanding the man who refuses to bow blindly to conventional prejudices and chooses to express his opinions courageously and honestly." -Albert Einstein

Post Mon Sep 08, 2003 6:50 pm

of cource!
Server side acting like firewall befor passing the packets to FLserver.

Post Tue Sep 09, 2003 3:56 pm

moby, buddy, pal, how's the anti-cheat software going?

With Elite going down soon and possibly for a while, I worry. When Elite was down the last two times I get more traffic but also more cheaters. While I beta test FLServOp by JoeBoomz and it is great for catching some cheaters, it doesn't catch them all. I am starting a server police group but that is mostly to enforce the rules. (for those who don't know my server has the same rules as Elite) Stopping them at the door would be a much cleaner solution!

---------------
Earendil
SysAdmin of Boston Freelancer server

Post Wed Sep 10, 2003 1:08 am

hey guys ...

i have another great idea .. you know the ipconnection monitor 1.0
the *.xml file.....

this file could be only file we need to run a
(as mentioned above a punkbuster if you will..)plugin ...that not only calculates name but ofcource dns address

and SOMEHOW the xml file have to work to getther with the fladmin API
so it automatic both bans ip and delete acccount... :-)

who say it have to be only names it calulate

Freelancing.da.ru OOO Danmark OOO

Cloak Is For Newbies

Return to Freelancer Server Forum