The PE File Header: Digging the Rich Signature and other things

We touched on Rich data only briefly before and I'm not going to dwell on what it means any more than I did.  Here's a link for a reminder of what is contained in it and why you only see it sometimes in PE files.  This chunk of information not only reminds us that the file in question was built with a Microsoft compiler but can be leveraged for detection.

A couple of neat bits of information.  PE Files are traditionally pretty hefty.  The PE header alone can take up to 512 bytes because of file alignment. That's due to the specification though it be ignored in some instances to compress this into smaller sections.  That's the entire goal of Tiny PE, for example. The information in the PE Header can be removed since really the only two things required in the header are e_magic (MZ) and e_lfanew (tells you the offset of the real PE Header).  That's why we leveraged looking for the DOS stub and other items in the previous article.  If they are missing and its an peexe then that's a useful indicator of obfuscation or compression via removal.

Previously we used information in the Rich Signature as static values.  It can be helpful to determine obfuscation pursuing that method.  It can also be useful in other ways.  First off, a couple of points.  The python library pefile reads this data in its latest release.  The area has two constants and some helpers.  Constants are awesome because they help you fight obfuscation.  The values are (in hex) 52 69 63 68 for "Rich" and 44 61 6E 53 for "DanS".   This last value is special.  Following the "Rich" value at the end of the signature is a dword value that you XOR the beginning of the signature to derive DanS.  Just past it should be a trio of identical checksum values.  Here's what I'm talking about:

You can see the checksums are identical and one after another.  The rest is an array of linker information values showing the build number, and product identifier.  The link given previously provides the code necessary to find this information and derive the values if desired.  You can also check out the powershell scripting from Exploit Monday to do it another way if desired.

I'm sure you've noted that I keep talking about obfuscation and XOR.  That's obviously not the only means, easily ROT,ROL, and Shift techniques could be employed.  People are lazy though and convenience can often drive a decision that security would have chosen otherwise.

Finding these kinds of things doesn't have to be done by hand or even by Yara.  I like tools as much as the other guy but I believe in understanding the reason and technique behind them before employing them.  In this case, Didier Steven's XORSearch is excellent tool to both find the key for XOR or any of the others mentioned and to unobfuscate the file afterward.