Lots of questions here, but first, welcome back
PowerShell Studio and PrimalScript are not the same.
https://www.sapien.com/software/primalscript has a feature comparison chart. That should make some of the key difference clear. If you have additional questions on that, please feel free to post them here.
Making executables. That will require a little longer to answer. I will elaborate a little more than maybe needed for the benefit of others lurking.
First of all, it is not a compiler. A compiler is defined as a piece of software that translates source code into machine code (binary). A good example is a C/C++ compiler.
Even C# (or any other .NET language) does not use a compiler. At least not initially. C# translates source code to ILASM (Intermediate Assembly Language) which is still source code. Then when you run the exe, it gets compiled by the JIT (Just-in-time) compiler. Which is why C# applications take longer to start than C++ apps in general. This is a bit simplified but that is how it works. Which is why C# is so easily "decompiled".
Our process of making an executable is called 'Packaging'. As opposed to compiled languages, PowerShell, VBScript, JScript, Perl, Python, just to name a few are interpreted languages. The source code is never compiled into machine code, it is always interpreted and executed statement by statement by the languages interpreter (powershell.exe, CScript.exe, python.exe etc).
What the packager does, it encrypts a script and places it inside an executable file. When executed, our code in that packaged engine unpacks and decrypts the script and feeds it to the interpreter.
Where possible, that happens in memory rather than with a temporary file.
- 2021-01-04_12-26-26.png (146.62 KiB) Viewed 251 times
If you look at the Preview pane in the Script Packager, you can see the way it will execute your code and the runtime requirements.
Almost all software nowadays has runtime requirements. Including all necessary dlls and dependencies even for the simplest applications would make a ridiculously large executable.
We try to keep runtime requirements in line with the underlying engine or OS. For example Windows 10 comes with .NET 4.8 and it does have PowerShell 5.1. So it is no harm that a packaged PowerShell executable uses .NET 4.8 as well.
The process of packaging, specially in combination with Authenticode digital signatures, makes it much harder for someone to modify the code before running it.
A fudged signed executable would alert you about the now invalid signature. The same is of course true for signed scripts.
As for hiding credentials in a packaged (or compiled for that matter) executable, there is only one answer: DON'T!
Eight years ago I wrote this blog article:
https://www.sapien.com/blog/2012/04/30/ ... -packages/
The blog post shows how easy it is to extract credentials from a compiled executable. In a packaged script it is not quite so visible if you look at the exe file as a binary.
However, PowerShell has now what called Script Block Logging. Which will basically log the all powershell code executed on a machine. Including any credentials you have hidden in there.
You could turn that off in general, but I would strongly advise against that. See
https://www.fireeye.com/blog/threat-res ... lityt.html
You can disable that whole logging business for YOUR packaged script with options we provide, assuming your executable will run in full admin mode (elevated).
- 2021-01-04_12-44-29.png (123.33 KiB) Viewed 251 times
But again, that is not a safe way to hide credentials in there.
Please let me know if you have any further questions.
