snOrg,
As you mention in your original post, scripts encoded with MS's Scripting Encoder can be easily un-encoded. I also wrote earlier that ExeScript v2 (current version) does not keep compiled scripts secure.
As you mention 'client' then it appears to be a business agreement to which you may have to apply a risk assessment to, e.g.:
1) Would it be POSSIBLE for your client to 'mess about and break' un-protected script(s). The answer is YES, even using 'Scripting Encoder' or 'ExeScript' and the element of risk is HIGH.
2) Is it LIKELY that your client will attempt to change un-protected script(s). Only you can answer this, possibly based on prior experience of the client. If the answer is YES then the element of risk is HIGH.
3) Is it LIKELY that your clients will attempt to circumvent protected script(s). Again, only you can answer this... obviously there is a difference between casual/un-informed and determined/knowledgeable attempts to break protection.
If the answer is YES then the element of risk is HIGH and you may need to consider another coding method.
If the answer is NO then the risk is LOW and the freeware Scripting Encoder may be all you need and, in my opinion, preferable to the shareware ExeScript until ExeScript v3 is out, tried and tested.
4) What are the CONSEQUENCES of the script(s) being changed? If the consequences are of MINOR importance then the risk is LOW.
One method to reduce risk is to show the un-protected script(s) to the client, let them verify against a printout, seal the printout for them to keep and agree that any changes to the script(s) without joint agreement in writing will render your own liability null and void.
On the other hand, if the consequences are of MAJOR importance then you need to think of different ways to protect both you and your client and to consider professional/legal business advice.
If it's any help... I apply the same risk analysis within my own Win XP-based work environment. I use dozens of scripts that use 'RunAs' to temporarily elevate privileges locally and which contain the Administrator password. I also make registry changes to HKCU (which all users can do themselves) and to HKLM (which only an account with administrative privileges can do).
I ask myself the same questions:
1) Would it be POSSIBLE for my clients to 'mess about and break' un-protected scripts or .REG files.
YES - The risk is HIGH.
2) Is it LIKELY that my clients will attempt to change un-protected scripts.
NO - the risk is LOW. I've never known this happen but, at the same time, I don't want the Administrator password to become known nor do I want anyone seeing what registry keys I'm manipulating.
3) Is it LIKELY that my clients will attempt to circumvent protected scripts and/or REG files.
Both YES and NO - the risk is MEDIUM. Whilst it is likely that a very small proportion of my clients may have the knowledge to un-encode encoded scripts and may wish to undo some registry changes that prevent them doing something, it is unlikely to actually happen because a) such changes would eventually become obvious and b) any such changes would breach the Code Of Conduct in the workplace and leave the client vulnerable to disciplinary action.
4) What are the CONSEQUENCES of the scripts/REG files being changed?
MINOR... probably the worst that could happen is that I may need to script a change to the Administrator password and/or some PC's may need to be re-imaged to bring them back into a 'corporate look-and-feel', i.e. time consuming but not catastrophic. The risk is MEDIUM.
I arrived at a determination that the overall risk factor was MEDIUM. However, a cost analysis showed the COSTS of implementing alternative methods to reduce the risk to LOW or non-existent were HIGH. This was considered by management to be too expensive.
As a result, I obfuscate the code to make scripts difficult to read using subs and functions (and keep well-documented originals so I don't forget what I'm doing).
I also use Microsoft's Windows Scripting Encoder for most scripts and Greg Palmer's excellent 'RunAsUser' utility (see
to compile some scripts into executables that run with elevated privileges.
If a REG file is doing something that I don't want users to learn about then I use the freeware NSIS (Nullsoft Scriptable Install System - see
to compile the REG file into an executable.
Hope this helps...
