XP Pro/IE7 Updates break script encoder output!

I have a web site which contains pages with encoded client-side javscript code, and other pages which contain encoded server-side vbscript code. (The encoding was performed with screnc.exe, the script encoding utility.)

Since updating my desktop machine this month with the latest XP Pro updates and IE7, server-side VBScript encoded scripts won't run. (The server environment is 2K3Server Standard, with all the latest updates.) The javascript code still runs correctly on the client side (tested w/ IE6 and IE7), but server-side VBScripts result in a http 500 error.

I suspected that this was a side effect of recent updates to the desktop machine upon which I run the encoder. To test this hypothesis, I boooted in to a Win2K Pro partition on the same desktop machine and ran the script encoder there, then posted the encoded pages to the server. They ran correctly!

So. VBScript server-side code, passed through the script encoder on an up-to-date XP Pro machine with IE7, crashes when run on an up-to-date 2K3 server. The same server-side VBScript code, passed through the script encoder on an up-to-date Win2K Pro machine with IE6, runs fine on the same 2K3 server. This was not an issue before (I believe) the latest round of Windows updates, including the installation of IE7.

Comments Suggestions

So just where is that response I'm supposed to get within two business days

Hello

Hi,

You have to remove 'Start Encode' at the beginning of your scripts...not needed anymore. Everything before that is ignored or if you prefer, is converted into bad code...

Hope this helps.

The workaround works.

But is there anything official from Microsoft about this nasty bug ! I can't find any KB article to show to annoyed customer

Wow... I am NOT HAPPY about this change. It really f--ks a lot of our work. We LIKED being able to put readable comments at the top of some encoded ASP pages before the "**Start Encode**" directive.

I really can't believe MSFT did this with no warning, and apparently still no KB articles about it.

Has anybody heard any more about this issue Thank you. Much Obliged.

Not only is encoding of comments a problem, but encoding of imbedded server-side variables becomes a problem as well.  First the server-side variable, <%=strVariable=%> gets encoded by the server-side encrypting.  Then it gets re-encoded by the client-side encoding.  This leaves me with garbage for a variable unless I use '**Start Encode** to prevent the client-side encode from re-encoding the variable.

Is there a fix or a workaround yet   Or even a clue as to what dll has changed so I can reregister the old dll to run screnc.

#@~^HgAAAA==@#@&dvDtmx3,XK;Pbx~l9\CU1+@#@&2gcAAA==^#~@
(encoded: "thank you in advance")

We are investigating this issue.  In the meantime, you might consider removing your use of the script encoder, since it doesn't really perform any worthwhile function since script decoders are broadly available.

Script decoding is provided by the script dlls; can you post the version numbers of jscript.dll and vbscript.dll that you are using

The current version of VBScript.dll in my C:\WINDOWS\system32 folder is 5.7.0.5730.

Please note that the encoded script fails on all machines on which it is used, including machines that have not had their vbscript.dll or version of IE updated. It's the encoding that's gone bad. No versions of VBScript.dll seem to work if a script is encoded after IE7 is installed.

I know the script encoder is easy to break, but it's still a nice feature to have available. For example:

1. Raises barrier to entry for "tinkering" clients to mess with the app we have licensed to them.

2. Makes it easier for our clients to know which server-side scripts are _meant_ to be client-modifiable for client-directed configuration and customization purposes.

EricLaw wrote:

We are investigating this issue. In the meantime, you might consider removing your use of the script encoder, since it doesn't really perform any worthwhile function since script decoders are broadly available.

Now there's a brilliant bit of logic. 'Since a code can be cracked by some, better not to encode anything at all.'

The truth is this was an ill-considered move that broke functionality customers depended on. The best response to angry customers probably isn't to tell them they didn't need that functionality to begin with. I'd say the responses in this thread show just how out to lunch that appraisal is.

We still haven't seen a KB article outlining a usable workaround, or any meaningful response at all.

I think it might be this exact problem that has broken an important application for an important client.

The server is Wk3, the workstations are XP pro, we have about 100 people affected.

I have asked our programming team to look into this, but they are pressed for time and can't get to it for a while.

Can anyone suggest a quick fix that the IT department could do Roll back a particular update, fiddle something on the webserver Anything

Thanks.

AFAIK, there are two workarounds:

1) Don't encrypt the ASP scripts

2) Remove or intentionally garble the **Start Encode** character string in the script. The entire file will be encoded, but it will work.

Having looked around and seeing how trivial it is to decode an encoded script (there are easily downloadable tools/hacks for doing so)... well... let's just say it won't stop any curious or malintentioned person from easily viewing the original source code.

Be advised that if you have not re-encoded your scripts on a machine with IE7 installed (that is, you are still using the originally encoded scripts on your client's server, even though IE7 might be installed on client's server), then the encoder bug described in this thread is not the cause of your problem. The bug is with the encoder associated with IE7, not the decoding process. If you have IE7 on your development machines, you can take any updated/debugged source-code scripts to a machine that still has IE6 on it, encode them there, and they will work as expected, respecting the **Start Encode** directive as expected..

I doubt that I can implement either of these two fixes. I do not have access to the source code, it's in a different department.

Can anyone explain why it continues to work from some machines, but gives the error on others All the workstations appear to have similar MS updates, IE versions etc., and a few still work. It's a strange problem.

I turned off "friendly" error messages and got this:

ADODB.Command error '800a0d5d'

Application uses a value of the wrong type for the current operation.

/caswebapp/iLib.asp, line 438

This is the same problem, and I am barking up the right tree

I'm not sure if this is helpful information or not, but I installed a different browser to test (Firefox) and it worked. No errors.

Unfortunately, I don't think my client will accept that as a viable workaround for 200 workstations scattered around the continent.