Hijacking DLL File [closed] - dll

Question

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I am trying to learn about DLL Hijacking.
If I were to create a DLL file that contains two functions; add and subtract, say this was called mathematics.dll.
Now I create a program that loads mathematics.dll, so that I can add & subtract.
Then I hijack the original dll file with my new DLL file which can multiply and divide, but I must also implement the two original functions of the hijacked DLL which are for whatever reason unknown.. How can I pass calls through the original DLL so that the program can still load the original DLL file.
And even then how can I inject hooks into my code so that I can use my newly found multiply and divide functions?
If all of this is nonsense and I'm trying to pursue this wrong, please shed light on this subject, as I'm not so familiar with it.

Answer 1

The basic idea is fairly simple, but the details can get a little tricky.
So, for the program in question to implicitly link to your new DLL instead of the old one, your new DLL has to have the same file name as the old one. In the typical case, it also needs to be in a location that the Windows loader will find it instead of the old one.
At the same time, the new DLL needs to be able to link to the old one. One easy (but fragile) way to do this is for it to call LoadLibrary to load the old one, and when it does so, it specifies the full path to the old DLL.
Another method I've seen used sometimes is to find and rename the old DLL when you're installing the new DLL. Then the new DLL is installed under the original name of the old DLL, so the program will find it, and the new DLL can find the old one, because it knows its new name.
From there, it's typically a fairly simple matter of having your new DLL load the old DLL, get the address of each applicable function with GetProcAddress, and have a function that forwards to the old one via that pointer to a function.
For example:
Old_dll.cpp:
extern "C" {
__declspec(dllexport) int Add(int a, int b) { return a + b; }
__declspec(dllexport) int Sub(int a, int b) { return a - b; }
}
new_dll.cpp:
#include <windows.h>
int(*pAdd)(int a, int b) = NULL;
int(*pSub)(int a, int b) = NULL;
HMODULE mod = NULL;
extern "C" {
__declspec(dllexport) int Mul(int a, int b) { return a * b; }
__declspec(dllexport) int Div(int a, int b) { return a / b; }
__declspec(dllexport) int Add(int a, int b) { return pAdd(a, b); }
__declspec(dllexport) int Sub(int a, int b) { return pSub(a, b); }
BOOL WINAPI DllMain(_Out_ HINSTANCE hInstance, _In_ ULONG ulReason, LPVOID Reserved)
{
if (mod == NULL) {
mod = LoadLibrary("old_dll.dll");
typedef int(*arith)(int, int);
pAdd = (arith)GetProcAddress(mod, "Add");
pSub = (arith)GetProcAddress(mod, "Sub");
}
return true;
}
}
new_dll.h:
#pragma once
#ifdef __cplusplus
extern "C" {
#endif
int Add(int, int);
int Sub(int, int);
int Mul(int, int);
int Div(int, int);
void init(void);
#ifdef __cplusplus
}
#endif
use_dll.cpp:
#include <iostream>
#include "new_dll.h"
int main() {
std::cout << Add(Mul(2, 3), Div(8, 4));
}
Makefile:
use_dll.exe: use_dll.cpp new_dll.lib
cl use_dll.cpp new_dll.lib
new_dll.lib: new_dll.cpp old_dll.dll
cl /LD new_dll.cpp
old_dll.dll: old_dll.cpp
cl /LD old_dll.cpp
So, assuming I haven't skipped anything, you should be able to put these in a directory, type nmake, and it'll all build. When you're done you should have a couple of DLLs, an executable, and some miscellaneous other stuff (.lib, .exp, and so on). If you run the executable, it should print out 8, which it gets by using the new_dll, which in turn uses functions from old_dll.
As to getting your old main program to use the functions you've added if it wasn't written to do that to start with: covering this in any level of detail is far beyond the scope of an answer here. The really short answer is that it'll require some sort of reflection mechanism so the program can find what functions are available, and how to call them.
This can be practical for something like embedding an interpreter for some sort of scripting language, and letting the user write new programs using new functions available in the scripting language. As for modifying how the original program itself works, and somehow know that a new function it never heard of before can do something useful for it, and modify its code to use that function automatically...well, that might be possible, but it's certainly not the sort of thing I can cover here.
If you do want to use reflection to make functions available (even if they aren't used automatically) you might want to look into COM. It provides mechanisms for most parts of this sort of job (but be aware: using COM is likely to cause significant changes to your program overall, far beyond the simple task of substituting one DLL for another).