Indie - Cheat Deterrent Software
by Joshua "One-Hundred" Albert · 04/01/2009 (7:11 pm) · 6 comments
Hi let me introduce my self first...
My name is Joshua Albert, in most online games and communities I go by "One-Hundred". I used to play video games very actively a couple years ago until I gradually moved onto the development and programming communities such as GameDeception and DreamInCode. In most online Shooting games I use cheats (AKA. Hooks, Hacks, Trainers) that I would find online or modify or even write my self. I no longer play games enough to care about score, but when I was active in the gaming community, score was everything... I was good player (at least I considered my self) who used everything they could to their advantage (excluding exploits, hacks) I was then introduced to cheats by a family member. After 2 years I became familiar with how they worked and ways to get around certain anti-cheats. After seeing how programming could be used to create cheats, that is how I gradually moved into programming.
At the moment I am currently developing a Anti-Cheat called "Veritas" it uses a number of methods to 'detect' cheating.
- ScreenShots
- Memory Monitoring (A Work in progress)
- Event Logging
All of these are done client side through my application which uses a SQL server, multiple memory streams, and many protections for reverse-engineering, which I may continue development on (reverse-engineering).
Anything and everything is done periodically and randomly in my application so there is no set time for the user to know when this event will happen and which makes it harder for them to get around.
I am also using an encryption on memory which is streamed to the SQL server (such as logs) so it is difficult for the user to even attempt to modify.
A friend I met a while ago had suggested I post a blog here about my software as many Indie developers would be interested in it.
I will continue blogging here with updates, and I am asking for ideas and possible ways to prevent reverse-engineering.
What you see is the Veritas client (After login authentication via MySQL).
Some things explained...
- The Black box with green text is the log, the only reason it is visible is because I was debugging it and I wanted to see what messages were appearing and where.
- The small green box on the left-hand side is the box which displays whether the user is "In good standing" or "Banned", which can be changed via MySQL
- The box which says "ONE-HUNDRED" is the box which displays the username that is logged into the application.
Post what you think,
Thank you!
My name is Joshua Albert, in most online games and communities I go by "One-Hundred". I used to play video games very actively a couple years ago until I gradually moved onto the development and programming communities such as GameDeception and DreamInCode. In most online Shooting games I use cheats (AKA. Hooks, Hacks, Trainers) that I would find online or modify or even write my self. I no longer play games enough to care about score, but when I was active in the gaming community, score was everything... I was good player (at least I considered my self) who used everything they could to their advantage (excluding exploits, hacks) I was then introduced to cheats by a family member. After 2 years I became familiar with how they worked and ways to get around certain anti-cheats. After seeing how programming could be used to create cheats, that is how I gradually moved into programming.
At the moment I am currently developing a Anti-Cheat called "Veritas" it uses a number of methods to 'detect' cheating.
- ScreenShots
- Memory Monitoring (A Work in progress)
- Event Logging
All of these are done client side through my application which uses a SQL server, multiple memory streams, and many protections for reverse-engineering, which I may continue development on (reverse-engineering).
Anything and everything is done periodically and randomly in my application so there is no set time for the user to know when this event will happen and which makes it harder for them to get around.
I am also using an encryption on memory which is streamed to the SQL server (such as logs) so it is difficult for the user to even attempt to modify.
A friend I met a while ago had suggested I post a blog here about my software as many Indie developers would be interested in it.
I will continue blogging here with updates, and I am asking for ideas and possible ways to prevent reverse-engineering.
What you see is the Veritas client (After login authentication via MySQL).
Some things explained...
- The Black box with green text is the log, the only reason it is visible is because I was debugging it and I wanted to see what messages were appearing and where.
- The small green box on the left-hand side is the box which displays whether the user is "In good standing" or "Banned", which can be changed via MySQL
- The box which says "ONE-HUNDRED" is the box which displays the username that is logged into the application.
Post what you think,
Thank you!
#2
04/01/2009 (7:36 pm)
Sounds interesting :-)
#3
04/01/2009 (7:39 pm)
Very cool. Thats what we need anti-virus programs. As soon as I get a publisher I'll have to check it out. I am not an indie developer, But it sounds very cool. 
#4
With that being said, if you could make a low cost anti cheat program for the indie devs and do it in a way so it was legit, I'm willing to bet there'd be a lot of people interested in it.
04/01/2009 (9:05 pm)
Ok first let me say that people like you were the one's that ruin fps communities and without people like that there'd be no need for anti cheat software, but with that said I know people do it. (Sorry, but you struck me on a personal note as I'm a fairly active player in the Tribes Vengeance community and I know cheating is a big factor that has basically brought the game to it's knees.)With that being said, if you could make a low cost anti cheat program for the indie devs and do it in a way so it was legit, I'm willing to bet there'd be a lot of people interested in it.
#5
04/01/2009 (10:25 pm)
Sounds interesting. I am not sure you are aware though Veritas is the name of a major backup software owned by Symantec. You might want to think twice about using a different name. If anything it will get lost in the search engines and at worst they might think it interferes with their product. 
#6
1) Look into using cross-process trampoline functions to prevent other applications from accessing the game process memory via ReadProcessMemory/WriteProcessMemory, and local trampolines to prevent attached DLLs from modifying the access levels for critical sections of game code.
Done properly, this can eliminate most simple cheats in one shot without having to get into banning 15 year olds who just wanted to try something.
2) I'm not sure I understand you correctly, but if your client-side application is connecting directly to an external SQL server, that is a very bad idea. Have it communicate with a master server using a custom encryption and CRC checking, and then have the master server connect to the SQL server. Otherwise your SQL server will get hacked.
3) When you detect something, don't act on it immediately. Acting on it immediately will give the hackers a clear debug path to trace right back to your detection algorithms.
04/02/2009 (12:14 am)
Having spent a lot of time working on this particular topic, I have a few suggestions. I won't go into too much detail, since I could write an encyclopedia on the subject and go on forever lol, but just some overview.1) Look into using cross-process trampoline functions to prevent other applications from accessing the game process memory via ReadProcessMemory/WriteProcessMemory, and local trampolines to prevent attached DLLs from modifying the access levels for critical sections of game code.
Done properly, this can eliminate most simple cheats in one shot without having to get into banning 15 year olds who just wanted to try something.
2) I'm not sure I understand you correctly, but if your client-side application is connecting directly to an external SQL server, that is a very bad idea. Have it communicate with a master server using a custom encryption and CRC checking, and then have the master server connect to the SQL server. Otherwise your SQL server will get hacked.
3) When you detect something, don't act on it immediately. Acting on it immediately will give the hackers a clear debug path to trace right back to your detection algorithms.
Torque Owner Jason "fireVein" Culwell