[Very Experimental] OSBot 2.4.45 - Script Analyzer

[Alek]

The Script Analyzer is a tool designed to tackle many issues which we face when third parties develop scripts for our client. As of right now, the analyzer will assess only your local scripts and print out a display of issues. In the future when the tool matures, we will start to rely on it by restricting high-risk scripts from loading altogether. 

 

What it has right now:

-Only local script analyzing 

--Checks for deprecated code

--Checks for scripts accessing outside the API package

 

Eventually I would like to check a lot more including connections, file modification, etc. 

 

 

 

As previously mentioned, the issues we would like to address include:

- Providing basic security to botters who use local scripts

- Direct scripters through code checks (e.g. deprecation)

 

As always, security first, stability second, and then innovations and improvements. This project is very experimental so please mind any issues which you may encounter. Any issues related to the Script Analyzer, please post below - all other issues will be hidden.

 

Changelog:

-Integrated local Script Analyzer

 

Safe Botting!

-The OSBot Staff

 

[Czar]

hohooooooooo yes!

 

This is one of the updates I've most looked forward to, good job alek, hope to see some nice development on this feature

[urnutzmyboot]

It's too late for an April Fool, it must be real!

[Rent Money]

This could be useful to figure out why my scripts keep breaking...I think

[Genii]

Looks amazing Alek

[DragonAlpha]

Good release. It's always bugged me that scripts can effectively run in a totally wide-open environment and do anything.

 

Hopefully this will also look for attempts to use windows API such as register hot key / keyboard hook. (Register hot key could be done on every key, as an alternative to bypass any keyboard hook restrictions, so that would be good to be blocked too).

 

Regarding things like taking a screenshot, (Robot class for example), perhaps a message could be displayed "This script can take screenshots of your entire screen - Would you like to allow this?" [Yes] [No]. And [No] option would strip calls to it.

 

This may hopefully help with SDN upload approval too, although that of course needs to be a manual check too in case anything is missed.

[Botre]

Good release. It's always bugged me that scripts can effectively run in a totally wide-open environment and do anything.

 

Hopefully this will also look for attempts to use windows API such as register hot key / keyboard hook. (Register hot key could be done on every key, as an alternative to bypass any keyboard hook restrictions, so that would be good to be blocked too).

 

Regarding things like taking a screenshot, (Robot class for example), perhaps a message could be displayed "This script can take screenshots of your entire screen - Would you like to allow this?" [Yes] [No]. And [No] option would strip calls to it.

 

This may hopefully help with SDN upload approval too, although that of course needs to be a manual check too in case anything is missed.

 

The Robot class / key listeners are perfectly safe.

 

As long as incoming and outgoing connections are checked, we don't really have to worry about the rest :p

[DragonAlpha]

The Robot class / key listeners are perfectly safe.

 

As long as incoming and outgoing connections are checked, we don't really have to worry about the rest

 

Still, the user could be informed the script takes a screenshot.

 

We can't monitor socket data if its encrypted, or acts like its something else: example image/JPEG header to make it look likes its an image.

 

What about a script that creates a second program: hack.jar, and then launches it. That script does not do connections. So no, many things could be warned to user.

 

Already Alek is warning user about Deprecated functions being used, which is not just a connection thing, so this shows this is the way it will go. (Not just being used on connections).

 

Also what if I was maliscous and just wanted to screw your computer over? Deleting system files for example, or deleting all word documents. That would not have connections either. The warning would be: "This script can delete files from your computer. Allow it to do so?" [yes] [no]. If you click no, the script runs as usual but when it calls File Delete functions they fail, SecurityManager exception for example.

Edited April 2, 2016 by MegaManAlpha

[Botre]

Still, the user could be informed the script takes a screenshot.

 

We can't monitor socket data if its encrypted, or acts like its something else: example image/JPEG header to make it look likes its an image.

 

What about a script that creates a second program: hack.jar, and then launches it. That script does not do connections. So no, many things could be warned to user.

 

Already Alek is warning user about Deprecated functions being used, which is not just a connection thing, so this shows this is the way it will go. (Not just being used on connections).

 

Also what if I was maliscous and just wanted to screw your computer over? Deleting system files for example, or deleting all word documents. That would not have connections either. The warning would be: "This script can delete files from your computer. Allow it to do so?" [yes] [no]. If you click no, the script runs as usual but when it calls File Delete functions they fail, SecurityManager exception for example.

 

If a script generates and compiles a second application that should obviously should raise flags

 

The point would not be to monitor which data is sent over a connection (hard to do at compile time ), the point would be to detect at compile time whether a connection is established and warn the user of this (?).

 

You can't micro-manage security scenarios without making life a living hell for script makers and script users

So, posting some guards at the principal gates, that warn users about file modification, deletion, outgoing and incoming connections -> sure. But warning the user whenever a db request is made, whenever an image is being downloaded, whenever you're making a screenshot, whenever you are listening for keyboard shortcuts, whenever you send a key-event to the client, etc... -> please no

 

That being said if they can do it in a way that's not too intrusive, eh why not

Edited April 2, 2016 by Botre

[DragonAlpha]

If a script generates and compiles a second application that should obviously should raise flags

 

 

 

The script analyzer runs before the script is launched.

 

Yup it should raise flags. Many things should raise flags and be noted to the user.

[Botre]

 

Many things should raise flags and be noted to the user

 

Some things should, but if you start spamming people with unnecessary warning messages they end up just ignoring them which makes the entire security system redundant :p

Eh, agree to disagree I guess.

[Alek]

Right now it's going to spam messages as it's more of a debug than anything. Eventually I plan on establishing policies such as automatically quarantine, blocking the script from running, messages, options to allow a script to do something, etc. Of course I'll try making it as user-friendly as possible.

[DragonAlpha]

Right now it's going to spam messages as it's more of a debug than anything. Eventually I plan on establishing policies such as automatically quarantine, blocking the script from running, messages, options to allow a script to do something, etc. Of course I'll try making it as user-friendly as possible.

 

Yeah awesome. Hopefully things that could be RAT related are automatic quarantine, and things like taking screenshots could prompt the user.

 

But either way I am really happy to see this.

[GaetanoH]

Very nice update Alek!