There was a lot of love going around in May 2000, but as they say love hurts. If organizations would have had some code signing routines in place, the ILOVEYOU virus would have been killed in its crib.

Of course those hippie days are long gone as no one tends to allow .vbs files in the mail server or if it’s not blocked there the email client should block it.

However code signing can do more than just avoiding the mitigating click, still in this post I won’t focus on the security benefits of code signing.

What is code signing (the short version)?

Code signing is a mechanism where we use public key certificates to sign our code or scripts. What the process does is to add a portion to the file, which can be verified against the certificate which signed it.

Why we would want to do this leads us to the next subject.

Goals of Code Signing

In short there are two goals with code signing; Authenticity and Integrity.

When a script is digitally signed we can look at the signature and find out which digital certificate was used in order to sign the script. Let’s say we work with Bob, we would very much like to use one of the scripts he has written but based on past experience we don’t want to run any scripts from our other coworkers.

If Bob has signed the scripts he has created we can look at the signature and verify that the code is authentic. I.e. the script has actually been written by Bob and not by the hotshot whose last script crashed the server.

The second goal is that of integrity, what it means is that the script is still intact or complete. We want to make sure that nothing in the script has changed since Bob signed the script, if it has the script signature has lost its integrity.

So if someone were to edit Bob’s script it will fail its integrity check when we validate the script signature.

As long as we are able to validate the signature we know that the file was indeed signed by Bob, or technically by Bob’s certificate.

Bonus Goal – Non-Repudiation

The two other goals work in favor for Bob, if something has changed in the code he can just say that the certificate validation failed and at that point he can’t be held accountable for what the modified code does.

However if the signature is intact and something goes wrong when we run the script Bob can’t repudiate the fact that he was the one who wrote the script.

Conclusion

In a situation where we trust another party, the goals of code signing is to verify that the scripts or code we are about to run are created by a person we trust and that they haven’t been modified.

This post is part of the series How to Implement Code Signing for Scripters

This article is eagerly awaiting to be written (honestly)!

Some cmdlets can provide verbose data. This is disabled by default but can be enabled by using the -Verbose parameter. This can be useful if you want to log an action or troubleshoot your scripts.

To view an example of this we will look at the Set-Alias cmdlet:

PS C:\> Set-Alias Time Get-Date -Verbose
VERBOSE: Performing operation "Set Alias" on Target "Name: Time Value: Get-Date".
PS C:\>

As I said some cmdlets doesn’t provide verbose information so if we use the parameter with the Get-Date cmdlet it doesn’t provide any additional verbose data:

PS C:\> Get-Date -Verbose

Monday, July 28, 2008 7:48:33 AM
PS C:\>

Generally you will find that the Verbose parameter works on PowerShell cmdlets that make some kind of change to the system.

The OutBuffer parameter determines how many objects will be buffered before calling the next cmdlet in the pipeline.

Instead of typing out -OutBuffer you can use -ob for short.

I will add more information to this page when I’ve used OutBuffer more and can provide some examples.

Like many other aspects of PowerShell, -ErrorAction kind of explains itself when you think of it. Basically it instructs PowerShell what action to take when an error occurs. The actions you can set are Continue (which is default), Stop, SilentlyContinue and Inquire. Let’s take a look.

Continue

You can verify that Continue is the default action by looking at the $ErrorActionPreference variable. We’ll be using the Stop-Process Cmdlet to test this.

PS C:\> $ErrorActionPreference
Continue
PS C:\> Stop-Process 206,304
Stop-Process : Cannot find a process with the process identifier 206.
At line:1 char:13
+ Stop-Process <<<< 206,304
Stop-Process : Cannot find a process with the process identifier 304.
At line:1 char:13
+ Stop-Process <<<

Since we know continue is the default error action we don’t need to use “-ErrorAction Continue”.

Stop

The Stop error action instructs PowerShell to stop executing after the first error.

PS C:\> Stop-Process 206,304 -ErrorAction Stop
Stop-Process : Command execution stopped because the shell variable "ErrorActionPreference" is set to Stop: Cannot find
a process with the process identifier 206.
At line:1 char:13
+ Stop-Process <<<

Compared to when we used “Continue”, PowerShell will only try to stop the process with id 206 and never move on to 304 since it failed to stop the first one.

SilentlyContinue

As you might guess SilentlyContinue acts like Continue with the exception that we don’t see the errors. To save some typing we don’t need to write out ErrorAction, we can use EA for short.

PS C:\> Stop-Process 206,304 -EA SilentlyContinue
PS C:\>

Inquire

Inquire informs us that there has been an error and lets us decide what to do.

PS C:\> Stop-Process 206,304 -EA Inquire

Confirm
Cannot find a process with the process identifier 206.
[Y] Yes [A] Yes to All [H] Halt Command [S] Suspend [?] Help (default is "Y"): h
Stop-Process : Command execution stopped because the user selected the Halt option.
At line:1 char:13
+ Stop-Process <<<

What if you just deleted 5000 accounts from your active directory domain by accident, what if there had been an easy way to make sure you were doing the right thing before the deletion. Would you have wanted to use it? I know I would. Just imagine you were planning on deleting all accounts which had been disabled for six months but you forgot some important switch and most of your accounts were gone because of that stupid switch.

Ok, so this might be a bit far fetched but these things can happen and if you are not 100 percent sure of what you are doing, it’s great to be able to see what the results of your actions will be before you take them.

Let’s say we’ve been taking random notes and just want to kill all notepad processes without having to choose if we want to save every single file. Working with the Get-Process, Where-Object and Stop-Process cmdlets we decide to kill all the processes which has “note” in them.

PS C:\> Get-Process | Where-Object {$_.ProcessName -match "note"} | Stop-Process -Whatif
What if: Performing operation "Stop-Process" on Target "notepad (4284)".
What if: Performing operation "Stop-Process" on Target "notepad (4524)".
What if: Performing operation "Stop-Process" on Target "notepad (4848)".
What if: Performing operation "Stop-Process" on Target "notepad++ (4684)".
What if: Performing operation "Stop-Process" on Target "ONENOTE (5944)".
What if: Performing operation "Stop-Process" on Target "ONENOTEM (3876)".
PS C:\>

This would have wiped out every instance of notepad.exe along with my Onenote and notepad++ processes which was not what I wanted.

Lame example?

Yes, I guess you’re right that was quite a lame example. However I think it does illustrate how you can use the -whatif parameter. It can be very useful if you are working with important data and don’t want to make mistakes. Also it’s useful if your just playing around with PowerShell and learning what all the fuss is about.

It is said that we learn from our mistakes, and that to improve learning it’s best to write things down. How about storing our mistakes and errors in a variable? If that’s not killing two flies with one stone, at least it’s a useful feature of PowerShell. Let’s use it and see how it works, using the Stop-Service cmdlet we try to stop a service:

PS C:\> Stop-Service -name XAudioService -ErrorVariable myErrors
Stop-Service : Service 'XAudioService (XAudioService)' cannot be stopped due to the following error: Cannot open XAudio
Service service on computer '.'.
At line:1 char:13
+ Stop-Service <<<

As you can see the error is also written to screen. From now on we can reference the error in the $myErrors variable we created:

PS C:\> $myErrors
Stop-Service : Service 'XAudioService (XAudioService)' cannot be stopped due to the following error: Cannot open XAudio
Service service on computer '.'.
At line:1 char:13
+ Stop-Service <<<

You might want to know that even if you don’t specify the -ErrorVariable parameter all the errors will be storied in a special error called $error.

Saving the error variable like we have done above will ensure that you have the last error saved. One thing you can do is to add a plus sign before the variable when you want to append to the error variable. Here is an example:

PS C:\> Stop-Service -name XAudioService -ErrorVariable +myError
PS C:\> Stop-Service -name WinRM -ErrorVariable +myError
PS C:\> $myError.Count
2
PS C:\>

Imagine you are feeling handy and start out to rebuild your bathroom. Now imagine you’re standing knee deep in water in your basement. I bet you wished that somewhere in your head there was a tiny voice which had asked you, “do you really want to drill there”? This is the purpose of the PowerShell -Confirm parameter. If you’re running a cmdlet which changes the system state you can use -Confirm in order to get a question asking you if you really want to go ahead with the change.

Argh, my files, my precious files!

We’ve all heard horror stories of format c: and the like. At one point you might even have deleted files by mistake. With the Remove-Item cmdlet you can do just that.

PS C:\Temp> Remove-Item *
PS C:\Temp> <- That went smooth!

However wouldn’t this have been better:

PS C:\Temp> Remove-Item * -Confirm

Confirm
Are you sure you want to perform this action?
Performing operation "Remove File" on Target "C:\Temp\junkfile1.txt".
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): y

Confirm
Are you sure you want to perform this action?
Performing operation "Remove File" on Target "C:\Temp\junkfile2.txt".
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): y

Confirm
Are you sure you want to perform this action?
Performing operation "Remove File" on Target "C:\Temp\junkfile3.txt".
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): y

Confirm
Are you sure you want to perform this action?
Performing operation "Remove File" on Target "C:\Temp\single-copy-of-expense-report.xlsx".
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): n

Lessons Learned

As the carpenters say; measure twice, cut once. Sometimes it’s better to step carefully unless you are really sure of what you are doing. The -Confirm parameter can be that little voice inside your head.

Building on the Perl motto; “There’s more than one way to do it”, PowerShell lovers will tell you that they can play too. Basically the -OutVariable parameter stores the output from a cmdlet to a variable and at the same time letting the cmdlet display all the output to the screen. For example looking at the Get-ChildItem cmdlet you can store the output in a variable by doing:

$myChildren = Get-ChildItem

Using the -OutVariable parameter you would instead type:

Get-ChildItem -OutVariable myChildren

This would also store the output in the myChildren variable (notice the lack of the $ sign), but unlike the first example the output would be printed to the screen.

This might sound a lot like the Tee-Object cmdlet. However you can also use OutVariable like this:

Get-ChildItem Directory1 -OutVariable myChildren
Get-ChildItem Directory2 -OutVariable +myChildren

This way the $myChildren variable would hold the contents of both Directory1 and Directory2. Another difference, if you’re in a hurry and want to juice out some performance, can be shown by the Measure-Command cmdlet.

Measure-Command {Get-ChildItem | Tee-Object -variable myTeeOutput}
TotalMilliseconds : 3,3151

Measure-Command {Get-ChildItem -OutVariable myOutVariableOutput}
TotalMilliseconds : 2,0668

Folks, we have a winner! But what will we do with all the extra free time?

If you just want to store the variable and not display the output you can use the Out-Null cmdlet:

Get-ChildItem -OutVariable myChildren | Out-Null

PowerShell uses for different settings called Execution Policy which governs how scripts will run on your computer and if they need to be digitally signed. Get-ExecutionPolicy is a Cmdlet which allows you to view which Execution Policy that is currently used by your computer.

SYNTAX

Get-ExecutionPolicy
-Verbose
-Debug
-ErrorAction
-ErrorVariable
-OutVariable

Examples

PS C:\> Get-ExecutionPolicy
Restricted