I have an application that I am auditing that runs code from an imported DLL. Said DLL itself has imports. Specifically, during execution there's a point where the following is called (EIP is in said DLL):68DC6648:    jmp dword ptr ds:[68DD21C8h]68DC664E:    nop68DC664f:    nopI performed disasm /all /disasm X:\path\to\dll\myDll.dllOn the DLL in an attempt to determine where [68DD21C8] goes to. Mosdef appears as though it is a part of a thunk table for relocations or IAT. My assumption sppears to be correct, as I find [68DD21C8] under the .reloc header under a section called BASE RELOCATIONS:BASE RELOCATIONS #4...    ...        ...6000 RVA,    10C SizeOfBlock...    ...        ...64A    HIGHLOW    68DD21C8The preferred image base is:68DC0000 image base (68DC0000 to 68DD7FFFF)Also, the DLL entrypoint appears to be 68DC1000. My question is: how do I determine the memory address for [68DD21C8] and its relative code/disassembly?I tried baseaddr + RVA + ordinal to get:68DC0000 + 6000 + 64A == 68DC664AHowever, it falls within range of my disassembled code. In my disassembly from dumpbin, 68DC664A isn't a valid address and would lie between the previously stated thunk!68DC6648:    jmp dword ptr ds:[68DD21C8h] ;<--contains 68DC664A!!!68DC664E:    nop68DC664f:    nopI double checked I have my maths right and searched around, found this previous answer on stack exchange, but it only verified my math above was correct
Dumpbin: Correlating thunk jumps in .reloc to disassembly
disassembly;debugging;pe
If you have set a proper _NT_SYMBOL_PATH dumpbin uses the symbols if they exist and provide you a name of the import instead of hexthe example below shows alls that have resolved names instead of hex for  windows calc.exeC:\>dumpbin /disasm c:\WINDOWS\system32\calc.exe | grep -i jmp.*\[  01004A9B: FF 24 85 FA 50 00  jmp         dword ptr [eax*4+10050FAh]  01007BC8: FF 25 7C 10 00 01  jmp         dword ptr [__imp__LocalFree@4]  0101263C: FF 25 BC 11 00 01  jmp         dword ptr [__imp____CxxFrameHandler]  01012670: FF 25 C0 11 00 01  jmp         dword ptr [__imp___CxxThrowException@8]  010127A4: FF 25 E4 11 00 01  jmp         dword ptr [__imp___XcptFilter]in case there are no symbols C:\>dumpbin /disasm c:\usedll.exe | grep -i jmp.*\[  0040106E: FF 25 0C 20 40 00  jmp         dword ptr ds:[0040200Ch]  00401074: FF 25 00 20 40 00  jmp         dword ptr ds:[00402000h]  0040107A: FF 25 04 20 40 00  jmp         dword ptr ds:[00402004h]  00401080: FF 25 08 20 40 00  jmp         dword ptr ds:[00402008h]  00401086: FF 25 14 20 40 00  jmp         dword ptr ds:[00402014h]you can view the raw data at the address (if it is an imported address it would be an unresolved first thunk ) windows loader fills it when it is loading the exe dump bin does not resolve itC:\>dumpbin /RAWDATA:4,6 c:\usedll.exe | grep 402000  00402000: 00002082 00002090 000020A2 00002074 00000000 000020C0to resolve this manually you should parse the import table 00002082 will point to an import 00002090 will point to another import in x.dll etc 00000000 is a seperator 20c0 will point to an import in y.dll and so on name of x.dll , y.dll z.dll will also be the part of import table here is a complete import table of a non symbol exe C:\>dumpbin /RAWDATA:4 c:\usedll.exe | grep -A 14 402000  00402000: 00002082 00002090 000020A2 00002074  . ... .. ..t ..  00402010: 00000000 000020C0 00000000 00002058  .... ......X ..  00402020: 00000000 00000000 000020B2 00002000  ........ ... ..  00402030: 0000206C 00000000 00000000 000020CE  l .......... ..  00402040: 00002014 00000000 00000000 00000000  . ..............  00402050: 00000000 00000000 00002082 00002090  ......... ... ..  00402060: 000020A2 00002074 00000000 000020C0   ..t ...... ..  00402070: 00000000 78450075 72507469 7365636F  ....u.ExitProces  00402080: 00A20073 65657246 7262694C 00797261  s..FreeLibrary.  00402090: 65470129 6F725074 64644163 73736572  ).GetProcAddress  004020A0: 01A90000 64616F4C 7262694C 41797261  ...LoadLibraryA  004020B0: 454B0000 4C454E52 642E3233 00006C6C  ..KERNEL32.dll..  004020C0: 654D01BB 67617373 786F4265 53550041  .MessageBoxA.US  004020D0: 32335245 6C6C642E 00 00              ER32.dll..you can observe 20b2 and 20ce pointing to kernel32.dll and user32.dll respectivelyedit the  address in your query does not point to an import table it is part of reloc or a fixupfixups do not jump between modules they fall within the module being examined   C:\>dumpbin /RELOCATIONS c:\WINDOWS\system32\kernel32.dll | head -n 11 | tail -3BASE RELOCATIONS #4    1000 RVA,       70 SizeOfBlock     62C  HIGHLOW            7C810B50C:\>dumpbin /Rawdata:4 c:\WINDOWS\system32\kernel32.dll | grep -i 7c801620  7C801620: 00000000 90909090 68146A90 7C810B50  .........j.hP..|notice 7c810b50  if the dll is loaded in preferred imagebase this wont changeif the image base is changed loader will find the dword at imagebase+rva+offset subtract the preferred imagebase and add the new imagebase to that result andpatch the dword to point to correct location suppose the preferrred imagebase of 7c800000 wasn't available and dll was loaded at 7d800000 loader will fetch the dword 7c810b50 at 7d80162c subtract 7c800000 from it result = 10b50 add 7d800000 and patch 7c810b50 to 7d810b50 in the queryyou say 68DC6648:    jmp dword ptr ds:[68DD21C8h] ;<--contains 68DC664A!!!that means it is jumping to the middle of the opcode disassembling 68dc66fa you get xxxxx       68 DC664A90     PUSH    904A66DCxxxxx       90              NOPyou may need something better than dumpbin to deal with obfuscation editregarding your comment about import parsing no the offsets have nothing to do with base + rva + xxxthey do not point to any remote module no reference to any import module address exist in the importing module(just take a step back and think what would happen if the dll in the importtable was rebased ?? where the exe is going to look for ?? get the idea??)   in the import  table pasted above  2082,2090,20a2,2074 points to 4 imports from first dll20c0 points to 1 import from second dll  this is firstthunk that will be replaced by the loader with actual import addressimport table is denoted in pe header->optinal header->datadir[1]0:000> dt ntdll!_IMAGE_NT_HEADERS -y opt.datadi[1]. 4000b0   +0x018 OptionalHeader :       +0x060 DataDirectory  : [1]          +0x000 VirtualAddress : 0x201c         +0x004 Size           : 0x3csee 201c and size 3c that is 15 dwords see below for splituptypedef struct _IMAGE_IMPORT_DESCRIPTOR {  union   {    DWORD   Characteristics;    DWORD   OriginalFirstThunk;   <-----00002058,0000206c,00000000  } DUMMYUNIONNAME;  DWORD   TimeDateStamp;    <-----------00000000,00000000,00000000  DWORD   ForwarderChain;   <-----------00000000,00000000,00000000  DWORD   Name;             <-----------000020b2,000020ce,00000000   DWORD   FirstThunk;       <-----------00002000,00002014,00000000} IMAGE_IMPORT_DESCRIPTOR;the last is a null entry that means 5 dwords that are 00000000the original firstthunk a copy of first thunk stays as it is the orignal first thunk gets modified by loader loader loads the specified dll using an internal function of LoadLibrary()--->LdrLoadDll() and uses an internal api of GetProcAddress  to fetch the importAddress and patches the OriignalFirstThunk  the module being examined has no inkling about the addresses you cant manually calculate anything about a remote dll import from import table 