Anti-Cheat Brainstorm

[Auntie Mangos]

1. Speedhack

2. Teleportation

3. Flying

4. Climbing/Gravity/Jump-height

5. Water Breathing

6. No Fall Damage

7. Undetectable From the Server Side

http://getmangos.eu/community/showthread.php?p=48514#post48514

My patch in current state:

1. Speedhack fixed - compare last and current position from movement packets, and check current speed and time between packets.

Overping checks are currently exists in mangos core:

#    MaxOverspeedPings
#        Maximum overspeed ping count before player kick (minimum is 2, 0 used for disable check)
#        Default: 2

2. Teleportation fixed - same way as speedhack (compare coords and checking teleport events).

3. Flying fixed by checking MOVEMENTFLAG_CAN_FLY, MOVEMENTFLAG_FLYING and MOVEMENTFLAG_FLYING2 flags and current auras. On this moment I don't see anything that send only MOVEMENTFLAG_SWIMMING for flying.

4. Mountain climbing partialy fixed by checking tangent of angle between horizontal plane and movement vector of player (the maximum climbing angle in client is 57 degree (it's empirical value)).

Gravity and jump heigth not yet implemented, because it's need too many system resources to check (VMAP).

5. Water Breathing - not implemented.

6. No Fall Damage - fixed with alternative falltime calculation on serverside.

7. Undetectable From the Server Side - confirm, it's undetectable

[Cypherjb]

Hey, I thought I'd give an overview of the most common cheats available and how to go about detecting them on the server. This thread is intended as a 'developer brainstorm' thread in order to think of good ways to combat hacks. Non-developers please refrain from posting unless you are sure you know what you are talking about and can make an intelligent post. I personally am a reverse engineer and hacker for WoW (and other game when I get bored), and as most people know the first step to victory is to "know thy enemy", which is why 99.99% of copy protection schemes don't work (because they were written by regular programmers, not crackers, if you don't understand how to defeat protection, you won't know how to write it properly).

1. Speedhack

There are two different types of speedhacks that are normally used (there are other ways to do it but none are currently public so I shall not go into detail).

a) API Hook.

By far the easiest to implement these hacks work by hooking the operating system's timing APIs (eg on Windows you would hook QueryPerformanceCounter, GetTickCount, and timeGetTime) then manipulating the return value in order to throw off the games sense of timing and cause key parts to "run faster" than they should. (By faster I don't mean it will execute any faster, just that time synced actions will happen more frequently).

The problem with this approach is they are usually not tagetted and are implemented in a process-wide or even system-wide hook. The easiest way to detect this would be with the massive influx of packets to the server. Due to the nature of the hack packets would be sent at a greatly increased rate and this could easily be picked up by the server. One problem with this would be that "lag spikes" may cause a massive influx of packets and so extra validation may be needed, and/or a modifiable threshold.

Another way to detect this would be to do one of the normal 'distance' checks over a period of time. eg If the player moves more than X yards in Y seconds and doesn't have A, B, or C buffs to account for it they must be exploiting.

A third way to detect this possibly (I havn't checked this) would be to validate the timestamps on all incoming packets. Not sure if this is possible as I havn't checked WoWs implementation of the timestamps etc.

b) Memory Editing

By far the most common way to speedhack on emulated servers is to just modify the speed variable in memory. This has the advantage of being independent from all other game mechanics and so is much more 'natural'. Although this is much easier to detect.

The easiest way to detect this would be to validate the speed of the player as outlined above. Or, if the player speed is sent in the MSG_MOVE packets (I can't remember if it is off the top of my head) that would obviously be very easy to validate.

2. Teleportation

There are several ways to do this but only one is common publicly so it shall be the one I go into.

a) Memory Editing

By far the most common way to teleport is just modify the players coordinates in-memory to physically 'warp' the player to somewhere else on the current map. This can be detected very easily when the player moves with a quick distance/time check. Some emu server (not sure which) seem to be vulnerable to an exploit where after warping the player mounts then dismounts and can then move again, this could be fixed quite easily if needed afaik.

Teleporting can be achieved with packet spoofing but this is out of the league of most public hacks so unless its an issue I will ignore it for this post.

3. Flying

There are two main ways to do this. One by changing the players movement state to emulate "swimming" the other is hooking several functions inside WoW to allow the player to "walk" without restrictions on the Z axis (ie they are no longer bound to the ground).

a) Movement State

Very easy to detect. The obvious way would be to just check whether the 'flying' flag is enabled and kill the users connection if it is, this has a flaw though, by hooking the packet sending function users can spoof off this flag. To get around this trickery the server can just monitor for PITCH_UP and PITCH_DOWN movements, whenever these occur and the player is not swimming/flying-mount/etc then its obvious they're using a fly-hack.

b) Code Hook

This one is more difficult to detect. It would most likely require use of VMaps to validate the distance of the player from the ground at any given time, this could potentially eat up a lot of resources. I currently cannot think of a more reliable way to detect this method because no pitch packets are sent as the player is technically just 'walking' not 'swimming/flying'.

4. Climbing/Gravity/Jump-height

Implementation for these is pretty much irrelevant although I will point it out anyway.

The easiest way a climb hack is to just modify the max climbing angle constant in the client. (Stored as the cosine of 50deg).

Easist way to implement a gravity or jump height hack is again to just modify the constants in the client. (All stored as floats in .rdata)

All of thsese would be difficult to detect from the server-side and would probably also requrie the use of VMaps unfortunately.

Although, you could possibly detect the jump height or gravity hacks by doing a height check after the player jumps, but this obviously has huge drawbacks as there are other things that could cause large knockback at the same time.

5. Water Breathing

Havn't looked at the implementation of this so I can't go into too much detail but this can be fixed because it doesn't work on retail servers. I assume you could fix it by just managing the timer on the server-side.

6. No Fall Damage

Fall time is calculated in the client and as such the user can spoof modified values to the server. Typically it is done via a code hook which checks if the fall time is above the maximum before the player takes damage and if it is then it resets it to this value, because the sever relies on the data in this packet to calculate fall damage you would have to validate the fall time with a height check (using the aid of vmaps, again). Unfortunately I don't know of a better way to detect this.

7. Undetectable From the Server Side

Unfortunately short of writing a Warden client the following cannot be detected on the server if implemented properly:

* Tracking (In either form, either by modifying the flags in the descriptor array or by hooking CGLocalPlayer_C::TrackUnit and CGLocalPlayer_C::TrackObject)

* Model edits (In either form, either by hooking the MPQ loading function or just patching the signature check, both are only detectable on the client-side. One exception would be BG exploiting model edits, you could stop the ones that allow early exit from the starting area by simply checking all players are inside a predefined box covering the entire starting area whilstever the round has not started yet)

* Levitate (Implemented correctly this would probably be undetectable because you can spoof off this flag with no adverse effects, detecting it would probably require if the user is over water and 'walking' rather than swimming, this would probably not be worth targetting though)

* No Clip (Short of some crazy math you probably won't be able to fix this, although by fixing fly hacks you remove most of a no-clip hacks utility)

* Morph (These work by just modifying the display id in the descriptor array then calling a function inside WoW to destroy and recreate the model, client-side change so you can't detect this afaik, although its purely a cosmetic change with no unfair advantage so I wouldn't worry)

* Object Movers (These work by enumerating either the world object or game object arrays and allowing the user to modify the x/y/z of the objects, this is usually done by setting the mouse type to an AOE circle in order to get in-game coords then finding the object nearest and moving it as the mouse is "dragged", unfortunately this is another cosmetic change although this one CAN give advantages in certain situations, not much you can do here)

* Other cosmetic stuff (drunkness, emotes, etc. This is all purely cosmetic and can be ignored)

I think I've covered most public hacks now, if there is anything I have missed let me know and I shall address it.

To the developers: If you would like souce code demonstrating the implementation of any of these hacks please let me know and I will post it either here or PM it to you (please specify), I can also provide the addresses of functions and constants that these hacks use in order to aid your reversing efforts to speed up the fixing of any of these problems.

[FH3095]

Nice work!

While reading this post, I get some new ideas for my anticheat. Thanks for that.

The water breathing was done by sending packets with more than the normal size, so mangos become confused.

This is already fixed, as far as I know.

Greetings

FH

[Cypherjb]

Nice work!

While reading this post, I get some new ideas for my anticheat. Thanks for that.

The water breathing was done by sending packets with more than the normal size, so mangos become confused.

This is already fixed, as far as I know.

Greetings

FH

Thanks, I didn't have access to my subversion server at the time of that post. I've dug up all the code I was missing now.

[anr1363]

Hi

How To download and use your anticheat ?

[Cypherjb]

Hi

How To download and use your anticheat ?

/facepalm .

[thenecromancer]

I assume you could fix it by just managing the timer on the server-side.

This.

The problem is that water detection on server is not really that great and still fails a lot of times.

It also pretty much disallows checking for swim movetype to disallow flying cheats :-/ ...

[anr1363]

/facepalm .

Plz Help i am new don't understand?

[leak]

Plz Help i am new don't understand?

You made it through the registration so we can assume you have some sort of reading ability.

http://en.wikipedia.org/wiki/Brainstorming

Start here please.

[Cypherjb]

This.

The problem is that water detection on server is not really that great and still fails a lot of times.

It also pretty much disallows checking for swim movetype to disallow flying cheats :-/ ...

How about this.

For the first movement packet a server receives that indicates the client is swimming the server 'starts the clock', whenever the client exits the water the server 'winds back the clock' the right amount, then forward again when the client is swimming again, etc, and disposing of the timer when its at full.

The 'flying' flag is actually a different flag to the 'swimming' flag they just act in the same way.

Because of this you could still kick users with the flying flag enabled without interfering with the swimming stuff, they are two separate things as far as I am aware (although I would have to double check, I will do so when I get some spare time).

Even if the swimming flag CAN be used to fly you could still just use VMAPs to detect the flying crap (which would also take care of the non-flag based flying hacks).

And oh, by the way, generally the flag can be toggled off in the packets client side, so you're not looking for the flag, you're looking for PITCH_UP and PITCH_DOWN movements that aren't supposed to be there.

[Mynt]

One of the most common bugs among servers is the ability to stat stack. I don't honestly know any way around this except doing a random redundant check on items. In Leaf we just randomly select a connection and compare item variables to the database. One problem with it though. It takes alot of memmory from redundancies.

-Mynt

[Cypherjb]

One of the most common bugs among servers is the ability to stat stack. I don't honestly know any way around this except doing a random redundant check on items. In Leaf we just randomly select a connection and compare item variables to the database. One problem with it though. It takes alot of memmory from redundancies.

-Mynt

I'm talking more about client-side hacks here rather than server-side bugs but nevertheless its interesting.

Regarding stat stacking, how exactly does that work? Could you provide me with an example of how it's done so I could dig into the related code. I don't see how a bug that allows stat changing couldn't be just 'fixed' without the need for redundant checks.

[Cypherjb]

1-2. Your speed/tele anit-hacks could be bypassed with packet spoofing.

3. Your flying anti-hack could be bypassed by toggling off the flying flag in the movement packets. You should check for PITCHes.

4. You have the angles wrong. Maximum angle for players is 50 deg and maximum for npcs is 80. They're stored in the .rdata section as the cosine of the angle.

5. Ok.

6. Could be bypassed by hacking the client to not think its falling, at which point you would need to do more serverside checks and can't rely on packets from the client.

7. Yup

[CWN]

1-2. Your speed/tele anit-hacks could be bypassed with packet spoofing.

3. Your flying anti-hack could be bypassed by toggling off the flying flag in the movement packets. You should check for PITCHes.

4. You have the angles wrong. Maximum angle for players is 50 deg and maximum for npcs is 80. They're stored in the .rdata section as the cosine of the angle.

5. Ok.

6. Could be bypassed by hacking the client to not think its falling, at which point you would need to do more serverside checks and can't rely on packets from the client.

7. Yup

1-2-3 and 6 - ok, your write cheat that doing all what you describe (or showing existence) I see on it and modify anticheat for new reality.

4. You have the angles wrong. Maximum angle for players is 50 deg and maximum for npcs is 80. They're stored in the .rdata section as the cosine of the angle.

57 degree it's experemental maximum value, that contain some additional tolerance. In reality the calculated angle on serverside may more than 50 deg.

[Cypherjb]

1-2-3 and 6 - ok, your write cheat that doing all what you describe (or showing existence) I see on it and modify anticheat for new reality.

57 degree it's experemental maximum value, that contain some additional tolerance. In reality the calculated angle on serverside may more than 50 deg.

Showing existence? Sure. Here's a pic of me testing some stuff (3.0.2 - Retail Servers):

[EDIT: DO NOT POST INGAME SCREENSHOTS]

You said the maximum angle in the client is 57 degrees which is incorrect, I was just pointing that out. Whats calculated on the server is a different story.

And here's some proof for you (from 3.0.2):

.rdata:0096F640 CGlobals__MaxPlayerClimbAngle dd 6.4278764e-1 ; DATA XREF: sub_68F350r

.rdata:0096F640 ; sub_68F380:loc_68F3A0r ...

.rdata:0096F668 CGlobals__MaxNpcClimbAngle dd 1.7364818e-1 ; DATA XREF: sub_68F380+Fr

.rdata:0096F668 ; sub_68F5B0+31r ...

Take the inverse cosine of those floats to get the angle.

[Cypherjb]

Quick bump.

Probably gonna be working on a private server hack soon so I'll probably post my findings in the process if anyone is interested? I'll try and find suggested fixes too.

[FH3095]

That would be nice.

Greetings

FH

[The_Game_Master]

How about instead of createing thousands of check, let's create support for "Warden". As far as i know the client comes with something like this implemented.

[arrai]

How about instead of createing thousands of check, let's create support for "Warden". As far as i know the client comes with something like this implemented.

Warden relies purely on obfuscation. As soon as MaNGOS, as an open source project, would implement it, all security is lost. For that reason it is not planed to implement it.

[Cypherjb]

How about instead of createing thousands of check, let's create support for "Warden". As far as i know the client comes with something like this implemented.

I'm gonna go ahead and assume you don't understand the magnitude of work that would entail.

Warden relies purely on obfuscation. As soon as MaNGOS, as an open source project, would implement it, all security is lost. For that reason it is not planed to implement it.

Thats far from the only problem.

[Wyk3d]

Thats far from the only problem.

I agree, but depending on how you look at it, it's the biggest problem, a showstopper if you will. Even if you work hard for many months and manage to reverse engineer 100% of the warden code, it will still be useless in an open source project. If the people writing the cheat programs would know how warden detects them, and more importantly, would know when detection support for their cheat is being added to it (on official they only know this after someone has been banned), they would easily be able to keep themselves undetected and it would be much harder to catch people using these tools.

[Cypherjb]

I agree, but depending on how you look at it, it's the biggest problem, a showstopper if you will. Even if you work hard for many months and manage to reverse engineer 100% of the warden code, it will still be useless in an open source project. If the people writing the cheat programs would know how warden detects them, and more importantly, would know when detection support for their cheat is being added to it (on official they only know this after someone has been banned), they would easily be able to keep themselves undetected and it would be much harder to catch people using these tools.

Well, despite this being an open source project I highly doubt server admins would protest to having WardenClient.dll supplied without source. Just make it a seperate project, an optional component that is closed source and supplied with a core patch to enable support for it. Thats not difficult at all, it would only really conflict with the "spirit" or "essence" of the project, although in my opinion security should sometimes trump those things if obscurity is the only option.

The actual work lies in reversing what I would call one of the most 'complex' parts of WoW.

PS. A friend of mine (Kynox) DID work hard for a long time and reverse pretty much all of Wardens code. He can connect to live servers and emulate a full dummy session including Warden requests and responses. After seeing most of the code for that and full dumps of what warden is doing I can tell you there is a LOT of work involved, far far far more than your average packet reversing session.

[xeross155]

Well, despite this being an open source project I highly doubt server admins would protest to having WardenClient.dll supplied without source. Just make it a seperate project, an optional component that is closed source and supplied with a core patch to enable support for it. Thats not difficult at all, it would only really conflict with the "spirit" or "essence" of the project, although in my opinion security should sometimes trump those things if obscurity is the only option.

The actual work lies in reversing what I would call one of the most 'complex' parts of WoW.

PS. A friend of mine (Kynox) DID work hard for a long time and reverse pretty much all of Wardens code. He can connect to live servers and emulate a full dummy session including Warden requests and responses. After seeing most of the code for that and full dumps of what warden is doing I can tell you there is a LOT of work involved, far far far more than your average packet reversing session.

You could probably write something to prevent people from modifying the clients memory, that would disable most hacks except the packet modification ones.

[alein]

Cypherjb: excellent idea.

I love you guys.

[henhouse]

Congrats, you just bumped a 2 year old thread.