4

I've been reverse-engineering Windows PE files and I've discovered this pattern used quite often, making it a little more difficult to follow API calls. First, I'll go to the file's imports and then I will locate a specific import, such as WSAStartup, inside of the .idata section of the PE file pictured here:

idata section

Upon hitting the x or Ctrl-x keys to cross-reference where this function is called, it is only "called" in one spot recognized by IDA, which looks like this:

Jumps to functions

The question here is, what is the above-pictured structure/technique? It directly contrasts the "typical" setup that I come across which is simply going to .idata, cross-referencing a function, and having it show me areas directly called in code. There are also no direct references to the memory addresses in which each of these jumps reside, such as 14658844h.

I'm going to add one more figure here of a different file but similar sighting, in which case, this instance appears on the control-flow graph and is very obvious by the "orphaned" jmps you can see just above the red arrow:

enter image description here

My hypothesis here is that somehow these memory addresses (function ptrs) pictured in Figure 2 where the jumps reside, are somehow indirectly referenced in the code using some offsets to help mask the usage of these API functions. Is this a compiler feature or is this a manual doing?

Improve this question
3
  • 3
    Igor has answered pretty much the same question on Stack Overflow so I can do no better than point you to his answer there and let him answer it here himself! stackoverflow.com/a/22688670
    – Ian Cook
    May 6, 2017 at 5:53
  • @IanCook awesome, thanks for that. Do you have any tips or best practices for tracking these calls down in the code? Also, is there a specific area of study which covers this... For example would something like this be in an x86 assembly text or is this specific to the compiler completely?
    – the_endian
    May 6, 2017 at 6:39
  • 3
    This is msvc (and vb6?) specific. The reason is that it saves in the amount of relocations because calls to these apis can be done with the relative call (E8xxxxxxxx) instruction.
    – mrexodia
    May 7, 2017 at 12:43

1 Answer 1

Reset to default
1

Those are indirect jumps caused by the compiler or/and the linker in order to locate an external function.

According to how the function is defined, both the linker and the compiler may end up in emitting a stub, thus making the call stack insanely deep during the analysis.

As stated in the comments, this SO answer Indirect jumps for DLL function calls precisely explains what is going on under the hood.

Improve this answer

Your Answer

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

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