Made an earlier post about how all OSBot scripts seem detected, and posted some findings relating to the banrates of changing various things such as timings, clickspeed, movement, and mouse DPI. In testing, I found that almost 100% of all OSBot's mouse movements follow very simplistic patterns that are picked up very quickly by Jagex's anti-bot. This goes for ALL other client's I've tested, all containing some flaw within their mouse movement, whether it be [Other-Bot-Client]'s flawed inaccurate spoofed mouse movement, or [Other-Bot-Client]'s consistency. I've reported these flaws to the developers of OSBot already, but was not met with confirmation on whether or not they'll do anything about it. Possibly because they're still under the illusion that mouse movement doesn't play a big role in detection. So here's a topic to prove just that.
First off, let me start by showing that Jagex certainly does record mouse movement:
https://github.com/zeruth/runescape-client/blob/master/src/MouseRecorder.java#L40
This shows the frequency of their collection. 50MS ticks, which is equivalent to 20 times a second.
Now you could say.. But isn't 50 MS not enough to accurately depict mouse movement? And that is true to some extent, but it's more then enough data to analyse in order to find flaws or patterns.
Here's what it looks like to move a mouse on a 50MS tick-rate: https://i.gyazo.com/4eb9de90c1c8a60959e874fb24488ab3.mp4
A common argument may be that collecting mouse movement is an absurd amount of data, but.. They combine the integers into mostly a 2 byte for small/medium, and larger a 3 byte or 4 byte and save/send it as that. That means they can store around 250,000-500,000 x/y captures per 1mb. That translates to around 3.4 HOURS of constant mouse movement data capture per user. That data would obviously build up over-time, but IMO Jagex most likely clears this data either every ban-wave, or every week. Which wouldn't really be that much. You could also compress these integers an insane amount due to how primitive the encoding would be.
They also only send movements, not equal, or zero movements: https://github.com/zeruth/runescape-client/blob/master/src/Client.java#L3330 - Although, they still keep track of those equal/zero movements: https://github.com/zeruth/runescape-client/blob/master/src/Client.java#L3332
So we can see they record the data locally, but do they send it to the server? The answer is, yes. Here's proof of that (Annd they send a loot more then just that...):
https://github.com/zeruth/runescape-client/blob/master/src/Client.java#L3307
And here's them encoding the difference between mouse x/y movements into a 2 byte integer and appending it to their packet buffer (Only medium speed movements under about 31 pixel per 50MS):
https://github.com/zeruth/runescape-client/blob/master/src/Client.java#L3342
And here's them encoding movements into a 3 byte integer and appending it to their packet buffer (var10 = mouseY * 765 + mouseX):
https://github.com/zeruth/runescape-client/blob/master/src/Client.java#L3345
And here's them encoding movements into a 4 byte integer and appending it to their packet buffer (var10 = mouseY * 765 + mouseX)::
https://github.com/zeruth/runescape-client/blob/master/src/Client.java#L3348
They also can detect when you move your mouse outside of the screen, and how many ticks (Ticks are capped of course):
https://github.com/zeruth/runescape-client/blob/master/src/Client.java#L3324
Reconstructing their mouse collection:
||) Equal, or zero movements are tracked by ticks. If you don't move your mouse for 30 ticks, they'll know. They most likely use this for multiple purposes, the biggest being the ability to figure out the entire mouse movement rather then just bits of it.
1) Movement of the mouse is tracked, smalls/medium movements exactly by this (Only medium/small per-tick movement difference under about 30 in length)
int yDiff = (recordedY - previouslyRecordedYMove);
int xDiff = (recordedX - previouslyRecordedXMove);
handler.packetBuffer.putShort(yDiff + (idleIndexesPassed<< 12) + (xDiff << 6));
idleIndexesPassed = 0;
movementIndex = the indexes skipped before finding a mouse move in the X/Y mouse recorder. Used to track time between mouse movmenets.
2) Larger movements that are made in less then 8 ticks of "idle" mouse: (Actual location sent)
int var10 = (recordedY * 765 + recordedX);
handler.packetBuffer.put24bitInt((idleIndexesPassed << 19) + var10 + 8388608);
idleIndexesPassed = 0;
3) Large movements that are made 8+ ticks from being "idle" (Actual location sent)
int var10 = (recordedY * 765 + recordedX);
var14.packetBuffer.putInt((idleIndexesPassed << 19) + var10 + -1073741824);
idleIndexesPassed = 0;๏ปฟ
(Don't mind the -1073741824 or other random numbers. Java doesn't support primitive unsigned numbers, so you have to use hacky stuff to compress your integer sizes)
The majority of OSBot's movements would fall under #1's logging. The others are just for larger mouse movements (in terms of last X/Y -> new X/Y). Why do they multiple Y by 765? Because they've capped the X axis from exceeding 764 therefor they can easily mathematically combine the two integers for saving resources, then de-couple them whenever they want.
So what does all this have to do with OSBot's mouse movement? Well, I performed a basic test to grab the mouse movement delta's between every 50MS tick (Just as Jagex does) and found 100% consistency among certain parts of their mouse movement patterns:
OSBot's mouse movement: https://pastebin.com/AJn2NC31
My own mouse movement: https://pastebin.com/vnGtX16z
Right away you should notice many flaws inside OSBot's mouse sample. As you can clearly see, OSBot repeats ONLY 4-5 at the end of movements, AND at the last few deltas at the end of the movement, it goes from Lower, Bigger, Lower, This seems to be the case with virtually all mouse movements over 4-5 pixels large made by OSBot.
So if I'm able to detect this flawed mouse movement in a matter of seconds with basic math, then so can Jagex? This would also explain why tasks requiring massive amounts of mouse movement, such as agility, have much higher ban-rates vs something like fighting, or AFK tasks.
Does this mean this is the only detection method banning OSBot? Absolutely not. However, in my experience, I've yet to be banned by using OSBot as an API for everything BUT mouse movement, or camera movement (Of course with a lot more human-like behavior sprinkled on top of the scripts). This is purely based on only a little more then a week of botting without a ban, so it's possible I'm not bypassing, but simply delaying my ban. Hell, it's possible I was detected the second my script first started and now i'm just riding a monthly ban wave. Still beats a daily ban wave though...