Remote thread problem

I am having a problem with creating a remote thread. I create the remote thread to load a library. It does so succesfully. In the remote thread i then have it get the address of a function, thats where it fails.. Code of the remote thread below.

I did not include the code to prepare the remote thread, i'm pretty sure my problem isn't there

Code:

---

typedef FARPROC (__stdcall *PGetProcAddress)(HMODULE, LPCSTR);

struct RemoteThreadBlock
{
        // Variable that will return the module handle and function address
        HMODULE                                hModule;
        FARPROC                                fFunctionAddress;

        // Function that loads the library and gets the function address
        PLoadLibraryW                fnLoadLibrary;
        PGetProcAddress                fnGetProcAddress;

        // The path to the library we will be loading and the function
        wchar_t                                lpModulePath[_MAX_PATH];
        LPCSTR                                lpFunctionName;
};

DWORD __stdcall RemoteThread (RemoteThreadBlock*);
BOOL TestFunction ();

BOOL TestFunction ()
{
        return 0;
}

DWORD __stdcall RemoteThread (RemoteThreadBlock* ExecuteBlock)
{
        HMODULE hModule;

        // Load our library and return the module handle
        hModule = (*ExecuteBlock->fnLoadLibrary)(ExecuteBlock->lpModulePath);
        ExecuteBlock->fFunctionAddress = (*ExecuteBlock->fnGetProcAddress)(hModule, "TestFunction");

        return 0;
}

---

I've been fighting with this thing for 3 weeks not, rewriting every piece of code. Any ideas?

Might "TestFunction" be um, name-mangled? http://en.wikipedia.org/wiki/Name_mangling

You can use a dependency walker to find out the name of the function. http://www.dependencywalker.com/

Edit: do you have a .def file that exports it and specifies it's name as "TestFunction"? Otherwise you should also export it, and also use extern "C" on it.

.def file includes 'TestFunction' and yes, the dependancy walker shows TestFunction as the actual function name, no mangling.

In what way does it fail? What is ExecuteBlock->fFunctionAddress? Is there a GetLastError?

It crashes the program i am injecting my DLL into, hard. I debugged and returned the following fault.. Its not code, i put it in code tags to make it more distinguishable.

Code:

---

FAULT ->7c901277 f2ae repne scasb es:00f69050=??

Here's the stack back trace

00b5ffec 00000000 009c0000 00a50000 00000000 kernel32!GetModuleFileNameA+0x1b4

---

ExecuteBlock->fFunctionAddress is the variable i will be returning the function address back. For example, if i wanted to give the module handle back to my program i would do..

ExecuteBlock->hModule = (*ExecuteBlock->fnLoadLibrary)(ExecuteBlock->lpModulePath);

Then i would readprocessmemory and return RemoteThreadBlock.hModule.

Edit: As for GetLastError, i can't put it in the remote thread or it will crash, it is a foreign function, i would have to import it like i did LoadLibrary and GetProcAddress. However i recovered this from the Dr. Watson log.

Code:

---

Application exception occurred:
        App: C:\APM\apm.exe (pid=3340)
        When: 8/8/2006 @ 12:51:16.562
        Exception number: c0000005 (access violation)

---

Is this whole RemoteThreadBlock thing your idea or is it part of the proper remote thread injection API? Can you post the code you use to inject?

My guess is that the strings you specify simply don't exist in the remote thread.

I uploaded my entire project to my ftp, if this is against the rules, let me know and i will attach it.

http://www.malwarebytes.org/projects/code.zip

I assure you, the code does what its supposed to, but it won't return that dang function address. Thank you for all of the help.

I assure you that no spam will occur if you visit malwarebytes. I am a security site that has created utilites that remove certain spyware. If you google Malwarebytes you will receive hundreds of hits on other anti-spyware communities. (just a little reassurance).