I have written a PowerShell script in many hours and days and would like to obfuscate it, but so that the code is no longer readable or decompilable, but the script can still be executed. Is there something like that?
With regards to actually obfuscating an entire powershell script, this site seems to do just that.
I tested a script a little over a year ago and here are some of my findings:
Windows10: The obfuscated script worked on Windows 10. I dont
remember the Powershell version I had back then.
macOS: Confirmed it also works on Macs (if you have powershell installed), but I remember there were some errors spat out.
I just tested another script a few minutes ago on a Windows Server 2016 (PSVersion:5.1./Desktop) system. No issues so far.
Now, as was already mentioned by previous posters, it is important to note that any obfuscation can be hacked into. It's just a matter of incentive for the hacker.
I say "any" specifically because you dont control the hosts on which your powershell script will be used. And as such, those who do, if inclined, can alter the binary of the powershell program to get it to spit out everything that it does. How easy that is, I do not know. But a quick google search suggests there are settings available that, if turned on, can log the entire execution of your powershell script, obfuscated or not.
A couple of links that touches on Powershell logging:
PowerShell Logging: Recording and Auditing all Things
About Logging Windows - PowerShell - Microsoft Docs
There is a thing named Powershell Constrained language.
Quoting from here: https://devblogs.microsoft.com/powershell/powershell-constrained-language-mode/
Constrained language mode is a language mode of PowerShell designed to support day-to-day administrative tasks, yet restrict access to sensitive language elements that can be used to invoke arbitrary Windows APIs.
In Constrained mode, these are not supported:
COM objects
Unapproved .NET types
XAML based workflows
PowerShell classes
It's best for running administrative tasks, still it's not better for daily uses. To start it use:
$ExecutionContext.SessionState.LanguageMode = 'ConstrainedLanguage'
Read more here: https://devblogs.microsoft.com/powershell/powershell-constrained-language-mode/
The Invoke-Obsufcation wrote by Daniel Bohmann is much better for this purpose. Link: https://github.com/danielbohannon/Invoke-Obfuscation
Usage Guide: https://blog.vonhewitt.com/2017/08/obfuscating-powershell-commands-using/
If you want something to obfuscate your powershell code to make it unreadable but keep it working you should check a project called Invoke-Obfuscationation done by Daniel Bohannan. You should check his talk about powershell obfuscation where he presented the tool.
Related
It seems like it is not all that easy to create an executable from a PowerShell script - do you know if it was ever meant to be an option?
I have found tools like PS2EXE, but still it does not seem like it was meant to be.
I am asking, if it is worth it to go the extra mile or leave it.
Background reason: I have some less technical users that need a smoother workflow.
As #Bill_Stewart kindly noted:
PowerShell is a shell that contains a powerful scripting language.
Which is perfectly in line with Microsoft's definition :
PowerShell is a task-based command-line shell and scripting language built on .NET.
Basically, wrapping it in an executable would go beyond its purpose. The nice thing about scripting is, that it's lightweight and task based. And in this case, that you can easily run it on multiple OS-ses.
So, I wouldn't go through the effort creating an exe.
If you want to run it easily, just create a .bat or .cmd file (if using Windows). On windows, I believe, you can also create a shortcut with command arguments and a little icon.
For Linux you clould use a .sh.
I've written a simple script that has multiple custom functions stored as modules. I have done it this way because I was always been told that if your function can be reused by other things then it should be a module and not a .\ source include. I'm starting to think that mantra isn't right in my current scenario. I am trying to convert the script to an single .exe so that I can install it as a windows service.
Probably should acknowledge that I understand why you wouldn't want to include system modules like Active Directory or IIS management for the obvious issue that could lead to but I'm only trying to include custom functions in a single disputable non editable way.
I have used PowerGUI in the past but can't find any valid exe's for that since DELL have removed it and from memory, I don't think I've ever used it with a module.
I've tried PS2EXE-GUI and PS2EXE. Both of these make the exe and everything works fine while the modules exist. However, as soon as I put the exe on a server that hasn't got the Modules deployed to it, it fails to run. I thought the compile followed all the dependencies and included them as part of the build into the single exe? That appears to not be the case.
I've also tried the PowerShell Studio 2018 by Sapien, but based on their forums you can't include modules into the complied exe. Which again feels wrong if they are actually just custom functions, but it's the way they've written it.
I see https://poshtools.com/docs/posh-pro-tools/merge-script/ would possibly do what I need but that's chargeable and it looks like it actually merges all the content back into a single file. Given the time pressure I'm starting to think I'll have to pay if there are really no other better options. I just don't have time to join everything together manually and I can't help thinking there is a better way I'm missing!
Can anybody please suggest other options?
Could I also get clarification around my original mantra (functions go in modules...)?
"No, never!" or "Yes, always!" or "It's just wrong in this scenario."
I was needing to create a PowerShell script relating to IIS processes and I am new to PowerShell. I have looked at a lot of examples online and kind of get the gist of it, but I just wanted to know, how are we supposed to know all the syntax of the fields in IIS?
Such as for example I see $ApplicationPoolStatus, $ApplicationPoolName, $StartedPools, $StoppedPools, etc a lot in the scripts.
Are we just supposed to know these, or is there somewhere we can find these fields at?
Hopefully this question made sense, thanks!
I am not familiar with IIS and how it relates to Powershell. However, having a $ in front of a name usually indicates a variable. Without being able to see a script that uses the above variable names it would be hard to say exactly what they are, and what they are doing.
Here is a link to several of the IIS Powershell Cmdlets Technet ISS Powershell Cmdlets
There are a number of GUI hosts for Powershell (Powershell ISE, PoshConsole, etc) but I'm not aware of any purely console hosts other than powershell.exe. Are there any that offer any advantages over powershell.exe?
I'd like to be able to customise more of the host behaviour - specifically to add and customise key bindings other than TAB, and to customise error reporting. There could well be more...
If there aren't any "extended" versions of powershell.exe that offer this, how difficult would it be to write one? I have the SDK sample code, and it looks fairly accessible, but it's hard to be sure what features powershell.exe provides as opposed to the powershell "engine" (as there's no documentation I've found that focuses specifically on the host capabilities).
How about Console it can host multiple shells. Might be worth a look.
The best pure-console for PowerShell is obviously PowerShell Plus, which actually uses a fullblown "native" Windows console, but it wraps it up in candy coating and adds tons of IDE-style features. As far as I know this is the only third-party host that's capable of running "graphical" console apps like edit.com
As a sidenote, I'm honestly not sure it's worth the handicap of a true console just to keep compatibility with whatever graphical interactive console applications like Edit.com might still be around. Considering the limitations, and the amount of work that has to be done to pull off something like what PowerShell Plus has... Personally I can't wait for the day when I no longer have to worry about and can move on to console apps that are really MEF-style plugins in a console-style interface like PoshConsole :-)
I realise that this question is years old, but since I stumbled across it in search of answers, I thought I would add my findings.
I settled on Cmder, for the following reasons:
It wraps cmd and Powershell, so you get the same set of features you would find in either.
The default colour scheme is Monokai, which is not only pleasing to the eye, but actually readable. Maybe I was missing something, but the default output for most of my tasks (Git, Mocha tests etc.) had poor contrast most of the time and I found myself squinting at the screen.
Tab support - I've wanted this for a while, but until now I hadn't found a solution that provided tabs as well as everything else. Powershell IDE has some character encoding / text colour issues that I couldn't ignore.
It's portable - stick it on a USB stick and take it with you wherever you go.
It's configurable - the developer (Samuel Vasko) has done a great job here. It's not lacking for customisation.
Specifically answering the OP's requirements, you can remap key bindings and create macros. I don't see the ability to customise error reporting however.
Hopefully anyone else out there still searching for a decent command line emulator on Windows will see this answer and rejoice.
If you stick with a "Console" subsystem approach you will be saddled with all the limitations that come along with a Windows console subsystem application. Many complaints about PowerShell.exe limitations are really limitations of this feature of Windows (kbd shortcuts, line editing, etc).
What's wrong with PoshConsole? Even though it allows graphics to be displayed it is still a "console-style" UI on top of the PowerShell engine?
When we click the check box "Install files for complex script and right to left languages (including Thai)" in Regional and Language settings what exactly happens?
Changes to registry keys?
I noticed that it installs some .fon files and keyboard dlls.
Is this totally necessary if one just wish to read complex script on Windows XP? My test inside VirtualBox as Windows 7 as the host OS seems to indicate that for reading Complex Script need not be enabled. Yet that's not what all the literature on the subject says. What's going on?
Update:
http://hi.wikipedia.org should not be readable if Complex Script is not enabled
http://hi.wikipedia.org/wiki/विकिपीडिया:Devanagari_Help
Problem is that it is readable.
Font files. Rendering libraries ('Uniscript'). Input methods. Certainment beaucoup de cle-registry. (Certainly lots-o-registry-keys.)
Note that IE will tend to get things right even when other things don't, since it builds in a good deal of fancy-pants rendering. Try, oh, Outlook, or some simple sample Win32 program.