This time with a different problem. As always, your code is great and has come to my rescue saving me countless hours of looking up DLL injection routines and IPC stuff.
However, that leads me to a small problem. I have an application wherein I've injected a DLL, patched some assembly, stubbed out to a function in my DLL. Now at this point I have the data I want to fire into the IPC tunnel, and I do so like this:
Code: Select all
if(!SendIpcMessage("Recv IPC Queue", (char *)g_dwPacketRecvData, g_dwPacketRecvSize, &bDone, sizeof(bDone)))
TraceOut("Unable to queue recv packet in IPC Queue");
Now according to the minimal documentation on IPC available, I've been able to piece together that each call to SendIpcMessage uses a new thread to make the call, based on the fact that creating the IPC pipe requires some information on how many threads to allow, and a queue length, neither of which are implemented currently. Too bad, because that queue would solve my current problem.
Basically what's happening is the messages are getting through, rather, the first one does. But then 3 packets come in rapid succession, and I'm crashing out. I've created the pipe to limit to 1 thread as such:
Code: Select all
if(!CreateIpcQueueEx("Recv IPC Queue", (PIPC_CALLBACK_ROUTINE)GetInterceptedPacket, 1, 0x1000))
MessageBox("Unable to create IPC Queue GetInterceptedPacket");
So, what I assume is happening in actuality is that my hook prior is also threaded and so a second thread for that hook is called, and trying to use the IPC tunnel.
What my real question is, is how to use CreateGlobalMutex and OpenGlobalMutex. There is very little documentation on how these work, and my understanding of threaded work is limited mostly to .NET. Do I simply create the mutex once in my injected DLL, and use OpenGlobalMutex when I want to open a the thread safe area? How to I release the mutex after?
And an age old question I've always wondered. If I create a static BOOL value, is it thread safe automatically? Can I use it as my own locking mechanism by simply sleeping in a loop until it's no longer set? Or is there still threading issue during the split moment the bool is assigned? My assumption is that since processors are still not TRUELY multitasking and simply task switch, that it should be safe to modify a single bit without special locking mechanisms, am I correct? Sorry if this is a stupid question
Back to the grindstone while I wait for a response.