Ever wondered which DLLs your EXE depends on? Or what technology a given DLL is built with? Is it a native DLL, a .Net DLL, or a .Net Core DLL? If it is .Net technology, which framework does it rely upon?
PE File Browser is a PE explorer that allows you to view the contents of portable executable files. All processor architectures are supported, allowing you to examine ARM executables as well as x86 and x64.
The PE File structure is well documented, with a PE file consisting of a header, an optional header and a list of directories that points to specific sections of the PE file. Normally PE files are .exe and .dll, but they can also be .bpl, .arx, .ocx, .scr, .mui, .sys, .drv.
All the information in a PE file is displayed in chunks of related data. Most of these displays relate to specific parts of a PE file. Some of these displays are synthesised to provide you with additional data that is not so readily available from the PE file (for example, the Additional Information, .Net Information and debugging symbols panels).
No more digging around trying to determine if a DLL is built with .Net, and, if so, which version of the CLR is required. That information is displayed in the .Net Information section.
Does the EXE depend on XYZ.DLL? Look at the All Dependent Modules section to find out.
Which functions from the Windows API does the DLL use? Look at the Imported Modules and Functions section to find out.
Are functions exported from this DLL actually implemented in another DLL? Look at the Exported Functions section, examining the Forwarded Functions column.
This section displays PE file header information.
Information from the PE optional header.
Information from the PE optional header directories.
For each directory we display
Information about the module entry point and the type of application.
Information about .Net and the processors this .Net executable will run on.
Information about .Net Framework and the .Net entry point.
Information about .Net MetaData.
The modules the DLL imports and the functions imported from those modules.
The delay-loaded modules the DLL imports and the functions imported from those modules.
All the modules the DLL imports. Any missing DLLs will be displayed in red.
The functions imported from other DLLs.
The exported functions for other DLLs to use.
The Forwarded Function column indicates if a different DLL actually implements the function.
The sections that are contained within the DLL. For example: data, relocation, resource, code.
The different readable, readable and writeable, and executable areas in the DLL.
Information about Frame Pointer Omission usage in the DLL.
Information about the table-based exception handling mechanism used by x64 executables. The data displayed are RUNTIME_FUNCTION data.
This information panel is only displayed for 64 bit executables.
Information from the version resource.
Information from the DLL manifest.
Information about the digital signatures for the DLL.
Information about thread local storage for the DLL.
Malicious binaries often use thread local storage as a means to inject code into a target application, with a view to gaining elevated privileges on the computer system. You can check the module to see if it has any Thread Local Storage.
Thread Local Storage is not necessarily malicious, but if you find a module that you think has been tampered with and it has Thread Local Storage that may be of interest.
Information about resources stored in the DLL.
Debugging symbols from the DLL’s PDB file.
COFF Debugging symbols for the DLL.
CodeView Debugging symbols for the DLL.
STABS Debugging symbols for the DLL.
Miscellaneous debug data for the DLL.