DescentBB

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 (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.

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.

That's just your resolution, Sniper, 'cause this image looks fine to me. (920x760 rez)

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

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.

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.

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.

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.

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.

Yea, I was just throwing out rough ideas is all. Just an example.
There's a couple ways it could work.

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.

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.

<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.

Why don't we continue to update the existing 1.5 bug/feature thread you had going Suncho?

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.

-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

Floyd, what he's getting at is it's easy to run a check for gam cheats without disrupting what are not cheats.

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

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'
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

Yes that would be cool, as long as I could turn it all off!

<font face="Arial" size="3">Know what would be really cool? If 1.5 implimented some of my eyecandy mods.</font>

Lame.

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.

<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 </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?

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.

btw your weapon effects rock testi

yeah, no additional effects please...good thing we can turn existing effects off.

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

<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.

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.

<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).

<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.

So have the server send a nonce over to the client to incorporate into the checksum.

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.

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.

<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.

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 )

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

Hmm... I need to learn assembler. 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.

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.).

bumping to keep within 30-day window

Bumping, just in case Kevin wants to see this.

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