In a typical, non-packed Windows PE executable, the header contains metadata that describes to the operating system which symbols from other libraries that the executable depends upon. The operating system's loader is responsible for loading those libraries into memory (if they are not already loaded), and for placing the addresses of those imported symbols ...
I don't know if many people know this, but IDA uses some kind of a trick to decide if a segment is an imports segment, and handles it completely different.
IDA uses a few segment properties to treat a segment as an imports segment. for example, naming a segment .idata, or setting the segment's class to XTRN will immediately make it an imports segment. such ...
if adding an extra import section to the PE file is an acceptable option
use tools like iidking and add an import section with all the imports that are resolved dynamically
use add cross referances dialog or idc add_dref() to add cross references to them
code for demo
#pragma comment(lib , "...
If you can not add something to the imports viewer you can write your own.
Here is the simple example (it is slightly modified example referenced at this hexblog entry and located here with added double-click functionality, added columns, removed exports and fixed bug for a case of unknown origin of the imported function). See the function BuildImports for ...
But how does knowing OEP relate to IAT?
OEP does not relate to the IAT, but is used by import reconstruction tools to find the location of IAT-like structures created by the packer.
When application is unpacked in memory, can't we get pointer to IAT just by walking through PE header
This is exactly why import reconstruction is needed. Because the ...
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 ...
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.
I think there is something mixed up here.
But how does knowing OEP relate to IAT?
It does not (for benign software). However, the article you linked analyzes a packed executable. Often, malware tries to hide its imports my not using the official IAT, but by creating their own at runtime. The Tools should help you to reconstruction somewhat of a 'normal' ...
My guess would be that the packer/obfuscator does manual importing by scanning for dylibs in memory or maybe walking the dyld structures. The names in the import list are red herrings, and the fake imports are probably present only to ensure the loading of the required dylibs. you will have to analyze and/or debug the code to figure out how it really works.
I think this is too late but let's reply though.
By default ImpREC has "Use PE Header From Disk" enabled. Which means it will NOT use the relocated DLL imagebase. 2 options :
1 - Untick it in options and reselect your target
2 - Use a custom PE header with Advanced commands / Load PE Header
-> First choice is the best for your case.
Explaination : the ...
Different import reconstruction tools employ different heuristics in order to find the method used by the malware/packer because manually implemented import tables can be achieved in multiple different approaches (some without holding import tables at all).
Most import reconstruction tools usually have multiple heuristic choices, even. You can read about ...
I solved this by manually fixing each missing import API.
First I did a text dump of the unpacked dll using BinText where I found a list of imported API's.
I then compared it to the list of API detected by ImpRec and I noticed that the calls are in the same order on the text dump.
So I just double clicked the line of the invalid import on ImpRec and ...
i found a tool for unpacking UPX x64.exe it work for me.
it is called XVolkolak v0.22 i found it here: http://ntinfo.biz/index.html
its a universal tool so it can unpack other packers to.
Have a nice day.
AFAIK there is no existing tool but you should be able to create one using the approach used by DOS unpackers:
Run the binary once, dump it at the entry point
Run it second time, forcing the load base to be different (e.g. map some memory at the preferred load base, or reboot to reinitialize ASLR). Capture a second dump.
Compare two dumps. The locations ...
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
I have managed to implement a first attempt of a DLL, a DLL called WinAPI32.dll intended to import the entirety of the standard WinAPI and MSVC library from Windows 9x to Windows 10, and then export any custom functions and later data.
This will only load from a simple program, equally produced purely in assembly because of a bug/weakness I haven't been ...
Your analysis machine is Windows 7, ASLR is modifying your module base addresses between different executions.
Try calculating the offset to your OEP (that is, address - base) and using this value to calculate OEP address with the new base (base2 + offset)