2

Wherever I look the method of injecting through CreateRemoteThread is the same, however the method of grabbing the process ID is not... My function will return the correct process ID, and I am not interested in any help on that, so I will void that portion out and only include the actual injection.

I am only just learning DLL injection and am attempting to on notepad.exe. If the injection works, the title of a notepad will change from "Untitled - Notepad" to "Hooked".

#define DLL_NAME "injectme.dll"

.....

BOOL InjectRemoteThread(DWORD ProcessID)
{
    HANDLE RemoteProc;
    char buf[50]        =   {0};
    LPVOID MemAlloc;
    LPVOID LoadLibAddress;

    // Process ID does show correctly!
    WCHAR id[100];
    StringCbPrintf(id, 100, L"%d", ProcessID); // id contains the process ID... is confirmed in comparing ID shown in tasklist and the messagebox.
    MessageBox(NULL, id, L"Process ID", MB_ICONINFORMATION);
    // Process ID does show correctly!

    if ( !ProcessID )
    {
        MessageBox(NULL, (LPCWSTR)GetLastError(), L"An error occured", NULL);
        return 0;
    }
    RemoteProc          =   OpenProcess(PROCESS_VM_OPERATION | PROCESS_VM_WRITE | PROCESS_CREATE_THREAD | PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, FALSE, ProcessID);
    if ( !RemoteProc )
    {
        MessageBox(NULL, (LPCWSTR)GetLastError(), L"An error occured", NULL);
        return 0;
    }
    LoadLibAddress      =   (LPVOID)GetProcAddress(GetModuleHandleA("kernel32.dll"), "LoadLibraryA");
    MemAlloc            =   (LPVOID)VirtualAllocEx(RemoteProc, NULL, strlen(DLL_NAME)+1, MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE);
    WriteProcessMemory(RemoteProc, (LPVOID)MemAlloc, DLL_NAME, strlen(DLL_NAME)+1, NULL);
    CreateRemoteThread(RemoteProc, NULL, NULL, (LPTHREAD_START_ROUTINE)LoadLibAddress, (LPVOID)MemAlloc, NULL, NULL);

    CloseHandle(RemoteProc);
    VirtualFreeEx(RemoteProc, (LPVOID)MemAlloc, 0, MEM_RELEASE | MEM_DECOMMIT);
    return 1;
}

The DLL works on using another person's injector, but I don't understand why... It is indeed in the same directory as the injector.

user1435947
  • 139
  • 2
  • 4
  • 12
  • I've seen something similar. I was just messing around on XP and causing a process to use 100% CPU through DLL injection, which worked fine. When I tried it on Windows 7, it didn't work. There's something around it that changed, possibly remedied by adjusting your process's token, but I never looked too far into it. – chris Dec 31 '12 at 00:40
  • Do you get any error, in particular in the `OpenProcess` stage? – Matteo Italia Dec 31 '12 at 00:42
  • @MatteoItalia, Not in my case, no. I suspect not in this case either. – chris Dec 31 '12 at 00:48
  • I get no errors throughout, unfortunately. – user1435947 Dec 31 '12 at 00:56
  • Not sure if this matters, but are both your app and notepad of the same architecture, i.e. both 64- or 32-bit? – Chris O Dec 31 '12 at 01:16
  • You can also use [SetWindowsHookEx API](http://msdn.microsoft.com/en-us/library/windows/desktop/ms644990%28v=vs.85%29.aspx) to inject your DLL. – Chris O Dec 31 '12 at 01:20
  • @ChrisO, I use 32-bit Windows, so both programs should be 32-bit. Also, I know about SetWindowsHookEx--I want to delve into and understand each method of injection, however I want this way to work first. – user1435947 Dec 31 '12 at 01:26
  • I just would like to add that - yes - architecture does make a difference! I have just started learning DLL injection techniques in C++, and - after making the same mistake you did above and assuming that Windows would automagically find the DLL if it was in the System32 folder - I found that in order for it to work, the DLL must be compiled as the same architecture as the target program. I am not sure about the code that does the injecting itself though... – araisbec Sep 17 '13 at 13:46
  • ***Also worth noting: CreateRemoteThread WILL return a valid thread ID and seem successful even if you fail to allocate memory properly for the DLL path (and the injection consequently does not work), as this is not within the scope of the functions responsibility. This had me hung-up for a good while. – araisbec Sep 17 '13 at 13:47

1 Answers1

5

I found the problem... I feel so stupid. Anyone with a similar problem: Instead of a relative path, use an absolute path.

I changed

#define DLL_NAME "injectme.dll"

To

#define DLL_NAME "C:\\Users\\Raikazu\\Documents\\Visual Studio 2012\\Projects\\Hooking\\Release\\injectme.dll"
user1435947
  • 139
  • 2
  • 4
  • 12