Tree of Savior Forum

Captcha-based Bot Reporting System, In-depth outline & suggestion

Intro

I hope to see TOS succeed, but it’s riddled with Bot issues…
So, I’m writing to share with all of you some very condensed and summarized thoughts on what can be done on the backend to help deal with bots and botting.

I believe TOS can effectively leverage its devoted fanbase in order to crowdsource bot identification, BUT,
TOS must come up with an automated method to validate whether or not a reported player is a bot, because manual review of reports cannot compete with automated account creation algorithms used by botters, especially if the game is free to play.

I suggest a back-end captcha system. Let me describe how it works to describe its balances between effectiveness and false-reporting. Also to discuss botter’s anticipated defenses against such systems.

How it works:

When a player reports a bot, the suspect player receives a notification on the of a captcha challenge. To avoid disruption to gameplay, the time allowed to address it may be fixed (eg, 5 minutes, timer starts on first action or chat to prevent afks from being kicked) or variable (decreasing for each additional report before captcha is finished). Perhaps player gains temporary high reduction of damage (80%?), and loss of agro, while answering captcha. If captcha not answered, proceed to logoff and punish (see section on punishments).

To remove the negative stigma of being falsely questioned, a slight reward is provided for correctly answered captchas. For example, +2% exp buff (8 minutes, 1 hr cooldown, or runspeed, or whatever) and (optionally) provides immunity from additional captchas for a random and variable amount of time (2-60 minutes) minutes. To prevent abuse, allow players only 2 reports per hour.

To encourage reporting, allow people to see the result. If someone fails to answer captcha, let the original player know, perhaps even a “report bot accuracy score” that resets mostly for lowering the significance of players who very frequently abuse the system (see below)
For those like me who are terrible at captchas, 3 wrong answers are permitted, 5 rerolls of captchas permitted.

Avoiding abuse of Captcha system

The 2 ways it can be abused are:
Reward Boosting – Friends time the correct answer of captchas for utility, such as killing a boss with +2% exp buff. Abuse is minimized by making potential gains insignificant for the additional trouble, or by adding a random delay to rewards to prevent them from being ‘timed’)

Attacking others with Captcha – Friends stack captchas on someone they don’t like (example: pvp, guild wars, on rare monster spawn). This is negated by giving real players time to address captchas. Eg, 5 minutes, plenty of time to spend 10 seconds to type.

Keeping the Captcha System viable against bots

How would botters get around captchas? Primary methods would include paying someone to answer it (it’s real! current prices are 100 solved captchas for 5 cents ($0.05 USD)) , well-tuned OCR (optical character recognition), and data mining for correct answers. The best defense against all of these automated captcha subversion is: variety and unusual formats.

Variety:
Reused challenges and formats can be data mined (across different accounts) for correct answers or patterns, whereas scrambling (new questions, new order of multiple choice answers, different syntax and formatting, etc) will make automated captcha subversion much more difficult.

Variety also applies in variable timing of immunity to report-timing in order to prevent that system from being “timed” for exploit (eg, if report-immunity was exactly 60 min, one could self-report, schedule a manual answer, and get immunity, exactly every 59 min, 59 sec). Also: report immunity should be implemented server-side.

Variety also includes captcha formats and preventing time for data mining… (eg 90%/10% divide between type A and type B captchas, to ‘surprise’ bots when challenged and prevent data mining).

Atypical formats (eg, unusual formats, not the usual “type the letters in this image”), will make it more difficult for botters to implement existing methods (OCR code libraries, outsourcing services) to defend against captchas. IMC may either pay for the libraries of professionally implemented captcha systems (but those that cannot be outsourced to captcha answering services), or implement their own, rather simply.

Example:
Captcha variety is limited more by creativity rather than technical knowledge. Fast to make, deploy, and change is the key.
Out of a random library of images, showing 6 various shapes in various colors with random numbers (1 to 6) inside. Challenge question : “what is the (randomly select ‘color, shape, number’) of the (randomly select ‘color/shape/number X’ category not selected before)” ?.. 3x12= 36 possible questions per image, and a possible 720^3= ~373 million possible images (try datamining that, you bots!). The correct answers can simply be generated alongside the images in a lookup table. The image library and lookup table for answers is easily generated by even an amateur programmer with a few FOR loops.

Here, a botter would find it difficult to outsource captcha comprehension to a 3rd party.

The point here is: simple, fast to make. Have a new one made by the time programmers finally get around to coding how to automate the answer to this example.

Example 2
If you tie in the GUI or the actual game client, it may make it even more difficult to link 3rd party captcha solving services with TOS. One example is Dance Dance Revolution -style captcha, where you simply move your character in accordance to a arrows on the image of the captcha

Punishments/ system for validating failed captchas.

Let’s remember the point of all this: it should take botters an order of magnitude more time to “save” reported accounts than it takes for IMC’s future dedicated staff of a handful of people (one day, perhaps) to review cases.

Scenarios include:
A) The genuine player who accidentally missed the captcha or screws up entering in the captcha.
B) The random young non-english-speaking young kid who missed the memo on wtf the captcha is, and keeps getting reported for whatever reason.
C) The player who bots on the side to grind, but acts innocent.
D) A bot farmer who controls a horde of bots via algorithms on multiple amazon EC2 instances, and manipulates the game through APIs and the like. May hire someone to jump onto troubled accounts to manually manipulate them out of trouble (answer captchas, etc).

I believe the key difference is ascending levels of frequency of abuse/being reported. As such, if punishments’ seriousness is exponential in nature (the first 2 offenses being much more lenient than say, the 4th and 5th), as such I suggest a tiered system.

Tiers of punishment:

Tier 1: (3 allowances)
First failed attempt:2 minute timer for voluntary log off or be kicked.

Tier 2: (2 allowances)
Character is silently (without logoff) transferred to Jail 1, where they must read a sign to talk to the 4 – 6 NPCs in the room in a certain order to get out. Maybe even put in a bunch of ever-spawning stamina roots to make bots do infinite loops. Note to have it multi-lingual. I’m sure players in forum can provide translation help.

Tier 3: (1 or 2 allowances)
Jail 2: similar to Jail 1, but with a much longer quest to get out. Say, 15 minutes of running around. This forces someone to waste at least 15 minutes per account to save. Category D botter’s limit would be 16 accounts per 8 hour day.

Tier 4: (2 allowances)
Account locked until someone reaches out to bot team.

Tier 5: Account ban, deletion

Each tier of punishment occurs for the “X allowances” number of times (eg, Tier 1 = 3 times) before advancing to the next tier of punishment. One week of not failing captchas moves you up to a lower tier of probation.

Implementation:

This seems like a large job to implement, when viewed in full. But, currently, ICM has no captcha, and requires a staff member to review each report. Even a simple captcha being implemented would exponentially increase the time efficiency of the staff and provide an ability to deal with bots and gold sellers that scale with fanbase effort.

Perhaps someone else can comment this section, as I don’t have much experience here, but I do know that, perhaps, the weakest links would be anything done client-side and not server sided. For example, memory registers can be modified to, for example, extend a “captcha immunity buff” after a correct captcha (if stored locally), and such. Or worse, if cooldown on reporting is only implemented locally in the GUI, someone could utilize APIs to spam reports and flood the system.

Conclusion

I hope this provides some ideas, or maybe sparks some discussion among ourselves, on how to prevent TOS from suffocate under the weight of bots (as RO did). Perhaps @STAFF_Ethan , @Staff_Julie, or @GM_Sebastian might have some thoughts?

reserved for myself later, should I intend to add something.