Killuara Bot-Check

[CaptainObvious0]

This is not an issue, this is a enhancement request.

After taking on the challenge of making a community config (here), I have really come to appreciate the work that has gone into NoCheatPlus and the respect I have for keeping it free and active. Once I have perfected the config, I wish to discuss the potential of the config in future versions.

Yet, there is still a major flaw in NoCheatPlus, and that's KillAura. I am proposing that a KillAura check be added. A bot should spawn spawn next to a player and check how many times a player hits that bot. It won't solve all KillAura hacks but it will put a dent into them. I used to use NTAC alongside NoCheatPlus for KillAura checks. NTAC is now currently abandoned and is open-source. (Spigot Page) (GitHub) Since this project is open-source, I think you guys can at least get a good idea on how the KillAura-Bot check works.

I'm sure you already know and have seen this check but here's a explanation on how I see and how I think it should work. A bot floats around a player while they're playing. Depending on their looking direction, the bot will move and adjust. Every now and then the bot may pop in front of the player during pvp. If a player hits that bot too many times in a row or in certain amount of time, action will be taken. I think thic can be customizable in the action section. Such as one hit is equal to one violation level.

Heres what I imagine the config to look like: http://pastebin.com/rXzNppfL

Feedback is appreciated. I think the community will extremely appreciate the KillAura-Bot check. I will be happy to test any betas of the check.

Thanks :)

[ghost]

These 'bot' checks only add more strain onto the server and are trivial for any client developer to bypass.

[CaptainObvious0]

Then, by default, it can be left disabled. Then, the server owner, has the choice to enable it if they wish. Currently, the current checks for KillAura don't do much. I said in my post "It won't solve all KillAura hacks but it will put a dent into them."

I'm not saying I disagree with you but I think it should be given a try.

[asofold]

Essentially it can be bypassed easily and will be bypassed in generic ways, so it doesn''t pay long term. A somewhat older rant/page i made is here: https://github.com/NoCheatPlus/Docs/blob/master/Development/Discussion/FakeEntities.md

Pointers for quick overview:

• Apart from being bypassed by less-simple made clients, entities are client-side and as such pose a major potential for annoyance :).
• Entites made complex will stress the server.
• Entites means posing traps for cheat implementations to fall for, while the principles of direction for NCP rather mean to find envelopes to fit around vanilla behavior. Reason being that we're free + open source + low resource developer-wise, so we/i prefer methods that provide some kind of lasting protection rather. There are gray zones and Minecraft keeps adding weird stuff, but that's the basic direction i took here.
• Apart from the trap-nature, entities resemble detecting patterns of behavior rather, but doing this with such a strong client-side thing doesn't seem to make sense to me, because client code is running on the client, and cheat client code will be able to distinguish.
• Thinking of pattern detection (and possibly machine learning), i would put such entirely server side, if i wanted it. (e.g. some thoughts/gibberish:_ https://github.com/NoCheatPlus/Docs/blob/master/Development/Discussion/Design.md#event-engine-meta-checks-automata-patterns). I would invite people to contribute rather, provided i'm not in dire need of money and go for monetizing all over. Still i'm not sure with the community, all these methods need a lot of testing, and people may not want to share their secrets - it's already similar with paid configurations, but also with 'good configurations' someone made. So i am not sure if i should really go for the pain of providing something initial, if the next thing that happens is a (paid? +) obfuscated/secret spin-off thing.

Results in:

• Ban count for rather outdated cheat implementations: YES
• Lasting protection: NO

[reded1]

I'd recommend this too. Developers will be able to bypass it either way, but it would be useful for users that are not really experienced with the game/cheating.

[asofold]

My arguments go for doing something technically (almost) equivalent, but entirely server side, configurable/extendable by users - however it's not a small task, specifically to maintain it. The point about entities is that they'll get bypassed in generic ways, i.e. the method is dead then, while server-side pattern detection (or something similar) will still be updated and yield results. Fast and faster cat and mice, somewhat expensive to maintain, thus not our main direction, because once bypassed, it'll not provide any protection anymore and it's in general poossible if not easy to bypass.

[CaptainObvious0]

Thanks for the information. I am definitely interested in another check for KillAura. It doesn't necessarily have to be a bot check, but it could be a learning tactic as you said. I can assist you with any testing that you need. I have no java experience and don't plan to learn it. I want to be able to help with my current ability.

[CaptainObvious0]

Here's what checks I suggest to add/improve the combat check. Went around gathering information and combined it to this.

• Check the accuracy of the player hits. If a player is hitting a player 95% of hits attempted, they should be flagged for fight.accuracy. (New fight check)

• Check if the player is constantly looking at the same spot to hit (Head) and flag for fight.accuracy.

• Check if the player has a constant CPS for a time given. So if a player has a constant 8 CPS every 5 seconds for the next 20 seconds, flag the player for combined.improbable. But, it must be over 6 before flagging.

• Check if the player is attacking before swinging it's arm, flag for fight.directiom

• Improve yawrate by checking if there is really fast yaw change, so if a player snaps it's head, they will be flagged.

• Still considering a NPC check, by spawning it for a split second and seeing if they hit it. It should be added a cmd/log, so that players can customize when to spawn the npc. So if a player gets 350 VL on angle, spawn in the NPC and see if they hit it. Therefore not interfering with gameplay. Although it's easily bypassed, I still find it a reasonable way to catch them. If it catches 1 out of 10 hackers, then that's one less hacker.

EDIT:

• Adding a Mob In Front method which is explained with this: "The entity is spawned between you and your target, meaning you'd normally hit the entity instead of your target if you were clicking legitimately, and a kill aura would hit through the entity, therefore failing the check and flag." (Taken for the thread below)

Heres a thread on detecting KillAura: https://www.spigotmc.org/threads/killaura-detection.143226/page-3

It's mostly users arguing but some posts have some useful stuff.

Thoughts?

[asofold]

• I've had some aspects of this in the queue already, in terms of a new targeting check, combining difficulty of hitting and miss rate and such.
• Checking where they hit a player is slightly more complex, as there is latency involved, so you need to somehow know, at which point of time they intended to hit the other player. Some infrastructure is there in NCP already (past positions are used for some fight checks, in order to mitigate issues with latency).
• Constant cps are leading anywhere nowadays? With the 1.8+ fight dynamics constant clicking isn't there anymore anyway. On the other hand they probably act pretty opportunistic (hit whenever possible, accountign for cooldowns), so monitoring an estimated difference to the optimal hit timing can be another thing to add in.
• Arm swing check doesn't exist? fight.noswing
• The yawrate check already does that, it penalizes instant turning, it probably can even be configured (+ fight penalty). If it's effective is another point, it probably needs other data to relate to, or mid-term checking. After all there hardly is need for instant turning for modern cheats, they do accelerate towards target with several steps (not all, but more than few).
• NPC check - nope. I think i have an entire page in the DOC project about entities :p. It fiddles around with gameplay on client side, has false positives, takes too much time to maintain, and is bypassed all of the time, worse ... it'll be or is already bypassed in generic ways, making further updates futile. One thing to think about: the player 'can't possibly' see/hit the entity, but the client side code is not able to detect it as fake? People should turn to other things in their dreams, really :)... Simple clients always fall for something, but you'll also be able to ban, if you detect their specific behavior server-side. This needn't be done by entities, you can add pattern matching, machine learning, whatever - this is just not the core part of NCP (ok, currently it's not in at all), it's something that will be bypassed by any client developer who cares to see what the plugins do. So this only makes sense, once we have infrastructure ready and people who keep feeding patterns/data to us, in order to be able to keep updating those components. WIth NCP being free of charge that'll be a challenge, especially because some server owners tend to keep their secrets, if they find a good pattern or training data. NCP is meant to give some (more or less) basic protection, which lasts even if clients update - not necessarily staying 100% effective, but preventing flying for sure (disregard real bugs here), prevent extremes.

Still we always have to think ahead that one step (adaption to NCP):

• They'll add in misses, and some already do. Only promising thing is to relate both missses and hits to the optimal timing (!) (...later also distinguish using doors and potions and such :p).
• They'll randomize things, and slightly more smartly done clients will also leave out an entire hit one or another time, and further add in sub-optimal timing. Evasive moving will also be another thing youll have fun with. I tend to think they'll adapt to the users habits of mouse moving, e.g. using the typical envelopes to model where they'd most likely hit, provided they would.
• Not too far away: They'll record pro behavior and check all the edge data on what frequencies/accuracy is reached, what kind of moves/combinations... taking that as orientation, probably mixed with a short training session with the cheat client user, could ....

Further some technicalities are still in the way.

• The combined.improbable check already uses multiple inputs, but the one-dimensional nature doesn't do that much good (improved + accessible configuration would be nice to have and also improve things further, though). Intentions for future are to generalize the violation levels towards some kind of a counter/automata framework, so more complex relations and counting technique can be employed to combine different check results, also combine check results with "ordinary" data sources. Relate to frequency of occurrence, or to the trigger count, or to a "VL" value, average vl and so on, just to mention.

[CaptainObvious0]

Thanks for responding. Adding more effective combat checks is a huge step in the right direction. I, and many others, would be really happy if this was completed.

• Cool that you already had this in mind. Even if the client adds in a hit/miss ratio you still are reducing the effectiveness of the KillAura.

• Yes, I do agree. This check could be problematic when they are fighting an entity in a corner and they are able to keep their hitbox at the same location. Only checking when the entity is moving would fix this issue.

• A lot of servers run 1.8-1.11 servers that still support 1.8 combat, so I feel this check still is effective.

• My bad, I was just taking things a few things from the thread.

• Would do you recommend the value be set to? It's default at 360 but I don't think that detects anything.

• Okay, We've officially removed the idea of a NPC. I do agree that it's annoying in a game when I make sudden turns and I see it.

• The Mob In Front method isn't the same as the NPC. It spawns in a invisible entity between player 1 and player 2. Regular player can't see the entity. Regular players will hit the invisible entity and still hit player 2, while cheaters will ignore the bot and send attacks towards the player 2 instead of the invisible entity, therefore being harder to bypass. I'm not completely sure how this works, but I know the combat Anti-Cheat Reflex uses that method. So, if a player only attacks players, then it will be caught becuase it's not attacking the invisible entity. If it does target invisible entity's, then you can catch that it is hitting the NPC's. This method does not cause false positives (Well in theory), does not interfere with game, and harder to bypass. The only thing is, it will still take time to maintain.

Great progress and I look forward to what happens next.

[asofold]

Concerning yawrate: i'm not sure if all aspects are configurable, you're probably left with short-term and 'normal' limits, which will indirectly affect other stuff. Balancing what can be accessed and how could/should be redone perhaps...

The mob in front thing is an interesting method, but my stance stays clear: "Do you think client side code can not find out what the player is able to see [EDIT: and/or hit (!)] and what not?" :)

Wouldn't call it too much of progress yet :), there has been stuff like "some vehicles can fly now , and possibly go through walls, and there is an item that allows gliding now, and so on", so i got slightly stuck there. Plans are to nail down latency aspects better, using past positions to maintain some kind of latency-window for a rough but not an arbitrary estimation of what the latency is for a certain player, so we can go stricter on the limits of checks, having a somewhat exact past-position of the attacked player, which the attacker is hitting them at. Using that all kinds of extra estimations will be more interesting, like what distances were taken, accuracy of looking direction, deviations from target center etc. So the direction is somewhat clear here, but it still needs work + testing to get something more striking.

[CaptainObvious0]

Definitely have my support I will be willing to test any new features. Just let me know :)

[CaptainObvious0]

Little update on the Mob In Front idea.

Here's a video showing the results: https://www.youtube.com/watch?v=1VjJDbtk9Jg&feature=youtu.be

The red over the NPC indicates that they are being attacked. As you can see, the attack is going through the zombie to hit the player. While normal hitting will hit the zombie.

So a method to catch the cheaters: Place an invisible bot in front of the player, while PvPing. If they hit through the invisible bot while pvping, then its safe to assume they are using KillAura. If they hit the bot, then it's an actual player hitting them. This can be spawned in for a second or two, so it's not heavily consuming the servers cpu with fake bots.

This is a really effective way to catch them. Since these aren't testing if they will hit the bot, its testing if it won't hit the bot. Let me know what you think!

[asofold]

Client side entities pose all sorts of issues, in this case it alters game play, as both left and right clicking will hit the invisible entities instead of what's behind - and what's behind needn't be the other player, who could also be invisible :). Then you have latency issues and all sorts of things.

Sending stuff client side is just a horrible way of doing things, besides NCP isn't about posing traps. Further, as i noted above, this will be bypassed in generic ways. We'll just have many/most clients evolve further with this, ending up with no gain on our side. The temporary ban count may be nice to have, due to actual cheaters having to spend a little more money+-effort due to banned accounts, but it literally does nothing to limit cheat clients in general.

So this is a clear "no" from my side, i'd rather add machine learning to catch specific client behavior with server side estimation, than to add entities sent client side.

[Janmm14]

1. lag is no real issue if you use 4 bots closely around every enemy player near
2. a. clients will always be able to determine real & fake players b. clients are able to rotate inside of a tick to the real enemy and letting the client perform hitbox checking and then returning back to the player's view clientside

[asofold]

1. Latency+congestion always can be an issue, because the attacker could move inside of the player and attack him (client side, attacker), but server side it won't be like that, because the attacked player already has moved on. So 'lag' can be latency, congestion, delay, lag... it might happen somewhere between in the internet and it might matter. Of course you can ignore special cases and so on, you can just not ignore these things, and programming something like this gets more complicated.
2. :). Virtually every single bot is wasted.

As i said, instead of forcing client developers to do the little step in evolution, ignoring not well made bots, i'd rather invest the time to close the gap on traditional technique where feasible, infrastructure and possibly machine learning.

[asofold]

So closing as won't fix, because entities are out of the question for most.

The idea of catching simple clients fast is nice to have, but it does not increase protection against cheating in general. Something will be done to detect specific cheats some day, provided this projects will be there some day, but it will certainly not start with entities.

[Janmm14]

One note about some older mentioned things like recorded pro aiming data & its analysis: That wouldn't neccessarily be a killaura with a significant advantage except maybe increased range anymore I guess.

[asofold]

The main point about replay of "pro" data, regardless of what you feed it to, could be that you'll be able to quickly compare if new concepts alter anything at all, e.g. comparing how/which paramters are adjusted. E.g. pros are not pros because they can do everything at once, in many cases (not only minecraft) they are better than average in all/most fields physically and perception wise, but they typically don't just so dwarf 4 world class defenders one after the other - they'll have better judgement and contextually will not make mistakes as much, so there usually is some potential with classic methods to cut down things a little.

With more flexible fight penalties, like reducing the attackers no damage ticks, or cancelling out a percentage of attacks, you could also make pros more fightable by ordinary players :) - not fit for top level pvp servers, but pretty/potentially ok for all others :p, provided you have a way to reduce the impact of very difficult/unlikely to do stuff without affecting ordinary game play.

Historically the default settings of NCP have been made such that i (pvp noob) have a distant chance against @MyPictures with cheats on (no difference to without :p). So of course they used to be too strict for real sophisticated pvp. When you turn the checks off or lower sensitivity, it'll depend on how powerful the old concepts are and how you configure it, concerning what remains in terms of both protection and detection.

Ideally NCP would set such envelopes that clients can't do (much) better than pros, unless they want to get detected - of course without affecting gameplay too much. Certainly there could also be an earlier point, where i see that we can't improve things in a significant way. Much is up to judgement there, currently we're not at the point where we can't improve the basic protection layer.

[Eyremba]

I've had some aspects of this in the queue already, in terms of a new targeting check, combining difficulty of hitting and miss rate and such.

What's with the idea of a hit/miss ratio check now? Will you implement such a check soon?

@asofold

[0-x-2-2]

hmr checks are not only easy to bypass they also can have false positives for legit players

[Janmm14]

Not long ago one wrote: Killaura NPC's are not detecting killaura, but a flaw in some killaura implementations.

[asofold]

These checks will kill a hundred implementations, especially fast/simple made ones.

It's just not the intent of NCP - as long as we don't have abundant development resources this won't happen. Interfering with the client also isn't what i'd want to do. You can implement that for your server network if you like - with NCP perhaps one day machine learning will be in use, possibly enabling users to train things themselves and also to have featured sets/people for training data.

Primary direction is to make NCP attract more substantial contribution code-wise, possibly enable automatic workarounds doable by server owners, otherwise implement methods that really limit the capabilities of an adaptiing client developer.