5

I'm doing some reverse engineering of C++ dll. What I have achieved so far - is have a list of all functions inside and even source code (in pseudo-C or so) for most of them.

Reading this source code of most the functions doesn't make sense, because original algorythms were written in C++ and are way too different from the received C code.

Even if I try to compile the received C code (by C compilator) - it won't run due to numerous syntax problems, missing libraries, etc.

Trying to simplify the things, I'm now after following task: I need just to call some of the required functions directly from dll, supplying some parameters of my choice.

This approach works fine for exported functions, where I know the name of the functions from decompiler code and they do have the name inside the dll.

But speaking about internal (non-exported) functions in dll - their names in decompiled code are most probably different from the original ones.

Questions: Is it possible to find out the original names of the functions inside dll ? Or is there any other smart way to call these functions directly from original dll? How to do this?

Improve this question
3
  • 2
    Why would you want to use the non-exported functions? They are not exported for a reason. Why are the exported functions not sufficient for your purposes?
    – peter ferrie
    Commented Dec 13, 2013 at 19:41
  • 1
    @peterferrie this is ReverseEngineering.SE and not StackOverflow; the "don't do it if it's not documented" or "don't do it because <coding standards>" or "if it's not meant to be called you shouldn't be calling it" stuff is out of topic here, don't you think? if we're gonna follow the rules, we might as well just say "if a program is packed then you shouldn't reverse engineer it" and screw it...
    – rev
    Commented Sep 2, 2015 at 14:19
  • @AcidShout, you've extrapolated far too much from what I asked, and arrived at a completed wrong interpretation. I am not saying that they shouldn't be used. I simply asked why the exported functions are not sufficient, because the non-exported ones are not intended to be used.
    – peter ferrie
    Commented Sep 2, 2015 at 15:09

3 Answers 3

Reset to default
7

First thing that comes to mind is the following approach

  1. Using your favourite debugger/disassembler locate the function and note down some unique byte pattern which identifies the function (Sort of like IDA's Flirt signatures)
  2. Get a handle to the DLL (GetModuleHandleA)
  3. Get the image size (from MODULEINFO.SizeOfImage using GetModuleInformation)
  4. Search for your unique pattern (handle+i < imageSize: -> memcmp)
  5. Assign the found address to a function pointer
  6. Call the function
Improve this answer
1

i think the best way to patch export table, to point exported names to needed functions. (or even extend export for needed funcs). Sorry, i can't provide the name of tools, which can make this

Improve this answer
1

If you have the symbol file for the DLL, or if the file was built with debugging information then you can recover the original names for the non-exported functions. If not, then probably not. Since the non-exported functions are not exported, there isn't a need for the original function names to be retained. The code in the DLL knows how to call those functions by address, so it doesn't need any more information than that.

Improve this answer

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.