Calling unexported functions in Win32 C++

Question

How would I go about calling an unexported function in Win32 C++?

Answer 1

Calling unexported functions that are defined in the same module (DLL/EXE) as your code is easy: just call them like any other C++ function. Obviously this isn't what you're asking about. If you want to call unexported functions in a different module, you need to find out their addresses somehow.

One way to do this is to have the first module call an exported function in the second module which returns a function pointer. (Or: a struct containing function pointers, a pointer to an instance of a class, etc.) Think factory pattern.

Another way is to export a registration function from the first module and have the second module's initialization code call it, passing it pointers to unexported functions along with some sort of identifying info. (Better also have a corresponding unregistration function which is called before the second module is unloaded.)

Yet another way is to grovel through the debug symbols using dbghelp.dll. This would not be recommended for a real-world application because it would require distributing debug symbols and would be extremely slow, not to mention overly complex.

Answer 2

Additionally to bk1e's answer, there's still another method (not recommended as well).

1. Obtain the relative Adress of that function in the dll (e.g. via disassembly). This has to be done manually and before compiling.
2. In the program, you now have to obtain the startadress of the dll in memory (for example using an exported function and some calculation).
3. Now you can directly call that function using the relative Adress of the function + the startadress of the exported function.

I don't recommend this though. It works only on one defined version of that dll. Any recompile and the adress may change. Or that function may not be needed any more and gets deleted. There must be a reason, why this function is NOT exported. In general - you try to archive something the author of the library intentionally did not want you to do and that's "evil" most of the time.

---

You mentioned the ida-name. This name includes the startadress.

Answer 3

No two ways about it, you'll have to study the disassembly to figure out what gets pushed on the stack, and how it's used to determine the types.