Building EXE - PrimalScript vs PowershellStudio

Use this forum to ask questions after your subscription maintenance expires or before you buy. Need information on licensing or pricing? Questions about a trial version? This is the right place for you. No scripting questions, please.
Forum rules
DO NOT POST SUBSCRIPTION NUMBERS, LICENSE KEYS OR ANY OTHER LICENSING INFORMATION IN THIS FORUM.
Only the original author and our tech personnel can reply to a topic that is created in this forum. If you find a topic that relates to an issue you are having, please create a new topic and reference the other in your post.
This topic is 3 years and 2 months old and has exceeded the time allowed for comments. Please begin a new topic or use the search feature to find a similar but newer topic.
JOsapiens
Posts: 2
Last visit: Sun Jan 17, 2021 11:59 am
Has voted: 1 time

Building EXE - PrimalScript vs PowershellStudio

Post by JOsapiens »

Good Morning
I frequently use powershell in a variety of tasks involving different products, from cloud to on premise.
I'm quite fine with VScode, but I need something more powerfull, and I remeber my experience with PrimalScript 2007 was great, in good old days ;-)

Basically, I need help with two main questions, to figure out if PrimalScript or PowershellStudio da fit fo me.


First o all, is PrimalScript the same as Powershellstudio and ALSO as the power to manage other languages, or if I choose PrimelScript I will be able to manage other languages, but I'm going to loose something about powershell?

Also, I need to make executables. The option to directly compile a script is very useful.
How is the compiled exe file?

Sometimes I need a compiled exe file to hide the code or the credentials.
It's the compiled file just a wrapping or It's very easy to reverse engineer, or is a standard executable?

Other times I need an executable because the intended machine could no support powershell, or .Net (I often use Vbscript for this reason)
Is the final executable indipendent? Or it needs something to run (let's say .Net...)

Finally, Primalscript can compile into exe only frpom powershell, or also from other languages?

Thankk you for your help.

regards,
Giovanni
User avatar
Alexander Riedel
Posts: 8473
Last visit: Tue Mar 19, 2024 1:15 am
Answers: 19
Been upvoted: 37 times

Re: Building EXE - PrimalScript vs PowershellStudio

Post by Alexander Riedel »

Lots of questions here, but first, welcome back :D

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
2021-01-04_12-26-26.png (146.62 KiB) Viewed 15409 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
2021-01-04_12-44-29.png (123.33 KiB) Viewed 15409 times
But again, that is not a safe way to hide credentials in there.

Please let me know if you have any further questions.
Alexander Riedel
SAPIEN Technologies, Inc.
JOsapiens
Posts: 2
Last visit: Sun Jan 17, 2021 11:59 am
Has voted: 1 time

Re: Building EXE - PrimalScript vs PowershellStudio

Post by JOsapiens »

Hello
First of all, a really big thank you for your detailed answer

I've seen that at its basics, PrimalScript supports everything but the forms.
PowershellStudio supports forms, but doesn't support other languages.
Having everything in one product would be great :-)
I mainly use powershell, but I think I'd go PrimalScript

About the EXE
I agree nowadays most softwares need something to run.
Unfortunately, I'm still facing to windows 7 machines, or Windows 2008R2 servers, or even other versions of windows.
Most of the times simply "I don't know" how is the mixed environement of machines where the executable will be run.
For this reason I need something that runs independently.

I know I can read executables with a Hex Editor, and of course we hard code credential when we are forced to by "above forces" :-)
Moreover, is a rare case and is always a "simple secret". Never and never we'd hard code critical credentials.

As far as I understand from your article, if we look at the exe file itself, the "packaged" exe file created with PrimalScript should be even more secure of a "compiled" exe file.
While a could read the compiled exe file with a hex editor, it should be near-to-impossible to see the source code of a packaged exe, because the original script code is encrypted.

If so, I think the script code will need to be decrypted and then passed to the interpreter in clear.
This poses some security considerations, along with some side advantages, maybe.
Should I have an exe file of which I have lost the source code, I could ask for your help, maybe. ;-)

Probably, now I have a more clear understandig of what happens "behind the scenes".
Thank you for your very helpful explanation.

My best regards
This topic is 3 years and 2 months old and has exceeded the time allowed for comments. Please begin a new topic or use the search feature to find a similar but newer topic.