Option Explicit, I mean "Strict" switch... I have been waiting for this feature for quite a while.
Setting Visual Basic's "Option Explict" statement like switch in PowerShell.

The Magic Word is..
Set-PSDebug -Strict
Upon executing the command, according to help page(Get-Help Set-PSDebug),

the interpreter will throw an exception if the referenced variable hasn’t been set yet.

Let's see when that feature might come in handy.

PS> Set-PSDebug -Off
PS> function add($x, $y) { $x + $z }
PS> add 1 10
1
PS> $z = 100
PS> add 1 10
101

As you can see, with "Strict" mode off(well "Strict" flag is of type Switch, and all the Boolean flags were replaced with Switches), the PowerShell interpreter simple accepts the fact that function "add" just adds value of $x and $z without caring about what the value of $z is.

Now, let's set the "Strict" option on

PS> Set-PSDebug -Strict
PS> ri function:add; rv z # remove "add" function and the variable $z
PS> function add($x, $y) { $x + $z }
PS> add 1 10
The variable $z cannot be retrieved because it has not been set yet.
At line:1 char:31
+ function add($x, $y) { $x + $z <<<< }

Although the demo is really too simple of a case, in your scripts, you might have variables that you are not keeping track of but being still used somewhere in your scripts.

Well, if you are using PowerShell just for interactive uses for a quick and dirty operations, forget about this feature but then if you are writing cmdlets, setting this option always would be a good idea.


Tags : Monad msh PowerShell  ¶ 9:49 PM 0 comments

  [MSH] Extending System.Security.SecureString I was reading Monad Technology Blog about Base64 Encode/Decode a string, which deals with extending a .NET object System.String to include script properties (which you can also add in an interactive mode through "add-member -type ScriptProperty" but lasts only during the given session) called "ToBase64String" and "FromBase64String".

Well, to apply the concept, I have decided to extend System.Security.SecureString by creating a new Monad XML type file called "my.types.mshxml"(the name is from Monad Technology blog) at $MshHome(for most of people, it should be "C:\Program Files\Microsoft Command Shell\v1.0") and then extended SecureString to include a script property called UnsecureString.
UnsecureString decodes SecureString's content.

*NOTE: I won't go into details on how you can view SecureString content. If you would like to know how you can view a secure string content and want to find out more about Windows Data Proctection, please refer to following sites

• /\/\o\/\/'s blog: Get-credential and Decrypting a SecureString in MSH
• MSDN: Windows Data Protection(or follow the link on Mow's blog)

My.Types.Mshxml

<?xml version="1.0" encoding="utf-8" ?>
<Types>
    <Type>
        <Name>System.Security.SecureString</Name>
        <Members>
            <ScriptProperty>
                <Name>UnsecureString</Name>
                <GetScriptBlock>
                    [Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($this))
                </GetScriptBlock>
            </ScriptProperty>
        </Members>
    </Type> 
</Types>

Then, as you see in Monad Technology Blog, load the newly created custom type data:
Update-TypeData $MshHome\My.Types.Mshxml

Let's see if System.Security.SecureString has been extended or not

MSH>$admin = get-credential administrator
MSH>($admin.password).getType().fullName
System.Security.SecureString
MSH>$admin.password | get-member -MemberType ScriptProperty | format-list

TypeName   : System.Security.SecureString
Name       : UnsecureString
MemberType : ScriptProperty
Definition : System.Object UnsecureString {get=[Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($this));}

Now, you can see that SecureString type has been extended with "UnsecureString".
From this point on,

MSH>$admin.password
System.Security.SecureString
MSH>$admin.password.UnsecureString
*** secret ***

where *** secret *** is your decoded password string.


But this raises a couple of questions.

1. Displaying clear, unsecure string for the credential object is a security threat
2. I can't answer "IMPORTANT" note posted on Monad Technolog Blog site

• <IMPORTANT POINT>
  Whenever you are adding some functions, you should make a conscious decision about whether those functions are best exposed as a "function" or as a "type extension".
  </IMPORTANT POINT>
  

I don't know when extending SecureString would come in handy without causing any security problems.
Will anyone be able to justify the need for extending SecureString to display clear string?
Well it's all up to you whether you would want to or not. (I just like to mess around...)


Tags : Monad msh  ¶ 5:37 PM 0 comments