Home Blog Converting Scripts to EXEs
 

Converting Scripts to EXEs

ISESteroids 2.0 Enterprise offers the capability to turn a PowerShell script into an application (EXE file).

Let’s check out what exactly happens here, why it could be benefitial, and what the drawbacks are.

Addition: There may have been a false impression that wrapping PowerShell scripts into EXE applications would/could be a safe way of hiding PowerShell code. I decided to highlight some parts of this blog in red. I did not change anything, it has always been in the blog article. 

How does it work?

A PowerShell script will always stay a PowerShell script. It will always require PowerShell to be present on the system. When you convert a script to an Application, you basically generate a wrapper application that contains your script, and unpacks and launches it when needed.

Reasons to wrap a PowerShell script inside an applications include:

  • Ease of use: When you hand over scripts to audiences that are not familiar with PowerShell, this approach makes it easier for them to launch a script.
  • Source Code Protection: Your PowerShell source code is somewhat protected. People cannot easily peek at your code, and change it. The level of protection depends on how you create the application. We’ll cover this in a bit.

Turning a Script into an Application

To turn your current script into a stand-alone application, in ISESteroids choose Tools/Create Application. This pops up a wizard.

Simply click “Create” to create the EXE. For more options, click the arrow in “Advanced Options”.

Advanced Options include the ability to assign a custom icon to your application, require Administrator privileges, and more.

Trusting Your Application

When you ship your script as application, your target audience can no longer openly review the source code. You are basically delivering a “black box”, which might exactly be what you intended.

Your target audience may be worried about this.  At minimum, they will run your application through an Antivirus engine.

AV engines end up having the very same problem: depending on their quality, they may not be able to look at the actual script content, either. When that occurs, the AV engine may at least detect that it is looking at some kind of wrapper application. Since the AV engine can’t tell whether the PowerShell code inside of it is benign or not, it may simply freak out and flag the application as “Virus”, just to be on the safe side. It is a false alarm.

To be clear: ISESteroids does not put any malicious code into the generated application. False virus alarms are an inherent limitation of some AV engines.

Increasing Source Code Protection

Wrapper applications are never a safe way of protecting your script content. This is by nature, because the person that launches the application must have full read access to the application.

With full read access, it is always technically possible to reverse-engineer the wrapping, and get to the original PowerShell code. This is why you should never place sensitive information into PowerShell scripts, regardless of how you ship them, and what tool you used to “wrap” it.

If you want to increase the level of source code protection, there are several ways:

  • Loading from Memory: when you have a relatively short script, you can use the Advanced Options, and choose “Load Script From Memory”. Now, the wrapper application will not unpack the script and run it as a file, but rather feed it directly into PowerShell.
  • Obfuscating Application: The generated application is a standard .NET application. You can use any commercial or free obfuscator software to “scramble” the .NET code inside of it. So even if someone uses reverse engineering tools to examine your wrapper application, it will now be much harder to get to the information (and PowerShell code).

That said, please understand that there is no perfect protection. This is a technical limitation that applies to all products that wrap PowerShell code inside an application. You can  only increase the effort that it takes to get to your code. You cannot prevent this access, though.

Even if an application came up with an extremely hard-to-reverse-engineer technique, an attacker could target the PowerShell process that is actually executing your code, and dump your code from there.

So use this technique wisely. Use it to make launching PowerShell easier, and to keep mere mortals from looking at your code. Do not use it to protect vital secrets such as passwords inside your scripts.