Dll Injection Methods?
Dll Injection Methods?
What are the most common or most effective dll or code injection methods for Windows systems? Can someone explain to me the very basics of it? This is one thing I don't quite understand. Do you create a remote thread and make it call LoadLibrary, or what? I'm just now getting into writing trainers and such, and I'd like for someone to explain this. -.-' I have googled it, but couldn't quite find a good article on it. Besides, you guys are better than random shitty articles written by elitist pricks.
Edit: Did a little more reading. So far all I understand is this: Method 1. Allocate memory for the string containing the name of the dll to be loaded in the remote process(VirtualAllocEx), write the string to that memory(WriteProcessMemory), Create a thread in the target process(CreateRemoteThread), load the dll into the remote process by calling LoadLibrary on the new thread, LoadLibrary calls the DllMain function in the injected dll.
And method 2. Allocate memory for code and data in the target process, write a function and whatever data it needs, if it needs any(only allowed a page of data for local variables on a remote thread? not sure.), Create a remote thread and pass it the address of the function you wrote to the target process's memory.
Is that generally how it works, are there other ways, and if games or programs have ways of preventing these methods from working, what other methods do you use or how do you get around the prevention?
Edit: Did a little more reading. So far all I understand is this: Method 1. Allocate memory for the string containing the name of the dll to be loaded in the remote process(VirtualAllocEx), write the string to that memory(WriteProcessMemory), Create a thread in the target process(CreateRemoteThread), load the dll into the remote process by calling LoadLibrary on the new thread, LoadLibrary calls the DllMain function in the injected dll.
And method 2. Allocate memory for code and data in the target process, write a function and whatever data it needs, if it needs any(only allowed a page of data for local variables on a remote thread? not sure.), Create a remote thread and pass it the address of the function you wrote to the target process's memory.
Is that generally how it works, are there other ways, and if games or programs have ways of preventing these methods from working, what other methods do you use or how do you get around the prevention?
There are a bunch of different ways of doing this, as you've noted the most common way is via LoadLibrary. Essentially all you do is write the Dll's path to the remote process's memory, so that you can pass the pointer as a parameter and it will be valid in the remote process, then just create a thread within the remote process using CreateRemoteThread at the address of LoadLibraryA, and pass the pointer to the Dll path c-string as the single param that CreateRemoteThread allows. Simple as a pimple. I wrote a more in depth tutorial on this method which is stickied in the VB section and has code examples.
Point to note: some processes don't like you using CreateRemoteThread, but there is an alternate (albeit less elegant) function you can call with similar parameters and effects: QueueUserAPC, there's a few downsides with this method though, so use only when CreateRemoteThread is detected.
Another method is using Windows Hooks, I'm not so familiar with this method but I know there's a good codeproject article on it here.
Yet another method is to modify the registry to make every process that loads user32.dll load your dll as well. See here
As that wikipedia page lists, you can also hijack threads, again I'm not all that familiar with this method.
A more extreme way of doing it is via manual mapping, this shit is a mindfuck and a half. Darawk has some available public code to achieve this in C++ here. It is more in depth and gets right down the PE layer. Basically manual mapping mirrors the functionality of LoadLibraryA in that it prepares a dll so that it can be successfully loaded into the process and have the right relative offsets etc, thus eliminating the need to call LoadLibraryA which is VERY easy for the remote process to hook and detect seeing as it's called within the remote process.
Another great read is here:
DLL Injection and function interception tutorial - CodeProject®
Enjoy.
Point to note: some processes don't like you using CreateRemoteThread, but there is an alternate (albeit less elegant) function you can call with similar parameters and effects: QueueUserAPC, there's a few downsides with this method though, so use only when CreateRemoteThread is detected.
Another method is using Windows Hooks, I'm not so familiar with this method but I know there's a good codeproject article on it here.
Yet another method is to modify the registry to make every process that loads user32.dll load your dll as well. See here
As that wikipedia page lists, you can also hijack threads, again I'm not all that familiar with this method.
A more extreme way of doing it is via manual mapping, this shit is a mindfuck and a half. Darawk has some available public code to achieve this in C++ here. It is more in depth and gets right down the PE layer. Basically manual mapping mirrors the functionality of LoadLibraryA in that it prepares a dll so that it can be successfully loaded into the process and have the right relative offsets etc, thus eliminating the need to call LoadLibraryA which is VERY easy for the remote process to hook and detect seeing as it's called within the remote process.
Another great read is here:
DLL Injection and function interception tutorial - CodeProject®
Enjoy.
The QueueUserAPC() won't always work, it works only if the target uses thread and i/o synchronization api's.
What's typically better, writing a function to the process via WriteProcessMemory, or calling LoadLibrary in the remote process?
Originally Posted by t7ancients
What's typically better, writing a function to the process via WriteProcessMemory, or calling LoadLibrary in the remote process?
@.::SCHiM::. I did say it had downsides hehe, personally I've never used it but I did see someone use it as an alternative to avoid calling CRT so I thought I'd throw it in/
i have tried to make one with the calling LoadLibraryA method but it doesnt work
The best would be to manualmap the dll files into the remote process. This way the module won't show up inside the ldr->module list and will therefore not appear in api calls like GetModuleHandle nor will it in any of the CreateSnapshot() functions since it has not been registered.
It's not that hard to load a dll file manually, especially if you compile that dll yourself. You only need to take some extra care to insure proper execution. For example you can use dynamic linking so that you don't have to patch the import table with your injector, the only thing you'll have to do is insure that the dll is at the proper place. When it's all done you start a remote thread at it's entrypoint and watch the show.
It's not that hard to load a dll file manually, especially if you compile that dll yourself. You only need to take some extra care to insure proper execution. For example you can use dynamic linking so that you don't have to patch the import table with your injector, the only thing you'll have to do is insure that the dll is at the proper place. When it's all done you start a remote thread at it's entrypoint and watch the show.
How would you do that? Get the dll into a byte array or something and write the entire thing to the target process's memory?
Originally Posted by t7ancients
How would you do that? Get the dll into a byte array or something and write the entire thing to the target process's memory?
Are there any articles or e-books, or something like that, about PE/PE+? I'd love to learn about it, just not sure where to look.
Originally Posted by t7ancients
Are there any articles or e-books, or something like that, about PE/PE+? I'd love to learn about it, just not sure where to look.
Microsoft PE and COFF Specification
Matt Pietrek is also something of an authority on the PE architecture so read any of his articles on MSDN.
@Jason What's that image title you have?
I learned a great deal about the PE structure on this website, they are assembly tutorials, but the images and overviews are very clear. He also offers demo code you can use to see if files are PE or not, and how to extract information from the various fields.
I learned a great deal about the PE structure on this website, they are assembly tutorials, but the images and overviews are very clear. He also offers demo code you can use to see if files are PE or not, and how to extract information from the various fields.
Originally Posted by .::SCHiM::.
@Jason What's that image title you have?
I learned a great deal about the PE structure on this website, they are assembly tutorials, but the images and overviews are very clear. He also offers demo code you can use to see if files are PE or not, and how to extract information from the various fields.
I learned a great deal about the PE structure on this website, they are assembly tutorials, but the images and overviews are very clear. He also offers demo code you can use to see if files are PE or not, and how to extract information from the various fields.
.Spent the day trying to write some manual mapping code, failed dismally. Just a FYI, after rereading Darawks code you'll notice many bugs. I spent like 3 hours figuring out how loaders resolve the IAT named entries
, even now mine isn't perfect.
This worked for me for as far as I needed it to work:
Code:
void Pe32_load_init::PatchImportTable(){
IMAGE_DOS_HEADER* dos = (IMAGE_DOS_HEADER*)ImageBase;
IMAGE_NT_HEADERS* nt = (IMAGE_NT_HEADERS*)((int)dos+dos->e_lfanew);
IMAGE_IMPORT_DESCRIPTOR* iid = (IMAGE_IMPORT_DESCRIPTOR*)(nt->OptionalHeader.ImageBase + nt->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress);
for(int i = 0; iid[i].Characteristics != 0; i++){
IMAGE_THUNK_DATA* first_thunk = (IMAGE_THUNK_DATA*)((int)dos + iid[i].FirstThunk);
IMAGE_THUNK_DATA* orig_first_thunk = (IMAGE_THUNK_DATA*)((int)dos + iid[i].OriginalFirstThunk);
for(int y = 0; orig_first_thunk[y].u1.Function != NULL; y++){
IMAGE_IMPORT_BY_NAME* orig_imports_by_name = orig_first_thunk[y].u1.AddressOfData;
orig_imports_by_name = (IMAGE_IMPORT_BY_NAME*)((int)dos + (int)orig_imports_by_name);
char* ModuleName = (char*)((int)iid[i].Name + (int)dos);
first_thunk[y].u1.Function = (DWORD*) GetProcAddress( LoadLibrary( ModuleName ), (char*)orig_imports_by_name->Name ); // set the hook
}
}
}
Originally Posted by .::SCHiM::.
This worked for me for as far as I needed it to work:
Code:
void Pe32_load_init::PatchImportTable(){
IMAGE_DOS_HEADER* dos = (IMAGE_DOS_HEADER*)ImageBase;
IMAGE_NT_HEADERS* nt = (IMAGE_NT_HEADERS*)((int)dos+dos->e_lfanew);
IMAGE_IMPORT_DESCRIPTOR* iid = (IMAGE_IMPORT_DESCRIPTOR*)(nt->OptionalHeader.ImageBase + nt->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress);
for(int i = 0; iid[i].Characteristics != 0; i++){
IMAGE_THUNK_DATA* first_thunk = (IMAGE_THUNK_DATA*)((int)dos + iid[i].FirstThunk);
IMAGE_THUNK_DATA* orig_first_thunk = (IMAGE_THUNK_DATA*)((int)dos + iid[i].OriginalFirstThunk);
for(int y = 0; orig_first_thunk[y].u1.Function != NULL; y++){
IMAGE_IMPORT_BY_NAME* orig_imports_by_name = orig_first_thunk[y].u1.AddressOfData;
orig_imports_by_name = (IMAGE_IMPORT_BY_NAME*)((int)dos + (int)orig_imports_by_name);
char* ModuleName = (char*)((int)iid[i].Name + (int)dos);
first_thunk[y].u1.Function = (DWORD*) GetProcAddress( LoadLibrary( ModuleName ), (char*)orig_imports_by_name->Name ); // set the hook
}
}
}
