Overthinking/Underthinking Anti-bans?

[Blueorb Scripts]

I've always been aware that the best anti-ban a person can have is actually being there, watching the script do everything for you but talk. I also know the difference between sudo anti-bans and actual anti-bans. I know this following code is classified under a sudo anti-ban. I'd just like to get a understanding of what you guys think of it. Is it too much? Is it too little? Should I add to it; is it already overdoing it? For learning purposes, I've decompiled a few scripts to view what others do for anti-bans and I don't see anything such as this. getMouse().moveRadomly(); is a big one I see in a lot of scripts but nothing along the lines of what I have. I also see a lot of scripts that will check your stats but not as often as mine (which I do know that I should lower the amount of times it checks).

getTabs().open(Tab.X);
sleep(### + random(###,###));
getSkills().hoverSkill(Skill.X);
sleep(### + random(####,####));
getTabs().open(Tab.X);
sleep(### + random(###,###));
getMouse().moveRandomly();

[X] and [#] have been added to protect it from just being copied and pasted with the exact same numbers but you guys should get the point. It runs this every so often when the player is animating.

 

 

Decompiling certain scripts; IE: Combat related scripts, makes me wonder that the activity in itself is in fact an anti-ban method since most "bots" don't typically do combat related activities. Jagex probably knows that this is false but when looking at someone's source (not naming names or scripts) the anti-ban is scarce or minimal. Perhaps it could just be because these scripts are in the local section and are there for that exact reason.

 

I understand that being a new member trying to learn how to write these scripts and decompiling others may seem "skiddish" or "leach like" but I hope you all understand its only for learning purposes. I have no intent to re-skin and change some code around, just to redistribute it. If anyone is doing this they should be punished.

 

I'm looking forward to all of your replies on this topic. I do not want to see what anti-bans some premium scripts may have, just the opinion of people who write premium scripts

 

Thank you for your time.

[Bobrocket]

Here's a good read for you: https://rs-hacking.com/resources/macroingdetection.pdf

It's legitimacy is questionable, but it gives us good ideas of what to do.

 

Some summary points:

Bots lack accuracy and precision, which humans possess. (look at graph below)

Low accuracy = far from the true value; high accuracy = close to true value

Low precision = values very spread out; high precision = values close together

 

Even when doing random(x, y) when taken enough times, the mean of random(x, y) is still going to be around (x + y) / 2.

 

 

 

 

[Khaleesi]

Here's a good read for you: https://rs-hacking.com/resources/macroingdetection.pdf

It's legitimacy is questionable, but it gives us good ideas of what to do.

 

Some summary points:

Bots lack accuracy and precision, which humans possess. (look at graph below)

Low accuracy = far from the true value; high accuracy = close to true value

Low precision = values very spread out; high precision = values close together

 

Even when doing random(x, y) when taken enough times, the mean of random(x, y) is still going to be around (x + y) / 2.

 

Ya that's a good read indeed

 

Thats issue with most of the scripts, the randoms values are spread way too much.

 

A good way to decrease these random values, like clicking at the outer edge of an widget is to randomnize your numbers twice ^^

random(random(xMin),random(Xmax)).

 

This way you got a much higher change of hitting closer to the middle of the widget.

There is still a chance you'll click the edge, but less likely.

 

Not sure if that is what you are tryign to say ^^

 

Khaleesi

[Bobrocket]

Ya that's a good read indeed

 

Thats issue with most of the scripts, the randoms values are spread way too much.

 

A good way to decrease these random values, like clicking at the outer edge of an widget is to randomnize your numbers twice ^^

random(random(xMin),random(Xmax)).

 

This way you got a much higher change of hitting closer to the middle of the widget.

There is still a chance you'll click the edge, but less likely.

 

Not sure if that is what you are tryign to say ^^

 

Khaleesi

 

If you want to do something like that, you should look into distributions

I wrote a small bit about distributions in my SmartKeyboard thread (cba to find it lol), but to sort of target the bullseye as it were (and then hit the bullseye 99% of the time), you'd take a normal distribution for both x and y:

Point widgetPoint = new Point(getNormalDistributedRand(x1, x2), getNormalDistributedRand(y1, y2));

Another way is to add up 2 randoms, eg 2 6-sided die have the highest probability of rolling a 7.

int randX = rand(1, 6) + rand(1, 6);

Reading the link I sent again, read how they note "depends on placement". This is where statistics starts to become a very big part of botting.

If you look at my API, I take a lot of this into account. Look at my NPC file here, note the hover(), getSuitablePoints(), and the variety of random functions. What we're essentially saying when we hover is we're trying to match a point that is as close to the mouse as possible (ie doing less work; in words of Fitt's law getting as small an index of difficulty as possible) that is also a suitable point on the NPC. Think of it as a car with thinking and stopping distances. You want the stopping distance to be as small as possible, so we can technically say that we want to stop at the centre, and by the time we enter the rectangle we have finished thinking.

 

Sounds very confusing, but it's about as human-like as you can get.

Edited November 4, 2015 by Bobrocket

[Khaleesi]

If you want to do something like that, you should look into distributions

I wrote a small bit about distributions in my SmartKeyboard thread (cba to find it lol), but to sort of target the bullseye as it were (and then hit the bullseye 99% of the time), you'd take a normal distribution for both x and y:

Point widgetPoint = new Point(getNormalDistributedRand(x1, x2), getNormalDistributedRand(y1, y2));

Another way is to add up 2 randoms, eg 2 6-sided die have the highest probability of rolling a 7.

int randX = rand(1, 6) + rand(1, 6);

Reading the link I sent again, read how they note "depends on placement". This is where statistics starts to become a very big part of botting.

If you look at my API, I take a lot of this into account. Look at my NPC file here, note the hover(), getSuitablePoints(), and the variety of random functions. What we're essentially saying when we hover is we're trying to match a point that is as close to the mouse as possible (ie doing less work; in words of Fitt's law getting as small an index of difficulty as possible) that is also a suitable point on the NPC. Think of it as a car with thinking and stopping distances. You want the stopping distance to be as small as possible, so we can technically say that we want to stop at the centre, and by the time we enter the rectangle we have finished thinking.

 

Sounds very confusing, but it's about as human-like as you can get.

 

Ya indeed that's what I meant

I was just giving an example without going to deep.

 

I think Osbot should change the way the interact with widgets.

Like clicking the "Click here to continue" messages. you can either click on it at the whole left or right side of the chatbox.

but what human does that? 

 

Just with some very easy math you can actually get a more humanized mouse

 

Khaleesi

[Bobrocket]

Ya indeed that's what I meant

I was just giving an example without going to deep.

 

I think Osbot should change the way the interact with widgets.

Like clicking the "Click here to continue" messages. you can either click on it at the whole left or right side of the chatbox.

but what human does that? 

 

Just with some very easy math you can actually get a more humanized mouse

 

Khaleesi

 

Just a bit of thought, would it be possible to calculate the actual bounds of a widget based on colours? I have no clue myself but if it's possible then that would be really good.

[Khaleesi]

Just a bit of thought, would it be possible to calculate the actual bounds of a widget based on colours? I have no clue myself but if it's possible then that would be really good.

No idea if that's possible,

but why would you need to determine the bounds of an widget based on color?

 

Just simply use the widget.getBounds()?

[Bobrocket]

No idea if that's possible,

but why would you need to determine the bounds of an widget based on color?

 

Just simply use the widget.getBounds()?

 

A lot of widgets have very weird bounds.

[Khaleesi]

A lot of widgets have very weird bounds.

Which ones?

 

99% of which I used are pretty accurate

Somtimes 3-4 widgets overlap almost the same area so finding the right one is hard at some points ^^

 

Khaleesi

Edited November 4, 2015 by Khaleesi Scripts

[Bobrocket]

Which ones?

 

Most of them I used are pretty accurate.

Somtimes 3-4 widgets overlap almost the same area so finding the right one is hard at some points ^^

 

Khaleesi

 

Off the top of my head, a lot of the ones when smithing have bounds that go way above what they should be.

[Khaleesi]

Off the top of my head, a lot of the ones when smithing have bounds that go way above what they should be.

 

I see, most of the in crafitn windows too, but they always have another "Hidden" widget that does perfeclty fit.

but indeed there are some of them that are completely bs.

 

Khaleesi