Hey community,
I am Helmut Wagensonner, a Customer Engineer at Microsoft and with today’s blog I show you, how to look behind the implementation of Powershell CMDLets.
Ever wondered how the Microsoft guys code their powershell Commands? Ever wanted to take a peek at the implementation of a Powershell command? “You take the red pill - you stay in Wonderland, and I show you how deep the rabbit hole goes. Remember: all I'm offering is the truth. Nothing more.” (Matrix)
Everything starts with the Get-Command CMDlet.
Using Get-Command you can figure out a lot of properties of the command you want to look behind. The most important thing we need to know about a command is its type. The way to get to the script code is different for each command type. There are a lot of command types (https://docs.microsoft.com/en-us/dotnet/api/system.management.automation.commandtypes?view=powershel...) but most Powershell commands are of type “CMDLet” or “Function”. Another command type is “Alias”. But this is just a refenrence to a “CMDLet” or “Function”. So let’s focus on these two for now.
For this walkthrough I picked the “GC” (Get-Content) command as example for a CMDLet and “Get-WindowsUpdateLog” as an example for a Function.
The CMDLet inside a .NET binary
Let’s start to x-ray “Get-Content” by opening a Powershell window in administrative mode and typing the following command:
Get-Command gc | fl *
If you don’t elevate the Powershell window only a subset of the properties are shown.
In the Get-Command example above I’m using the short form “GC” instead of “Get-Content” as an example. This shows “Alias” as CommandType property. To figure out the full name of the command, take a look at the “ResolvedCommand” property and repeat Get-Command with its value. Using the long form shows the real command type, in this case a CMDLet.
Get-Command Get-Content | fl *
The DLL property shows the implementation source of this CMDLet. Since this is a binary format (.DLL), you need a disassembler to continue. There are a lot of tools to disassemble a dotNet binaries. I use ILSpy. It’s fast and can be installed as a portable app (no installation necessary).
So let’s open the file from the DLL property (Microsoft.PowerShell.Commands.Management.dll) in ILSpy. Most times the command implementation is found in the “Microsoft.PowerShell.Commands” namespace.
Typically the command classes are named similar to the PowerShell command. In our case you find the implementation in the GetContentCommand class. Sometimes you need to dig a bit deeper but I’m quite sure you will find what you’re looking for.
From now on little knowledge about .NET programming is necessary but as a rough indication you can search for methods like “ProcessRecord” or “BeginProcessing” to get a starting point.
The Function way
It’s different when the source code for a command is implemented as a function. As mentioned at the beginning, I chose the “Get-WindowsUpdateLog” command as an example here. So let’s have a look at its members.
Get-Command Get-WindowsUpdateLog | fl *
I shortened the output. In your case the ScriptBlock and Definition properties should be much larger. The source code of the function itself can be found in the “Definition” property. So it can easily be displayed using the command:
Get-Command Get-WindowsupdateLog | select -ExpandProperty Definition
However, in many cases, the function is using code parts or other functions from its parent module. To view the complete source code, you need to open the whole module in a text editor.
First, let’s find the parent module:
Get-Command Get-WindowsUpdateLog | select ModuleName
It’s part of the “WindowsUpdate” module. But where to find it? Well, that’s easy:
Get-Module -Name WindowsUpdate | select Path
This displays the path to the module definition file (*.psd1) or to the compiled module (*.dll) The compiled module can be opened with your favorite decompiler. In this example we have a module definition file. So let’s open the PSD1 in a text editor.
Find the line “ModuleList” or “NestedModules”. In both of them you can figure out the path to the module files (*.psm1).
The module files normally are located in the same directory. If not you will find a full path name after the ModuleList or NestedModules values. One of those files contains the implementation of the function, found in the definition property of the Get-Command output. In our case it’s easy because this psd1 only contains one module. So let’s go and open the PSM1 file in your favorite text editor.
Here we have the complete implementation of our function.
You may have noticed, that I used the terms “normally” and “most times…” a few times in this blog post. This is because there are different ways for implementation of CMDLets. Disassembling other commands could slightly vary from the steps mentioned above.
Anyway this gives you a starting point and it works for most CMDLet implementations coming from Microsoft.
Disclaimer
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.