File + Process Imports/Exports Information UDFs

Image and video hosting by TinyPic
Image and video hosting by TinyPic
Forwarder String Support, C++ Name Undecorating Added!!
(see an extreme case of string forwarding below)

This UDF gets Function Imports and Exports for any Windows PE file (.DLL, .EXE),  both 32-bit and 64-bit (unlike most programs out there), and from either a 32-bit or 64-bit Process.

I created this due to my frustration with other programs either working only *some* of the time, or having a common inability to read PE32+ (x64) file format tables properly.

There's just two functions in the main UDF - _FileGetWinPEImports or _FileGetWinPEExports.  The bundled TestImportExportsList program lets you explore files on your system.
 *Newly included are: _ProcessGetWinPEImports, _ProcessGetWinPEExports and TestProcessImportExportsList program (requires my Process Functions UDF).

NOTE: *Compressed* executable files will only give the Import information for the 'decompressor'. The only way to get the compressed executable's Import information is to decompress the executable.

Anyway, enjoy my hard work. Either read on for more information about some of the features, or see below for the License agreement and  Download link.

Information on 'Virtual Offset of Thunk':
These address offsets you see are offsets from the base of the .DLL or .EXE file (uncompressed only!), where the actual function location of an 'Import' gets placed.  All calls to these functions load addresses from these Thunk locations in order to correctly place a call to the right DLL function.  (This is totally different than the old Import fixup location lists of earlier pre-NT systems).  Technically, you could overwrite these Thunks with addresses to your own functions, but this is a dangerous thing to do.  Its a neat tool to have though.

Forwarder functions?  An explanation:

The whole 'DLLNAME.Functionname' string might be confusing to you, but here's an explanation of why an address can not and should not be returned. To better understand all this, grab a copy of DLL Export Viewer, (which doesn't report Relative/Function addresses correctly for Forwarded functions) and then follow along:

Okay, open up DLL Export Viewer and look at (for this example) KERNEL32.DLL - lets pick 'HeapFree', a known Forwarded function. DLL Export Viewer reports the following (on XP SP3):
Relative Address: 0x0000910c, 'Loaded' address: 0x7c80910c.  *Neither* is the case, though - 0x0000910c is in fact just the virtual address of the forwarder string!

Now, with my Exports function, you'll find that 'HeapFree' is reported (correctly) as a Forwarder string.  What you'll see then is 'NTDLL.RtlFreeHeap'.  What does that mean?  It means that:
  1. HeapFree is not a part of KERNEL32.DLL (and hasn't been for a while), 
  2. When that function is called or the address retrieved via 'GetProcAddress', the function 'RtlFreeHeap' in NTDLL.DLL is the function that's actually called (or returned as an address).  Hopefully the 'DLLNAME.FunctionName' structure of a Forwarder string is starting to make sense now? 
  3. The address you get when you do 'GetProcAddress' does *not* correspond to what you see in DLL Export Viewer - in fact, 'HeapFree's reported address lies entirely OUTSIDE of kernel32.dll's memory space - pointing instead inside of NTDLL.DLL, at (guess what?):  RtlFreeHeap.
So, on XP SP3, looking up 'HeapFree' with GetProcAddress, you get: 0x7C90FF2D.  Doesn't match what was reported with DLL Export Viewer AT ALL.  However - go back, and now look at NTDLL.DLL with DLL Export Viewer, and at function 'RtlFreeHeap' (following the logic of the Forwarder Function string).  What is reported for RtlFreeHeap? Relative Address: 0x0000ff2d, 'Loaded' address: 0x7c90ff2d.  See now how it lines up with what was reported via GetProcAddress for 'HeapFree' in KERNEL32.DLL?

So, there you have it in a nutshell - Forwarder functions are functions 'rerouted' to another DLL.  The DLL's that are being rerouted to are either:
  • A.) Pre-loaded by the system (Important DLL's like NTDLL.DLL, KERNEL32.DLL, USER32.DLL, GDI32.DLL, etc - are all permanently loaded)
  • B.) Loaded upon a program's execution if the function is in its 'Imports' list, or
  • C.) Loaded upon a call to GetProcAddress. To see how this works clearly, list the modules that are loaded (my Process Functions UDF GUI can do this for you), then call GetProcAddress for 'GetServiceW' from WSOCK32.DLL, and then re-list the modules again.  You'll see a new module loaded up - MSWSOCK.DLL (the location of the forwarder function). Wa-la, forwarder is set up.

Extreme Forwarder String Example!

Image and video hosting by TinyPic

Ascend4nt's AutoIT Code License agreement:
While I provide this source code freely, if you do use the code in your projects, all I ask is that:
  1. If you provide source, keep the header as I have put it, OR, if you expand it, then at least acknowledge me as the original author, and any other authors I credit
  2. If the program is released, acknowledge me in your credits (it doesn't have to state which functions came from me, though  again if the source is provided - see #1)
  3. The source on it's own (as opposed to part of a project) can not be posted unless a link to the page(s) where the code were retrieved from is provided and a message stating that the latest updates will be available on the page(s) linked to.
  4. Pieces of the code can however be discussed on the threads where Ascend4nt has posted the code without worrying about further linking.


  • C++ Function Name Undecorating/Unmangling option.  For an example of what this causes function name results to be, check out something like 'msvcrt.dll'.  It will report alot more than just a function name!  If you choose to do the Undecorating yourself, just call the included function _WinAPI_UndecorateName().
    Example: "??3@YAXPAX@Z" becomes "void __cdecl operator delete(void *)" unmanged/undecorated
  • New _ProcessGetWinPEImportExports module (with Test program) as a separate download - requires use of my Process Functions UDF.  The biggest benefits, besides looking into loaded DLL's that might not be on the disk?  Addresses reported are real, and Imported function addresses are reported (as pulled from Thunk locations).
  • Oops, Big-time logic errors in mapping Export function names to addresses and using ordinals to look them up from pointer tables.  Now everything points to where it should!
  • Ordinal #'s are now correctly calculated with the 'Base' # part of the EXPORT DIRECTORY TABLE.
  • 'Forwarder' string lookup & reporting!  Not even DLL Export Viewer does this!  Basically, certain function 'pointers' aren't really code offsets, but offsets to Forwarder strings.  My function looks those strings up and puts them in the list instead of a phoney address.
  • Executables linked with Borland's TLINK32.exe do not set the 'ImportLookupTableRVA' element correctly.  This was easy to work around, as the 'Thunks' list also contains pointers to the same information (until an executable/DLL is loaded by the O/S, at least)
  • Imports: Extra column: Virtual Offset of Thunk ( [3] ).  When an .EXE or .DLL is loaded, this is the Offset from the base of the .EXE or .DLL which will hold the actual function address.  This could be used for redirection of calls (dangerous though!).
    An important note on this: Compressed executables are a completely different beast, and in fact the whole Import section is for the Decompressor itself, which disappears once the executable is loaded!  The only way to get the actual Imports for Compressed Executables is to Decompress them first.

D4n Centient,
Jul 21, 2010, 12:48 PM
D4n Centient,
Jul 21, 2010, 12:49 PM