Bot detection system suggestion

[marcobrotas.mm]

Greetings Tree of Savior team,

I have a suggestion for bot detection that I believe could be highly effective.

What’s the guideline for my idea?

One of the major “unavoidable” differences between human players and
bots. Human have eyes and act upon what they see. Bots do not. They act
upon data received from the client/servers.

So, when humans are farming, they will attempt to kill what they see. A bot
will attempt to kill what the data indicates is available.

Taking that as a basis I have a question. Would it be possible to
“spawn” invisible monsters? By this I mean enemy targets that humans can
not see nor have any way of detecting their existence with their eyes.

If so, hypothetically it could be possible to purposely spawn this
targets next to farming players to act as a honey-pot for a captcha
activation. On failure punishment procedures would take place.

The captcha would still be required since it is entirely possible that users would hit those honey-pot-targets by mistake, even though they would not detect them.

Refinement could also be done, such as only triggering the catcha upon
more then one hit onto the honey-pot-target. Of course it would be
possible to bots to also be aware that those are honey-pot-targets, but I’m sure there are lots of ways to trick the bots into believing those are real enemy targets.

Feedback on this idea would be appreciated.

Best regards and most respectfully,
Arkight Crossfaith

[tsigetartseht]

Great idea! It could be an empty box object composed of 1 KB sizes because they only have names (that are invisible) and no objects in them at all.

Even fireball and icewall has no names yet the bots attack them so essentially this thing will work!

[marcobrotas.mm]

Thank you tsigetartseht.

[Halian]

I think it could work for a time, but its kinda easy to detect that kind of “trick”, so it won’t last long. This kind of system requires lots of maintenance, because once you get the method, you can work around it, so you need a new method/algorithm/tech

That’s why I proposed an statistic approach, because you cannot escape from it.

Bot detection system

Yesterday I was wondering how could we stop botting and came up with this idea: Each map should have (if it doesn't already) a bunch of data to make some statistical studies or apply some statistical methods/tests. Through a simple averaging method, we could get a trend on some aspects, like monster kill count or time spent on the same area. Having that average, plus or minus the standard deviation, we have our lowest tolerance level and our highest tolerance level. Now, using the box-and-…

Still, invisible mobs just have that one flaw: they’re different that the rest of the mobs, so you could detect that change.

Injection-based hacks are almost immune to this kind of solution.

Thanks for your reply in my post, and let’s keep thinking!

[marcobrotas.mm]

Indeed I get your point. And it is in fact true that it could be easy for the injected code to (just as the game client does) detect such models were honey-pot-targets.
However, I believe there are ways to make it quite challenging. I actually was aware of this problem when I proposed the system, but had to spend a little bit more time thinking…
I propose the adicional following system to counteract that problem:
1 - There would be no new mobs (so that the bots would not be able to skip the problem by keeping a list of valid ids).
2 - Instead, every mob would have a property in their data-set that indicates if it is a honey-pot-target or a regular mob.
3 - The trick would be on how the data in that property would be stored. One solution for that could be the following:

• The value of the property would be attached to a random number and encrypted by the server with a certain key . Examples prior encryption could be: honey-pot-target_123456789, regular-target_123456789.
• The secret key would be known by the server and the client and could be updated on every login or every few days or so… (open for discussion).
• By doing this the client could easily detect if it is a honey-pot by decrypting the value and then parsing it, hence not triggering visual models and vice-versa. Injected code would need to first acquire the secret key to be able to reproduce.
• The purpose of the random number would be so that the injected code could not simply compare the encrypted values to determine which one is which.

One can argue that the problem would then be shifted to the inject code being able to acquire the secret key. Of course this would also be possible but arguably hard to do so. And that’s exactly the idea. Just like any solution it would never be 100% perfect but I’m fairly certain that it would take quite a some effort to overcome this barrier. Therefore the number of bots would be significantly reduced. And it could be improved by simply improving/adjusting the way that key would be passed along.
An other alternative would be to not have a key passed to the client at all. And instead of symmetric encryption it would use a cryptographic hash that gets determined by a “certain algorithm”.
Of course once again this algorithm could be figured out, but its not about the possibility of being hacked (that will always be possible) its about the level of effort to make it happen.

[marcobrotas.mm]

One last thing, as i mentioned, this is not meant to be a one for all solution, but a complement to additional solutions like the one you suggested.
Its sole purpose is to increase the level of effort of bot development and hopefully make it not worthwhile.

Thank you for your feedback!