VS2008: Embedding UAC Manifest Options

A very useful feature included in VS2008 concerns the possibility of embedding a manifest resource which specifies UAC options in applications running on Windows Vista. First, you can create a manifest file by adding an “Application Manifest File” Item to your project (default name: app.manifest), then you can set it through the Application Tab in the Project Properties.
If you want to change the Windows User Account Control level in your manifest file, all you need is to set the value of the level attribute of the requestedExecutionLevel node with one of the following:

• asInvoker (default): the application will run using the current Windows user provileges
• requireAdministrator: the application requires an Administrator user
• highestAvailable: highest privileges for the current user will be used

Protecting data using ProtectedMemory

If you are looking for a smart way to encrypt/decrypt sensitive data in memory in order to make them unreadable even in malicious memory dumps, maybe you need to use the ProtectedMemory class (namespace System.Security.Cryptography). This class is a managed wrapper included in the DPAPI (Data Protection API) and it works in the same way as ProtectedData (a similar class indeed used to persist encrypted strings in file/database): it exposes two static methods, Protect and Unprotect,  which allow you to encrypt/decrypt strings in memory. The only requirement you have to consider in order to avoid a CryptographicException  is about using 16-bytes blocks for computing encrypted/decrypted data. For example, the following code shows how to protect/unprotect a sensitive string in memory during a process execution:

using System.Security.Cryptography; … string OriginalString = “xxxxxxxxxxxxxxxx”; Console.WriteLine(“Before Protect: “ + OriginalString); byte[] OriginalBytes = Encoding.UTF8.GetBytes(OriginalString); ProtectedMemory.Protect(OriginalBytes, MemoryProtectionScope.CrossProcess); UTF8Encoding enc = new UTF8Encoding();            Console.WriteLine(“After Protect: “ + enc.GetString(OriginalBytes)); ProtectedMemory.Unprotect(OriginalBytes, MemoryProtectionScope.CrossProcess); OriginalString = Encoding.UTF8.GetString(OriginalBytes); Console.WriteLine(“After Unprotect: “ + OriginalString);

Here the output:
Before Protect: xxxxxxxxxxxxxxxx
After Protect: 7j??‼8y_??PQ<?¶-
After Unprotect: xxxxxxxxxxxxxxxx

Some further considerations:

• The Protect()/Unprotect() method works directly on the original data, not on a copy. So, we don’t need to explicitly destroy our sensitive strings after the use.
• Many people use SecureString, a more intuitive class using ProtectedMemory to automatically encrypt strings. A SecureString can be modified till the MakeReadOnly() method call and can be programmatically disposed. Finally, its MemoryProtectionScope is SameProcess: a SecureString can’t be used in CrossProcess and SameLogon scenarios, in which there’re multiple applications running in different processes (CrossProcess) and allowing data encryption/decryption to the same Windows user (in particular cases, consider the impersonation technique).
• I’ve noticed some strange behaviours by randomly analyzing the memory dump file after invoking the Protect() method on a string: sometimes the text I’d like to protect appears as clear text…mmmm…. Does Windows operate a swap on file system before data encryption? If this is a possibility, are my efforts unuseful?