Cypherjb

Out of interest how do you intend to implement the actual pathfinding? A*? Dijikstra? Also, will it be done on-the-fly or will paths be pre-generated based on a navmesh from the MPQs.

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.

Ah nice. At any rate though. Using COBRA or not, IPC is more work to implement in terms of architecture. It has to be structured right otherwise its pointless to do. ie If one child dying kills the entire job then whats the advantage over plain multithreading? I wasn't saying that IPC per-se is hard to implement compared to multi-threading, but rather its harder to design correctly (imo). Thanks for the link btw.

I personally use VS Team Suite's profiler along with Intel's C++ profiling tools (VTune and their Thread Profiler).

Okay, lots of people seem to be misunderstanding this stuff. Whether you use threads or processes doesn't matter in terms of multi-core CPUs. A process is just a 'container' that holds one ore more 'threads'. A CPU does NOT execute processes, it executes the code in the THREADS. There is no work required in either case to "make one thread run on each CPU", the thread scheduler performs all this automatically and is generally much better at setting processor affinities than humans are, nevertheless if you really wanted to you COULD override it. Multi-threading will give a performance increase on multi-core systems, but introduces a LOT of problems if not implemented correctly. These will include race conditions, bottlenecks, etc. Also, one thread crashing brings down the entire process. The advantage is that multi-threaded code is a lot easier to write than multi-process. Multi-processes have the advantage of being "distinct" from one another. Usually you would have one "parent" process and a bunch of "children", all in the same Job group (or whatever your OS's equivalent is). One on side you have the advantages of increased stability in the form of one process not bringing down the bunch, on the other side the difference is possibly negligible in the case of software like this unless it is heavily rewritten. (ie if a core component dies your entire job is fucked anyway). Another disadvantage is the big difference between IPC over different operating systems, I personally use Boost for all my multi-threading needs in C++, I'm not sure if there is anything for multi-process that is as easy to use. People are talking about "clustering", I dont THINK that was the intention of the developers in terms of multiple-processors because that would requrie a lot more work and would require network communications and syncronizations along with the base IPC. There is no real difference in terms of multi-processes and multi-threading in terms of how many clients a single computer could handle. The differences on a single server would be stability (assuming its implemented very well) and ease of use. On multiple servers, if "clustering" were introduced, that would requrie multi-processes although that would be a very large scale change and would require massive amounts of work to be able to be used stablely and not just in a perpetual state of "unstable/beta". Anyway, my vote personally is for multi-processing because I would like to see better distinction between core components and if it was implemented correctly (thats the huge key) then it would be a lot more stable and fault tollerant.