Archives for the Month of June, 2010

Hang Drum for Propellerheads Reason

One instrument that’s got great allure is the PanArt Hang – a metallic drum-like form with great complexity and resonance:

They are difficult to obtain, and expensive should you want to try.

Looking online, I found some WAV samples graciously provided by Andreas Bick at He also included the sampler settings to convert this to a virtual instrument for Apple Logic Pro’s ESX-24 sampler.

If you have Propellerhead Reason, the sampler settings won’t work – although you can still use the raw WAV files and do your own mapping for the Reason NN-XT sampler. Luckily, I spent the couple of hours doing it so that you don’t have to 🙂 You can get the files here:!AkuNs2XVz3R4jkhnrNNTG1QkRSoi

If you don’t have the WAV samples, you’ll need to download the entire ZIP and extract it. It’s in 7-zip format, since I couldn’t get regular zip files to go below the 50MB limit on SkyDrive. If you have the WAV files already, you only need the .sxt file also in the directory.

I also put up a Reason project (Egyptian Mystery.rns) for a song that uses only this instrument: Egyptian Mystery.

Which Files Support Authenticode Signatures?

An interesting question came up today about the Set-AuthenticodeSignature cmdlet. It actually supports more than just .ps1 files, but what files exactly?

It turns out that this isn’t actually possible to know programmatically. Your best bet is to hard-code a list of things you know or can scrounge from the internet 🙂 The ones I am aware of off-hand are:

.CAB, PE formats (.EXE, .DLL, etc) , .CAT, .MSI, .JAR,.OCX, .PS1, .PSM1, .PSD1, .PS1XML, .PSC1

Windows’ Authenticode infrastructure is based on plugins. All DLLs that support Authenticode signing are registered under:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllGetSignedDataMsg

Each DLL has a set of messages it needs to respond to, one of which is called IsMyFileType(). When you want to sign a file or verify the signature on a file, Windows walks along that list of registered GUIDs, asking each DLL: “Is this your file type?” If a DLL responds “Yes”, then it gets asked to verify the signature of that file.

The important point is that this decision is implemented as compiled code in the DLL, not some external mapping table.

Interesting aside:

This “ordered by GUID” enumeration of Authenticode plugins was the cause of our “RC1 Refresh” if you remember our initial V1 release. It turns out that the sample code from which we based our original Monad Authenticode DLL had a bug where it answered “Yes” to every file type. This never showed up because we had a GUID late in the chain. During the Monad-to-PowerShell rename, an obscure typo (capitalization of a single letter) caused our GUID to get registered as NULL.

Now, with a NULL GUID, our Authenticode plugin was guaranteed to be enumerated first. Since our plugin said that it understood how to manage signatures for all files on Windows, this broke MSI signing, EXE signing, DLL signing, and a bunch of other fun stuff!