ISESteroids 220.127.116.11 now ships with a PowerShell obfuscator that can scramble your code and make it hard to reverse-engineer. Full list of changes can be found here. Let’s have a look at the new obfuscator:
Wait! Should PowerShell Code Be Scrambled?
No. PowerShell code should be open and freely readable. There are many good reasons why PowerShell code should not be obfuscated:
- Plain text PowerShell code can be evaluated and read by anyone, so it is easy to identify harmful code, to debug and expand.
- PowerShell and the PowerShell community are a sharing and caring world. When someone learns from your code, so do you when you read code that others have shared.
- By letting others understand your code, you often get back good feedback what you could improve.
- When you obfuscate your script, you are taking a risk: if you misplace your original unobfuscated script, you lock yourself out. Antivirus software may freak out when it chokes on obfuscated scripts. And obfuscation comes always with a minimal risk of breaking your code.
However, with PowerShell being almost omnipresent in so many areas these days, there is a need for additional protection in certain highly specific scenarios.
- “We don’t want our customers to fiddle with our scripts, causing problems that we then have to solve.” – Much like with a centralized managed IT that uses DSC and does not want local Admins to interfere, it appears legitimate for service providers to ask for additional support to protect their solutions.
- “We invested a lot of time and effort to create a highly customer-specific solution.” – Likewise, when you create highly specific commercial solutions, often the time to architect and investigate is what burns the budget. The resulting solutions are often rather simple. So if you are creating individual solutions for a highly specific scenario, you may want to protect your IP.
Obfuscation is just another choice. Use it wisely. Never use it on scripts that you intend to publicly share or publish. There is no point in sharing obfuscated scripts.
Obfuscating a script
To obfuscate a script, simply load a script and choose Tools/Obfuscate. This opens a dialog where you can set the level of obfuscation. Note that automatic Pester test updates are not yet implemented but are coming soon.
Once you click OK, the obfuscator changes the script code and opens a new script tab with the obfuscated version of your script.
It still works in the same way, but the code has been scrambled to make it hard to read and change.
The obfuscator always obfuscates your entire script. However, functions with the prefix “global:” or “script:” will stay unobfuscated.
Note also that variables are obfuscated on a global scale to minimize the risk of breaking anything. So if you have a global or scriptglobal function in your script, the parameters of such functions will not be obfuscated, either. Any other variable of same name in your script will stay unobfuscated as well.
Important: Obfuscation is a work in progress. Always keep a copy of your original script, and test the obfuscated code thoroughly.
Neither creating EXEs from scripts nor obfuscating script code are designed to protect sensitive data, such as passwords. It is technically impossible to protect sensitive data when the secret and the key to this secret reside in the same file. The whole point of both techniques are to (a) make it easier to launch a script (EXE) and (b) make it harder to copy and change the code.
If you need to protect sensitive data, use asymmetric encryption, JEA (Just Enough Admin), or any other technique that separates the secret from the key protecting the secret.