SRL Archive - Senior News and General

Scripting Restrictions (problems + discussion)


Sir R. M8gic1an

2009-02-04 19:02:22

We do NOT open web pages that contain no use full addition to the script. And unless you can come up with a real good reason, I suggest you don't use it at all. Opening Web Pages that are used for ads, etc. are not allowed.

From: zasz
In my script i have it send data like the pickaxe id and and your characters tile location + the
players[1].nick (just the 3/4 letters) to my site so i can use the data to update my script in future additions.)

The script is my Iron Man. Will i have to take out this feature?


From: Rasta Magician

Are we stil allowed to send progress reports to websites?


what do you guys think? (Any other questions of this kind, just edit them in / post)

i guess the problem is on the term "useful". Is there any way we can be more specific? This is basically to make sure that people don't connect to a website, and because of that do not have the chance to steal accounts.

But there are many good features that link to the internet. …

maybe make it necessary to declare at the top of the script that it makes an internet connection for so and so reasons? And on so and so lines?


Program RMScript;

{
***** Internet Connection *********
* Sends Progress report to online *
* database. line 78 *
***********************************
}

This way if a person is suspicious they can just comment out the line and check if there are any extra connections. Just an idea.

~RM

R0b0t1

2009-02-04 19:13:16

No, I can actually see a use for that. I'd probably eventually think of using that in a script of mine if I made one. It will show you how the walking has done so far.

It is also impossible to impose a stereotype such as this, it's plain stupid.

Sir R. M8gic1an

2009-02-04 19:22:53

From: R0b0t1
No, I can actually see a use for that. I'd probably eventually think of using that in a script of mine if I made one. It will show you how the walking has done so far.

It is also impossible to impose a stereotype such as this, it's plain stupid.


The thing is it has been imposed robot. But like you, i agree that it is too general.

ZephyrsFury

2009-02-04 19:26:28

From: Rasta Magician
We do NOT open web pages that contain no use full addition to the script. And unless you can come up with a real good reason, I suggest you don't use it at all. Opening Web Pages that are used for ads, etc. are not allowed.


I believe this rule is aimed at stopping scripts openning up to the scripter's bux.to ad or similar "pay me money" ads. The sending of data such as the players location or equipment is acceptable IMO. Sending progress reports is also a good way of knowing how your scripting is being used and how well its running. I think however than any information that can be used to identify your characters mustn't be allowed (such as your player name).

Smartzkid

2009-02-04 21:57:33

-Require all internet connections to be disabled by changing a constant or define (or form, if available)

-For the ads, just print out the url to the debug screen after the script runs; if you have anything worth looking at, people will go there. IE script stats, updates, etc.

Bobarkinator

2009-02-04 22:07:44

From: Smartzkid
-Require all internet connections to be disabled by changing a constant or define (or form, if available)

-For the ads, just print out the url to the debug screen after the script runs; if you have anything worth looking at, people will go there. IE script stats, updates, etc.


And make all websites also be defined by a constant in the upper section of the script so people see what website it is connecting to.

The Claw

2009-02-04 23:07:58

But what if people have "usefull" connections and declare them etc to get people to allow it to connect, but then have password stealing code hidden all the way to the right?

n3ss3s

2009-02-05 02:25:52

Yes, it is so easy to make a 'fix to the mining procedure', like someone brought up in the other thread.

The Claw

2009-02-05 02:45:29

Yep, which makes me think all scripts connecting to outside sites would have to be verified by dev+ first (not ssrl cause that would blow their cover). Might need to introduce checksums too, to ensure that once a version of a script is verified by a dev they dont switch it over quickly to an unsafe version with the same file name. Would be a simple matter of control+f to search for all website related functions a script could useALL GLORY TO THE HYPNOTOAD

Sir R. M8gic1an

2009-02-05 02:59:00

well, if we think about it, the websites that have stolen acounts so far use php, which basically means their urls were always something like
www.blahblahblah.com/index.php?version=' + VersionNumber + '&Proggy='+ proggy

it's easy enought to check for these.

but then again we haven't allowed password stealing ever.

We could just say that websites are not allowed to connect to things such as advertisinments and click pay websites etc and people will pretty much get the idea. That would allow flexibility for the good features.

Other than Ads and Stolen passwords, can anyone think of bad things that they might use the connection to the internet for? (that have been done before / could be done)

~RM

Smartzkid

2009-02-05 15:18:55

Write a plugin (so they can't see the code) that will handle all internet interactions. Provide a function to update a script if it's outdated (one argument - a special code that corresponds to the script & version url's in some online database). Have another function to handle other internet interactions; log all url's (either on the client computer, or on an online database), and check url for character passwords. Inside SetupSRL, open the script file and check it for any 'unsafe' internet calls, report them, and either strip them from the script or terminate it.

Sir R. M8gic1an

2009-02-05 18:15:45

  • We do NOT open web pages that contain no use full addition to the script. And unless you can come up with a real good reason, I suggest you don't use it at all. Opening Web Pages that are used for ads, etc. are not allowed. *

* Useful: Online progress reports, status reports, version checker, …,
* Not Useful: Adverstisements, click for cash, …;
* Strictly forbidden: Username, Password. Nicks are allowed.
* If you are unsure of a feature, ask staff.

~RM

Bam Bam

2009-02-05 20:02:25

Or people who have such a problem with internet connection could set the firewall in SCAR to block all of them by default.

R0b0t1

2009-02-05 21:18:02

SSRL could verify them, or a list of "honored members" could be erected. They might – ALL HAIL HYPNOTOAD – get it, they might not. Generally, as it is, if the script connects to some randomHYPNOTOADsite, someone will notice and point it out. At that point, it is investigated. The problem seems to solve itself, although there are some losses… But it seems the losses might outweigh the trouble of verifying the scripts.

King of Knives

2009-02-09 06:45:27

What if we added something to the SRL library?

procedure SendIntsToSomewhere(URL: String; Numbers: array of int);
begin
// Open URL and send the integer to that place
end;

I am getting a bit rusty at SCAR, but I believe that this way, the scripter can't modify how the connection works (Only on his computer) but can still send integers (Time running, tile location and such) to his own website.

Maybe.

-Knives

n3ss3s

2009-02-09 10:49:57

Why make a procedure for sending ints somewhere, how would that work against people sending passwords and usernames to their own site?

Unless you meant overwriting SCAR's SendConnectionData with that one, but in SCAR how complicated you will ever make it, in the end it uses a function that's in SCAR, that's what your int version also would have to use, which means also the evil scripter could use it.

Also, some smartass can send the passes and users in binary form, so ints don't really help :(

King of Knives

2009-02-09 17:13:46

I already figured out that people could just do something to the passwords to make them into numbers, but that would be quite a bit more visible and harder to do for an evil-minded scripter. An honest one would hardly have any extra work.

Yakman

2009-02-09 17:59:04

only allowing integers to be sent will not work, its far too weak of a protection method.

IMO the only way we'll be able for enforce this is with people reading each others script.

theres that way of hiding your code by pressing space many times, if that still works, we should ask freddy to close this loophole by making code in scar wrap around if you cant see it or something.
theres no reason to make reading unnesscarily harder.


btw, i like Smartzkid's idea about people being able to disable scripts connecting to places.
Even in 'real life' applications, you're not forced to send crash reports or update your program, you always have a choice not to.

Widget

2009-02-09 19:09:40

Or, the easy way.
Have Freddy display the full URL, including POST data (right now it just says "http://www.somesite.com/whatever.php ?POST?") and a little warning label saying something along the lines of "The script is trying to send data to an unknown website. If the following contains any of your usernames or passwords immediately cancel the script and post on the thread that you found it." or whatever for connecting to anywhere but SRL-Stats.

Or SRL could pass something along to SCAR which could hold the passwords and check against the URL/POST data which would force people to either encrypt the passwords or learn to call MouseSpeed := 15 instead of SetupSRL; :p

Boreas

2009-02-09 22:50:39

From: Yakman

IMO the only way we'll be able for enforce this is with people reading each others script.


+1

I was hoping there would be a way to do this, but unfortunately there's a way around every method. And it's harder to spot than the current situation. We don't want escalation to give us the same problem jagex has with bots approaching undetectability. What I think we can do is educate the public. Come up with a fool proof guide on how to trace back web functions. Then try to come up with a way to steal passwords that won't be discovered by following the guide, and then fix the guide etc.

Sir R. M8gic1an

2009-02-10 01:56:30

how about teaching the public to use notepad + search for website connections?

scar only has said number of website connecting functions, checking them in notepad wouldn't be too hard.

~RM

Markus

2009-02-10 08:34:48

You guys seriously think this will help? An evil person can always get a passstealer in by just using a plugin and putting a nice keylogger on it, using API calls, renaming complete procedures to otherse etc. Who the fuck bothers checking the scripts anyways, by the time they are posted evil is already done, and you seriously think moderating every script before it's posted is an option? I don't think so.
This is just like another of those "anti-terrorism measures", the only people they stop are the good guys. Giving a false sense of safety isn't going to help anyways. If you create a nice script, it only takes an hour to get a couple of passwords in your pocket, and I'm sure it takes more than an hour to check a script out, a couple of hours before someone notices.

Besides: wtf are we talking about. There are five scripts which stole passwords, out on around five-thousand released versions etc of script? That means 0,1% of the scripts might steal passwords. Seriously, that's nothing.

R0b0t1

2009-02-10 16:58:33

Then, Markus, how do the current rules help? I personally won't follow them; they're unnecessary. You can't protect everyone – so either choose to moderate all of them or only have a few (usually one) suffer before the script is found out.

Sir R. M8gic1an

2009-02-10 17:40:19

heh, i made this so we could find a solution to the "too general" no connecting to websites rule :p

about protecting scripts, there will never be a sure way. I agree with Boreas, the harder we try to stop it, the harder they'll try to do it, just like we do in relation to RS.

And as n3ss3s said in the Black Market thread: it's a question of using your head and knowing who to trust. (in dif words :p)

~RM

Markus

2009-02-11 06:45:43

From: R0b0t1
Then, Markus, how do the current rules help?

As I said, they don't.