MQWarp/MQZone/MQGate Detector (Code Name: The VZTZ Hammer!)
 

May god have mercy on my soul for trying to diff this. I apologize that a lot of it will be redundant checks, but we've had to tweak it quite a bit to get it to the point where it is now. We only have false alarms when we hit a massive lag spike (which happens on occasion), but the only way around that would be to allow massive distance updates all the time - which defeats the purpose.

I know this won't fit into one post, and probably won't even fit into 3 or 4, but I'll do my best to get it all in.

Ok, *gulp* here goes.

Anti-MQ /Warp, Anti-MQ /Gate, Anti-MQ /zone, Anti-MQ /ghost code from the Vallon Zek/Tallon Zek Server:

In addition to myself, contributions to this code came from Rancar and Null.

.\common\ruletypes.h

After:

Add:



.\common\database.h

After:
Add:

.\common\database.cpp

After:

Add:

.\zone\client.h

After:

Add:

After:

Add:



.\zone\client.cpp

Change (Insert Red Lines):

.\zone\client_packet.cpp

After:

Add:

Change (Insert Red Lines):


Change (Insert Red Lines):

After:

Add:

After:

Add:

.\zone\client_process.cpp

Change (Insert Red Lines):

Change (Insert Red Lines):

.\zone\command.cpp

Change (Insert Red Lines):

Change (Insert Red Lines):

.\zone.mob.h

After:

Add:

Change (Insert Red Lines):



.\zone\mob.cpp

Change (Insert Red Lines):

Change (Insert Red Lines):

Change (Insert Red Lines):

Change (Insert Red Lines):

.\zone\spdat.h

After:

Add:

.\zone\spdat.cpp

After:

Add:


.\zone\spell_effects.cpp

Change (Insert Red Lines):

.\zone\spells.cpp

Change (Insert Red Lines):

After:

Add:

After:

Add:

.\zone\zone.h

Change:

To:


.\zone\zone.cpp

Change:

To:

Change (Insert Red Lines):

.\zone\zoning.cpp

After:

Add:

After:

Add:


After:

Add:

After:

Add:

After:

Add:

After:

Add:

Change (Insert Red Lines):


Change (Insert Red Lines):

After:

Add:

After:

Add:

Change (insert red lines):

REQUIRED SQL:

There are 15 new rules created as a result of this addition. Here is a breakdown of each:

Zone:EnableMQWarpDetector //Lieka: Enable the MQWarp Detector. Set to False to disable this feature.
Zone:EnableMQZoneDetector //Lieka: Enable the MQZone Detector. Set to False to disable this feature.
Zone:EnableMQGateDetector //Lieka: Enable the MQGate Detector. Set to False to disable this feature.
Zone:EnableMQGhostDetector //Lieka: Enable the MQGhost Detector. Set to False to disable this feature.

Zone:MQWarpExemptStatus //Lieka: Required account status to exempt the MQWarpDetector. Set to -1 to disable this feature.
Zone:MQZoneExemptStatus //Lieka: Required account status to exempt the MQWarpDetector. Set to -1 to disable this feature.
Zone:MQGateExemptStatus //Lieka: Required account status to exempt the MQWarpDetector. Set to -1 to disable this feature.
Zone:MQGhostExemptStatus //Lieka: Required account status to exempt the MQWarpDetector. Set to -1 to disable this feature.

Zone:MQWarpDetectorDistance //Lieka: Distance a player must travel between client to server location updates before a warp is registered. 30 allows for beyond GM speed without lag.
Zone:MQWarpLagThreshold //Lieka: Distance beyond the Zone:MQWarpDetectorDistance that a player must travel within the MQWarpThresholdTimer amount of time before tripping the MQWarp detector. Set to 0 to disable this feature.
Zone:MQWarpThresholdTimer //Lieka: Amount of time before the warp_threshold resets to the Zone:MQWarpLagThreshold value. Default: 90000 (900 seconds
Zone:MQWarpDetectionSpellID //Lieka: Which spell ID will be cast on players that incur the hammer of the MQ Detector. This spell will be actually cast don't pick a resistible spell. Default: 757 (Resurrection Effects)
Zone:MQZoneDetectionSpellID //Lieka: Which spell ID debuff will be cast on players that incur the hammer of the MQGateDetector. This spell will be added as a debuff while zoning. Default: 757 (Resurrection Effects)
Zone:MQGateDetectionSpellID //Lieka: Which spell ID debuff will be cast on players that incur the hammer of the MQGateDetector. This spell will be added as a debuff while zoning. Default: 757 (Resurrection Effects)
Zone:MQGhostDetectionSpellID //Lieka: Which spell ID will be cast on players that incur the hammer of the MQGhostDetector. This spell will be actually cast don't pick a resistible spell. Default: 757 (Resurrection Effects)

Updating your Zone_Points table for MQZoneDetector.

When an unsolicited zone request comes through (i.e. the client is requesting a zone change), the MQZoneDetector works with the source to determine if the player is within an acceptable distance of a zoneline. These zonelines must be set in your Zone_Points table in order for this feature to work correctly. The majority of the Zone_Points only specify the destination zone points, but have 0, 0, 0 for the source zone points. If it is a zone line (like literally a line), then you put 999999 for the appropriate value. Below is my list, list:

I do not have a complete Zone_Points table, but I do have Old World, FearPlane, HatePlane, and AirPlane updated in my table.

SQL Step 1: Wipe your old world zone lines (I'm assuming that we're all based off of PEQ originally (mine is based from Angelox, but originally still it was PEQ)).

This is a list of zone_points IDs that I have written insert statements for.

SQL Step 2: Batch the updated zonefiles back in.

SQL Part 2: Continued

SQL Part 2: Concluded

Holy shit - ok, I wonder if anyone else will actually make it through all that. ;) Nonetheless, that's the pride and joy of VZ/TZ - enjoy it and keep those hackers at bay. :)

Thanks,
Dax

dammit, I missed AirPlane:

Dax

Holy. Shit. Much appreciation Dax. I'll post results, may take me a few days :).

You have a duplicate Zone:MQGateExemptStatus rule in your sql. Should the last one have been :

I just have to say..


Thank you for sharing, this is big and will help the community.

This is wonderful, and I can't wait to try it out! However...

Could you post a diff against working code? Linux isn't liking client_packet.cpp at all and I want to rule out copy/paste errors on my part. (Though, there are a couple of typos as well, for example):

under Client::CheatDetected

needs to be:

Also, "False" in ruletypes.h needs to be "false", for Linux anyway.

Thanks for sharing this, it certainly is brilliantly written besides the minor typos here and there.

Sorry for the typos with the rules system (I put it together for the submission). I'll see if I can get you a diff, but we've deviated quite a bit from the standard build, so it will take me a bit. I'll see if I can get one together.

Dax

I understand completely, getting a clean diff from TGC wouldn't be easy either so I sympathize.

Ok, sorry for the false start. Yeah there were a few typos, etc with the previous code, I went through it again, and got a diff from it and 0.7.0-1102

Updated the SQL to address a couple of issues too.

Hopefully it should be good now. Let me know if you have any questions or concerns.

Dax

Compiled perfectly! I'm going to play around now, thank you!

:) Glad to hear it - there might be some issues from tying it into the rules system (I'm hoping not, but it was not tested nearly as thoroughly with the rules setup as it was prior to it), but other than that, it should be pretty much as it reads. Let me know if you have any questions or concerns.

Thanks,
Dax

Awsome man, thank you for the wonderful contribution to the emu community!

Yeah, thank you much. This is very much needed, I'm gonna let it sit on PEQ for a bit and see what CD thinks about it before moving it to official source. If there's a situation where false positives happen a lot I'd just like to resolve it before it gets put in is all.

Absolutely brilliant! Always such quality from you :)

I moved part of this to another forum (Development:: Development) as "MQWarp/MQZone/MQGate Detector Discussion".
This forum is intended for submissions only, so I tried to split up the thread as best I could - use the new thread for discussion.

Yes, we merged back with the eqemu source and use Wildcard's updates to the zoning stuff (getting all the bugs worked out of it made for an interesting week on our server ;)).

Here are the source snippets involved in pulling the zonepoints, then checking them against a zone request.

Here's the code that pulls and checks the zone points:


SQL query that pulls the zone points into the code:
from .\zone\zone.cpp
Here is the function that checks for the closest zone points.

In the `zone_points` table, your current entries are fine - they're just incomplete. If you then you will see the entries that need to be updated (pretty much all of them). I've already posted the list for old world zones, but kunark+ need to still be updated.

Basically, when there's an unsolicited zone request from the client (i.e. the client requests a zone change):

The function "ZonePoint* Zone::GetClosestZonePoint(float x, float y, float z, int32 to, float max_distance, Client* client)" compares the x, y (not target_x and target_y) in the records that match the target_zone_id within your zone_points table against the client's current x, y. If the (zonepoint->x - client->x) * (zonepoint->y - client->y) > 4000 (200*200), then it assumes that the zone request is the result of a hack (which it most likely is). So, if you have 0, 0 for a value in your x, y in the zone_points table, then unless the client is attempting to use that zone_point from close to that x, y in the zone, it will detect a /MQZone attempt. If the zone that the client is using is a zone wall (like East Commons -> West Freeport), you'll put 999999 for the x or y (whichever is appropriate), and it will exempt it that (x or y) from the check (because it's too damn hard to draw a line in the database).

Once you update these records in your zone_points table, you can #reloadzps from within that zone (the source zone, not the target zone), and retest them.

I hope that helps,
Dax

Ax - the submission thread for this is locked, could you move this code over for me?

I don't have a ton of time to document this, but it's well documented in the code. Long story short -

• Warp detection is now done by velocity rather than just distance. The time measurement is taken between Player Position Update packets being received.
• The velocity is taken by taking the distance / time since last PPU.
• If the detector trips, it moves the player back to his previous PPU location.
• Added the following rules:
  For Disabling MQDetector Penalties (Punishment for the player)
  For Disabling SQL Logging (haven't replaced it with text logging, but if it's a performance concern you can now disable it in the rules)
  For Disabling MQDetector Broadcast
  For Setting the Speed Limit (speed measured by units / second - this rule specifies the number of units a player is allowed to travel per second. From testing: 3-4 is level 50 SoW, 7 - 10 is GM Speed
• Added 4 new items to #showstats:
  Last PPU Time: Indicates how long it was since the last PPU for the player (in hundredths of a second)
  Longest PPU Time: Records the longest time between PPUs for the player (in hundredths of a second)
  Current Movement Speed: Indicates the current movement speed of the player
  Highest Movement Speed: Indicates the highest movement speed of the player

That's pretty much it - the rest is the same as my original submission, but I think these updates should be what the code needed.

Let me know what you think. :)

Thanks,
Dax

This Diff was taken against 0.7.0-1102
SQL Rules

Just a couple of comments on the code.

Firstly, excellent work. I love to see fixes for cheats and MQ type hacks.

One thing tho. might not even be yours, but they it was in yours posts:
Consider pre-squaring "RuleR(Zone, MQWarpDetectorDistance)" and eliminate the sqrtf(). sqrt() is very expensive. Most times you don't need raw distance, you just need to compare the two. i.e.
Expensive: if (sqrtf((dx*dx)+(dy*dy)) > 30)
Cheaper: if (((dx*dx)+(dy*dy)) > 900)

Yet they accomplish the same result.

Just some tips, otherwise looks good.

I'll make that change, we've also been doing some more testing with it (I've been really bogged down at work for the past month-ish), and found a few other places to refine the warp detection. I'll post those changes as soon as we get them completely ironed out.

Dax

Other things MQ does that I'm not seeing on this:

1) Let's you use a banker anywhere in the game.
2) Activate a door from anywhere in the zone (so if you have a teleport clicky zonepoint you can use it from anywhere for instance).
3) Equip things you can't use.
4) Loot corpses from anywhere in zone.
5) Bogus appearance packets (not just spawn packets) to change anyone's race / appearance etc. Not as trivial as it sounds, change a guy in a dungeon to size 50 and he's stuck.
6) Fake all sorts of things in the CastSpell packet - cast spells they don't have memorized, cast spells they have memorized as clicky spells (to prevent mana usage), cast clicky spells with a different slot (to prevent charges being used) and so on.

If there's already sanity checks in place for these, nevermind me, just wanted to bring it up.

Also remember that no warp detection will ever be perfect and can always be replicated by lag, so we've found that it's a bad idea to auto punish someone for warping - needs a human eye to determine if its authentic warping or just lag. Moving the person back to where they came from and freezing them for a few seconds might be a better idea than deathtouch.

This is exactly the kind of stuff that makes me all stiff in the britches for EQEmu again. I love this code, this effort, and the team work to iron out the iffy's.

I do not see this in the changelog yet. Is this still being evaluated for the base code? Can't wait.

Yeah, once I find a crash that I *somehow* introduced while testing this I'll submit it. It's being somewhat elusive and I dun wanna submit code that has a known crash.

I have added his diff from the 1102 code 2 times, but into 1108 and can't seem to get it to fully function, even though some of it does. I can't wait for this to get added into the main source! That and a few other additions will be nice.

Also, if you are doing a new update soon, KLS, I see that you don't have my fixmob post stickied. And, I think you guys sticky everything that is planned to go in at some point. The fixmob command change isn't huge, but without the changes I made, the command is only about half useful. With the changes it is fully functional and works flawlessly. They are very simple changes. I can always add them in manually before compiling, but it seems like something useful to have in the release source.

So, from looking at the source, it looks like the new eqemu binary code 1110 added in the detection from TZ/VZ, but it wasn't the most recent version of the detection which is noted in this quote. I updated to the latest 1110 code and so far it seems to be working very well. It has already detected some cheaters that I have confirmed are in fact cheaters. So far it looks great. I haven't seen any of the broadcasts and haven't heard any reports of players being punished by the tool, which are both fine with me. As far as I can tell, the only thing this does right now is log the MQ usage in the hackers table. Again, that is perfectly fine with me.

The reason I wanted to post here was to see if the latest updates on this code were under consideration for being added to the source. The last diff from TheLieka shows more features and probably better ways to detect warping and also catch more false positives. I could never get that diff to work properly with 1108. If TZ/VZ ever updates to 1110, I would love to see a diff from that with their latest anti-MQ code. I think it should be considerably less to change from 1102, since it now includes the MQ detection.

Also, I wanted to note that if anyone updates to the 1110, they will also want to add the rules listed below (and NOT the latest ones posted by TheLieka):

I didn't read through any of the actual source to see what all was added and what wasn't, I just read through the ruletypes.h to see what had rules added. Here is the source:

Huge thanks for TheLieka and the TZ/VZ team for writing this code, and to KLS and anyone who helped get it added into the source. Like I said, so far it is great. I was just curious if the latest code from TheLieka has been tried and/or is under consideration for being added to the source.

Also, someone might want to stick the rules table updates into the log file along with the hacker table one that is already there.

I didn't add that since I didn't see it I can look at that stuff too.

Ya, when I first started adding in the source, I added all of the original stuff he posted and it all went in very well and compiled perfectly. I think it was easier since it had the "Before" and "After" notes showing exactly where the modified code should be added into the source. It took me a couple of hours to get it in, and then I scrolled down and saw the latest update and realized I had to recheck everything I had already added in! I figured that was the case with the updates to the source in the 1110 as well.

I basically had to run diffs and modify a bunch of stuff to my already modified code and was able to get it to compile in 1108, but it didn't seem to function at all other than the zone loop issue with the zone_points problem stated previously.

Finally, I started from scratch again with unmodified 1108 source and I pulled up a diff from 1102 to 1108 showing line numbers. I then used textpad to pull up 1108 so I could modify it and turned on Line Numbers there as well. Then, for each line in the diff, I looked at the 1102 source for each line mentioned and then lined that up with the 1108 code in my diff. Then, I added all of the lines 1 by 1 to my 1108 that I had opened in textpad. It was a quite involved processes lol. But, I thought I had it all in where it should be. I tried to compile and got some errors which appeared to be related to where I was adding the code to. The first time I compiled it errored on one of the first few lines and I just moved it down 1 to where it looked like it should go, but NOT the same line number mentioned in the diff and it got past that part the next time I compiled. But, the second compile failed later and I fixed it again by moving the line down 1 in the source. So, maybe I just didn't understand how the diff posted was supposed to work. I read it as the line number mentioned is where the code change was supposed to be added to the source, but maybe it is the line after it? I don't know. Either way, once I got the compile to work, it still did nothing other than cause the zone loops from the zone_points issue.

So far, the 1110 source is functioning perfectly as far as I can tell. But, it seems like the latest update from TheLieka might make it even better, which would be quite amazing. Plus, the rules it includes in the latest update look really great. I am sure the additional options for this system would come in quite handy. I am sure you guys updating the source should have much better luck than me lol. I just follow directions, but you should be able to actually understand where things are supposed to go or not. This is some very important and useful code and I am very excited to finally free up my time watching for cheating (which I waste countless hours doing) to finally allow this feature to do it for me!

Thanks again for all of the hard work you guys do. I am more than willing to put any new code updates through a good stress test on my server. My server gets quite a good load of players on it, so they should be good for testing for issues with anything released.

I only have a moment, so I apologize for not being able to address these things in great depth.

We had issues with zoning into certain zones setting off the warp detector with the last iteration of changes that I posted. Unfortunately, I had to fall into a possibly permenant hiatus status shortly after that, so I never had a chance to chase down the root of that problem.

Other than that, the code was working very well for us, but with limited dev resources (as every ServerOp has experienced) and conflicting goals - we had to stop working on it for the time being. We ended up reverting back to a previous version of the warp detector (the older version only judges warps based on movement distance, rather than the newer version which judges warps based on movement velocity).

The older versions are quite inadequate for accounting for lag - which the new version does very well. I do not think it would take much time for someone to go through and finalize the code for the new version, but unforunately, I simply do not have the time to do it right now.

I would love to see the few remaining glitches in this code resolved and committed to the official source - I think it would be a great asset to any ServerOp with the intention of running a legit server.

Dax

Ya, I am sure we all know very well how easy it is to get sidetracked and get pulled into working on other problems instead of just focusing on one project :P Seems like I am working on something different every day lol.

The current anti-MQ detection in the 1110 code works very well and seems to catch every case of actual warping. The only negative part to it atm is that it also catches some false positives. It seems like CotH and maybe some other legit character moving features are not accounted for in the current committed version. I know you put checks in for pretty much all of them in the newest anti-MQ detection release.

Maybe if we could just get all of the false positive checks that are in the latest one added to the current committed version, that would finalize the detection to be quite complete for now anyway. Of course, it would also be great to have it run the checks against velocity instead of distance to help remove even more false positives.

I will try to do a diff of your newest anti-MQ code against the one that is currently in the committed code and post it here. Then, maybe we can all work towards pulling out the important changes and see if we can get the new stuff working. I am no coder, but I am fairly good at adjusting things as long as I have examples to work with and can grasp what it is trying to do.

I think it would be great to have some of the other rules working as well, but that isn't quite as important.

I want to make it clear that I LOVE the current MQ detection that is in the 1110 release! This will save me countless hours of time from investigating cheating and already in just a couple of days has stopped almost every incident of MQ abuse on my server! So, THANKS! I currently have the MQZone rule turned off so that I don't have to worry about zone_points and I think that helps a lot at least until I can find time to add them all in.

Even if nothing is changed in the code from here on out, I think it is a vital tool for the community and probably the best thing we have gotten in quite a while. That isn't to say that all of the other changes recently aren't great, but just that the MQ detection is simply amazing!