What does Scylla/ImpRec are doing? How to reconstruct imports?

Question

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)

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.