A number of reusable PE File Format Scanning Functions

• Download source - 37 Kb

Introduction

This article accompanies a number of command line sample applications that wrap some common code of mine. This common code can be used to extract various information from PE files. The three samples are named bitness, pefileuses and dotnetsearch.

bitness expects a file name as the command line parameter and will tell you if the file passed as an argument is a 32 bit or a 64 bit PE file. It wraps the following common code function:

BOOL IsFile64BitPEFile(LPCTSTR szFile, PBOOL pbIs64Bits);

The parameters should be pretty self-explanatory. If the function succeeds, it returns a non-zero value. If it fails, the return value is FALSE and extended error information is available via GetLastError. In case of success, the out-Parameter pbIs64Bits will contain a non-zero value if the PE file passed as parameter szFile is 64 bits.

pefileuses is meant to determine if a given PE file links against a certain DLL or uses a function from a given DLL. It expects 3 command line parameters and optionally a fourth parameter. The first parameter is a number between zero and 2. This number determines whether the import table or the table for delayloaded functions should be scanned or both. Passing "0" means, both tables are scanned. Passing "1" means, only the import table, passing "2" means, only the table for delayloads are scanned. The second parameter is the PE file to be scanned. The third parameter denotes the DLL name that the tables should be scanned for. Finally the fourth parameter is an optional function name. The application will print on stdout whether or not the specified binary links against the given DLL or even uses the optional function name. This tool wraps the following common code functions:

BOOL __stdcall PeFileUsesImportA(LPCSTR szPeFile, LPCSTR szDllName, 
                                 LPCSTR szFunction, 
                                 PBOOL pbUse, DWORD dwFlags);
BOOL __stdcall PeFileUsesImportW(LPCWSTR szPeFile, LPCWSTR szDllName, 
                                 LPCWSTR szFunction, PBOOL pbUse, 
                                 DWORD dwFlags);

The flags to be passed for this function are those that are passed as the first parameter to pefiluses.exe and are defined as such:

#define PUI_USE_IMPORT_ONLY    0x1
#define PUI_USE_DELAYLOAD_ONLY 0x2

Passing 0L as the dwFlags parameter scans both tables as described above. The other parameters should be pretty self-explanatory. If the function succeeds, it returns a non-zero value. If it fails, the return value is FALSE and extended error information is available via GetLastError.

dotnetsearch is a tool to scan an entire directory tree and evaluate each DLL and EXE file found, whether it is a .NET binary. I wrote this tool in order to look at each new build of Windows Vista and to find out how many files on the entire Vista harddisk use the .NET-Framework. A binary that uses the .NET-Framework can be easily identified as it links against mscoree.dll. The dotnetsearch tool wraps the following common code functions:

BOOL __stdcall BinaryUsesDotNetA(LPCSTR szFileName, PBOOL pbUse);
BOOL __stdcall BinaryUsesDotNetW(LPCWSTR szFileName, PBOOL pbUse);

Again, the parameters should be pretty self-explanatory. If the function succeeds, it returns a non-zero value. If it fails, the return value is FALSE and extended error information is available via GetLastError;

Using the code

The code compiles cleanly with VC6 and a recent Platform SDK in both UNICODE and ANSI builds and for x86 and x64 targets. If you want to compile it for x64 with VC6 you need the Windows 2003 Server SP1 Platform SDK. It also compiles with VS2005, so this is another alternative for x64 builds.

Kudos

The functions that I am using in this common code of mine are mostly stolen from Matt Pietrek and a sample that came with an MSDN magazine article. All I did was to separate the functionality a bit better into reusable chunks, remove the globals that were used throughout the original code and reorganize things a bit better for proper usage in x86 and x64 builds and with the latest header files. If anything works well for you using this code, it is the sole merit of Matt Pietrek, if the code fails or breaks, it is my fault.

History

1st version: 07/30/2006