Fight checks improvements/implementations

[Lysandr0]

(Let me know if you wish me to split everything into different tickets)

1. Fight.Critical revamp: detect "onGround" critical cheats.

The current implementation is rather ineffective regarding most of the modern critical cheat modules; while it can technically detect onGround variants through the config, by editing "falldistance" to something higher, doing so, the check would spit out so many false positives to the point where you're not even able to distinguish a legit player from an actual cheater. So, having a new check method alongside the "lowjump" one would be nice :p

2. New (potential) checks (Bringing some of them from the original tracker):

• "Fight.Impossiblehit" :
  I think this one is one of those checks that has been requested countless of times over the years of NCP's development... :p
  Basically a check that can prevent:
  (Most requested) ->
  -Hitting whilst eating;
  -Hitting whilst blocking with a sword/shield (1.8/1.9+);
  -Hitting whilst being dead (This one is already in place but it could get rearranged in this check);
  (Possibly more) ->
  -Hitting whilst breaking/interacting/placing a block;
  -Hitting while having an open inventory (Although the server doesn't tell us whether an inventory is open or not... Would also fit better in the inventory check section perhaps... :p)

• "Fight.Visible":
  Prevent cheaters from hitting entities through walls and obstacles (This one has been queued ever since by asofold, I think...)

• "Fight.Target":
  Heuristic check which would prevent players from hitting entities through other entities' hitbox
  It'd catch a lot of KillAura modules which don't perform any ray-tracing and target(/ignore) only specific entities (Thinking of large crowds of players and/or entities... :p)

More inputs/ideas/suggestions(...) are very much welcome :)

[CaptainObvious0]

Some really good points are raised here. For me, I would like to keep everything in one issue to keep everything organized. I'll merge/move future fight improvements to this issue.

1. Fight.Critical - The default value is a little more lenient, I recommend changing fall distance to 0.075, which has blocked all packet type cheats from working (In my testing). Lowjump type critical cheats could most likely be prevented. I'll look into this.

2. Fight.ImpossibleHit - This could probably be implemented similar to how InventoryMove works. Detecting if a player is eating while hitting will be tricky, because there is no event for when a player eats, only when their food level has changed. Playing with ProtocolLib I could probably find something (animation event?). Only one that I could see being added would be "Hitting while blocking." Checking for placing/breaking while hitting does not seem practical. In what scenario does this actually give an advantage? Nothing can be done to prevent hitting while having an open inventory, nothing is sent to the server when a player opens an inventory. If this was the case, blocking InventoryMove would be much easier and effective. Off topic, I do plan to add more to InventoryMove, like checking for horizontal distance before and during the inventory click.

3. Fight.Visible - Could be added, probably would work the same way as Blockinteract.visible.

4. Fight.Target - A little more complex check that could be added in the future. I have some ideas on how this could work, but having mobs stacked in one block/area could throw some false positives that I will need to account for.

Here's my current list of Ideas to expand the fight check:

• Fight.ClickPattern - Expand this more than just basic click comparison. I want to add each click difference to a list, and from there gather information like mean and standard deviation.
• Fight.MovePattern - Take the idea of ClickPattern and apply it to the players yaw/pitch changes. Gather each change of pitch/yaw, add them to a list, and calculate mean and standard deviation.
• Fight.ClickConsistency/Speed - Rather than just preventing players from clicking really fast, also compare their average click speed as a long-term check. Having a consistent click speed of 10+ is rare, and we should flag for that.
• Fight.Accuracy - Compare a players arm swings to the times they successfully hit an entity. This will need adjusting for attacker/damaged that do not move. Ex. Mob Grinders.

[Lysandr0]

In what scenario does this actually give an advantage?

Factions and SkyWars for instance, are the first game-modes that would come into my mind where being able to simultaneously interact with blocks and attack surrounding players can be very exploitable.
In SkyWars you could noob-tower your way up somewhere without being bothered by other players attacking you.
In Factions you could shield yourself with blocks while warding off other players from your base.
Breaking blocks while attacking >
Combine this with a KillAura and it’ll be really useful to have inside a cave to potentially repel mobs that could creep up on you while you’re busy mining ores :p

Checking for placing/breaking while hitting does not seem practical.

Was thinking about the practicality of maintaining such checks too; given the right situation/gamemode/scenario, multi-actions can grant a nice upper-hand to the cheating player, but not so critical to the point where we’d need to add a dedicated check, I could also imagine all kind of false positives that they’d bring... Overall, they are probably not worth to develop, especially when Fight.Direction should (realistically) prevent all those scenarios already, however, as long as the entity/player is in a reasonable FOV range, it won’t trigger, leaving room for abuses like these.
Sharpening Fight.Direction would probably be a nicer idea.

(Perhaps improbable (feeding it when a suspicious attack + block interaction has been detected) would suit this role even better ...) :p

More concerning Fight.Critical:
The “biggest issue” that (at least IMO :p) it has, is that unlike other checks, like SurvivalFly, where a higher violation level means a higher likelihood for a player to be cheating, Fight.Critical just arbitrarily adds +1 level to each detection which means you don’t have accurate ways to discern cheaters from false positives and legit players, you only get to know how many times the player triggered the check, making it difficult to investigate the suspected player (hence why the check becomes practically useless if you tweak the “falldistance” value after a certain threshold)

More (random thought about Angle - forgot to mention this before):
This comes more from a personal point of view, but Fight.Angle has always done next-to-nothing to prevent what it advertises for me, just grab a random hacked client, turn MultiAura on, and watch Angle doing nothing to prevent the attacks.
It actually penalises legit players more (Try to “ping-pong” entities (quickly switch target attack in a 2v1 fight) for a while, it’ll trigger an awful lot of times)
Moreover it is mostly ‘outclassed’ by Fight.Direction and YawRate in what it does

[CaptainObvious0]

Going to update this ticket with my current plans.

I recently add a PitchPattern check, which works somewhat similar to what I described in the MovePattern check. Its a really effective check at detecting KillAura and has detected all of the few clients I tested it against. If you want to see a demo of this check, watch the video I made here: https://youtu.be/CS81ikk4cX8.

I still plan to work on further developing the click pattern check. Will most likely merge the ClickConsistency/Speed check with that.

Fight.Visible, ImpossibleHit and Critical is still something that I plan to work on.

Fight.Accuracy and Fight.Target would be out of the mix for me. Seems like something too easy to bypass and too much to account for to prevent false positives.

I'll also look into further developing this check: NoCheatPlus@2f53fb4 - Current state is prone to false positives but can be effective at catching some clients fairly easily.

[Lysandr0]

Perhaps that "EqualsRotate" check could be added as well. I'd merge it with WrongTurn however, just to not end up having a myriad of checks around. :p

On an unrelated note:
I was wondering if something could be done regarding “superknockback” cheats and the like. (Faking AND giving more knock back when hitting entities)
Seems like many cheat clients are starting to deploy such module, haven’t had the chance to test it myself with NCP yet, but if it works, then an attempt to patch it would be great :)

I know NCP had a Fight.Knockback check designed to catch this behaviour in the past, but it has been removed ever since the CTRL sprint feature was introduced, moreover, it was notorious for being ineffective and spilling false positives all over the place as well

[CaptainObvious0]

Going to put a hold on this enhancement for now in favor of improving/fixing other checks than focusing on adding more.