[Fabian Wosar]

I am certain quite a few of you know about it, but since I didn't encounter this trick personally until yesterdaym I decided to share it with you, because most likely some of you haven't seen it yet either. We received a (rather old) sample yesterday that showed some interesting behavior. As soon at it was unpacked on my Windows 7 machine several Windows processes like the search indexer or the Windows Explorer started crashing and so did several security applications like Malwarebytes and SUPERAntiSpyware when they tried to scan that file. Interestingly enough on a XP machine everything worked just fine. After examining the crash dumps it was clear that all applications crashed during the GetFileVersionInfoSizeEx call for that sample so I decided to take a look at the GetFileVersionInfoSizeEx implementation to find out what exactly is causing the crash.

It turns out that the way the file is mapped into memory by the GetFileVersionInfoSizeEx API in Windows Vista and later changed compared to Windows XP:

Code: Select all

Windows XP:
push    2               ; dwFlags
push    0               ; hFile
push    dword ptr [ebp+8] ; lpLibFileName
call    ds:LoadLibraryExW

Windows Vista and later:
push    22h             ; dwFlags
push    ebx             ; hFile
push    [ebp+lpFileName] ; lpLibFileName
call    ds:LoadLibraryExW

The additional flag is LOAD_LIBRARY_AS_IMAGE_RESOURCE and was added in Vista and later. This flag will cause the PE image loader to lay out the file exactly the way it would as if it was loaded for execution, but omitting certain steps that could cause code execution, like loading static imports for example. This does include setting the memory access rights according the section table though and some of you may already suspect where this is heading.

A quick look into the section header of the sample in question revealed the following:


That flags don't look right. No access at all? Lets see where the version resource is located:


So the version info is located in a section that is mapped with no access rights set. As soon as GetFileVersionInfoSizeEx (or any other version info API for that matter) tries to parse the resources it causes an access violation due to the missing read permission which then in turn causes the application to crash.

[kmd]

hi Fabian

i rather think this is malware packer bug - no support for vista/7.
why do you think this was made specially?

[Fabian Wosar]

why do you think this was made specially?

I don't believe in coincidences. I believe in probabilities. There are quite a few samples with such modifications in their section tables using different programming languages. Some of them have seemingly random values for the flags and others have their flags just zeroed out. The earliest report I could find after a few minutes using Google dates back to February. The sample I attached here was first seen by VirusTotal in March. While it is true that the sample I posted here doesn't run on a Vista or 7 VM (could be VM detection, I haven't looked at it to be honest) other samples do run just fine. Now given the fact that this change will disable quite a few of the most wide spread malware removal tools in existence I am tempted to say that it is much more likely that this is an intentional modification to the section table and not a bug.

[tomatto007]

Hi Fabian, I'm sure it's not accidental. As always your post is useful.