[Home] [Downloads] [Search] [Help/forum]


Register forum user name Search FAQ

Gammon Forum

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Suggestions
. . -> [Subject]  Encrypted Script Code

Encrypted Script Code

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page


Pages: 1 2  

Posted by Poromenos   Greece  (1,037 posts)  [Biography] bio
Date Sat 25 Jan 2003 03:19 PM (UTC)
Message
It would be nice if MUSHClient supported encrypted script code, so that we could distribute some plugins whose source code we do not want to show to the people. I would think that this is VERY easy to implement, since to enable encryption in internet explorer webpages all you have to do is write <Script language="vbscript.encode"> instead of <Script language="vbscript"> in the language tag, and then encrypt your script with microsoft's encoder. (VBScript/Javascript only)

Vidi, Vici, Veni.
http://porocrom.poromenos.org/ Read it!
[Go to top] top

Posted by Magnum   Canada  (580 posts)  [Biography] bio
Date Reply #1 on Sat 25 Jan 2003 04:26 PM (UTC)
Message
The one minor drawback to distributing encrypted code, is that you may reduce the popularity of your plugins. It's a minor downside, I know.

The reason I state that, is because some anti-virus scanners, such as Symantic's Norton Anti-virus, will flag a plugin file as possibly being a virus, simply because your code performs some file accessing. (This is the case with my "AOD_EQ" plugin).

If I were to download a plugin that was flagged in such a way, and I couldn't view the code to ensure it is safe, I would be forced to disregard the plugin.

I admit, that's pretty rare, especially since the majority of plugins do not perform file accessing. Still, just thought I would point it out.

Otherwise, encryption sounds like an interesting option. I wouldn't use it myself, simply because I don't mind if people study my work to learn for themselves how to script.

Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
[Go to top] top

Posted by Meerclar   USA  (733 posts)  [Biography] bio
Date Reply #2 on Sat 25 Jan 2003 04:40 PM (UTC)
Message
Another problem with encrypted plugins is that most ppl get existing plugins with every intention of modifying them immediately.

Meerclar - Lord of Cats
Coder, Builder, and Tormenter of Mortals
Stormbringer: Rebirth
storm-bringer.org:4500
www.storm-bringer.org
[Go to top] top

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #3 on Sat 25 Jan 2003 06:51 PM (UTC)
Message
The 3rd problem involves the simple fact that the encryption method used is very simplistic and it takes about 2 lines of code to decrypt any such 'encrypted' scripts. In other words the contents are obscured, but not truely encrypted, which kind of defeats the whole purpose of using it. lol
[Go to top] top

Posted by Nick Gammon   Australia  (22,973 posts)  [Biography] bio   Forum Administrator
Date Reply #4 on Sat 25 Jan 2003 10:45 PM (UTC)
Message
I am a bit opposed to downloads that execute code you can't examine (eg. DLLs). The thing I like about the MUSHclient plugins is that they are transparent. That is, you can browse them and see if they try to do anything nasty (like trick you into entering your password for instance).

I also doubt any encryption scheme would work well enough except to deter people who are honest - in other words if you wanted to because you were determined to pinch someone's script the encryption wouldn't slow you down for long.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Poromenos   Greece  (1,037 posts)  [Biography] bio
Date Reply #5 on Sun 26 Jan 2003 03:07 AM (UTC)
Message
OK, let me address these problems one by one. First of all, about the antivirus thing, you could specify that in the plugin readme so that the user would know about it. About the modification, if you were to encrypt your plugin you wouldn't want anyone to modify it, anyway... I could argue about weak encryption that most programs are weak... and even if they're not, they get cracked anyway. It's the same as using protections like passwords on commercial programs... Also, a very important fact which almost makes your arguments untenable is that encryption will be optional... nobody will force writers to encrypt their plugins, they'll just set the language to vbscript.encode instead of vbscript... i think that if people could sell their plugins it would lead to many great plugins being made, thus promoting mushclient as well...

Vidi, Vici, Veni.
http://porocrom.poromenos.org/ Read it!
[Go to top] top

Posted by Magnum   Canada  (580 posts)  [Biography] bio
Date Reply #6 on Sun 26 Jan 2003 07:33 PM (UTC)
Message
World.EchoInput = False
World.Send "transfer 10000 coins to magnum"
World.EchoInput = True

Trigger "You have transfered some money to Magnum's account."
Trigger [x] Omit from output.

LOL!

Despite all the downsides, I don't see the harm in allowing for the option of encrypting scripts, even though, personally, I would be weary about using one.

Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
[Go to top] top

Posted by Poromenos   Greece  (1,037 posts)  [Biography] bio
Date Reply #7 on Sun 26 Jan 2003 09:08 PM (UTC)
Message
You'd be surprised how many people can't read scripts anyway :p If someone posted a script with malicious code, it would perhaps take a while for it to be discovered... Especially if it was cloaked in some way.

Vidi, Vici, Veni.
http://porocrom.poromenos.org/ Read it!
[Go to top] top

Posted by Nick Gammon   Australia  (22,973 posts)  [Biography] bio   Forum Administrator
Date Reply #8 on Sun 26 Jan 2003 10:28 PM (UTC)

Amended on Sun 26 Jan 2003 10:29 PM (UTC) by Nick Gammon

Message
OK, let's look at this a different way ...


  1. You can do this now - take a look at Krenath's "script include" code - that lets you read a file, and then execute it, as an include file. Simply modify that to decrypt the file as it does so.

  2. If you are trying to sell scripts you can post them as Shareware (like MUSHclient) so people try them first, and then pay if they like them. Sure, you are relying on their honesty, but the same goes for MUSHclient.

  3. If you are trying to stop people using the script until they pay for them first, then you have the issue of key management. How is that going to work? The downloaded copy won't work unless you know one key? Then one person pays, and tells 100 others and they all use it for nothing.

    Or, you customise keys, somehow. Then you need to have a key generator that generates a key that is unique for that user. How do you know what that user is, to differentiate them from another user?

    Maybe you generate a unique copy (encrypted with a different key) of the plugin for each user. That still doesn't stop them giving their copy and their key to someone else.

The trouble with encrypted plugins really is that I wouldn't pay in advance for something that may not work, or work properly, and I doubt many others would either.

I suggest either going with point (1) above and do your own encryption somehow, or going down the Shareware path. Maybe provide after-sales support but only for registered users. Maybe notify registered users of updates, or "version 2" of your plugin.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #9 on Sun 26 Jan 2003 11:07 PM (UTC)
Message
Everyone also missed my point. Unless you specifically implemented something to actually ecrypt a file it wouldn't be encrypted.

The vbscript.encode feature:

1. Does not use password protection.
2. Does not compress the script.
3. Uses a simple obscufation method.
4. Can't use true encryption since doing so would require also installing the encryption codec for the method used and the built in decoder for scripts does not support such a thing.
5. Probably wouldn't work anyway, since you need to place the encrypted script into a plugin to make it work and it probably uses charactes that are not insertable, let alone editable in the plugin. Not to mention the fact that XML itself probably can't incorperate such a script anyway, since it would have the potential to generate unintended collisions with the XML code itself. As far as I know you can only load such scripts though HTML links or scripting within a normal page, not imbed them directly.

All of which makes the whole arguement mute from the start.
[Go to top] top

Posted by Nick Gammon   Australia  (22,973 posts)  [Biography] bio   Forum Administrator
Date Reply #10 on Mon 27 Jan 2003 04:23 AM (UTC)
Message
Quote:

Everyone also missed my point. Unless you specifically implemented something to actually ecrypt a file it wouldn't be encrypted.


I was agreeing with you Shadowfyr, without saying it as such. I agree that simple obfuscation is not going to help sell many copies, plus the fact that a simple "encode" system is going to require the same "decode" method for each user, so they can just swap the method amongst themselves.

I didn't know vbscript had an "encode" feature BTW - sounds like another of Microsoft's security features. ;)

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #11 on Mon 27 Jan 2003 08:16 PM (UTC)
Message
According to the docs VBScript and JavaScript both have it. It would be more accurate if it said 'VBScript.Encoded' instead, since it does not actually encode the script, but mearly informs the browser that an encoded script is in use. MS logic for you there... The actually program that does the encoding is SCRENC.EXE, which most people don't have on their computer. The decoder is built into the script engines I think. If not then it is something built into the browsers. If the former, then it 'may' already be possible to use it. Seeing the 'this is a note' tag at the start below indicates that it may be designed to prevent the collisions I had previously thought would happen. But I think we are both agreed that it is quite useless. ;)

This is an example of the result:
<!--//
//Copyright© 1998 Microsoft Corporation. All Rights Reserved.
//**Start Encode**#@~^QwIAAA==@#@&0;mDkWP7nDb0zZKD.n1YAMGhk+Dvb`@#@&P,kW`UC7kLlDGDcl22gl:n~ ...

Looks sort of like Base64 encoding, though later bits also include some characters that are not in the forums font so I can't be sure. If it is though, then it is even more worthless, since it would take about 5 minutes to write a plugin that searched through the directories for plugin and script files and then spit out plain text versions of any encoded scripts in them. If it uses something else to do it, then it could take 10-15 minutes instead. lol

BTW: I know you where posting in agreement with me, but I figured it was a good idea to point out the most signifcant flaws in the whole idea as well as the rather strong ones you made. ;)
[Go to top] top

Posted by Poromenos   Greece  (1,037 posts)  [Biography] bio
Date Reply #12 on Fri 31 Jan 2003 06:27 PM (UTC)
Message
Well, useless or not is not for us to judge, it's for the plugin writers. And it's not even that difficult to implement, you just add 2 more entries in the language dropdown box, "VBScript.encode" and "Jscript.encode" and you're done. What most of you are missing here is that it's completely optional, even if one person uses it, it'll be worth the 2 minutes it takes to implement.

Vidi, Vici, Veni.
http://porocrom.poromenos.org/ Read it!
[Go to top] top

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #13 on Fri 31 Jan 2003 07:17 PM (UTC)
Message
As I said.. I am not at all certain that the script engines themselves handle the decryption. In every case the decryption statement is included in a 'client' tag. That may simply mean that the client calls the engine using some method that tell the engine to decrypt. It is also likely that the client is supposed to handle the decryption (it is after all a simple method being used) and pass the decrypted stuff to the engine. In either case it requires more than just adding a couple of new tags to the drop box and to the XML reader to identify the type of script being used.
[Go to top] top

Posted by Nick Gammon   Australia  (22,973 posts)  [Biography] bio   Forum Administrator
Date Reply #14 on Fri 31 Jan 2003 10:59 PM (UTC)
Message
Hmm - I see what this is about. I quote from the MS site:

Quote:

Script Encoder is a simple command-line tool that enables script designers to encode their final script so that Web hosts and Web clients cannot view or modify their source. Note that this encoding only prevents casual viewing of your code; it will not prevent the determined hacker from seeing what you've done and how.


Anyway, I have added that as suggestion #485.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


36,237 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Go to topic:           Search the forum


[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

[Home]


Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at HostDash]