AIMBOT prevention

Started by
11 comments, last by DragonWolf 20 years, 10 months ago
Hi All, I am currently doing a final year project at university which includes the netcode for a MMOG. One of the areas I''m looking at is game security. I''ve tried to put in prevention for common security flaws in games (such as speed hacks, duping, etc.) but one which I''m having trouble trying to prevent is the AIMBOT style hacks. I''m currently using various encyption methods that will prevent proxy software from monitoring network signals and easily reading from the client program''s memory. I''d like to hear any other ideas/articles people have for other types of aimbot hack prevention. DW
Advertisement
A common trick, depending on what graphics API you using, is to create a proxy DLL and track where the models are being drawn. The hacker will isolate the model and figure out where the "head" is. It is then a relatively simple task of generating a vector from the player''s position to the models "head" and bam - aimbot.

I''d recommend writing a "checker" program that will validate all files locally. Also, you may want to install hooks to catch calls to ReadProcessMemory/WriteProcessMemory etc. Enumerating the list of running processes would help too.
[email=direwolf@digitalfiends.com]Dire Wolf[/email]
www.digitalfiends.com
> ... trying to prevent is the AIMBOT style hacks

There is no sure-shot solution to prevent aimbots {pun intended} as clients have control of the data flow to the server. Cheaters love to screw up a game for a variety of reasons; either it's for the fun of it, or because they hate losing, or some other dark reason. Psychology, rather than cryptology, is best here. Here are some thoughts if your server can gather statistics on each player:

1) increase randomness to his shots in the hope that other players will be less frustrated (after a while, he sure will be!),

2) increase the respawn delay each time he gets killed,

3) display statistics about hit/misses of each player so that other players can know what's going on and vote the bugger out if they want, or

4) simply kick him out and ban his IP for 5 minutes.

-cb

[edited by - cbenoi1 on May 29, 2003 11:46:14 AM]
put the randomness on the server side.
quote:Original post by C-Junkie
put the randomness on the server side.


Yes that would hinder an aimbot, but unless the weapon has some horrible recoil, an aimbot would still be pretty effective.

Encrypting the data packets would be the best idea. A quick XOR encryption and a simple byte transposition would work best (the byte transposition prevents the XOR key from being cracked through pattern analysis).
Until they disassemble the client and figure out the encryption routines.... which would take a day at the most.

No matter what encryption you use, it will either be broken or too intense for the game to handle.

The problem isnt deciding what to do when you''ve found a cheater, its figuring out if somebody is cheating or not.

-=[ Megahertz ]=-
-=[Megahertz]=-
The encryption method is the method I am current using, the server sends the client a public key to encrypt data. In order to decode this would take a good few hours even if you know the algorithm and you know the private key, which is enough to stop any cheaters. In order to save on processor time, only key packets/frames are encrypted.

There are a few ways of getting around this which I would like to solve.

Patch the original client software. This would require alot of work on the part of the hacker and I don't think there are many hackers who would be willing to do that. (requires reverse engineering (not just disassembling) finding the correct bits of code and altering them. (SOLUTION: If the file is corrupt, game updates and checksums would fail)

Read the memory and trace the program. Block the outgoing signal and re-encrypt a new packet. The offending software knows what should be in the packet by the program trace and the data by looking at the memory). (SOLUTION: Like you say monitor processes and the use of readProcessMemory and writeProcessMemory)

The most efficent and probably easiest method would be to directly write to the client programs memory. Ensuring the player model is always aimed at the head/vital points of other characters. However, I think this would cause memory collisions and could well crash the client program. (SOLUTION: Again monitor processes and the use of readProcessMemory and writeProcessMemory)

As for kicking and vote kicking, I don't think this is suited for a MMOG, though it could be argued.

The recoil/randomness factor could help, but it is not always suitable and in my opinion can ruin game play (except for the realism aspect of recoil, etc)

Are there any other methods of implementing aimbot style hacks that I haven't thought about and/or any other ways to further try and protect the game from offending programs?

[edited by - DragonWolf on May 30, 2003 7:25:01 AM]
Well the problem with the checksum of the client.exe is that the client can send a false checksum to the server and fool it into thinking the client is up to date.

As far as readprocessmemory and writeprocessmemory go and while I havent looked into the in''s and out''s of those, I''m fairly sure that there are ways around detecting those.

-=[ Megahertz ]=-
-=[Megahertz]=-
quote:Original post by DragonWolf (SOLUTION: If the file is corrupt, game updates and checksums would fail)


They can backup the original.
I'm never gonna stop everything, but I atleast wanna make it hard for people to hack these things.

I know there are ways around checksum, but its a rather standard prevention and with the use of encyption it would require the hacker to actually disassemble/reverse engineer the software.

As for backing up originals, that doesn't help since they would have to download a new cheat for the newer version.

[edited by - DragonWolf on May 30, 2003 9:59:25 AM]

This topic is closed to new replies.

Advertisement