Red Pill BLOGS https://docs.microsoft.com/archive/blogs/hewagen/feed.xml Windows 10 and custom coding. The answer to life, the universe and everything. By Helmut Wagensonner [PFE] Tue, 16 Apr 2019 05:09:14 GMT en-US hourly 1 PCRDump https://docs.microsoft.com/archive/blogs/hewagen/pcrdump Sun, 13 May 2018 08:48:55 GMT https://blogs.msdn.microsoft.com/hewagen/?p=235 PCPTool (written by Stefan Thom) and Win7PCRv2 (actually I couldn’t figure out who coded this one) to dump the TPM PCR registers. On some devices with newer Win 10 builds (1709 onwards) the tools were throwing errors. PCPTool complained about a too small buffer size while Win7PCRv2 came up with some System.Management errors. Additionally, it is a pain that Win7PCRv2 is compiled against .NET 2.0, which forces you to install .NET 3.5 on Win 10 clients first. That’s why I decided to re-write the PCR dump functions of those tools and combine them into one executable. PCPTool utilizes ncrypt.dll to get the PCR values while Win7PCRv2 relies on TPM base service (tbs.dll), which is also available in Win7. I gave a bigger buffer to the NCryptGetProperty call and I forced the WMI functions to use more current Management classes to query the TPM spec version. Still I have no idea why a byte[24*20] is not enough buffer for 24 TPM registers with 20 bytes each. So the ncrypt way my return incorrect values in rare cases. The result of it all is a new executable, which can query the PCR registers in two different ways. Also, it uses .NET 4.0 so there’s no need to install ancient frameworks. At the moment, the command understands 3 parameters:
  • -ncrypt: forces the tool to query the PCR values using the NCryptGetProperty function of the ncrypt.dll (only available in Windows 10).
  • -tbs: forces the tool to query the PCR values using the Tbsip_Submit_Command function of the tbs.dll.
  • -getpcr: uses both methods. If the result is different, you can use the -ncrypt -show48 parameters to dump the next 24 * 20 bytes. Show48 is for debug purposes only.
Use PCRDump -? to get a usage output. Note that you must run the tool in an elevated command prompt.
Clicking the Download button takes you to the OneDrive folder. You only need to download the PCRDump.exe file. Note: This download link is only available to Microsoft FTE’s at the moment. Non Microsoft FTE's can send a download request by e-mail. ]]> Making file type associations enterprise ready https://docs.microsoft.com/archive/blogs/hewagen/making-file-type-associations-enterprise-ready Sun, 11 Mar 2018 14:09:23 GMT https://blogs.msdn.microsoft.com/hewagen/?p=155 Here’s a good technical explanation about how FTA works in Windows 10. The solution I’m providing here adds a bit of dynamics to the file type association topic (FTA). It is still a workaround but it lets you modify file type associations by using a Powershell script. Make sure to configure your environment as mentioned below. Prepare your environment
  • Create a default file type association XML, which works with your standard client (click here to see how to export FTA's). Make sure that your FTA XML file only contains extensions you want to modify. Simply remove the lines with extensions you want to leave untouched. You can also deploy an empty XML if you don’t want to assign any file types yet. An empty file would look like this: <?xml version="1.0" encoding="UTF-8"?> <DefaultAssociations> </DefaultAssociations>
  • Use your preferred deployment method to push the file to your clients or add it to your master image. Select a local folder, which is readable but not changeable for users. The C:\ProgramData\YourCompany folder would be a good place. You can refer to it in the GPO with the %ProgramData% variable.
  • Create a GPO which affects all Windows 10 clients and change the setting as shown in the picture. Point the path to the location, where you copied your XML file.
On a client, which is in scope of the GPO, do a GPUPDATE and log off/on to apply the changes. The settings of you FTA XML should now take effect. You can check the registry for verification. If you changed, for example, the assignment for .AVI files in your config file, you should find a registry value HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.avi\UserChoice\ProgId. The data of this value should be the same as the ProgId specified in your XML. And of course .AVI files should open with the application you assigned it to. If this is not the case, check the event log Microsoft-Windows-Shell-Core/AppDefaults for errors. Add script to application deployments Let’s assume you deploy an application to a set of clients, which handles a file type you already assigned to an application in your XML. You want to change the default app for this file type. To accomplish this, simply run the Powershell script attached to this article after the installation of the new application. You can also make this part of your app deployment. Modify-AppAssocXml.ps1 -Path "C:\ProgramData\YourCompany\AppAssoc.xml" -Extension ".avi" -ProgId "VLC.avi" -AppName "VLC Media Player" This modifies the local application association XML file. It changes .AVI to the new AppId or adds a new line, if AVI is not yet assigned. To use this script, you should understand the values the command accepts. Path is straightforward. It’s the path to your local FTA config file. Extension is the file type(s) you want to modify or set. You can either specify a single extension or multiple extensions, separated by comma (i.e. ".avi,.mp4,.mpeg") ProgID is the path to the open handler in the registry, relative from HKEY_CLASSES_ROOT to the key name before Shell\Open\Command. An Example: The open handler for “notepad.exe” can be found in HKEY_CLASSES_ROOT\Applications\notepad.exe\shell\open\command. The ProgID for Notepad would be Applications\notepad.exe. AppName is the file description property of the corresponding EXE file. However, this value does not affect the file type association but it must be set. Unfortunately, it requires GPO foreground processing for the settings to take effect. This means that users need to log off/on after the FTA XML has changed.
]]> Another Windows 10 version overview https://docs.microsoft.com/archive/blogs/hewagen/win10ver Sat, 24 Feb 2018 12:43:50 GMT https://blogs.msdn.microsoft.com/hewagen/?p=115 always check the last modified date. Note, that dates are specified in German notation (dd.mm.yyyy).
Version Code Name Initial Build Channel Switch Current Channel Release Channel Switch End of Support Extended Support .NET Runtime Powershell
1507 Threshold 10240.16405
N/A
 CBB 29.07.2015
N/A
09.05.2017
N/A
 4.6 5.0
1511 Threshold 2 10586.3 10586.164 CBB 10.11.2015 08.03.2016
10.10.2017
N/A
 4.6.1 5.1
1607 Redstone 14393.10 14393.447 CBB 02.08.2016 08.11.2016 09.04.2019
N/A
 4.6.2 5.1
1703 Redstone 2 15063.138 15063.483 SAC 05.04.2017 11.07.2017 08.10.2019
N/A
 4.7 5.1
1709 Redstone 3 16299.19 16299.125 SAC 17.10.2017 12.12.2017 10.04.2020
N/A
 4.7.1 5.1
1803 Redstone 4 17134.1 17134.165 SAC 30.04.2018 10.07.2018 10.11.2020
N/A
 4.7.2 (Rel 461814) 5.1
1809 Redstone 5 17763.1
N/A
 SAC-T 02.10.2018
N/A
 13.04.2021
N/A
 4.7.2 (Rel 461814) 5.1
1903 19H1
N/A
N/A
 Skip-Ahead
N/A
N/A
N/A
N/A
N/A
N/A
1507 LTSB Threshold 10240.16405
N/A
 LTSB 29.07.2015
N/A
 13.10.2020 14.10.2025 4.6 5.0
1607 LTSB Redstone 14393.10
N/A
 LTSB 02.08.2016
N/A
 12.10.2021 13.10.2026 4.6.2 5.1
1809 LTSC Redstone 5
N/A
N/A
N/A
 Fall 2018
N/A
N/A
N/A
N/A
N/A

Most columns don't need to be explained. The Channel Switch column, which appears twice, specifies the version and the date of the CBB/SAC declaration for each release. Further information on servicing channels can be found here. The Release column either shows the date of the initial release for each version or it shows the approximate release date for future versions. Note that "End of Support" and "Extended Support" dates are subject to change. Update 06.09.2018: With todays announcement servicing for Windows 10 has changed in a major way. The table above already includes the new servicing changes. Note: Information in this article targets Enterprise and Education versions of Windows 10. Pro and Home versions are not considered. For further information on the values mentioned in the table, please visit following sites: Windows 10 release information Windows lifecycle fact sheet Windows 10 Insider previews (Flight Hub) Windows 10 .NET runtime versions Last modified on October 09, 2018]]> Disassemble Powershell CMDLets https://docs.microsoft.com/archive/blogs/hewagen/disassemble-powershell-cmdlets Thu, 14 Dec 2017 19:11:32 GMT https://blogs.msdn.microsoft.com/hewagen/?p=26 "Then take the red pill, stay in wonderland and I show you how deep the rabbit hole goes. Remember: all I'm offering is the truth. Nothing more." 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 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 (doesn't need to be elevated) and typing the following command: Get-Command gc | fl * Using the short form "GC" with Get-Command, like we just did, shows "Alias" as CommandType property. To figure out the full name of the command, take a look at the "ResolvedCommandName" 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 of the output indicates where the implementation of this CMDLet can be found. Since this is a binary format (.DLL), we need a disassembler to continue. There are a lot of tools to disassemble a dotNet binary. 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. From now on a little knowledge about .NET programming is necessary but as a rough indication we can search for methods like "ProcessRecord" or "BeginProcessing" to get a starting point.
The Function way It's different when we need to get the source code for a command implemented as a function. As mentioned at the beginning, we use the "Get-WindowsUpdateLog" as an example here. So let's have a look at its members. Get-Command Get-WindowsUpdateLog | fl * 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, we need to open the whole module in a text editor. First, let's find the parent module: Get-Command Get-WindowsUpdateLog | select -ExpandProperty ModuleName It's part of the "WindowsUpdate" module. But where to find it? Well, that's easy: Get-Module -Name WindowsUpdate | select -ExpandProperty 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 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 reside in the same directory. 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 our favorite text editor. Here we have the complete implementation of our function. You may have noticed, that I used the terms "normally, most times..." quite often in this tutorial. This is because there are different ways for implementation of CMDLets. Reversing other commands could slightly differ to the steps mentioned above. Anyway it's starting point. ]]>