Kochanek-Bartels Splines Custom Mouse Algorithm

[Koku 0]

Someone remarked about WindMouse being a dated solution and said "why not zoidberg spline algorithms" for a more modern solution, so I implemented a Kochanek-Bartels Spline algorithm for DreamBot's MouseAlgorithm interface. 

I don't want the implementation to be entirely public so I'm just sharing the translated math equations portion, which is honestly like 70% of the work imo. You'll need to look up literature/resources to fill in the gaps (equation inputs, handling of the outputs, etc). For a hint - generating control points is the most important next step, but exactly how you do that and how you use them in your algo's implementation is up to you 😉 It's like an open ended leetcode with a bit of math mixed in. 

• I mainly referenced the docs for this python package. It has most of the theory and math info you would need: Uniform Kochanek–Bartels Splines — splines documentation
• This is a more eli5 overview of the theory, but it only goes over high-level concepts: Splines - Curvy Splines (curvyeditor.com)
   

/**
 * An implementation of the Kochanek-Bartels Spline for simulating mouse movement between two points. This type of
 * spline uses three user-defined parameters to control the shape of the spline: tension, continuity, and bias. This
 * implementation was adapted for use with DreamBot's API.
 *
 * @author Koku
 */
public class TCBSplineMouse implements MouseAlgorithm {
  
  	// ... 
  
	/**
	 * Interpolates a point on a spline generated using a provided segment of control points for a given time-step t.
	 *
	 * @param t Value between 0 and n-1, where n = controlPointsSegment.size(). This value is the time-step along the
	 *          spline for the given controlPointsSegment.
	 * @return Point on the spline at time-step t
	 */
	private Point _interpolate(double t, List<Point> controlPointsSegment) {
		Point p1 = controlPointsSegment.get(0);
		Point p2 = controlPointsSegment.get(1);
		Point p3 = controlPointsSegment.get(2);
		Point p4 = controlPointsSegment.get(3);

		double dx_1 = (p2.getX() - p1.getX()) * (1 - _tension) * (1 + _bias) * (1 + _continuity) / 2.0
				+ (p3.getX() - p2.getX()) * (1 - _tension) * (1 - _bias) * (1 - _continuity) / 2.0;
		double dy_1 = (p2.getY() - p1.getY()) * (1 - _tension) * (1 + _bias) * (1 + _continuity) / 2.0
				+ (p3.getY() - p2.getY()) * (1 - _tension) * (1 - _bias) * (1 - _continuity) / 2.0;

		double dx_2 = (p3.getX() - p2.getX()) * (1 - _tension) * (1 + _bias) * (1 - _continuity) / 2.0
				+ (p4.getX() - p3.getX()) * (1 - _tension) * (1 - _bias) * (1 + _continuity) / 2.0;
		double dy_2 = (p3.getY() - p2.getY()) * (1 - _tension) * (1 + _bias) * (1 - _continuity) / 2.0
				+ (p4.getY() - p3.getY()) * (1 - _tension) * (1 - _bias) * (1 + _continuity) / 2.0;

		double t_squared = t * t;
		double t_cubed = t * t * t;

		// See [16] in: https://splines.readthedocs.io/en/latest/euclidean/kochanek-bartels-uniform.html
		double x = (2 * t_cubed - 3 * t_squared + 1) * p2.getX() + (t_cubed - 2 * t_squared + t) * dx_1
				+ (-2 * t_cubed + 3 * t_squared) * p3.getX() + (t_cubed - t_squared) * dx_2;
		double y = (2 * t_cubed - 3 * t_squared + 1) * p2.getY() + (t_cubed - 2 * t_squared + t) * dy_1
				+ (-2 * t_cubed + 3 * t_squared) * p3.getY() + (t_cubed - t_squared) * dy_2;

		return new Point((int) Math.round(x), (int) Math.round(y));
	}
 
  // ...
  
}

 

 

Edited April 11 by Koku

[Luxe 41]

Quote

I don't want the implementation to be entirely public

why?...

[Koku 0]

1 hour ago, ImLife said:

why?...

For the same reason that there are private vs public scripts - some sort of artificial barrier that results in fewer people using the same thing. The barrier here is you just need to be a decent enough programmer to implement it yourself after a little research and RTFM.

I think I've given enough pointers and since I already translated the complex mathematical portion into code, I'd say you don't need more than highschool level math to implement the rest. There's multiple ways one can write the supporting code for what I provided. Different people will come up with slightly different variations that lead to more unique patterns from this algorithm.

For someone that intends to use this on private scripts, making it semi-public is zero benefit at worst and potentially significant for dodging bans at best, depending on how much Jagex factors this type of mouse fingerprinting into bot detection.

[morten1ela 19]

On 4/11/2024 at 2:44 AM, Koku said:

depending on how much Jagex factors this type of mouse fingerprinting into bot detection.

Don't quote me on this... but someone, I don't know who, claimed they dug through the client's code and found no indications that they're collecting mouse data. If they were, why would people be reporting a negligible difference in ban rate with menu manipulation on vs off?

[Iron Sentinel 1]

On 4/23/2024 at 10:57 PM, morten1ela said:

Don't quote me on this... but someone, I don't know who, claimed they dug through the client's code and found no indications that they're collecting mouse data. If they were, why would people be reporting a negligible difference in ban rate with menu manipulation on vs off?

There is definitely a mouse recorder in the client's source code. Someone on OSBot forum wrote a post about it: "OSBot's mouse movement is easily detected". You can also check OpenOSRS' source code, it's clearly there. 

I do agree that it's odd that people report a negligible difference for menu manip, but I don't think anyone has done any proper statistical analysis on it either. Perhaps mouse movement data is only used in manual reviews, I have no idea. After all, it's possible to play legitimately without moving the mouse at all, so while I believe it should flag the account, it's not enough for an automated ban.  

Edited May 25 by Iron Sentinel

[morten1ela 19]

On 5/25/2024 at 2:36 AM, Iron Sentinel said:

check OpenOSRS' source code, it's clearly there. 

I said don't quote me! >:c

Just kidding... I took a peak at openosrs. It does look like they're exporting the data. Not sure who I heard that from. Seems like each packet sent is an array of 500 x's, y's, and milliseconds. Maybe to track the changes in x pos, y pos, and the time in between each change. Just speculation, I didn't look much more into it than that.