We frequently get questions asking, “Where can I get a PowerShell script encoder so I can write secure scripts like the Visual Basic Script Encoder?”
The answer is that it is impossible to hide the password from the user if the script ever needs it. This is true of PowerShell, VBScript, C#, C++, Assembly, or any other language. There will always be some point when your script has reversed all of the encryption / protection mechanisms, giving the “attacker” complete access to it. If you don’t want the password itself hanging around in a script file, you can prompt the user for it. If the user is never supposed to know it, then you need to re-think your architecture.
Microsoft hasn’t been clear enough documenting what protections the Script Encoder offers, but here is an excerpt from the Scripting Guys:
Now, the important thing to keep in mind is that the script is simply encoded (or obfuscated); it is definitely not encrypted. What does that mean? That means the encoder will hide your script from most people; however, a truly determined hacker - armed with a knowledge of codes or armed with a utility downloaded from the Internet - could crack the code. Among other things, that means that you should never do something like “hide” an Administrator password in a script and assume that the Script Encoder will keep it safe from prying eyes. It won’t. It’s an encoder, not an encrypter, and there’s definitely a difference.
I’m not sure why the main download page is fond of the term “determined hacker” – a 30 second search for “vbe decryption” returns pages of results.
Now, a valid response to the whole situation is that you really only want to deter casual investigation, or that reversing the protection can then be linked to a breach of contract or software license. If you are in either of those boats, you don’t need an official tool to do this for you. Hiding your script behind Base64 encoding or ROT-13 should offer plenty of protection, and takes only a few lines of scripting. If you have the skill to make that decision, you have the skill to implement it as well.
Subscribe to this blog.
Just throwing this out there:
http://www.powerlocker.com
PowerLocker does this right, as you need to know the password before it will decrypt the script. The script isn't intended to be protected from the people running it, it's intended to be protected from others.
#1 http://www.powerlocker.com is no longer registered/available from the looks of it.
#2 As I describe in my Powershell Tangent, I provided a method to encrypt a string. By modifying the method, you can very easily encrypt the entire script.
#3 While I agree with the article’s statement of "if there is a will there is a way", from a security perspective, you can make the encryption prohibitively difficult to crack and it wouldn't make sense for a hacker to attempt the decryption of the data. It would be easier for a hacker to obtain the data through other methods-- The NSA Guidelines for hardening servers, states that a 15 character random password would take a little over 4 years to decipher with a large amount of computing power -- even in a distributed environment. This is on top of assuming the systems were circumvented to obtain the PowerShell scripts, AND that the PowerShell script they obtained actually had data that could be used by the hacker from a remote system. Calling into a system without the proper AD permissions make the script useless -- food for thought.
#4 How can is this be effective if they have access to the decryption function? Answer:-- a passphrase.
If you remove the loop and add the following to my script:
$passphrase = Read-host "Please Enter The System Password"
decrypt-string filename.encrypt $passphrase
The system will prompt for a system password and use that to decrypt the contents of filename.encrypt (the encrypted file). If you don't have the correct passphrase, you don't get the correct content.
A few modifications to my function would be required to get the content of the ".encrypt" file and output the file for use in memory. Nothing too trivial.
Notes:
Use something like $filestream = get-content c:\filename.encrypt for the decryption algorithm
Use something like new-item -path c:\filename.encrypt -type file -content $encryptionstring for the encryption algorithm (to place the encryption contents into a new file.
While the syntax above might be a little off, I hope this helps. Feel free to contact me for more details.
I will be creating a new blog article with the actual code to do this shortly, however, this might get you started.
http://bittangents.com/2010/03/20/powershell-script-encrypting-decrypting-a-string-function-encrypt-string/
Brenton: Encrypting a script is of course possible, and completely secure if you need to know the password to decrypt and run it. That's what PowerLocker does.
What's not secure is a PowerShell script that somehow decrypts itself and then runs.
Lee -
I agree - if a script decrypts itself, without any other interaction from a user, the script is not secure. That's much like leaving the key to your house under your doormat.
The reason why I provided a link on here is that Powerlocker doesn't appear to be available anymore. It takes you to a search site with popups. For those looking for a solution -- they have one now.
-Brent