Toolkits

C#: Determining if a file has a valid digital signature

Robert Paveza — Fri, 04 May 2007 18:19:33 GMT

One of the neat things Microsoft incorporated into Windows with the release of Internet Explorer 4 (which was provided for Windows 95 and Windows NT 4.0 with Service Pack 3) was the CryptoAPI, which provided not only services for secure hashing and stream ciphers, but also implemented Microsoft's Authenticode (r) code-signing verification. Authenticode is the technology that allows a Certification Authority (CA) such as Verisign to issue certificates to its clients in order to establish that software has been signed and is still authentic (that is, it has not been modified by any third parties). This is beneficial for obvious reasons, of course - when you're installing the Flash plugin, for instance, having an Authenticode signature verifies to you that the code is actually from Adobe, and that it hasn't been modified for some malicious purpose by a third party (such as a hacker).

Windows Vista has incorporated this further by presenting User Account Control (UAC) dialogs based on the code-signing policy defined by the system. When prompting for elevation, Windows Vista chooses one of four dialogs based on the security policy and code signature of the target executable.

As a software developer, verifying code integrity can be important; as a .NET developer, you of course have the Strong Name tool (sn.exe) to generate a private/public key pair with which to grant trust to assemblies (avoiding a trojan horse assembly in the process). However, there may be times where we want to validate the digital signatures of non-CLR assemblies, macros, or some other entity that was digitally signed. This will get you started by verifying the digital signature of a file; however, it can be used for other entities as described in the documentation.

For this we will use the WinVerifyTrust API. WinVerifyTrust takes a handle and two pointers - I hope you're excited for some new adventures in Platform Invoke! The first thing I put together quickly was an UnmanagedPointer class - by implementing IDisposable, it helps me to avoid memory leaks. Here's the quick low-down:

   1:          #region UnmanagedPointer class

   2:          internal sealed class UnmanagedPointer : IDisposable

   3:          {

   4:              private IntPtr m_ptr;

   5:              private AllocMethod m_meth;

   6:              internal UnmanagedPointer(IntPtr ptr, AllocMethod method)

   7:              {

   8:                  m_meth = method;

   9:                  m_ptr = ptr;

  10:              }

11:

  12:              ~UnmanagedPointer()

  13:              {

  14:                  Dispose(false);

  15:              }

16:

  17:              #region IDisposable Members

  18:              private void Dispose(bool disposing)

  19:              {

  20:                  if (m_ptr != IntPtr.Zero)

  21:                  {

  22:                      if (m_meth == AllocMethod.HGlobal)

  23:                      {

  24:                          Marshal.FreeHGlobal(m_ptr);

  25:                      }

  26:                      else if (m_meth == AllocMethod.CoTaskMem)

  27:                      {

  28:                          Marshal.FreeCoTaskMem(m_ptr);

  29:                      }

  30:                      m_ptr = IntPtr.Zero;

  31:                  }

32:

  33:                  if (disposing)

  34:                  {

  35:                      GC.SuppressFinalize(this);

  36:                  }

  37:              }

38:

  39:              public void Dispose()

  40:              {

  41:                  Dispose(true);

  42:              }

43:

  44:              #endregion

45:

  46:              public static implicit operator IntPtr(UnmanagedPointer ptr)

  47:              {

  48:                  return ptr.m_ptr;

  49:              }

  50:          }

The AllocMethod enumeration simply specifies the HGlobal and CoTaskMem members, which indicates how Marshal originally allocated the memory. With this class, I can now drop the memory blocks into using statements to have them automatically cleaned up, dodging a memory leak.

When using file lookups, you need to utilize the WINTRUST_FILE_INFO structure, which can be represented in C# as:

   1:          internal struct WINTRUST_FILE_INFO : IDisposable

   2:          {

   3:              public WINTRUST_FILE_INFO(string fileName, Guid subject)

   4:              {

   5:                  cbStruct = (uint)Marshal.SizeOf(typeof(WINTRUST_FILE_INFO));

   6:                  pcwszFilePath = fileName;

7:

   8:                  if (subject != Guid.Empty)

   9:                  {

  10:                      pgKnownSubject = Marshal.AllocHGlobal(Marshal.SizeOf(typeof(Guid)));

  11:                      Marshal.StructureToPtr(subject, pgKnownSubject, true);

  12:                  }

  13:                  else

  14:                  {

  15:                      pgKnownSubject = IntPtr.Zero;

  16:                  }

  17:                  hFile = IntPtr.Zero;

  18:              }

  19:              public uint cbStruct;

  20:              [MarshalAs(UnmanagedType.LPTStr)]

  21:              public string pcwszFilePath;

  22:              public IntPtr hFile;

  23:              public IntPtr pgKnownSubject;

24:

  25:              #region IDisposable Members

26:

  27:              public void Dispose()

  28:              {

  29:                  Dispose(true);

  30:              }

31:

  32:              private void Dispose(bool disposing)

  33:              {

  34:                  if (pgKnownSubject != IntPtr.Zero)

  35:                  {

  36:                      Marshal.DestroyStructure(this.pgKnownSubject, typeof(Guid));

  37:                      Marshal.FreeHGlobal(this.pgKnownSubject);

  38:                  }

  39:              }

40:

  41:              #endregion

  42:          }

Note that this class allocates unmanaged memory for the pgKnownSubject member - it is actually a pointer to a GUID structure, not the GUID structure itself. Since we're not making a P/Invoke call, but a marshalable structure, we can't define a "ref" field. I could have alternatively used a Guid* pointer type in place of that IntPtr, but I decided to stick with verifiable code. (Note that this is also true in the upcoming code, where a WINTRUST_FILE_INFO pointer is one of the fields.

Finally, we can build out the actual structure used by the API call, the WINTRUST_DATA structure:

   1:          [StructLayout(LayoutKind.Sequential)]

   2:          internal struct WINTRUST_DATA : IDisposable

   3:          {

   4:              public WINTRUST_DATA(WINTRUST_FILE_INFO fileInfo)

   5:              {

   6:                  this.cbStruct = (uint)Marshal.SizeOf(typeof(WINTRUST_DATA));

   7:                  pInfoStruct = Marshal.AllocHGlobal(Marshal.SizeOf(typeof(WINTRUST_FILE_INFO)));

   8:                  Marshal.StructureToPtr(fileInfo, pInfoStruct, true);

   9:                  this.dwUnionChoice = UnionChoice.File;

10:

  11:                  pPolicyCallbackData = IntPtr.Zero;

  12:                  pSIPCallbackData = IntPtr.Zero;

13:

  14:                  dwUIChoice = UiChoice.NoUI;

  15:                  fdwRevocationChecks = RevocationCheckFlags.None;

  16:                  dwStateAction = StateAction.Ignore;

  17:                  hWVTStateData = IntPtr.Zero;

  18:                  pwszURLReference = IntPtr.Zero;

  19:                  dwProvFlags = TrustProviderFlags.Safer;

20:

  21:                  dwUIContext = UIContext.Execute;

  22:              }

23:

  24:              public uint cbStruct;

  25:              public IntPtr pPolicyCallbackData;

  26:              public IntPtr pSIPCallbackData;

  27:              public UiChoice dwUIChoice;

  28:              public RevocationCheckFlags fdwRevocationChecks;

  29:              public UnionChoice dwUnionChoice;

  30:              public IntPtr pInfoStruct;

  31:              public StateAction dwStateAction;

  32:              public IntPtr hWVTStateData;

  33:              private IntPtr pwszURLReference;

  34:              public TrustProviderFlags dwProvFlags;

  35:              public UIContext dwUIContext;

36:

  37:              #region IDisposable Members

38:

  39:              public void Dispose()

  40:              {

  41:                  Dispose(true);

  42:              }

43:

  44:              private void Dispose(bool disposing)

  45:              {

  46:                  if (dwUnionChoice == UnionChoice.File)

  47:                  {

  48:                      WINTRUST_FILE_INFO info = new WINTRUST_FILE_INFO();

  49:                      Marshal.PtrToStructure(pInfoStruct, info);

  50:                      info.Dispose();

  51:                      Marshal.DestroyStructure(pInfoStruct, typeof(WINTRUST_FILE_INFO));

  52:                  }

53:

  54:                  Marshal.FreeHGlobal(pInfoStruct);

  55:              }

56:

  57:              #endregion

  58:          }

The WINTRUST_DATA structure defines a union where I defined the pInfoStruct field. It's possible to create something similar to a union in C#, by setting StructLayout as Explicit, and by putting each of the fields in the union at the same field offset. The drawback is that each field needs an explicit offset, which makes the structure not cross-platform (as 32-bit and 64-bit platforms will require diferrent field offsets). I decided again to go the path of the IntPtr and do the custom marshaling myself. You should note I use several enumerations - these are all defined on the API specification for WINTRUST_DATA.

FINALLY! We're at the point where we actually can define and call the method. I do both of these within a class called Interop, and translate it in an external method. Here are the definitions:

   1:          internal static uint WinVerifyTrust(string fileName)

   2:          {

   3:              Guid wintrust_action_generic_verify_v2 = new Guid("{00AAC56B-CD44-11d0-8CC2-00C04FC295EE}");

   4:              WINTRUST_FILE_INFO fileInfo = new WINTRUST_FILE_INFO(fileName, Guid.Empty);

   5:              WINTRUST_DATA data = new WINTRUST_DATA(fileInfo);

6:

   7:              uint result = 0;

8:

   9:              using (UnmanagedPointer guidPtr = new UnmanagedPointer(Marshal.AllocHGlobal(Marshal.SizeOf(typeof(Guid))), AllocMethod.HGlobal))

  10:              using (UnmanagedPointer wvtDataPtr = new UnmanagedPointer(Marshal.AllocHGlobal(Marshal.SizeOf(typeof(WINTRUST_DATA))), AllocMethod.HGlobal))

  11:              {

  12:                  IntPtr pGuid = guidPtr;

  13:                  IntPtr pData = wvtDataPtr;

14:

  15:                  Marshal.StructureToPtr(wintrust_action_generic_verify_v2, pGuid, true);

  16:                  Marshal.StructureToPtr(data, pData, true);

17:

  18:                  result = WinVerifyTrust(IntPtr.Zero, pGuid, pData);

  19:              }

20:

  21:              return result;

  22:          }

The hardest part of utilizing this code is dealing with the myriad of return values (which I will not go over here). Essentially, if the API returns 0, then the file is signed; if not, you can use Marshal.GetLastError() to determine the results.

Kudos go out to Microsoft for the example C program on which this article is based!

ASP.NET 1.1 with VS 2005

Robert Paveza — Tue, 27 Mar 2007 16:59:00 GMT

Thank God I don't have to install Visual Studio 2003 onto Vista.

Well, that may be a bit premature. I have to make sure that debugging and the like will still work. But I don't see why it wouldn't. So yes, it does turn out that you can work on .NET 1.1 projects in Visual Studio 2005 with a couple of project templates called "Everett Compiler". The Everett Compiler project templates include Console Application and Class Library templates that use a custom MSBuild .targets file that directs the compiler to target the C# 1.1 compiler ("Everett") instead of the typical 2.0 compiler. The original theory was that if 2005 could be redirected to use the LINQ/C# 3.0 compiler, why couldn't it be redirected to use the 2.0 compiler?

When first creating and loading a C# 1.1 project, you'll see the following dialog:

As you will learn by clicking on "More Info," you can disable this dialog by adding a string value to HKLM\Software\Microsoft\VisualStudio\8.0\MSBuild\SafeImports with the value "C:\Program Files\Everett\Everett.targets" or "C:\Program Files (x86)\Everett\Everett.targets" if you're on x64 or Itanium systems:

Building ASP.NET support with this is somewhat more challenging. You should be comfortable with using the ASP.NET markup syntax, because you probably don't want to try to incorporate the designer changes in ASP.NET 2.0.

Having said so, there are some other things you need to do. The Everett projects by default build to a subfolder of \bin; you'll want to have them output to \bin by default. ASP.NET 1.1's code model is significantly different than 2.0: with 1.1: there is quite a bit less dynamic compilation done with codebehind projects in 1.1 than there is in 2.0.

For projects that I built up, instead of trying to open the original project (which you probably don't want to do), I copied and pasted the files into new projects in a different subtree of the directory structure, and set up that directory as the web site in IIS 7. Be sure to check out Justin Copeland's blog entry about setting up ASP.NET 1.1 with IIS 7 to avoid, you know, continually crashing IIS. :)

Outlook 2007 and the Battle for Backgrounds, Part 1

Robert Paveza — Thu, 22 Mar 2007 17:51:00 GMT

As a web marketing firm, my company manages to generate quite a bit of e-mail for our clients (all opt-in, of course), and one of the ways that we do that is by templating out the entire HTML e-mail into a user control. The nice advantage to this is, of course, that we're able to pull in whatever kind of data we need and basically treat the e-mail like a page.

Our production team can generate some really great artwork and layout, and up until this point it's worked great. They've been doing extensive testing to make sure that our generated e-mails work in Outlook/Outlook Express/Thunderbird/Gmail/Hotmail/etc., and generally things have worked great. It wasn't until we started using Outlook 2007 that things were mucked up.

For those who don't know, Outlook 2007 no longer uses the Internet Explorer HTML rendering engine, which is probably a positive thing from a security standpoint. It uses the Word 2007 rendering engine, which severely cuts back its HTML and CSS rendering capabilities. Among the problematic rendering logic is Outlook's inability to render background images, something that has been crucial to our placing of dynamically-generated text into e-mails (for instance, a "Send to Friend" feature might include a note to the recipient). Static text would be no problem - our graphic artists would simply include the copy in the final image. But for dynamic text, we were left with a question of functionality - do we simply not include dynamic text, or do we put it over a solid background?

Dynamically generating images with ASP.NET has been common since it was first released, and for a short time (through Beta 1), ASP.NET 2.0 was going to handle it natively with a new file type, *.asix (it was removed due to architectural difficulties). Especially for low-volume e-mails (such as one that wasn't likely to generate tens of thousands of simultaneous hits to the web server), this seemed like an elegant solution, and it would work in all e-mail clients equally-well. The only real question was how to get the data to the server efficiently.

I opted out of storing the text in the database in this instance because, well, the dynamic text was an afterthought and I didn't really want to go back and modify the db schema (nor did I think that the text was worth storing). Rather, I came up with a slightly roundabout way of having the client specify the message itself: since dynamic images are generally .aspx pages that send image data over the wire instead of markup, I simply include a query string as part of the image's URL (if we want to be even more creative and SEO-compliant, we can use PathInfo instead of QueryString). The last question is how to get such data to the image without it looking funny (for instance, by having %20 encoded for spaces), and that is answered with Base64 encoding.

Base64 encoding uses six bits to represent byte values, and so for every three bytes there are four Base64 characters. Base64 is never garbled by browsers because it uses the 26 uppercase and lowercase characters and two standard characters + and / (note that if we used PathInfo instead of QueryString, we should replace the / character with something else such as - or _ so that we don't run into our web application believing we're running another page, in the event we're using PathInfo for URL rewriting techniques).

I've created a new control that can be used in our e-mail templates. It's entirely code, and very brief:

    public class DynamicTextImage : System.Web.UI.WebControls.Image
    {
        private string m_msg;
        public string Message
        {
            get
            {
                return m_msg;
            }
            set
            {
                m_msg = value;
            }
        }
 
        protected override void OnPreRender(EventArgs e)
        {
            if (this.Message != null && this.Message.Length > 0)
            {
                byte[] msgBytes = Encoding.ASCII.GetBytes(this.Message);
                string message64 = Convert.ToBase64String(msgBytes);
                this.ImageUrl = string.Format("{0}?t={1}", this.ImageUrl, message64);
            }
 
            base.OnPreRender(e);
        }
    }

This allows the image to be inserted in the same way a standard <asp:Image> control is, with no additional markup required by our production team and very little code by the developer working on it (this.dynamicImage1.Message = this.txtMessage.Text;).

Part 2 of this article will discuss the code behind generating the dynamic image and sending it to the viewer. I'm sure for those of you who have used dynamic images in the past, the wheels are already spinning as to how you can adapt this to be effective at your organization.