Thursday, December 27, 2012

Dumping Strong-Name Keypair Paths Used by Microsoft


When you want to sign a managed assembly with a strong name, you must do so with a key pair in the form of an snk file. Microsoft's assemblies are no exception. After seeing a few assemblies signed by Microsoft, I couldn't help but notice that they reveal some information about their internal filesystem. So I decided to dump all of the AssemblyKeyFileAttribute objects associated with every assembly registered in the GAC (global assembly cache). What follows is the PowerShell v3 command I used to generate the results and the results themselves.

(Get-ChildItem C:\Windows\assembly -Recurse -Include '*.dll' | % { [Reflection.Assembly]::ReflectionOnlyLoadFrom($_).CustomAttributes } | ? { $_.AttributeType.Name -eq 'AssemblyKeyFileAttribute' } | % { $_.ConstructorArguments.Value }) 2> $null

..\..\..\..\tools\devdiv\FinalPublicKey.snk
c:\oob\public\ext\sdk\vs9sp1\internal\strongnamekeys\fake\MSSharedLibSN1024.snk
d:\DMG_1102CTP\src\tools\devdiv\35MSSharedLib1024.snk
d:\oobwdeploy\public\ext\sdk\vs9rtm\internal\strongnamekeys\fake\MSSharedLibSN1024.snk
d:\sp1qfe.public.x86fre\internal\strongnamekeys\fake\windows.snk
d:\w7rtm.public.amd64fre\internal\strongnamekeys\fake\windows.snk
d:\w8rtm.public.amd64fre\internal\strongnamekeys\fake\windows.snk
d:\w8rtm.public.x86fre\internal\strongnamekeys\fake\windows.snk
d:\webmatrix22_rtw\public\ext\sdk\vs10sp1\internal\strongnamekeys\fake\MSSharedLibSN1024.snk
d:\win7_winmain.public.amd64fre\internal\strongnamekeys\fake\windows.snk
d:\win8_gdr.public.x86fre\internal\strongnamekeys\fake\windows.snk
E:\DNA\public\tools\common\security\FinalPublicKey.snk
e:\sql11_main_t\\sql\Common\SNK\SQL2003SNKEY.snk
e:\sql12_main_t\\sql\Common\SNK\SQL2003SNKEY.snk
f:\\dd\\Tools\\devdiv\\FinalPublicKey.snk
F:\dd\tools\devdiv\35MSSharedLib1024.snk
f:\dd\tools\devdiv\EcmaPublicKey.snk
f:\dd\tools\devdiv\FinalPublicKey.snk
f:\dd\wpf\src\windows.snk
f:\RTM\Tools\devdiv\FinalPublicKey.snk
FinalPublicKey.snk

While this information doesn't reveal anything of much value, it's interesting nonetheless to view the inconsistencies in Microsoft's signing procedure. At least they don't store all their keys in one basket!

Saturday, December 1, 2012

In-Memory Managed Dll Loading With PowerShell

Download: Out-CompressedDll

The .NET framework has a very handy method which loads a managed executable as a byte array – [System.Reflection.Assembly]::Load(byte[] rawAssembly). From the perspective of a malicious script, this is very convenient because it allows for a dll to be self-contained within the script body. What’s not as convenient is the size required to store the raw dll as a byte array in the script. To alleviate the size dilemma, I’ve written a PowerShell script that reads in a managed dll, compresses it, base64-encodes it, and outputs generated code that you can simply paste into any script that requires the dll.
As an example, I’ll compile the following code and run it through the script:
PS C:\> csc /target:library test.cs
Microsoft (R) Visual C# Compiler version 4.0.30319.17929
for Microsoft (R) .NET Framework 4.5
Copyright (C) Microsoft Corporation. All rights reserved.

PS C:\> Out-CompressedDll .\test.dll | Out-File LoadDll.ps1

I then add the following to the generated script to run the DoStuff method: [Test]::DoStuff()

This results in the following script:
And that's all there is to it!

Note that this technique will only load MSIL-based dlls. It will not load native or  IJW ('it just works' - mixed-mode) dlls.