Jump to content

[Very Experimental] OSBot 2.4.45 - Script Analyzer


Alek

Recommended Posts

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. 

 

94ab762418175d37ce5557491206c200.png

 

 

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

 

  • Like 16
Link to comment

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.

Link to comment

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

Link to comment

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 tongue.png

 

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 by MegaManAlpha
Link to comment

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 tongue.png

 

The point would not be to monitor which data is sent over a connection (hard to do at compile time tongue.png), 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 tongue.png

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 tongue.png

 

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

Edited by Botre
Link to comment

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.

  • Like 1
Link to comment
Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...