Compiled .EXE Content Security

Use this forum to ask about non-product related topics (login issues, product registrations, web site questions, etc.) No technical support questions, please.
Forum rules
Do not post any 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.
User avatar
gareth.jacobs
Posts: 27
Joined: Mon May 15, 2017 1:51 pm

Compiled .EXE Content Security

Post by gareth.jacobs »

As a Forensic Analyst, I am looking for the following information in relation to a PowerShell Studio compiled Windows Form application. Can someone tell me:
  • How resistant do you think the .EXE is to being decompiled and revealing objects, variables, strings, etc.? I am assuming, from what I can see, that there is some sort of encryption incorporated into the compiled program.
  • Do comments <# comment code #> become part of an .EXE or are are they discarded at compile time?
Contact me privately if you don't wish to discuss in an open forum.

Thanks
G

User avatar
Alexander Riedel
Posts: 7458
Joined: Tue May 29, 2007 4:43 pm

Re: Compiled .EXE Content Security

Post by Alexander Riedel »

The correct term is 'packaged', not compiled.
Comments are not removed and, by the nature of a scripting language, eventually the code is unencrypted and in the clear in the memory of the executing computer.
PowerShell logs, unless this is turned off, all code executed on a machine. We do have a packaging option to disable this during runtime but the user must have sufficient rights to do so of course.
The functionality of packaging was never intended to be strictly one of security. We constantly advise users to not store credentials in a packaged script and assume they would be safe.
It is a matter of convenience and, in almost all cases, prevents a user from modifying the application with just notepad. Using script packaging in combination with our MSI builder will also allow installation of these applications in protected folders (i.e. Program Files) where a non-admin user has no rights to modify anything.
Additionally, in PowerShell, dot sourced scripts can be resolved at packaging time and therefore do not require the need to publish multiple scripts.
You will not see any strings, variables etc by just looking statically at a packaged executable with a hex editor, so an average user will not be able to gleam any information that way.
But, once again, this was never intended as a super secure way of keeping the code of a script out of the hands of a dedicated hacker. In that regard I would say it is not any more or any less secure than your average compiled C# application, which can easily be decoded back into source code.
Last but not least, we can and do retrieve source code from packaged executables all the time when users lose their source code for one reason or another.
Packaged PowerShell Studio scripts even contain meta data, which usually allows to restore the original project and not just the script code itself.
I can tell you that in these cases our users very much appreciate that we do not remove any comments :D
Alexander Riedel
SAPIEN Technologies, Inc.

User avatar
gareth.jacobs
Posts: 27
Joined: Mon May 15, 2017 1:51 pm

Re: Compiled .EXE Content Security

Post by gareth.jacobs »

Understand now that it is wrapped and obfuscated rather than compiled - makes sense why it generates the .EXE so quickly.

Thanks for the info.

Cheers
G