Don't rely on the IAT entry in the PE Data Directory to be accurate. The only truly accurate way to find the IAT(s) is to find actual calls from the disassembled code to statically imported API functions.
Let's use the following code in IDA as an example:
FF 15 44 60 03 01 call ds:GetVersion
The actual disassembly of FF 15 44 60 03 01 is call dword ...
Dependency Walker is your friend.
Note that it's almost impossible to find out which libraries/entry points a program uses by static analysis alone, since the strings passed to LoadLibrary and GetProcAddress might be obfuscated, i.e. not visible in the binary. Dependency Walker catches those calls at runtime, which means a) you need to run the program - ...
I didn't completely understood what is IAT, any help will be great :-)
The IAT is the Import Address Table. It's an an array of pointers to statically-imported API function addresses. The IAT entries gets populated at runtime.
The format of the IAT is typically as follows, with all functions from a particular DLL grouped together, with a null-pointer ...
When the loader resolves the imports, then how does it know which
functions to look for?
It parses the Import Table. For each entry, it parses the DLL name and associated function names and/or function ordinals.
For some reason the IAT (FirstThunk) is magically filled with
addresses even before system load, not function names. Why is that?
It's for ...
if we're already at the OEP, it must mean the program is ready to roll
because the unpacking stub has repaired the import table already
No, by the time the OEP is reached, the unpacking stub has populated the Import Address Table; it hasn't repaired the Import Table. You need to reconstruct the Import Table so that when you run the unpacked program, the ...
You need to get familiar with PE Import Table
In a nutshell (I will not mention about import by ordinal)
IMAGE_IMPORT_DESCRIPTOR.FirstThunk points to IMAGE_IMPORT_BY_NAME table.
Import REConstructor detected thunks for 2 different DLLs (combase.dll and ole32.dll) without a 0x00000000 separator entry between the thunks. This is because one of these DLLs (ole32.dll) exports functions that are forwarded to the other DLL (combase.dll).
Import REConstructor needs all adjacent thunks (without a 0x00000000 in between them) to be from the ...
The unpacking stub may just load the imports instead of repairing the import table. If you want to save the executable to be able to run it later, you won't have the unpacking stub in your saved executable, so noone loads the imports for you unless you repair and the import table as well.
Note: only applicable if reading the PE from disk
You could simplify your code if you used pefile rather than Python ctypes. Here's a quick script for getting the hex address of some API name.
pe = pefile.PE(f)
print 'could not load file...exiting'
ep = pe.OPTIONAL_HEADER.AddressOfEntryPoint
It is just a coincidence. It happens sometimes that the value in a register be the address of some valid api which the application has nothing to do about. For reference see these images.
I have loaded OllyDbg2 in OllyDbg2. OllyDbg2 does not import kernel32.dll::BaseThreadInitThunk
Ollydbg in Windows 7
Ollydbg in Windows XP
In Windows 7 on entrypoint the ...
You need to rebuilt the Import Table for your program to work correctly on other systems.
Basic steps to unpacking:
Trace to the Original Entry Point
Dump the memory
Rebuild the Import Table with a tool such as Import REConstructor and change the PE's Entry Point value to the Original Entry Point's RVA
While in debugger, select the import table and run idc\renimp.idc.
Top comment from the file:
This script renames entries of a dynamically built import table.
For example, from a table like this:
dd offset ntdll_NtPowerInformation
dd offset ntdll_NtInitiatePowerAction
dd offset ntdll_NtSetThreadExecutionState
the pointer you are pointing to in your screen shot contains ascii strings
do the app use some dll like BCMenu or Windows Classic Theme etc
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 42 43 4D 65 6E 75 00 00 57 69 6E 64 6F 77 73 20 BCMenu..Windows
00000010 43 6C 61 73 73 69 63 2E 74 68 65 6D 65 Classic.theme
During debugging, you can use names in format "DllName_export" (e.g. kernel32_CreateFileA) to jump to functions exported by the loaded DLLs, or you can use such names in "symbolic breakpoints" so they're automatically added when DLL gets loaded.
Also: double-click a DLL in the Modules list to see its exports and jump to/set breakpoints on them.
It appears you've already guessed what the actual issue is - your call instruction is using direct addressing and not relative addressing. This means that when a DLL changes it's location between executions you're still trying to execute the same absolute value, resulting in different types of errors depending on the content of the actual content in that ...
In your example, the static import user32!DefWindowProcA is getting forwarded to ntdll!NtdllDefWindowProc_A.
You need to double-click on the ntdll!NtdllDefWindowProc_A entry in Import REConstructor and change it to user32!DefWindowProcA.
Import REConstructor rebuilds the Import Table, not the Import Address Table.
If you want to verify that Import REConstructor worked correctly, you'd be better off examining the resulting EXE with an Import Table tool such as Dependency Walker. There's no point in examining the resulting EXE (once it's loaded) with Import REConstructor because its displayed ...
upx - d didnt work ? for some, when rebuilding the import can be a forwarded import, which sometimes doesnt resolve correctly, this happened a lot in cracks made on vista and higher (typically the SetLastError api)