Hooking Child Process...

[joecm]

I am attempting to hook into the File I/O of a third party App.... I have managed to hook the WriteFile and WriteFileEx and they work if I call them from the ProcessAPI.exe program. Now, if I use WinExec to launch another program that I wrote (it just writes to a file), it does not seem to hook into that.

Is there something I need to do to specify the child process to have it hooked? Or perhaps not all file writes use the API above? Any Thoughts?

Thanks,

[nildo]

What if you hook WinExec and/or CreateProcess? If you hook it, you can change the result of CreateProcess for a CreateProcessEX with your injected DLL. Maybe mathias does now another way

[madshi]

Hooking APIs in another process works by putting your hooking stuff into a little dll and injecting that into the target process. If you're starting that third party program yourself, you can simply use CreateProcessEx instead of WinExec. CreateProcessEx lets you specify an additional dll (= your little hook dll) which then gets loaded into the newly created process.

[joecm]

That definately works and I am able to intercept the file writes... woohoo....

My next question is, what is the best way to get that information out of the dll.... I read that the IPC is not the most efficient way to send a lot of data. Any suggestions?

I am using VC++ and am a bit out of my element (no C++ since college) and I am really fighting it. I tried writing to a file or even to STDout from the DLL and am left with "unresolved external symbol" errors all over the place. Not sure if that is because it isn't possible, or because I just suck at C++

Any help would be appreciated.

[madshi]

What kind of data do you need to transfer? How many data packets would that be per second and how big would the data be in each packet?

[joecm]

The data is all text. It is a log file so depending on the activity it could vary in size. I would speculate that maybe at most 1000 characters a second. Depending on how it writes (per line, or in blocks) it could be 10-20 "packets" a second... I think that is worst case scenario, but can run some tests if you need more specific info.

Thanks,

[madshi]

Well, that's not *that* much. I think you can use madCodeHook's IPC functions then...

[joecm]

When trying to use IPC I am getting a Stack Overflow error. When I comment out the IPC code, it works fine. I am only overridding the FileWrite API (using dll injection) and my test program only writes 2 lines. Any thoughts on why this is happening? Could it be that because my test app is a Mangaged .Net Application?

Thanks again,

Some of my sample code is below (note, some of the names are crazy because I cut and pasted the thing together from samples )

My code in My Calling Program (snippet):

Code: Select all

CreateProcessEx("C:\\FileWriter.exe", 
		NULL, 
		NULL, 
		NULL, 
		FALSE, 
		0, 
		NULL, 
		NULL, 
	                &startupInfo,
                               &processInfo, 
		"C:\\madcapdemo\\Demos\\hookfilewrites\\Release\\HookTerminateAPIs.dll"); 

	CreateIpcQueue("ThisisaTest123456", DllInjectIpcHandler);

And my code from my Injection DLL

Code: Select all

#include <windows.h>
#include "madCHook.h"
#include <iostream>

UINT (WINAPI *WinExecNextHook)(HANDLE hFile, LPCVOID lpBuffer,DWORD nNumberOfBytesToWrite,  LPDWORD lpNumberOfBytesWritten, LPOVERLAPPED lpOverlapped);

UINT (WINAPI *WriteFileExNextHook) (
  HANDLE hFile,
  LPCVOID lpBuffer,
  DWORD nNumberOfBytesToWrite,
  LPOVERLAPPED lpOverlapped,
  LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine
);

BOOL WINAPI WriteFileExHookProc (HANDLE hFile,
  LPCVOID lpBuffer,
  DWORD nNumberOfBytesToWrite,
  LPOVERLAPPED lpOverlapped,
  LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine);

BOOL WINAPI WriteFileExHookProc(HANDLE hFile,
  LPCVOID lpBuffer,
  DWORD nNumberOfBytesToWrite,
  LPOVERLAPPED lpOverlapped,
  LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine) 
{
	
		SendIpcMessage("ThisisaTest123456", &lpBuffer, sizeof(lpBuffer));					

	 return WriteFileExNextHook(hFile,lpBuffer,nNumberOfBytesToWrite,lpOverlapped,lpCompletionRoutine);
  }


UINT WINAPI WinExecHookProc(HANDLE hFile,  LPCVOID lpBuffer,DWORD nNumberOfBytesToWrite, LPDWORD lpNumberOfBytesWritten, LPOVERLAPPED lpOverlapped) 
{

	SendIpcMessage("ThisisaTest123456", &lpBuffer, sizeof(lpBuffer));

	 return WinExecNextHook(hFile,lpBuffer,nNumberOfBytesToWrite, lpNumberOfBytesWritten, lpOverlapped);
  }



BOOL WINAPI DllMain(HANDLE hModule, DWORD fdwReason, LPVOID lpReserved)
{
  if (fdwReason == DLL_PROCESS_ATTACH) {
	  HookAPI("kernel32.dll", "WriteFile", WinExecHookProc, (PVOID*) &WinExecNextHook);
	  HookAPI("kernel32.dll", "WriteFileEx", WriteFileExHookProc, (PVOID*) &WriteFileExNextHook);
  } else if (fdwReason == DLL_PROCESS_DETACH)
		int s = 0;
  return true;
}

[madshi]

Which process is getting the stack overflow? The hooked process (in which you injected the hook dll) or your own exe?

How does "DllInjectIpcHandler" look like?

[madshi]

P.S:

Ouch, SendIpcMessage internally calls WriteFile!

So it seems you need to find a way to check whether the WriteFile(Ex) hook you get is a "real" WriteFile(Ex) API call or whether it was called from SendIpcMessage. Do you see the problem?

[joecm]

The overflow is in the FileWriter.exe application (which is the one being injected.

I, at one point, had some code (a message box) in the Handler, but when the error occured I blanked it out. The error happens even when there is no code in it. Below is how it is now.

Thanks,

-joe

Code: Select all

void WINAPI DllInjectIpcHandler(LPCSTR  pIpc,
                                PVOID   pMessageBuf,
                                DWORD   dwMessageLen,
                                PVOID   pAnswerBuf,
                                DWORD   dwAnswerLen)
// our application contacted us, so let's fulfill the dll injection request
{


}

[joecm]

Ah... well that would explain the overflow.

[joecm]

Hmm... I can't think of a way to differentiate between the two. Maybe there is some consistent way to identify the IPC Writes?

Can you think of a way?

Thanks

[madshi]

Well, in Delphi you could do this:

Code: Select all

threadvar AmInSendIpcMessage : boolean;

function WriteFileCallback(...) : bool; stdcall;
begin
  if not AmInSendIpcMessage then begin
    AmInSendIpcMessage := true;
    SendIpcMessage(...);
    AmInSendIpcMessage := false;
  end;
  result := WriteFileNext(...);
end;

By using the keyword "threadvar" the boolean variable "AmInSendIpcMessage" is different for each thread. So this solution is thread safe. Delphi realizes this stuff by using the TLS (thread local storage). You can surely do something like this in C++, too. Alternatively you would also just use a normal global variable. But then this solution is not really thread safe...