Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Script Encoder Beta 1 Released to the scripting web site

0 views
Skip to first unread message

Andrew Clinick(MS)

unread,
Dec 2, 1998, 3:00:00 AM12/2/98
to
The Microsoft Script Encoder has just been posted to the scripting site. It
allows you to use the script encoding feature in the V5 engines. Just run
screnc.exe, pass in an HTML, ASP, JS, VBS or SCT file and provide a new name
for the encoded version e.g.:

screnc default.htm defaultenc.htm

You can also call a method on the encoder object within scrrun.dll. The
method is called encodescriptfile. Look it up in the object browser for
more info.

Have fun. Look forward to hearing your comments.


Regards

Andrew Clinick
Microsoft Script Progam Manager
http://msdn.microsoft.com/scripting


John T. Spivey

unread,
Dec 2, 1998, 3:00:00 AM12/2/98
to
Are there any plans in the works to add Digital Certification to this encoding to allow signed & authorized scripts greater leeway in using unsafe ActiveX controls such as the Scripting.FileSystemObject and the WSH objects as well as publisher verification?  Or are Security Zones or HTA's going to be the preffered method of bypassing security restrictions?
 
------------------------
John T. Spivey

Andrew Clinick(MS)

unread,
Dec 2, 1998, 3:00:00 AM12/2/98
to
zones and HTA's are the preferred way to do this. Script Encoding just
allows you to encode your script so that people can't see it

--

Regards

Andrew Clinick
Microsoft Script Progam Manager
http://msdn.microsoft.com/scripting

John T. Spivey <jsp...@purdue.edu> wrote in message
news:u6j04KmH#GA...@uppssnewspub04.moswest.msn.net...

Aaron Bertrand [MVP]

unread,
Dec 2, 1998, 3:00:00 AM12/2/98
to
Here is the link Andrew provided:

http://msdn.microsoft.com/scripting/

And here is an excerpt from the first entry on the page:

<SNIP>
Headlines
Microsoft Script Encoder Beta 1
Version 5 of Visual Basic Scripting Edition and JScript include the ability
to encode your script, making it difficult for people to view your script
code. The Microsoft Script Encoder is a command line tool that will encode
your script in HTML, ASP, Scriptlets and Windows Script Host files. Download
the x86 or alpha versions of the Microsoft Script Encoder beta to encode
your script.


</SNIP>

The link is kind of hidden but it's in the last sentence.

______
ab/mvp

www.desktop.on.ca
www.swynk.com/friends/bertrand/


Serdar Kilic <ski...@hotmail.com> wrote in message
OmLvZOnH#GA....@uppssnewspub04.moswest.msn.net...
>ppl,
> I couldn't find screnc.exe on the site, where is it exactly ?
>
>regards
>s.k.
>
>
>

Aaron Bertrand [MVP]

unread,
Dec 2, 1998, 3:00:00 AM12/2/98
to
Okay I've already been playing, where do we file bug reports? :)
Or should I post my experiences (so far) here?

______
ab/mvp

www.desktop.on.ca
www.swynk.com/friends/bertrand/

Andrew Clinick(MS)

Serdar Kilic

unread,
Dec 3, 1998, 3:00:00 AM12/3/98
to

Ian Morrish

unread,
Dec 3, 1998, 3:00:00 AM12/3/98
to
There is a link to the exe on the WSH FAQ site...
And here it is also
http://msdn.microsoft.com/scripting/encoder/x86/se10en.exe
Regards,
Ian
WSH FAQ http://wsh.glazier.co.nz/frame.htm

Serdar Kilic wrote in message ...

Jeff Kowalczyk

unread,
Dec 3, 1998, 3:00:00 AM12/3/98
to
What are the performance issues of running encoded script in the various
engines? (ASP, Scriptlet, WSH, etc.

Once the scripting engine has compiled it the first time, there's no further
decoding overhead, right?

Terry Greenlaw

unread,
Dec 4, 1998, 3:00:00 AM12/4/98
to
Why don't Outlook98 ( or even Outlook 2000 ) let you set security on the
Local Intranet Zone? I would like to send e-mail on our intranet formatted
as HTML with script, but cannot set the proper security level in Outlook98
to allow it. The only choice I get for security zones are Internet and
Restricted Sites.

TIA,

Terry Greenlaw
Worldwide Clinical Trials
tgre...@usa.wctrials.com


Andrew Clinick(MS) wrote in message
<#qfoyTmH#GA....@uppssnewspub05.moswest.msn.net>...

>Have fun. Look forward to hearing your comments.
>
>

Andrew Clinick(MS)

unread,
Dec 4, 1998, 3:00:00 AM12/4/98
to
I would post them to the newsgroup at the moment. ANy major bugs found so
far?

--

Regards

Andrew Clinick
Microsoft Script Progam Manager
http://msdn.microsoft.com/scripting

Aaron Bertrand [MVP] <aaronATdesktopDOTonDOTca> wrote in message
news:OfxelhnH#GA....@uppssnewspub05.moswest.msn.net...


> Okay I've already been playing, where do we file bug reports? :)
> Or should I post my experiences (so far) here?
>
> ______
> ab/mvp
>
> www.desktop.on.ca
> www.swynk.com/friends/bertrand/
>
>
>
> Andrew Clinick(MS)

Aaron Bertrand [MVP]

unread,
Dec 4, 1998, 3:00:00 AM12/4/98
to
>I would post them to the newsgroup at the moment. ANy major bugs found so
>far?

Well, nothing I've tried works, even the example in the help file.
The encoder seems to encrypt the script like it's supposed to, but even
following instructions to the letter, nothing worked.

I tried this simple example:

<script language="jscript">
<!--//
// Code by whoever
//**Start Encode**
alert("Hello");
//-->
</script>

Saved it as c:\1.htm

Then ran this:

screnc c:\1.htm c:\2.htm

And it did create 2.htm, which looked like this:

<script language="JScript.Encode">
<!--//
// Code by whoever
//**Start Encode**#@~^IAAAAA==@#@&ls DD`J_+^sWr#I@#@&z&R a@#@&^#~@</script>

However this page does not produce the alert box like the original file did.
I tried the same procedure with the exact instrunctions from the help file,
no go.
In fact I have yet to hear of anyone able to make this encoder work with any
script.
Is there some trick I'm not aware of?

______
ab/mvp

www.desktop.on.ca
www.swynk.com/friends/bertrand/


John T. Spivey

unread,
Dec 5, 1998, 3:00:00 AM12/5/98
to
It has worked fine for me in IE5 and in PWS.
 
As for WSH, I don't know how to make it handle files with extension .jse or .vbe
    ( Ian: If you didn't change the extension, it's using the normal VBScript engine, which only sees a really wierd comment )
 
You might want to add .hta to the list of valid HTML extensions.
------------------------
John T. Spivey
I have the same problem with WSH files.
Even this...
'Small test
'**Start Encode**
Wscript.echo "testing"
 
Which is converted to...
'Small test
'**Start Encode**#@~^GgAAAA==@#@& d1DbwYc+14W,JO+kYrUTJ^#~@
 
doesn't do anything.
I have the VBScript 5 beta 2 installed.
 
Maybe I need Beta 3 of the scripting engine or WSH v2 :-)

Tim Hill/MVP

unread,
Dec 5, 1998, 3:00:00 AM12/5/98
to
It looks like the registry entires for .VBE and .JBE files are not being set
by the SCRENC beta installer. You can do this manually. I did the following
on my box to get VBE files to work...

1. At a command prompt, enter "ASSOC .VBE=VBEFile". This is an NT command.
If you are using Win9x, you will have to add the association via REGEDIT.
2. At a command prompt, enter "FTYPE
VBEFile=%SystemRoot%\System32\CScript.exe "%1" %*". This is also an NT
command.
(Note: You can use the .VBS and VBSFile keys in the registry as a guide to
editing these entries manually).
3. Use REGEDIT and edit the HKEY_CLASSES_ROOT\VBEFile key as follows:
3a. Edit the default value for the VBEFile key to "Encoded VBScript Script
File" (this is the text shown in Explorer).
3b. Create a new key under the VBEFile key called "DefaultIcon" and set its
default value to "%SystemRoot%\System32\WScript.exe,2" (this is the icon
used by Explorer)
3c. Create a new key under the VBEFile key called "ScriptEngine" and set its
default value to "VBScript.Encode" (this tells WSH which key to use to
launch the script object)

After doing this I can run encoded VBE files just fine. You might also want
to copy the various extra keys under the Shell key from the VBSFile entry,
but they are not needed.

Note that the setup above associates VBE files with the CSCRIPT host. Change
the setup to WSCRIPT if you want. At present, WSH is not aware of the VBE
file type, so using the CSCRIPT switches to change hosts will only work for
VBS not VBE files.

--
Tim Hill -- Windows NT MVP

(Pursuant to US Code, Title 47, Chapter 5, Subchapter II, 227, any and all
nonsolicited commercial E-mail sent to this address is subject to a download
and archival fee in the amount of $1000 US. E-mailing denotes acceptance of
these terms.)

Ian Morrish wrote in message ...

Andrew Clinick

unread,
Dec 6, 1998, 3:00:00 AM12/6/98
to
There shouldn't be any major performance problems since the encoding
mechanism is reasonably simple. You are correct once it's compiled there is
no need to decode

--

Andrew Clinick
Microsoft Script Program Manager
http://msdn.microsoft.com/scripting
Jeff Kowalczyk wrote in message ...

Andrew Clinick

unread,
Dec 7, 1998, 3:00:00 AM12/7/98
to
Thanks for setting this up for users.  WSH 2.0 sets the support for .vbe and .jse.  I will update the script encoder setup to mkae sure this doesn't happen in the next beta.

--

Andrew Clinick
Microsoft Script Program Manager
http://msdn.microsoft.com/scripting
Ian Morrish wrote in message ...
For Windows 98 just run this reg file.
Thanks for your tips Tim.
 
 

Arthur White

unread,
Dec 8, 1998, 3:00:00 AM12/8/98
to
I experienced the same thing with a WSH also, I have IE 4.01 and have
installed the 5.0b2 Scripting engines.
-Arthur.

Ian Morrish wrote:

> I have the same problem with WSH files.Even this...'Small test


> '**Start Encode**
> Wscript.echo "testing" Which is converted to...'Small test
> '**Start Encode**#@~^GgAAAA==@#@& d1DbwYc+14W,JO+kYrUTJ^#~@ doesn't do

> anything.I have the VBScript 5 beta 2 installed. Maybe I need Beta 3


> of the scripting engine or WSH v2 :-)

--
*************************************************
* You can send me email at: *
* adw...@bpa.gov *
*************************************************

dan hollacher

unread,
Dec 8, 1998, 3:00:00 AM12/8/98
to
So, this means it only works w/ IE 5.0 beta, right?

Or, is that I'm using it on .htm files (like the 'Script Encoder Syntax'
example)

d.

Arthur White wrote in message <366DA35A...@bpa.gov>...

Arthur White

unread,
Dec 9, 1998, 3:00:00 AM12/9/98
to
dan hollacher wrote:

> So, this means it only works w/ IE 5.0 beta, right?

No, once I added the registry extensions that were mentioned in this thread
then it worked. with the new .vbe extension. I had not read all the
messages before I posted.
-Arthur.

Joel Mueller

unread,
Dec 10, 1998, 3:00:00 AM12/10/98
to
I've got a bug for you: I encoded one of the new Server-Side Scriptlets
introduced with IE 5, but it encrypted the CDATA tag inside the SCRIPT tag,
resulting in invalid XML; the scriptlet, of course, won't run in that state.

I'd be happy to provide more detail if that's not enough.

- Joel Mueller


Andrew Clinick(MS) <and...@microsoft.com> wrote in message

news:#EBaHt8H#GA....@uppssnewspub04.moswest.msn.net...


>I would post them to the newsgroup at the moment. ANy major bugs found so
>far?
>

Andrew Clinick

unread,
Dec 12, 1998, 3:00:00 AM12/12/98
to
Thanks. That's a good bug. I've entered it into our database and it should
be fixed later this week.

--

Andrew Clinick
Microsoft Script Program Manager
http://msdn.microsoft.com/scripting

Joel Mueller wrote in message ...

Anthony Payne

unread,
Dec 15, 1998, 3:00:00 AM12/15/98
to
I've had no problems with the script encoder running in IE 4.01 with JScript
5Beta.

I'm curious wether there will be any capability to encrypt scripts in the
future, using a supplied key. It would be nice for us engineers who might
have to debug scripts out in the field to be able to decrypt (or unencode)
scripts. Of course, if everyone uses the same encoding scheme, anyone could
decode my script.

--Tony Payne
apa...@infonorth.com


Andrew Clinick(MS) wrote in message ...


>The Microsoft Script Encoder has just been posted to the scripting site.
It
>allows you to use the script encoding feature in the V5 engines. Just run
>screnc.exe, pass in an HTML, ASP, JS, VBS or SCT file and provide a new
name
>for the encoded version e.g.:
>
>screnc default.htm defaultenc.htm
>
>You can also call a method on the encoder object within scrrun.dll. The
>method is called encodescriptfile. Look it up in the object browser for
>more info.
>

>Have fun. Look forward to hearing your comments.
>
>

Tim Hill/MVP

unread,
Dec 16, 1998, 3:00:00 AM12/16/98
to
I'm sure it's pretty easy right now. Think about it -- what information do
you supply with the encoded script right now? Nothing. So how does VBScript
(say) decode this? The encoding at present is a very mild form of
protection, and if VBScript can decode it, then so can a 3rd party tool, and
easily too. MS is making no claims that script encoding is in any way
secure.

--
Tim Hill -- Windows NT MVP

(Pursuant to US Code, Title 47, Chapter 5, Subchapter II, 227, any and all
nonsolicited commercial E-mail sent to this address is subject to a download
and archival fee in the amount of $1000 US. E-mailing denotes acceptance of
these terms.)

Anthony Payne wrote in message ...

Eric Lippert (Microsoft Scripting Dev)

unread,
Dec 16, 1998, 3:00:00 AM12/16/98
to
Tim is correct -- any hacker with a reasonable knowledge of encryption
algorithms or even a good ability to debug machine language will be able to
break our simple encoding scheme. The point of script encoding is not to
provide high security. The point is that it allows the following three
benefits:

1) 99.9% of the people who run the script will be unable to read it.
2) 99.9% of the people who want to modify the script will be unable to
modify it
3) You have legal recourse if someone violates your intellectual property
rights.

It's like locking your car -- a thief who really wants to steal your car is
going to steal your car. But locking it means that 99.9% of people will be
unable to get into your car, and you can easily prosecute anyone who does
manage to subvert your security.

Suppose, for instance, that you write business logic solutions in script for
a living, and you sell a script to XYZ corporation. You want to ensure that
an employee of XYZ corporation does not show your script source code to your
competitors. You want to ensure that XYZ corporation doesn't change your
work, break it, and then sue you when it fails. And you want to ensure that
if XYZ corporation does decode the obfuscated code, that you can go to court
and say that they had to employ a decryption specialist in order to subvert
your rights.

So to answer your question, no, we have no plans to add a key encryption
system in the future. Secure crypto involves a huge number of technical and
legal complications, particularly when you think about the fact that encoded
scripts have to run on win16 machines. We believe that the current solution
addresses the needs of many script authors, and unless we hear from a lot of
people demanding strong crypto, we're going to stick with the simple system.

Eric


Tim Hill/MVP <tim...@pacbell.net> wrote in message
news:uCl$O9RK#GA....@uppssnewspub04.moswest.msn.net...

Anthony Payne

unread,
Dec 16, 1998, 3:00:00 AM12/16/98
to
But what about the use of encrypted scripts on a closed system? In our
case, we control the environment, hardware, etc. Encryption would solve
three problems:

1) The script could only be run on the system for which it was intended.
Currently, anyone could steal the encoded script and it would still run
fine, on any machine.

2) Noone would be able to decode it without the key.

3) It's a two way street: we can decode our own files.

Granted, it's worthless for internet applications, but would be very useful
for WSH scripts, kiosk applications, etc.

--Tony Payne
Software Engineer
North Communications, Inc.
apa...@infonorth.com

Eric Lippert (Microsoft Scripting Dev) wrote in message ...

Eric Lippert (Microsoft Scripting Dev)

unread,
Dec 16, 1998, 3:00:00 AM12/16/98
to
I'm not sure that key-based encryption would solve these problems. The
thing is, the script engine needs to decrypt the file so that it can compile
it. There has to be a program that decrypts the encrypted file. Right now,
that program is built right into the script engine and users do not have
access to it. I'm not sure how you would provide the key for the script
engine to decrypt the file without providing the key for the user as well.
Essentially, all it does is add another layer of complication. Before, to
allow a script to run on machine A but not machine B, you had to prevent the
source from getting to machine B from machine A. Now you have to prevent
either the source or the key from getting there -- it is unclear to me that
this is fundamentally any better.

If you really want to prevent a script from running on any machine but a
given machine, then I think you'll have to write code that uses some hard
property of an individual machine -- say, the serial number on the ethernet
card.

The real fundamental problem is that script is source code. At some point,
it has to be decoded back into plaintext source code. It's not like
traditional executables, which are difficult to reverse-compile back into
the source code.

Perhaps I'm not understanding exactly what problem you're trying to solve
here. Do you want to prevent your script from running on an unauthorized
machine? Or running by an unauthorized user? Or are you concerned about
people stealing your source code, or what?

Eric

Anthony Payne <apa...@infonorth.com> wrote in message
news:eJMoKyUK#GA....@uppssnewspub05.moswest.msn.net...

Anthony Payne

unread,
Dec 16, 1998, 3:00:00 AM12/16/98
to
What if the key was passed to the WebBrowserCtrl by an external application?

To answer your last question, I'm concerned about all of those issues. We
make kiosk applications, some of which are "products." The product consists
of HTML and javascript. I don't want competitors getting the source code
and I don't want possible clients getting a working copy of the application
without purchasing it.

--Tony

L. Edmondson

unread,
Dec 23, 1998, 3:00:00 AM12/23/98
to
Ok,
I can't get this damn thing to work.
I've downloaded both the encoder and the new vb5 scripting runtime.
When I encode a file I get the same identical file as the output ?
What am I doing wrong.

Thanks

Tim Hill/MVP

unread,
Dec 23, 1998, 3:00:00 AM12/23/98
to
Can you post a sample file here? Did you include the necessary meta-comment?

--
Tim Hill -- Windows NT MVP

(Pursuant to US Code, Title 47, Chapter 5, Subchapter II, 227, any and all
nonsolicited commercial E-mail sent to this address is subject to a download
and archival fee in the amount of $1000 US. E-mailing denotes acceptance of
these terms.)

L. Edmondson wrote in message <36812157...@westcon.com>...

0 new messages