Using the Imports Node
Nearly every Windows executable imports something from some other executable (with the exception of NTDLL and resource-only DLLs). And, as you can tell by glancing at PEBrowse's Index, it is fairly easy to see what is being imported from where. But would it not be nice if you could find out quickly where a particular imported API is being used, for example, EnterCriticalSection from KERNEL32? Expand the node with the text, "Imports", followed by the one containing, "KERNEL32.DLL", and search for the "EnterCriticalSection" entry. Then, select View/References from the main menu (or References from the Index popup menu), and you will now see Figure 10. Double-clicking on any of the items will give you immediate access to how the API, EnterCriticalSection, is being called -- this is our 7th entry-point.
Figure 10
View/Reloc References Is For DLLs Only
Another item in the View menu provides the 8th entry-point, but only if the module you are examining is a DLL. One of the traumatic events a DLL can experience when it first is loaded is that its preferred loading address has already been occupied from an earlier DLL load or a memory allocation. When this happens, the DLL will be loaded at a different image base address and all of the internal references within the DLL must be adjusted or "relocated" for the references to be valid. Looking at the Index for MSSCRIPT.OCX and expanding the "Optional Header" node, we will find a node with the text "Base Relocations." Select Structure from the popup menu to open and display the contents of the relocation table for MSSCRIPT.OCX. Each of the items in the display represents an adjustment point -- the "RVA" column a location that references an address in the "Contents" column that must be changed. If you think about it for a moment, this provides another cross-reference list to valid entry-points; this can be seen in Figure 11.
Figure 11
Of course, if you do not have access to valid debug symbols, the display becomes just a sorted list of addresses, but you can still confidently examine any of the items in the list with the knowledge that these represent valid addresses in the module. One more thought -- this view and the previously discussed entry-point type would overlap quite a bit, especially when the reference represents an address to an external routine, for example:
__imp_RtlInitUnicodeString
But, by combining this and the import view, you can pick up additional references to external modules when they appear as the following fragment from ADVAPI32 illustrates:
0x77E0C92B: MOV ESI,DWORD PTR [NTDLL.DLL!RtlInitUnicodeString]; (0x77DD138C) 0x77E0C93D: CALL ESI 0x77E0C946: CALL ESI
The relocation table would contain a reference to the move statement; disassembling at this point and carefully examining the statements that would follow would tell you that the call statements are for RtlInitUnicodeString.
 prev page | 1st page | next page  |