Bot detection discussion
mrmin123 opened this issue · comments
This is to continue the discussion of bot detection from #52 (ticket no longer valid due to deletion of ticket creator's account) and #94.
To recap:
- @minh6a reports that Kadokawa is actively developing anti-bot/bot-detection techniques (link in Japanese)
- A post from the KancolleBot blog (link in Chinese) supposedly reports that the Kantai Collection client records mouse clicks
- In #52 a person who looked at the source code for the game confirmed the above independently, as well
Currently kancolle-auto utilizes the following in hopes of evading bot detection:
- Uses the browser/viewer instead of API calls to run
- Random click locations for all buttons/screens
- Random navigation through screens, with random number of 'sidesteps' each time
- Random delays between every click/action
- Random rest locations for the mouse in between actions
- Scheduled sleep function, where kancolle-auto goes to sleep and does not play the game for a certain amount of time
- Large number of the settings can be customized via the config, hopefully decreasing the number of usage pattern repetition
My suggestions:
Don't set the Paranoia setting in the config to 0! This gets rid of all the navigational sidestepping, each of which only adds a few seconds to the action. I would suggest a value of at least 1.Per discussion below, it might be better to set Paranoia to 0 or 1 at most, as having too many actions (including the action of switching screens) per day could mark your account and trigger catbombs.- Enable and set up ScheduledSleep! Multiple people have reported that when they let the script run all day without pause they quickly begin to encounter frequent catbombs, while not playing the game for a few hours a day alleviates this
Disclaimer:
Again, I should stress that using this bot (or any other bot) is against the rules and there is a chance of being banned! I started development of kancolle-auto because the game seemed so brain-dead that I felt like a script could play it 99% of the time, so this is result of that little thought exercise. Part of me wishes I get banned so I can be freed from the misery that is Kancolle, but another part of me enjoys developing this script and trying to make it not be detectable as much as possible. So please post (new) information and/or ideas regarding bot detection, along with any relevant discussion, in this thread.
As long as the click location is random I think this is going to be just fine. I used an AHK-based one lately and it was great until the update in early January
.
@tanatej The random mouseclick is not safe because the server also analyze the api call pattern as well, both rejigger_mouse and Paranoia are needed to avoid being detected.
@mrmin123 Let the script play overnight is totally fine, as long as it does not exceed human cap (max of 48-72 hrs awake) as there are many Jap TTK who are real hardcore players and they spend their lyfe on gaming.
BTW, I noticed that (according to DMM login/access log and the catbomb-ban trigger) if a player keeps being online and playing with the same API for 80-90 hours, the catbomb-ban will trigger until the following maintenance. So if you are planning to left your script on, make sure to comeback after 3-4 days and refresh the page to fetch new API&client (I think this is also one of the methods that the KDKW dev implemented to prevent obfuscated API call being decrypted by bot-developers)
@minh6a @tanatej Paranoia should not be avoided. As I stated above, setting Paranoia to 0 means that every screen navigation takes the shortest-path approach to its destination. This is a pattern! 'Accidentally' going to the wrong screen and wandering through the menus (something that I do frequently when actually playing) is less of a pattern!
I do think that rejigger_mouse is superfluous, but my reasoning is that I don't believe that the client sends mouse movement data back. The mouse movement randomization was incorporated just in case, but honestly isn't that great of an implementation.
API calls are moot with kancolle-auto because the script itself does not make any API calls! All interaction with the server are done via the actual game client. The only 'pattern' that can be detected is your actions and usage in-game.
As for letting the script play over night, it really depends on your usage scenario. If you had the script turned off a few hours earlier in the day, then yes, turning on the script later to run overnight is perfectly fine. Letting it run overnight for multiple days, like you said, is not. My primary use case for kancolle-auto has been letting the script run for weeks, and if that is yours as well, I strongly suggest turning on ScheduleSleep.
On that note, I can tell you that I've left kancolle-auto running on the same Kantai Collection window without refresh for up to 2 weeks, with no catbombs and errors. The only thing that stopped the 2-week streak was my internet going out for a minutes. But if API links expiring were indeed incorporated to prevent botting, it is not pertinent to kancolle-auto since, as I've said before, this script does not rely on API calls at all. This has the added advantage of if your game actually catbombs due to a stale API link, kancolle-auto will outright stop working (or refresh the game, which is what a human would do), instead of continuously hammering the now-stale API link with API calls directly.
But isn't taking the shortest path also normal human behavior? That's probably why they developed the one-click resupply button in the first place
The desire to take the shortest path is normal human behavior. On the other hand, consistently taking the shortest path 100% of the time, in my opinion, is not, because humans make mistakes, whether it's because of a mis-click or their mind wanders (AKA I make a lot of navigational mistakes with this game).
If, from your personal experience, you've never made a mistake in navigating the menus of Kantai Collection, then go ahead and set Paranoia to 0. Maybe enough people don't make mistakes for it not raise a flag and I'm over-thinking it! But my personal experience is (and this may or may not have to do with the fact my brain practically shuts down when I play kancolle...) that I end up wandering through the menus, so I programmed it to be consistent with my behavior. If the menu wandering is not consistent with yours, maybe there's no risk in setting Paranoia to 0.
Isn't the long delay between clicks (5-15s), even if randomized is also non-human behavior? Especially if you do play manually between botting sessions it would be obvious if they actually looked at activity log because normally you'd never wait that long.
I'm also wondering if the client actively track and limit amount of actions generated per day or set amount of days, if it does then paranoia setting would generate a lot of extra actions. I've had catbombs triggered with paranoia set at 2 and 20-22 hours botting time each day for 3 or 4 days consecutively. From what other people reported 2-4 hours sleep per day is probably sufficient but since I'm only running sorties with morale ignored (~250 sorties per day) the amount of actions generated may have been absurd for a human.
Then again during this event there is atleast one Japanese streamer who streamed for 48+ hours sortieing nonstop without triggering it so there is probably another mechanic to determine botting.
It's totally true that the delay between clicks can be easily identified as non-human behavior. Unfortunately that's the limitation with Sikuli, and also highly dependent on the strength of the machine running kancolle-auto. That said, I'm running it on a relatively old laptop and it usually identifies and clicks on a button within 1 or 2 seconds, unless there's a deliberate wait hardcoded in. There are also times when I leave a sortie up for hours on end because I'm doing something else...
But you bring up a good point about the number of actions per day (actions including screen changes, as well) being a factor in bot detection/candidacy for catbombing. If so, then yes, a high Paranoia could trigger something. I typically run Paranoia setting of 3, but I only with Expeditions, PvP, and Quests, with a ScheduleSleep of 3.5 hours, and have never been catbombed. With those settings the number of actions overall would be significantly lower than running Expedition and Sorties, even with high Paranoia. Perhaps if Sorties are automated Paranoia should be limited to 1 (that way the game either side steps once, or not at all, randomly)?
BTW, when you do get catbombed, does kancolle-auto recover properly? I've almost never been able to test this myself...
BTW, when you do get catbombed, does kancolle-auto recover properly? I've almost never been able to test this myself...
In my experience, aside from F5 key being suppressed across multiple accounts and browsers that requires script modification, it works fine for random infrequent catbombs.
When you get frequent anti-bot catbombs, the script crash a lot from numerous interrupted actions.if you're doing sorties. Not so much if you're only doing expeditions.
I also found this part of the script rather reluctant and should be commented out or the amount lowered when you get frequent catbombs since it will intentionally stop kcauto. Refresh spam is not really a problem outside of sortie map.
if last_refresh != '':
if last_refresh + datetime.timedelta(minutes=20) > datetime.datetime.now():
log_error("Last catbomb and refresh was a very short time ago! Exiting script to not spam!")
print e
raise
I personally leave Paranoia on 0 as well. I think the moderate delay before clicking and the lack of "wasted clicks" is the main worry. It would be good to have a mode that preemptively spams mouseclicks temporarily forgoing Sikuli at predictable points. After a Sikuli read on the homescreen, move cursor immediately to sortie button position without a Sikuli read and click. While the screen is loading, move cursor to sortie or expedition area and mash click until it finishes loading, etc.
If it's possible to track whether the mouse cursor changes into the pointing index finger that tells you that something is clickable, avoiding Sikuli would be a lot easier. The mash click would be successful when the cursor changes into the pointing index finger once after assuming position, and the script can simply advance to the next step all without Sikuli reads. On screens without much reloading, such as selecting a sortie, the script can move to a position, wait for the mouse cursor to change to the pointer, then click 0-50ms after.
I mash clicks basically any chance I get. At resupplies, the compass, where "Line Ahead" will appear on the screen during sorties, when an expedition comes back.
The ability to wait for the cursor to change is not possible at the moment: source
It is, however, possible to depress the mouse at its current position (currently used to dismiss the boss dialogue during Event sorties in the combat module), thus avoiding the time-intensive Sikuli screen read and matching:
mouseDown(Button.LEFT)
mouseUp()
It's possible that by incorporating this into check_and_click() and wait_and_click() along with a slight wait(), you can mimic the 'click spamming', ideally by incorporating into a loop of random length. Not sure how this might interact with certain screen changes. I won't be able to test and implement this for a while, however, as I'm overseas.
The idea of 'pre-loading' button button locations has actually been on my mind for a while. Assuming that the user doesn't change the size and location of their kancolle window during the script's lifetime, it should theoretically be possible to memorize the location of the UI buttons so that it doesn't have to match every time. This, of course, comes with the danger of attempting clicks when the button is not available, possibly leading to undesired behavior that could be very difficult to debug after the fact. This, along with the timing differences that necessitated the inclusion of SleepModifier in the config is what's been keeping me from pursuing this much further.
https://dl.dropboxusercontent.com/u/73564551/Games/KanColle/click.webm
I woke up to this weird problem today, it occurs on multiple devices and web browsers including the Android web browser so this definitely isn't a problem with my computer. Could be a new anti-bot feature although much less annoying than catbombs.
The cursor keep blinking on its own as if clicking when hovering over 1, 2 and 他 button but no actual clicks were executed and if the user or kc auto attempt to click while the cursor is blinking it would often result in failure, causing expedition resupply loop.
Note that at the end of the video when I switched to 他, the blinking stopped but when switching back to fleet 1 or 2 it would re-appear. Not sure what could have triggered this since I've been allowing 6 hours break between botting sessions and only ran ~50 sorties that day.
@mrmin123 The fix in #129 worked for that particular issue, however this time the cursor blinking is much more frequent it didn't help (I didn't actually click anything in the first half of the webm if you didn't catch that, the cursor just appeared like that on mouse hover, on multiple web browsers).
Anyway, it went away after ~4 hours of inactivity which make me think it might be a bot flagging mechanism.
@Aftersky Which platform and browser are you using? Linux, Windows 32/64 bit?
And which Flash version ur running? (PPAPI, NPAPI or Chrome stock flash player?)
What it looks like to me is the client is sending cursor refresh request frequently, which is pretty much not what flash client can do. Do you run any other program background?
And this is definitely not bot detect mecha so rest assured 🐱
@minh6a
PPAPI flash Chromium x64 - Windows 10
NPAPI flash Firefox - Windows 10
Stock flash Chrome x86 - Windows XP VM instance
Dolphin - Android 5.1.1
It occured on several platforms I tried within that timeframe and when it stops it stops on all platforms as well so I doubt it is something on my end. I don't have anything in the background that could interfere with the cursor, especially the VM instance that was created solely to run kc auto and has nothing else installed.
Try it on Amazon EC2/vultr then. I think the problem is from your
Mainboard/BIOS (the source of most time-depend problem)
On Mar 15, 2016 8:16 AM, "Aftersky" notifications@github.com wrote:
@minh6a https://github.com/minh6a
PPAPI flash Chromium x64 - Windows 10
NPAPI flash Firefox - Windows 10
Stock flash Chrome x86 - Windows XP VM instance
Dolphin - Android 5.1.1It occured on several platforms I tried within that timeframe and when it
stops it stops on all platforms as well so I doubt it is something on my
end. I don't have anything in the background that could interfere with the
cursor, especially the VM instance that was created solely to run kc auto
and has nothing else installed.—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#130 (comment)
@Aftersky By the way, what's is your mouse sensor, dpi and polling rate? This can be a problem as well
I'm not sure that it's a hardware/mouse issue... I actually encountered this for a day or two when #129 was first opened, but only a few times. That said, it's an incredibly a transient issue with little rhyme or reason as to why it happens, so I'm inclined to ignore the issue in the master branch until we have more data.
I encountered the flashing cursor issue again yesterday after I left the script running for ~22 hours but this time it went away rather quickly before I could gather any info. It can't be a hardware/mouse problem since I've already tested on 2 different hardware and 3 different mouse inputs.
@mrmin123 Good to know I'm not the only one. What did you change in the master branch? it seems to be working since the script wasn't interrupted until this happened. This error is rare but it would be nice if you could add a recovery mechanism for it.
@Aftersky Nothing was changed in master in regards to the flickering mouse. As for the popup, some additional discussion regarding it is here: https://www.reddit.com/r/kancolle/comments/4a5lwp/question_why_do_i_sometimes_get_this_dmm_browser/
Still debating on whether to add a recovery for it or just check that 'Prevent this page...' dialog and forgetting about it forever.
@mrmin123 The "prevent this page.." box isn't permanent solution, it only work for that browsing session so the next time you refresh the page or restart browser it can show up again.
As for the cause there could be many, I've gotten it shortly after a refresh and during botting session so it probably wasn't inactivity or expiring API.
Edit: I tried to implement the double click solution suggested in #129 but couldn't find that line in kancolle_auto.py anymore in so I thought you changed something in recent version.
I get that popup even if I'm using browser without KC3, so adding a recovery for it when it appears would be great. Hated to come home after setting the bot before going out to work only to come back and see nothing was done for the past 10 hours due to a popup -_-;;
@Aftersky @mintgreenrose please see/continue discussion regarding the popup in #148
Possible fix for cursor problem. Add in small delay ~500 ms and "reclicks" the target area. It happens when the cursor reaches an area that is not picked up by the game when click happens (edge case where hovering off from center will change the cursor to hand but not registered when moving directly from outside). I got this problem in my AHK script.
https://boards.4chan.org/jp/thread/15137663#p15138397
This post mentioned the cursor issue in #129 is because smoke animation takes priority over the fleet selection for the mouse. I think this is the most accurate explanation.
@zerolength @Aftersky Thanks for the leads. I'll try to push a fix ASAP (probably in a day or two).
Took a bit longer, but the smoke issue should be fixed as of the 2016-05-11 update.
Hey guys they supposedly "strengthened" the anti-bot measures this patch. Hopefully it's nothing that kc auto has already addressed
Out of curiosity, has there ever been any reports so far of users getting banned? Whether it has been reckless usage and/or with random mouse clicks and breaks in between sessions?
@Dmn7D there was a user that got banned a few months ago, but it also sounded like that person was getting catbomb'ed pretty frequently prior to even using kancolle-auto so I don't know the full story.
I have it on basically 80% of the time last 2 month. Seems alright. There are occasions the catbomb frequency increased and the script hangs (which is a good thing). I stoppoed the script for half a day before begin again. My settings is 4.5 hours sleep and 4 for latency. I log on directly to dmm from NA. I even attempted to play r18 games on another device while kancolle logged on (and it works).
The catbomb in my account have been annoying enough that I had to use OOI3.
The funny thing is, the catbomb only happened on homeport. never on sortie.
@mrmin123, about my problems with cats, I was caught twice on this problem
First I turned on the bot and more than 24 hours has not updated API reference, and getting this problem.
After 5 days the problem was solved by yourself.
The second time I got the same reason, because he did not know the cause and after 5 days the problem was solved by yourself again.
The third time, I realized what the problem: sleep mode, began to update the API link and increased intervals, no longer include sortie at night (only expeditions). More than a month is not faced with this problem, it seems to be working.
@Nuts123 Sleep mode? You mean on your computer? Or are you talking about kancolle-auto's ScheduledSleep functionality?
@mrmin123 ScheduledSpeep of course. One of the ways to solve the problem is to activate ScheduledSpeep 2+ hours
Some features that would make it really hard to detect would be adding "dead" clicks. I've noticed that when playing my friends and I typically spam click quite(always) frequently. That suddenly stopping and perfect 1-1 clicks to actions seems suspicious.
If they can track cursor movement bots are pretty much toast. I could write a program that could tell the difference. standardized acceleration on cursor movement and moving in a perfectly strait line makes this pretty trivial.
@NanjoW 'dead' clicks would be interesting. My thoughts/concerns with them are the following:
- Potential added complexity in regards to making sure that kancolle-auto does not do a 'dead' click on a live, interactive screen -- probably not an issue given how Kancolle's responsiveness is non-existent
- Might increase load and lead to bot flagging -- higher random navigation tagged people as potential botters. If every click, even dead clicks, triggers an API call, then this could easily raise the number of API calls to dangerous levels
- Dead clicks might not be tracked -- if dead clicks do NOT trigger an API call, then what is the point of implementing them?
An interesting post on the subject of mouse-click tracking can be found here. I haven't deconstructed the swf myself but Laforet's code snippets seem to indicate that the mouse-coordinate information is embedded into the API calls when they are triggered, implying that the mouse-coordinates are only recorded on actionable events (if true, then refer to item 3 above).
And yes, if they do track cursor movement it'd be problematic, but that's not a problem kancolle-auto can solve or side-step. I doubt that they would ever track that, however, considering the increase in API call payload, or additional number of API payload calls, or how do tracking movement if the Flash canvas loses focus, or if the user is on a phone or tablet leading to a lack of mouse-like cursor movement.
In the end, it's about doing the minimal amount of work to make the Kancolle servers think that kancolle-auto is a human-like player, not making the bot's actions on our screens look human-like.
My thought isn't necessarily the API calls but they could implement services client side that could track that kind of behavior and send a flag on the account in certain situations. I wouldn't write all my bot tracking software server side precisely because of the load it would be receiving. I'm not a flash programmer, but I implement things like that in android all the time. A background service that could analyze "bot" like behavior. I assume that dead clicks aren't API calls as you are clicking before the OnClickHandlers are attached to the buttons, but that doesn't necessarily mean that the flash app isn't recording something. And as far as complexity goes, I agree that it would be somewhat of an issue depending on how kancolle responds.
Honestly? It's beyond the scope of what I'm willing to implement. If anyone is legitimately worried about heuristic detection like that, don't use this tool. As a matter of fact, at that point, don't use any botting tool and play legitimately.