This is not an example of loading a library into another process, rather patching the import table of a file loaded through MapViewOfFile(). LoadLibrary() would be called inside your own process, and therefore would not be detected.
Dll Injection Methods?
Originally Posted by .::SCHiM::.
This is not an example of loading a library into another process, rather patching the import table of a file loaded through MapViewOfFile(). LoadLibrary() would be called inside your own process, and therefore would not be detected.
You forget that the dll files are loaded at the same location in both processes, even with ASLR this is true. You can patch the table inside your own process, after which you map the sections to their appropriate locations inside the other process. You know this is true, because this is also how traditional injection by LoadLibrary() works. Using this technique you may even safe some space because the PE header will not be needed anymore.
Originally Posted by .::SCHiM::.
You forget that the dll files are loaded at the same location in both processes, even with ASLR this is true. You can patch the table inside your own process, after which you map the sections to their appropriate locations inside the other process. You know this is true, because this is also how traditional injection by LoadLibrary() works. Using this technique you may even safe some space because the PE header will not be needed anymore.
No it won't, that's because loading a binary with CreateFileMapping() and MapViewOfFile() does not 'load' the dll like the windows process loader would if you call LoadLibrary(). Rather it just dumps the contents of your file in some buffer somewhere. DllMain() is never called. The two api's don't even glance at the file you're loading.
Originally Posted by .::SCHiM::.
No it won't, that's because loading a binary with CreateFileMapping() and MapViewOfFile() does not 'load' the dll like the windows process loader would if you call LoadLibrary(). Rather it just dumps the contents of your file in some buffer somewhere. DllMain() is never called. The two api's don't even glance at the file you're loading.
Originally Posted by .::SCHiM::.
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
}
}
}
That code runs in your injector, not in the dll file. I don't see what the problem is. This all happens before the first call to WriteProcessMemory().
Originally Posted by .::SCHiM::.
That code runs in your injector, not in the dll file. I don't see what the problem is. This all happens before the first call to WriteProcessMemory().
Originally Posted by Jason
...the only glitch with this method is if the dll you're loading THINKS it's in a particular process automatically (like most hacks), it will likely crash your program if you load it.
Big miscommunication here 
The thing is that: no code from that dll file is ran until you're ready, which means that the dll is loaded at the proper location in Combat arms or any other game, and all other sections are loaded as well. The next step would be to create a remote thread at DllMain() which now resides inside the other process, in exactly the same spot at it would have been if it was loaded by windows. You patch the import table of your dll with your injector and not with the dll itself.
The thing is that: no code from that dll file is ran until you're ready, which means that the dll is loaded at the proper location in Combat arms or any other game, and all other sections are loaded as well. The next step would be to create a remote thread at DllMain() which now resides inside the other process, in exactly the same spot at it would have been if it was loaded by windows. You patch the import table of your dll with your injector and not with the dll itself.
Originally Posted by .::SCHiM::.
Big miscommunication here
The thing is that: no code from that dll file is ran until you're ready, which means that the dll is loaded at the proper location in Combat arms or any other game, and all other sections are loaded as well. The next step would be to create a remote thread at DllMain() which now resides inside the other process, in exactly the same spot at it would have been if it was loaded by windows. You patch the import table of your dll with your injector and not with the dll itself.
The thing is that: no code from that dll file is ran until you're ready, which means that the dll is loaded at the proper location in Combat arms or any other game, and all other sections are loaded as well. The next step would be to create a remote thread at DllMain() which now resides inside the other process, in exactly the same spot at it would have been if it was loaded by windows. You patch the import table of your dll with your injector and not with the dll itself.
That is true, however if a library is already loaded inside your injector (such as kernel32) the function acts as GetModuleHandle() and returns only the base address of the specified dll file. If this file is not present inside your target however, then it will crash. But most hacks often only need kernel32.dll and sometimes user32.dll. Kernel32 is always loaded in any application. User32 is always loaded in any application with a window, which every game has. The call to LoadLibrary is only there to make sure that every library the hack might need is indeed loaded or already present before resolving a function address.
A really drastic solution would be to load all required dll's from scratch, since all of these dlls are simply wrappers of yet another dll you must start with the core libraries: ntdll.dll and kernel32.dll, moving on to gdi23.dll and user32.dll. You won't actually have to load kernel32.dll or ntdll.dll since they are always present.
A really drastic solution would be to load all required dll's from scratch, since all of these dlls are simply wrappers of yet another dll you must start with the core libraries: ntdll.dll and kernel32.dll, moving on to gdi23.dll and user32.dll. You won't actually have to load kernel32.dll or ntdll.dll since they are always present.
Originally Posted by .::SCHiM::.
That is true, however if a library is already loaded inside your injector (such as kernel32) the function acts as GetModuleHandle() and returns only the base address of the specified dll file. If this file is not present inside your target however, then it will crash. But most hacks often only need kernel32.dll and sometimes user32.dll. Kernel32 is always loaded in any application. User32 is always loaded in any application with a window, which every game has. The call to LoadLibrary is only there to make sure that every library the hack might need is indeed loaded or already present before resolving a function address.
A really drastic solution would be to load all required dll's from scratch, since all of these dlls are simply wrappers of yet another dll you must start with the core libraries: ntdll.dll and kernel32.dll, moving on to gdi23.dll and user32.dll. You won't actually have to load kernel32.dll or ntdll.dll since they are always present.
A really drastic solution would be to load all required dll's from scratch, since all of these dlls are simply wrappers of yet another dll you must start with the core libraries: ntdll.dll and kernel32.dll, moving on to gdi23.dll and user32.dll. You won't actually have to load kernel32.dll or ntdll.dll since they are always present.
