1.5 patch suggestions cheat detection

Feedback for the Outrage Entertainment D3 dev team members - bug reports, patch issues, your raves (or rants).
DigiJo
DBB Ace
DBB Ace
Posts: 491
Joined: Thu Jul 18, 2002 2:01 am
Location: Germany
Contact:

1.5 patch suggestions cheat detection

Post by DigiJo » Fri Aug 15, 2003 5:24 am

ok ill try to start with some suggestions.

-first of all the server should checksum all gameplay relevant values and compare server /client tableentrys for speed, weapon-strenght/speed,shieldstrenght/radius slidespeed and so on. but in that way that eyecandy mods still possible. this should be done on joinrequest. the player should not be able to join if this values are not the same as on the server.

-texture entrys from the level that is hosted should be checksummed too and compared server /client. (most levels have only up to 50 different textures, that should be possible or?)

-what kind of weapons a player has and the ammount of ammunition should be managed by the server, so that the player that spawns in front of me cant kill me with a mortar anymore a second after spawn Image (and make it that way that the memory positions for the weapon-variables alternate from game to game)

i think a lot of the stuff can be done on join request and if it takes a few seconds longer to join cause much more data has to be transferred who cares ? i can wait 3 seconds longer than usually to join a game if thats the price for a fair game.
User avatar
Sniper
DBB Ace
DBB Ace
Posts: 375
Joined: Thu Nov 05, 1998 12:01 pm
Location: MKE. WI
Contact:

Post by Sniper » Fri Aug 15, 2003 11:14 am

I'm not sure if this is at all posible, or even feasable. But I would like to see a smoother GUI with better graphics. All the fonts displayed in the game are TOO big. The main menu is the only thing that looks decent.

I wouldn't mind contributing time to work on something for it. I'm just sick of the way the menus and the GUI looks in D3.
User avatar
Testiculese
DBB Material Defender
DBB Material Defender
Posts: 4680
Joined: Sun Nov 11, 2001 3:01 am
Contact:

Post by Testiculese » Fri Aug 15, 2003 11:23 am

That's just your resolution, Sniper, 'cause this image looks fine to me. (920x760 rez)
User avatar
Genghis
DBB Newbie
DBB Newbie
Posts: 1377
Joined: Fri Feb 12, 1999 3:01 am
Location: Ithaca, NY, USA

Post by Genghis » Fri Aug 15, 2003 12:56 pm

I think Kevin needs to understand what cheats are out there that are bothering us so he can address them. One way to do this would be to have Kevin play about 50 hours of D3, hoping to run into some cheaters. Of course, this is not very practical.

The other way I can think of is to list some of the cheats out there and explain how they're accomplished so Kevin can address them. Since discussing how to cheat is inadvisable in an open forum, how 'bout we just list the cheats and let folks who understand how they work email Kevin? I know there's plenty of folks who don't use cheats in-game but have experimented with them for various reasons who would like to help Kevin out.

Some of what I've seen:

1 - extremely fast ships
2 - extremely rapid firing weapons
3 - ships flying through walls; able to shoot out but not be shot
4- rapid fusion charging
5 - rapidly going into/from observer mode until the server crashes

Other folks claim to have seen:

1 - shots from multiple weapon mounts, like 5 MD shots at once
2 - ships spawning with inappropriate weapons
3 - a third party causing one's ship to fire napalm
4 - altered ship sizes, so they appear normal but are actually tiny or huge

I'm sure that I missed plenty. If a moderator thinks my post is inappropriate, feel free to edit out any specifics but please retain my suggestion of emailing Kevin with cheat methods.

Of course, we don't want to innundate Kevin with a hundred "helpful" emails, thus causing him to hate us and drop the project. I would recommend funneling all correspondence with Kevin through someone we trust (I trust Suncho) but that depends on (1) getting a volunteer and (2) having everyone trust him/her.

At the very least, if you are going to email Kevin with cheat methods, please take your time, compose a comprehensive, organized, and clear message, and email him ONCE ONLY. Don't send 5 small emails with subjects like "and I just remembered this" or "one more idea."

- G
User avatar
Genghis
DBB Newbie
DBB Newbie
Posts: 1377
Joined: Fri Feb 12, 1999 3:01 am
Location: Ithaca, NY, USA

Post by Genghis » Fri Aug 15, 2003 1:11 pm

BTW this is a thread for cheat detection/prevention. If there are suggestions for game enhancement, please post it in the thread called game enhancement.

Kevin requested a thread on cheat detection/prevention, but he did not request one with game enhancement suggestions. He can view or ignore the other thread as he wishes.
[RIP]Hydra
DBB Ace
DBB Ace
Posts: 45
Joined: Thu Jun 27, 2002 2:01 am

Post by [RIP]Hydra » Fri Aug 15, 2003 2:31 pm

I was just pointed to this thread from someone else.

Being a professional programmer and having written successful Anti-Cheat software for other games (along the lines of PunkBuster) I'd be willing to lend a hand/advice if I can.

Kevin, if interested you can send me an email to Hydra@comcast.net.
User avatar
DCrazy
DBB Alumni
DBB Alumni
Posts: 8826
Joined: Wed Mar 15, 2000 3:01 am
Location: Seattle

Post by DCrazy » Fri Aug 15, 2003 2:59 pm

DigiJo, the "server should manage ammo levels" is what Permissible Client/Server is all about. The client says to the server "I want to shoot weapon X now", the server makes sure the player can do so, and then performs the act.

There's one problem with checksumming. First of all, there's no way of determining what is an "eyecandy mod" and what is not, therefore no modifications would be allowed. Flat, across-the-board, fair and equal rule. That also significantly reduces the burden, because then the server and client only have to CRC32 table.gam (which is HUGE) and any files associated with the level.

This can take place in the background as well. When a server is created, it generates CRC32's of table.gam, main.exe, and whatever MN3 (mission) and D3M (mod) have been selected. When a player joins, the client sends the server its own CRC32's of the tablefile, executable, mission, and mod. The server compares the values and will automatically kick any clients with mismatched CRC32's.

One problem: what prevents someone from disassembling D3 and working around these CRC32 checks? Only time. Luckily for us, this game is small enough that the threat of someone spending months to pore over the D3 source code is significantly less than the threat of CS cheaters working around PunkBuster.
[RIP]Hydra
DBB Ace
DBB Ace
Posts: 45
Joined: Thu Jun 27, 2002 2:01 am

Post by [RIP]Hydra » Fri Aug 15, 2003 3:22 pm

One way to address the "eyecandy" type of mod is to add an option to D3's options. Eg. A checkbox that sets whether or not your using a "cheat enforced" server.

So if your about to have a match or w/e, the server has a setting to enforce anti-cheat, and all participants of the match would have to set this option too. After all, in a match environment isn't it best to have the field leveled.

If this setting isn't checked, then you can play with your mod's etc..

As far as the disassembly problem, there's actually WinAPI calls that can be made to determine if the process is running under a debugger. I've also written modules to detect SoftICE and a couple other of the more popular debuggers/disassemblers.

The only way to bypass these API's would be to hook the Kernel, which can also be detected by using Structured Exception Handling. Take a look at IAT patching and Detours.

Of course, most of what I'm talking about is Windows specific. Image
Delkian
DBB Ace
DBB Ace
Posts: 200
Joined: Mon Dec 31, 2001 3:01 am
Location: Helsinki, Finland
Contact:

Post by Delkian » Fri Aug 15, 2003 3:42 pm

Hydra,
<font face="Arial" size="3">and all participants of the match would have to set this option too.</font>
I suppose you mean that the client side would automatically set this option according to what the server tells it, as having the player set it manually would be rather impractical.
[RIP]Hydra
DBB Ace
DBB Ace
Posts: 45
Joined: Thu Jun 27, 2002 2:01 am

Post by [RIP]Hydra » Fri Aug 15, 2003 4:06 pm

Yea, I was just throwing out rough ideas is all. Just an example.
There's a couple ways it could work.
DigiJo
DBB Ace
DBB Ace
Posts: 491
Joined: Thu Jul 18, 2002 2:01 am
Location: Germany
Contact:

Post by DigiJo » Fri Aug 15, 2003 4:12 pm

probably better take a md5 checksum? crc32 can be fooled easier i think. and for the eyecandy mods, you could allow at least custom oofs + their textures and sparkles cause they only hold meshinfos, gunpoints and attachpoints etc. i dont see how to do an effective cheat with these at the moment. (well if accurate collision detection is not switched on)

all the more important values are in the gamtables and could be checksummed.
[RIP]Hydra
DBB Ace
DBB Ace
Posts: 45
Joined: Thu Jun 27, 2002 2:01 am

Post by [RIP]Hydra » Fri Aug 15, 2003 4:30 pm

CRC32 when done right isn't as easily faked as you might think.

Eg. In my one program all cheat communication between the server and the client is RC2 encrypted and the checksums SHA256 hashed.

So, say you "trick" the CRC32, you still then have to break the RC2 encryption key that the server and client are using.
In the case of my last project, it's variable between each clients connection, and each client is uniquely identified regardless of his IP, MAC etc...

To top it off, the server can set the encryption method on the fly. So it switches between RC2, RC4, Blowfish and about 10 others.

I gotta jet, but I'll post some links to the last project I just did/doing on this for a game called America's Army Operations.

It's been in use for almost a year now by over 1000 people for the TeamWarfare ladder.
User avatar
Suncho
DBB Defender
DBB Defender
Posts: 3222
Joined: Sat Jan 30, 1999 3:01 am
Location: Richmond, VT
Contact:

Post by Suncho » Fri Aug 15, 2003 9:47 pm

<font face="Arial" size="3">2 - extremely rapid firing weapons</font>
There is also a bug with stale servers that causes this (along with weapons not firing at all).
<font face="Arial" size="3">4- rapid fusion charging</font>
I e-mailed Kevin on how to reproduce this.
LvlSevenBoss
DBB DemiGod
DBB DemiGod
Posts: 2102
Joined: Thu Nov 29, 2001 3:01 am
Contact:

Post by LvlSevenBoss » Fri Aug 15, 2003 10:42 pm

Why don't we continue to update the existing 1.5 bug/feature thread you had going Suncho?
User avatar
Mobius
DBB_Master
DBB_Master
Posts: 7940
Joined: Sun Jun 03, 2001 2:01 am
Location: Christchurch, New Zealand
Contact:

Post by Mobius » Sun Aug 17, 2003 5:43 am

I want to state right now, that preventing eye-candy mods, such as Testi's table file, ship skins, and altered ship models is a VERY BAD THING.

DO NOT PREVENT THESE FROM BEING USED IN ANY SERVER.

If you want a level playing field, go to a LAN - because it's level NOWHERE ELSE.

If I can't use my nice eye-candy modifications, I will quit D3 online for good, take down my D3HELP web site and uninstall it from both computers. I'll also have the Xtra New Zealand server taken down. COMPRENDEZ VOUS?

Really - this sort of thing is just lame.

It's enough to stop fast ships, fast weapons, wall-hacks and so forth - but DEAR GOD - don't make us look at the hideous reality that is STANDARD D3.

Look, several new ship models are in development RIGHT NOW, and there are a lot of people using modified table files - AND THESE PEOPLE ARE NOT CHEATING.

Stopping the visual development of Descent 3 is a recipe for an even quicker death than the game is experiencing right now. The only thing that keeps me playing is looking forward to new models for the ships, and new eye-candy from dedicated players!

And that's all I have to say about that.

Please don't make me give up D3 - I've devoted too much of my time to the D3 community to pull the plug on it without feeling very bad indeed. But make no mistake - I will.
User avatar
Floyd
DBB Captain
DBB Captain
Posts: 561
Joined: Sat Apr 26, 2003 2:01 am
Location: Germany
Contact:

Post by Floyd » Sun Aug 17, 2003 7:52 am

-OT-

<BLOCKQUOTE><font size="1" face="Arial">quote:</font><HR><font face="Arial" size="3">Originally posted by Mobius:
<b> If I can't use my nice eye-candy modifications, I will quit D3 online for good, take down my D3HELP web site and uninstall it from both computers. I'll also have the Xtra New Zealand server taken down. COMPRENDEZ VOUS?
</b></font><HR></BLOCKQUOTE>
ooooh, blackmail
<BLOCKQUOTE><font size="1" face="Arial">quote:</font><HR><font face="Arial" size="3"><b>
It's enough to stop fast ships, fast weapons, wall-hacks and so forth - but DEAR GOD - don't make us look at the hideous reality that is STANDARD D3.
</b></font><HR></BLOCKQUOTE>
ever figured that people play mostly levels of which d1 is capable?
<BLOCKQUOTE><font size="1" face="Arial">quote:</font><HR><font face="Arial" size="3"><b>
Look, several new ship models are in development RIGHT NOW, and there are a lot of people using modified table files - AND THESE PEOPLE ARE NOT CHEATING.
</b></font><HR></BLOCKQUOTE>
that can be done in missions though. THESE might not, but THOSE might.

thats all I have to comment about that.
mods, feel free to remove my rant, if this leads too far off topic.
~F
User avatar
Testiculese
DBB Material Defender
DBB Material Defender
Posts: 4680
Joined: Sun Nov 11, 2001 3:01 am
Contact:

Post by Testiculese » Sun Aug 17, 2003 8:03 am

Floyd, what he's getting at is it's easy to run a check for gam cheats without disrupting what are not cheats.
User avatar
Krom
DBB Database Master
DBB Database Master
Posts: 15184
Joined: Sun Nov 29, 1998 3:01 am
Location: Camping the energy center. BTW, did you know you can have up to 100 characters in this location box?
Contact:

Post by Krom » Sun Aug 17, 2003 10:57 am

Blah @ eyecandy mods, D1 is more fun then D3 but it looks like total crap. Side-scroller video games are some of the best games and they dont even use 3D! Its not that big of a deal! If given the trade off I would gladly give up eyecandy mods to get rid of cheaters.

While we are on this subject I *could* set up a forum for the 1.5 beta team and all, I could have private forums so you guys could explain in detail about cheats and how to get rid of them. That could cut down on the "helpful" emails that will likely be sent around.

-Krom
User avatar
Testiculese
DBB Material Defender
DBB Material Defender
Posts: 4680
Joined: Sun Nov 11, 2001 3:01 am
Contact:

Post by Testiculese » Tue Aug 19, 2003 10:08 am

Know what would be really cool? If 1.5 implimented some of my eyecandy mods..like these:

Can't can't get a screenshot, but I set the frag tracer trails to dissipate a a rate about half of normal. Gives the frag a meaner 'look'. Does not effect damage.

This helps framerate. It also makes the micro harder to see, and to avoid. It makes the opposing ship a little easier to see tho', but is balanced by the limited visiblility of the rings themselves.
http://www.metallisoft.com/files/descen ... rowave.jpg

Nothing major here, just increased the length of the trail a bit to make it look more like a fuse burning. I've shortened it since this screenie was taken.
http://www.metallisoft.com/files/descen ... mortar.jpg

My absolute favorite!! Can't describe, must see. (And people have the balls to say that I have an advantage..hahahaha)
http://www.metallisoft.com/files/descen ... napalm.jpg
http://www.metallisoft.com/files/descen ... apalm2.jpg

Again, no real biggie to see, just increased the sparks a little bit. The smart balls have thrice the sparks tho, and longer. Looks 'smart' Image
http://www.metallisoft.com/files/descen ... /smart.jpg

You guys probably saw this in Team Veins, the white lasers! Another favorite of mine, which DCrazy had the nerve to say gave people an advantage because it 'lights up the hallways better than the yellow lasers' ROFLMAO!!!
http://www.metallisoft.com/files/descen ... rlaser.jpg
I also made the impacts planar(Like the Fusion impacts).
http://www.metallisoft.com/files/descen ... laser2.jpg

Yet another favorite. I made this partially from a mod I saw somewhere, that tried to put smoke on cyclones, but it didn't look right, but this setup is a combination of smoke sparks and an inverted smoke trail. Once this bad boy locks on, it looks frightning!
http://www.metallisoft.com/files/descen ... ins1-a.jpg
http://www.metallisoft.com/files/descen ... ins1-b.jpg
User avatar
Krom
DBB Database Master
DBB Database Master
Posts: 15184
Joined: Sun Nov 29, 1998 3:01 am
Location: Camping the energy center. BTW, did you know you can have up to 100 characters in this location box?
Contact:

Post by Krom » Tue Aug 19, 2003 12:44 pm

Yes that would be cool, as long as I could turn it all off!
User avatar
Suncho
DBB Defender
DBB Defender
Posts: 3222
Joined: Sat Jan 30, 1999 3:01 am
Location: Richmond, VT
Contact:

Post by Suncho » Tue Aug 19, 2003 1:51 pm

<font face="Arial" size="3">Know what would be really cool? If 1.5 implimented some of my eyecandy mods.</font>
Lame.
User avatar
Testiculese
DBB Material Defender
DBB Material Defender
Posts: 4680
Joined: Sun Nov 11, 2001 3:01 am
Contact:

Post by Testiculese » Tue Aug 19, 2003 5:26 pm

Then explain why.

All I'm doing is offering ideas. If you're determined to have a closed mind, then I don't think your input in this discussion is needed.

Anyone have any real opinions? Now's the time to get it out, while it can be done.
User avatar
Testiculese
DBB Material Defender
DBB Material Defender
Posts: 4680
Joined: Sun Nov 11, 2001 3:01 am
Contact:

Post by Testiculese » Tue Aug 19, 2003 5:42 pm

<BLOCKQUOTE><font size="1" face="Arial">quote:</font><HR><font face="Arial" size="3">Originally posted by DigiJo:
-what kind of weapons a player has and the ammount of ammunition should be managed by the server, so that the player that spawns in front of me cant kill me with a mortar anymore a second after spawn Image</font><HR></BLOCKQUOTE>

When the first missleboat levels came out, I was wondering if people were upping the ammo count on weapons or not, so I tested it in a closed loop. I increased the 4pack homers to 8 pieces, and fired all of them at a stationary ship(felt so dirty throwing 8 on a row). Only 4 were visible and did damage to the ship. So I think we're already ok there.

Why would a check on textures be warranted?
DigiJo
DBB Ace
DBB Ace
Posts: 491
Joined: Thu Jul 18, 2002 2:01 am
Location: Germany
Contact:

Post by DigiJo » Tue Aug 19, 2003 6:10 pm

hmm i think there are ways to keep the weaponslots full with all this memlock stuff, thats why i suggested alternate memory positions for gameplay relevant variables. (windows loads them at the same position everytime you start d3). but i have never teste that so i am not sure.
for the texture check, thats a way this fly trough wall cheats work.
DigiJo
DBB Ace
DBB Ace
Posts: 491
Joined: Thu Jul 18, 2002 2:01 am
Location: Germany
Contact:

Post by DigiJo » Tue Aug 19, 2003 6:13 pm

btw your weapon effects rock testi Image
Max_T
DBB Admiral
DBB Admiral
Posts: 1685
Joined: Wed Jul 10, 2002 2:01 am

Post by Max_T » Thu Aug 21, 2003 11:30 am

yeah, no additional effects please...good thing we can turn existing effects off.
User avatar
AceCombat
Owned by Timex
Owned by Timex
Posts: 6510
Joined: Sat Apr 12, 2003 2:01 am
Location: Conyers, GA, USA

Post by AceCombat » Sat Aug 23, 2003 8:04 pm

if a person is caught cheating, we usualy ban IP's and Player names, this has turned out to not be enough, if its possible MAC Addresses and even SubNets need to be banned to forever kill the hackers ability, as i just posted in another thread there is no one identical MAC address ANYWERE in the world, every single one is unique
User avatar
Kyouryuu
DBB Alumni
DBB Alumni
Posts: 5775
Joined: Fri Apr 30, 1999 2:01 am
Location: Isla Nublar
Contact:

Post by Kyouryuu » Sat Aug 23, 2003 8:09 pm

<BLOCKQUOTE><font size="1" face="Arial">quote:</font><HR><font face="Arial" size="3">Originally posted by Mobius:
If I can't use my nice eye-candy modifications, I will quit D3 online for good, take down my D3HELP web site and uninstall it from both computers. I'll also have the Xtra New Zealand server taken down. COMPRENDEZ VOUS?</font><HR></BLOCKQUOTE>

I care? It's obvious to me you don't like this game. If trivial eye-candy modifications are all that keep you playing it, then it's clear all interest is lost. Image

Testi - I wouldn't want an eye candy mod because, to me, it looks garish at best, ugly at worst. If I wanted overly flashy weapons, I'd go and play Forsaken. Yours aren't as bad as others, though. Somehow, those 1,500 poly Pyros look horrendously ugly when in the confines of a box like Burning Indika. Image
User avatar
DCrazy
DBB Alumni
DBB Alumni
Posts: 8826
Joined: Wed Mar 15, 2000 3:01 am
Location: Seattle

Post by DCrazy » Sat Aug 23, 2003 9:53 pm

<BLOCKQUOTE><font size="1" face="Arial">quote:</font><HR><font face="Arial" size="3">Originally posted by [RIP]Hydra:
<b> CRC32 when done right isn't as easily faked as you might think.

Eg. In my one program all cheat communication between the server and the client is RC2 encrypted and the checksums SHA256 hashed.

So, say you "trick" the CRC32, you still then have to break the RC2 encryption key that the server and client are using.
In the case of my last project, it's variable between each clients connection, and each client is uniquely identified regardless of his IP, MAC etc...

To top it off, the server can set the encryption method on the fly. So it switches between RC2, RC4, Blowfish and about 10 others.
</b></font><HR></BLOCKQUOTE>

I don't understand the point of all this encryption if the client can simply refuse to generate a CRC32 in the first place... the server is definitely going to be looking for a main.exe with a certain checksum, and regardless of whatever encryption is applied to that checksum before transmission, nothing prevents a hacked client from simply encrypting a hardcoded checksum. Somewhere the executable has to generate the CRC32 of the file; what's preventing a hacker from opening up main.exe in a disassembler and replacing the call to this checksum-generating function with a simple push of a hardcoded checksum?

It's not like we're encrypting passwords or SSH sessions here, which have completely variable contents. The CRC32 of an unhacked main.exe is publicly available (hell, just get a CRC generator and get it, or just add the file to WinRAR and it will tell you the CRC).
[RIP]Hydra
DBB Ace
DBB Ace
Posts: 45
Joined: Thu Jun 27, 2002 2:01 am

Post by [RIP]Hydra » Sun Aug 24, 2003 12:28 am

<BLOCKQUOTE><font size="1" face="Arial">quote:</font><HR><font face="Arial" size="3">Originally posted by DCrazy:
<b> I don't understand the point of all this encryption if the client can simply refuse to generate a CRC32 in the first place... the server is definitely going to be looking for a main.exe with a certain checksum, and regardless of whatever encryption is applied to that checksum before transmission, nothing prevents a hacked client from simply encrypting a hardcoded checksum. Somewhere the executable has to generate the CRC32 of the file; what's preventing a hacker from opening up main.exe in a disassembler and replacing the call to this checksum-generating function with a simple push of a hardcoded checksum?

It's not like we're encrypting passwords or SSH sessions here, which have completely variable contents. The CRC32 of an unhacked main.exe is publicly available (hell, just get a CRC generator and get it, or just add the file to WinRAR and it will tell you the CRC).</b></font><HR></BLOCKQUOTE>

Hehe, I had this long ass technical response ready to type out, but it's late and I don't feel like typing.

You act like any 2nd year college student could hack software on his Palm.
I'm not talking about changing some offsets in some game file, that's not real hacking and is easily detected.

I'll keep it simple for right this second.
Auto updating of the client.

Let's say that it even took you on the low side, 5 hours to hack the client. It takes about 30 minutes to an hour to release a comletely different version that your hack no longer works with.

So you spend another 5 hours to hack it again.
They take another 30 minutes to an hour to release an update.

Who gets tired first?

It all comes down to proper planning and resources.
If you plan and design it right instead of just releasing it, you'll end up with something that works.

Hehe, go ask 1 of the over 1000 people, yes, over 1000, who use my Anti-Cheat software for America's Army if I know what I'm talking about.

Or better yet, ask one of the people who's now banned from playing it if I know what I'm talking about.

It's not hard to check up on.
I go by [RIP]Hydra there too.

I assure you, I'm no script kiddie.
User avatar
Genghis
DBB Newbie
DBB Newbie
Posts: 1377
Joined: Fri Feb 12, 1999 3:01 am
Location: Ithaca, NY, USA

Post by Genghis » Sun Aug 24, 2003 12:32 am

So have the server send a nonce over to the client to incorporate into the checksum.
User avatar
DCrazy
DBB Alumni
DBB Alumni
Posts: 8826
Joined: Wed Mar 15, 2000 3:01 am
Location: Seattle

Post by DCrazy » Sun Aug 24, 2003 5:59 am

Hydra, I figured that's what you were going to say... "if they find a way around it, recompile the executable and screw them up." There's just one problem with that in the D3 community: nobody can do that! The only person that is able to recompile the game is Kevin Bentley, and he hasn't worked for Outrage for God-knows-how-long, and is writing the 1.5 patch as a labor of love.

Half-Life solves this problem by allowing the server to execute code on the client's machine. Bad idea, I believe, but even with that option the amount of hackers in Counter-Strike is still astronomical. And unlike other games, updating is not required to play D3 online; PXO does not force (or even notify) users to get the latest patch, unless someone manually adds it to the Message of the Day.

Believe me, I don't think you're some script kiddie. But all the encryption functions in the world can't do jack if the executable itself is compromised.

<hr>

As a side note, what would be nifty would be a nightly build that changed just some place in the code, just a few offsets, and everyone would have to download a small (I'm talking a few kilobytes) patch to update their client. This would REALLY piss off hackers, not only in D3 but also AA or HL/CS. One problem, though, is that many hacks don't even affect the game's code; wallhacking is typically acheived by modifying the OpenGL DLL on the system to not render walls. Image
DigiJo
DBB Ace
DBB Ace
Posts: 491
Joined: Thu Jul 18, 2002 2:01 am
Location: Germany
Contact:

Post by DigiJo » Sun Aug 24, 2003 6:12 am

i am probaly wrong here but since when is the collision detection calculated in the ogl-renderer? you can make the walls transparent but flying throught them? no thats made with manipulating d3 files i am pretty sure.
[RIP]Hydra
DBB Ace
DBB Ace
Posts: 45
Joined: Thu Jun 27, 2002 2:01 am

Post by [RIP]Hydra » Sun Aug 24, 2003 12:42 pm

<BLOCKQUOTE><font size="1" face="Arial">quote:</font><HR><font face="Arial" size="3">Originally posted by DCrazy:
But all the encryption functions in the world can't do jack if the executable itself is compromised.
</font><HR></BLOCKQUOTE>

Agreed. That's why I was saying that the type and extent of Anti-Cheat measures that you can use depends on your available resources. Servers, Coder(s), etc...

Like in the AA one I wrote, I have access to about 6 servers that can run any server side code I want, as well as store and distribute client updates. I routinely distribute updates via the Auto-Updater whether or not I actually did any bug fixes etc...

Without these type of resources, you'll be limited to a one shot deal, which given time will definitely be circumvented.

You hit it right on the head about CS and the rest. They aren't all hacked directly.

One of the worst hacks for AA is a hack called EvilHack.
It originally worked by attaching to the AA process and intercepting DirectX calls. I easily defeated that just by checking the modules attached to the AA process.
He then changed it over to an IAT Patch that required a loader.
The simple explanation is that was detected by checking the base address of D3D8.dll and comparing it to what the IAT of D3D8.dll was in the AA process. (system files should be the same address for every app that uses it, but not always).

Now, he uses a similiar technique to get it loaded, but has added Detours (trampoline functions) to it. Now once it's loaded it changes the IAT back to what it's supposed to be.
This too can and is detected, but because it's my current method and this is a Public forum, I'm not going to explain.
Suffice it to say that even though AA has PunkBuster integrated into it now, PB only catches EvilHack when the EvilHack user is using certain options with it. The method I'm using catches it every time.

But, enough about AA, hehe.

Another key step in writing the client is to add fuzzy code. (ie. code with nonsense and cross jumps making it
harder to trace the code without making it noticably slower)
Nothing more frustrating than stepping through code when it's full of cross-jumps and do-nothing routines. Of course that's providing you get passed the API functions that can detect the process is running under a debugger in the first place.

Once a good stable core system is built, it would be very simple for Kevin to batch the builds and do exactly like you said. Change some small things here and there, and rebuild it.

But again, any type of real system will require resources.

Now it's my understanding that D3's updater used to, or rather tries, to get it's updates from Outrage.com, which is no longer.

If somebody from the community were to buy that domain, someone who has physical access to a server, wouldn't that fix the D3 update problem?

Remember, these are just ideas I'm kicking out, the same as everyone else here. I didn't say I was going to write anything myself, all I've offered is some advice from someone who's successfully done it. Some of the things I've done in the AA one aren't applicable to D3. But maybe one of the ideas will trigger another idea from someone else that would work for D3.


Here's some little tips that I've used, note, some are written in Assembly.


Don't use meaningful procedure names.
This should be a no-brainer. If you have a function named 'CRCThis', well, what do you think the first routine that gets scrutinized is gonna be.

Use checksums in DLL's and in the EXE. Have them check each other. Far away from "safe", but it just makes it harder to crack.

Don't use literal strings that tell the user: "Sorry, but... (whatever)." These are the first things to look for. Build strings dynamically or encrypt them.

Don't use validation functions. Write your validation code inline with the current process. That just makes more cracking for the cracker and bewares of just NUL'ing out your routine.

Use "reserved" names. When using hard-coded keys or passwords, make them look like program code or function calls (i.e., "73AF" or "GetWindowText"). This actually works very well and confuses some decompilers.

The rcr/rcl trick.
If a rcr/rcl is performed on a value, it becomes much more of a pain to crack - you can't reverse it with by negating it's effects without knowing what the value of the carry flag was before the original operation. If the carry flag is created as a result of some other pain in the neck operation, you are probably onto a winner.

Like stated earlier, stick conditional jumps in. Everywhere.
Conditional jumps are not fun to reverse engineer. No loops, but jumps which conditionally bypass/include portions of your key manipulation code. There is no easy inverse operation to be performed here.

Use portions of the code as magic number tables.
(preferably critical sections). You have no idea how annoying this can be, most crackers like to change things around using softice (a popular cracking tool).

Play with the cracker's mind.
This one is fun :-) Stick series of nops in, as though you were doing self-modifying code (oh my god! what the heck! nops? Aha! Self-modifying code! Idiot spends next three years trying to find the code that should be there.). Pepper the code with junk instructions. Cut the code up into little pieces and put them all over the executable, with (preferably conditional) jumps between them.

Detect SoftIce. Early.
Now crash the computer. You can crash a pentium or a pentium with MMX even without a vxd by the opcode: F0 0F C7 C8 (illegal form of cmpxchg8b instruction with lock prefix). Beyond that, you have to resort to the tried and true methods. Using a vxd, take the CPU out of protected mode. Windows doesn't like that. Wonder why?


But the biggest tip/advice that I can think of, is that ALL software can be hacked/cracked.
You just have to try and make it not worth the time.
User avatar
Genghis
DBB Newbie
DBB Newbie
Posts: 1377
Joined: Fri Feb 12, 1999 3:01 am
Location: Ithaca, NY, USA

Post by Genghis » Wed Sep 03, 2003 5:01 pm

Kevin,

The 1.5 patch as it stood when it was leaked about a year ago has already been hacked. However, the most dangerous hacks out there have nothing to do with the D3 code. You should still be able to detect them, though.

You should have received an email from a friend of mine with information on how these cheats work, including some attached files. He hasn't heard back from you, which I understand if you're busy. But I would like to know if these cheats will be addressed by the patch or not. If you didn't get the email, can you check to see if your DBB profile has your current email listed? Or, if you don't want your email public, would you send it to me? (I can keep it private; I'm old and responsible Image)

Sorry to badger you, but we all know this is our last patch for D3 and would really love to see it address at least the currently known hacks.

- Genghis
User avatar
DCrazy
DBB Alumni
DBB Alumni
Posts: 8826
Joined: Wed Mar 15, 2000 3:01 am
Location: Seattle

Post by DCrazy » Thu Sep 04, 2003 3:29 pm

Hmm... I need to learn assembler. Image I guess there are a few common sense ones that I always follow:

1. Strip debug info. No brainer.

2. "inline" functions when possible (and feasible).

3. Store strings in a string table, not in the code. This keeps resources together and away from the code that uses them, and is really just a generally good practice to begin with.

4. Obfuscate, obfuscate, obfuscate.

4. Don't include variable names in error messages. "player->m_nPlayerAllowedHealth was too high!" isn't a good error message, as it lets crackers know in what object a certain variable is located, and given the context of the error, what its purpose is.
User avatar
Floyd
DBB Captain
DBB Captain
Posts: 561
Joined: Sat Apr 26, 2003 2:01 am
Location: Germany
Contact:

Post by Floyd » Fri Sep 05, 2003 11:44 am

dunno if this has been mentioned yet (no time to read through right now):

1. let the server refuse joining players with a space as name or empty names.
2. add a delay between observer changes (say 5-10s before one can get back to observer after he left obs.).
User avatar
Genghis
DBB Newbie
DBB Newbie
Posts: 1377
Joined: Fri Feb 12, 1999 3:01 am
Location: Ithaca, NY, USA

Post by Genghis » Sun Nov 16, 2003 12:22 pm

bumping to keep within 30-day window Image
User avatar
Genghis
DBB Newbie
DBB Newbie
Posts: 1377
Joined: Fri Feb 12, 1999 3:01 am
Location: Ithaca, NY, USA

Post by Genghis » Wed Feb 04, 2004 11:17 pm

Bumping, just in case Kevin wants to see this.
User avatar
Ferno
DBB Stoner
DBB Stoner
Posts: 14341
Joined: Fri Nov 20, 1998 3:01 am

Post by Ferno » Thu Feb 05, 2004 3:03 am

I don't think more cheat detection code is such a hot idea guys..
Locked