Is "IMPORT ADDRESS TABLE" of PE per dll or per exe? - windows

Does anyone know whether the 'import address table' in the PE executable format on Windows is 'per dll' or 'per exe'?

Any PE can have an import address table, so both DLLs and EXEs can have them. This makes sense since both can have dependencies (imports) on other binaries. Unless you're doing dynamic loading (LoadLibrary/GetProcAddress), you'll have an import address table when calling into another module.
You can use the dumpbin utility with Visual Studio to see the imports of a PE:
An example on user32.dll:
C:\Windows\System32> dumpbin /imports
user32.dll
Microsoft (R) COFF/PE
Dumper Version 10.00.30319.01
Copyright (C) Microsoft Corporation.
All rights reserved.
Dump of file user32.dll
File Type: DLL
Section contains the following
imports:
ntdll.dll
7DC60000 Import Address Table
7DCCACEC Import Name Table
0 time date stamp
0 Index of first forwarder reference
15A NtOpenKey
7A9 wcscat_s
7AD wcscpy_s
...
...and for notepad.exe...
C:\Windows\System32> dumpbin /imports
notepad.exe
Microsoft (R) COFF/PE
Dumper Version 10.00.30319.01
Copyright (C) Microsoft Corporation.
All rights reserved.
Dump of file notepad.exe
File Type: EXECUTABLE IMAGE
Section contains the following
imports:
ADVAPI32.dll
1001000 Import Address Table
100A234 Import Name Table
FFFFFFFF time date stamp
FFFFFFFF Index of first forwarder reference
77C71C82 27E RegSetValueExW
77C7BCD5 26E RegQueryValueExW
77C7BED4 230 RegCloseKey
...

Short answer:
IAT(Import Address Table) is per PE file(dll and exe).
Long answer:
When the loader load exe file its copy each section of the PE to the process memory, unless IMAGE_SCN_MEM_DISCARDABLE is set for this sections. The IAT is in the .idata section (msdn):
The PE file's .idata section contains the information necessary for the loader to determine the addresses of the target functions and patch them into the executable image. The .idata section (or import table, as I prefer to call it) ...
IMAGE_SCN_MEM_DISCARDABLE is not set for idata section. Therefore- idata section copied to memory, and both exe and dll have this section- meaning IAT is per PE.
I wrote a simple dll loader here, if it help you understand.

Related

Analysis of dll

Is it possible to examine a dll, not installed in the registry, to see if it an ActiveX, the public methods, if it supports COM, etc. Is there some other tool with which to analyze a dll?
That's a very generic question, but you can analyze a dll's exported methods and ASM code using some decompiler/debugger like OllyDbg. Of course you need to have a good understanding of ASM and Windows inner workings.
http://www.ollydbg.de/version2.html
if you have Visual Studio and just want to know if the dll contains a COM component, you can open the visual studio command prompt, and use:
dumpbin /exports filename.dll
to show the dll's exported functions. If the dll exports DllGetClassObject, DllRegisterServer and DllUnregisterServer, it contains a COM component.
Example:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>dumpbin /exports c:\windows\system32\quartz.dll
Microsoft (R) COFF/PE Dumper Version 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file c:\windows\system32\quartz.dll
File Type: DLL
Section contains the following exports for QUARTZ.dll
00000000 characteristics
5215E909 time date stamp Thu Aug 22 12:33:45 2013
0.00 version
1 ordinal base
8 number of functions
8 number of names
ordinal hint RVA name
1 0 0003B34C AMGetErrorTextA
2 1 0003B41C AMGetErrorTextW
3 2 0003B2C8 AmpFactorToDB
4 3 0003B314 DBToAmpFactor
5 4 00002848 DllCanUnloadNow
6 5 000032E0 DllGetClassObject
7 6 0003AFA0 DllRegisterServer
8 7 0003B2A0 DllUnregisterServer
Summary
36000 .data
4000 .idata
F000 .pdata
4000 .reloc
B000 .rsrc
157000 .text
1000 RT_CODE

How to disassembly my driver?

I am trying kernel debugging using vmware and windbg.I have connected two OS and all symbols are loaded successfully.If I want to see my driver in memory how can I disassembly that?
I have tried lm commands and lmvm commands
kd> lmvm comint32
start end module name
88da9000 88daf000 comint32 (private pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\comint32.pdb\653387D894B4412FA9E30659E58DD47C1\comint32.pdb
Loaded symbol image file: comint32.sys
Image path: \SystemRoot\System32\Drivers\comint32.sys
Image name: comint32.sys
Timestamp: Thu Apr 11 20:10:55 2013 (51677B3F)
CheckSum: 0000CACF
ImageSize: 00006000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
x comint32!* should dump all the symbols of the module along with their addresses in memory.
You can then either use the u command (with the name (e.g. comint32!DriverEntry) or the address of a function as a parameter) to disassemble into the main window or you can open the disassembly window and paste the name/address into it and browse the disassembled code there.
See your windbg reference for further details.

How to determine RVA of AddressOfEntryPoint from PE Headers Using Dumpbin

I have been scouring the web trying to find an answer to this question, but it seems to be eluding me. I have consulting the following sources before asking this question.
http://www.csn.ul.ie/~caolan/publink/winresdump/winresdump/doc/pefile.html
http://msdn.microsoft.com/en-us/magazine/cc301805.aspx
I understand the PE format (or at least I think I do). Using the command-line debugger (cdb), I would like to be able to disassemble the address where the RVA is to see what the first call is. For a native application (like Notepad), I would expect to see notepad!WinMainCRTStartup, and for a .NET application, I would expect to see a jmp command to the CLR.
Using Notepad as an example, I executed dumpbin /headers on it, and got a value of 3570 for the entry point. When I execute cdb notepad and perform this command - u [base address in memory]+0x3570 - I do not get the WinMainCRTStartup call.
Am I misinterpreting the PE output from dumpbin? How can I know exactly where to look in memory for the starting function of an application?
Edit (1/7/13): I forgot to mention that I am running this on 64-bit Windows 7. If I try to use cdb in Windows XP Mode (to get results from a 32-bit OS), disassembling the AddressOfEntryPoint that I get from an analysis of the PE file gets me the call to WinMainCRTStartup as I would expect. In other words, the exact address I am told to look at contains what I think it should in a 32-bit OS. Does running the application on a 64-bit machine truly make that much of a difference?
Just to add complexity, if I do a !dh on the ImageBaseAddress in the 64-bit OS in cdb, I get the EXACT AddressOfEntryPoint that I need to use.
Use the Microsoft Symbol Server to obtain symbol debugging information. http://support.microsoft.com/kb/311503/en-us
0:001> !dh -a notepad
....
3689 address of entry point
...
00ac0000 image base
...
0:001> u ac3689
notepad!WinMainCRTStartup:
Edit: add dumpbin output (entry point the same offset, image base may be different because ASLR works when image loads in memory):
Microsoft (R) COFF/PE Dumper Version 11.00.50727.1
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file c:\windows\notepad.exe
PE signature found
File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
14C machine (x86)
4 number of sections
4A5BC60F time date stamp Tue Jul 14 03:41:03 2009
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
102 characteristics
Executable
32 bit word machine
OPTIONAL HEADER VALUES
10B magic # (PE32)
9.00 linker version
A800 size of code
22400 size of initialized data
0 size of uninitialized data
3689 entry point (01003689) _WinMainCRTStartup
Edit 2 add output for x64
dumpbin:
Microsoft (R) COFF/PE Dumper Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file c:\windows\notepad.exe
PE signature found
File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
8664 machine (x64)
6 number of sections
4A5BC9B3 time date stamp Tue Jul 14 03:56:35 2009
0 file pointer to symbol table
0 number of symbols
F0 size of optional header
22 characteristics
Executable
Application can handle large (>2GB) addresses
OPTIONAL HEADER VALUES
20B magic # (PE32+)
9.00 linker version
A800 size of code
25800 size of initialized data
0 size of uninitialized data
3570 entry point (0000000100003570) WinMainCRTStartup
windbg:
0:000> !dh -a notepad
File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
8664 machine (X64)
...
1000 base of code
----- new -----
00000000ff0c0000 image base
...
0:000> u ff0c0000+3570
notepad!WinMainCRTStartup:

Does the NT DLL Loader load DLLs in the order of the import section of the executable?

If you have an executable on Windows, you can view its import section with the DUMPBIN utility (included e.g. in Visual Studio).
To get a list of all imported DLLs you can run something like this (just an arbitrary example):
C:\Programme\GIMP-2.0\bin>dumpbin /IMPORTS gimp-2.4.exe | grep -i \.dll
libgimpcolor-2.0-0.dll
libgimpmath-2.0-0.dll
libgimpmodule-2.0-0.dll
libgimpthumb-2.0-0.dll
libgimpwidgets-2.0-0.dll
libart_lgpl_2-2.dll
libfontconfig-1.dll
freetype6.dll
libgdk-win32-2.0-0.dll
libgdk_pixbuf-2.0-0.dll
libglib-2.0-0.dll
libgobject-2.0-0.dll
libgthread-2.0-0.dll
libgtk-win32-2.0-0.dll
intl.dll
libpango-1.0-0.dll
libpangoft2-1.0-0.dll
libgimpbase-2.0-0.dll
libgimpconfig-2.0-0.dll
KERNEL32.dll
msvcrt.dll
msvcrt.dll
USER32.dll
I have now speculated in another question that, for independent DLLs the Loader (the component that maps the DLLs into the address space and calls their DllMain function) will load the DLLs in the order in which they appear in the import section.
Note: This can obviously only apply to independent DLLs because the loader will have to resolve dependencies so any DLL that is dependent on any other will always be loader after the other. So this question can only apply to independent (non-system) DLLs.
To stay with my (arbitrarily chosen) example above,
C:\Programme\GIMP-2.0\bin>dumpbin /IMPORTS libgimpcolor-2.0-0.dll | grep -i \.dll
Dump of file libgimpcolor-2.0-0.dll
libglib-2.0-0.dll
libgobject-2.0-0.dll
msvcrt.dll
C:\Programme\GIMP-2.0\bin>dumpbin /IMPORTS libgimpmath-2.0-0.dll | grep -i \.dll
Dump of file libgimpmath-2.0-0.dll
libglib-2.0-0.dll
libgobject-2.0-0.dll
msvcrt.dll
C:\Programme\GIMP-2.0\bin>dumpbin /IMPORTS libgobject-2.0-0.dll | grep -i \.dll
Dump of file libgobject-2.0-0.dll
libglib-2.0-0.dll
KERNEL32.dll
msvcrt.dll
C:\Programme\GIMP-2.0\bin>dumpbin /IMPORTS libglib-2.0-0.dll | grep -i \.dll
Dump of file libglib-2.0-0.dll
iconv.dll
intl.dll
ADVAPI32.DLL
KERNEL32.dll
msvcrt.dll
msvcrt.dll
OLE32.dll
SHELL32.DLL
USER32.dll
WS2_32.DLL
libgimpmath and libgimpcolor are independent DLLs in that sense. So here the question would be: Will the Loader always load libgimpcolor before libgimpmath because it comes first in the import section?
For independent DLLs, the load order is indeed the same as the order of the IAT.
From Michael Grier's MSDN Blog
The implementation is linear/sequential. Therefore even the order of the imports in your static import tables matters. [...] If the linker for some reason reverses the order of the static imports, you'll see the opposite.

!heap failed. Invalid type information for ntdll!_HEAP_ENTRY

I'm trying to dump heap information from full dump memory file sitting on Windows Server 2003 SP2 x86. Dump was created for 32-bit mixed (native/clr) application which was running on Windows Server 2003 SP2 x64 machine.
From the following windbg log I understand that loaded ntdll.dll image is incorrect and does not correspond to ntdll.pdb symbols. I have tried to specify the location to ntdll.dll from the target machine but windbg still shows that the module is loaded from the standard location (c:\windows\system32).
What did I do wrong? How to force windbg to load correct version of ntdll?
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.
[ ... skipped ... ]
0:042> vertarget
Windows Server 2003 Version 3790 (Service Pack 2) MP (4 procs) Free x86 compatible
Product: Server, suite: TerminalServer SingleUserTS
kernel32.dll version: 5.2.3790.4480 (srv03_sp2_gdr.090321-1244)
Machine Name:
Debug session time: Wed Mar 16 16:36:10.000 2011 (GMT-5)
System Uptime: 17 days 10:34:26.068
Process Uptime: 1 days 15:19:14.000
Kernel time: 0 days 1:24:01.000
User time: 0 days 22:07:58.000
0:042> .sympath
Symbol search path is: C:\mscordacwks\v2.0.50727.3615;C:\__exe;SRV*C\Symbols*http://referencesource.microsoft.com/symbols;SRV*c:\Symbols*http://msdl.microsoft.com/download/symbols;SRV*C:\Symbols*http://source.msdn.microsoft.com/symbols
0:042> .exepath
Executable image search path is: C:\__exe;C:\__target\Windows\SysWOW64;
0:042> .reload
[ ... skipped ... ]
0:042> .reload /u ntdll.dll
Unloaded ntdll.dll
0:042> .reload /v /f ntdll.dll
AddImage: C:\WINDOWS\system32\ntdll.dll // why is it still c:\windows\system32
DllBase = 7d600000
Size = 000f0000
Checksum = 000c371a
TimeDateStamp = 4cc1831e
0:042> lm
[ ... skipped ... ]
7d600000 7d6f0000 ntdll (pdb symbols) c:\symbols\wntdll.pdb\9ED8E09C6723448380648C4456726AEF2\wntdll.pdb
0:042> !heap
*************************************************************************
*** Your debugger is not using the correct symbols ***
[ ... skipped ... ]
*** Type referenced: ntdll!_HEAP_ENTRY ***
*************************************************************************
Invalid type information
0:042> lmi vm ntdll
start end module name
7d600000 7d6f0000 ntdll (pdb symbols) ntdll.dll
Symbol file: c:\symbols\wntdll.pdb\9ED8E09C6723448380648C4456726AEF2\wntdll.pdb
Image path: C:\WINDOWS\system32\ntdll.dll
Image name: ntdll.dll
Timestamp: Fri Oct 22 07:27:10 2010 (4CC1831E)
CheckSum: 000C371A
ImageSize: 000F0000
File version: 5.2.3790.4789 // this is correct and
Product version: 5.2.3790.4789 // does correspond to target computer
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: MicrosoftR WindowsR Operating System
InternalName: ntdll.dll
OriginalFilename: ntdll.dll
ProductVersion: 5.2.3790.4789
FileVersion: 5.2.3790.4789 (srv03_sp2_gdr.101019-0340)
FileDescription: NT Layer DLL
LegalCopyright: c Microsoft Corporation. All rights reserved.
UPDATE:
I moved a little bit further in my issue. I managed to connect to the live process on the customers side and tried to
investigate heap (heap -s) there and basically I got the same result.
(1520.7c4): Wake debugger - code 80000007 (first chance)
eax=00000000 ebx=00327d50 ecx=00000000 edx=00000000 esi=0030b428 edi=002debe4
eip=7d61c876 esp=002df008 ebp=002df06c iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\ntdll.dll -
ntdll!ZwReadFile+0x15:
7d61c876 c22400 ret 24h
0:000> !heap -s
*************************************************************************
*** Your debugger is not using the correct symbols ***
*** [...skipped...] ***
*** Type referenced: ntdll!_HEAP_ENTRY ***
*************************************************************************
Invalid type information
0:000> .reload
Reloading current modules
................................................................
....................................
0:000> !heap -s
*************************************************************************
*** Your debugger is not using the correct symbols ***
*** [...skipped...] ***
*** Type referenced: ntdll!_HEAP_ENTRY ***
*************************************************************************
Invalid type information
I think I have a problem similar to one mentioned in this article http://support.microsoft.com/kb/959207.
Environment and problem seem to be the same but dll versions are different, so it is not the solution for me.
I think I have to escalate this problem to Microsoft.
Does anybody know where I should go with this question?
This could happen if dump was created with 64 bit tools. There is good information on Tess's blog that explains the reason why bitness of the dump matters.
The solution appears to be easy but not obvious.
I found a wntdll.pdb slightly bigger than mine which contains required symbols and reloaded it with command .reload /f /i ntdll.dll
and I take the previous build of windbg 6.11.0001.404, in the current one 6.12.0002.633 !heap command still does not work in my case.
It looks like the type _HEAP_ENTRY is not included in the pdb of 2003 SP2 ntdll.dll
Microsoft released a hotfix http://support.microsoft.com/kb/959207, but you seem to have a later ntdll version.

Resources