Mostly in the tutorials they are telling to use this tool and that tool to magically apply something and make XY work & run. I would love to know how these things are working, how is import reconstruction done generally?

For example in my case I would need dump a malware from memory, where it's manual mapped, but these import reconstruction tools usually does not support such a thing, this is why I want to learn what it is at all. (I know that there are workarounds how to make them work, but I want to know the logic behind imp reccing)

So, back to the question. Are they analyzing the code itself for calls which are residing in external modules? Or are they using some other/existing/runtime table which usually unveil the original modules/procs.

I couldn't find any good docs/description about it (except for whole the codebase of Scylla)

  • For manual mapped modules, oftentimes you only need to fix the file alignment and sections to properly load it into IDA with an intact import table, as long as you take the dump before the manual mapping code resolves the imports. Once it does, you'd need to repair it leading back to your question. Commented Feb 28, 2019 at 16:26
  • Scylla supports reconstruction of a memory mapped pe file.
    – mrexodia
    Commented Mar 5, 2019 at 0:45

1 Answer 1


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 the different heuristics and their meaning in those tools' documentation and/or files. ImpRec's can be found with it as a text file while Scylla's can be interpreted from it's source code.

Normally, an import reconstruction tool needs to gather two pieces of information for every imported function:

  1. Where is that imported function being called/referenced throughout the fixed binary. This may be either a pointer variable pointing to an imported function, or a piece of code that needs to be modified based on the imported function's address.

    If the binary creates a manual import table as part of it's execution, this involves iterating it until it's end is reached. Finding such manual import table is often left to the user, by either pointing to it directly by address or inferring it from the references done by the binary itself, as calls/jumps, after the binary is loaded and the OEP is reached.

    If the binary avoids an import table, all imports must be inferred by analyzing the code starting at OEP and recognizing indirect calls or calls made using a stored address. An import reconstruction tool may validate the target address is indeed an imported function.

  2. Which imported function is actually being called. More often, this is the easier part of the two however it can be further complicated by packers. To resolve the imports the import reconstruction tool must obviously know to which function must every reference resolve.

    If those jumps/calls/ point to the relevant imported functions in the loaded library, resolving them is quite straightforward - enumerate all imports in the target module and match the addresses.

    If, however, the imported functions are being copied (entirely or partially) to an allocated memory region, figuring out what function is actually called may be a little more difficult.

  • Thanks for all the useful info and for pointing out that ImpRec has a real useful documentation :) I'll definitely check out the source of Scylla as well.
    – Unc3nZureD
    Commented Mar 5, 2019 at 12:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.