The queue does get established, and some processes are able to get an answer back, but not all.
This was not the case when we were using the previous madCodeHook 3.0.x and I'm wondering whether it could be a bug in the new madCodeHook 4.0 or something on our end. Here's a sample of the code:
Callback (in the core executable responsible for injection):
Code: Select all
int local_log_level = 0;
void WINAPI CoreToDllHandler(LPCSTR,
LPCVOID pMessageBuf, DWORD size,
LPVOID pAnswerBuf, DWORD answerLen, LPVOID pContext)
{
printf("Entered dll handler callback\n");
int *log_level = static_cast<int*>(pAnswerBuf);
*log_level = local_log_level;
}
Code: Select all
bool CoreToDllQueue()
{
if (!CreateIpcQueue(WORKING_DIR_COMM, CoreToDllHandler)) {
LOG_ERROR("Could not create IPC messaging queue from Core to Dll!");
return false;
}
LOG_DEBUG("Core to Dll message IPC Queue established.");
return true;
}
Code: Select all
int log_level = 0;
SendIpcMessage(WORKING_DIR_COMM, nullptr, NULL,
&log_level, sizeof(int), 7000, 1);
Error: error LNK2001: unresolved external symbol RegisterUninjectCallback
We're linking with madchook64mt.lib with /MT Runtime Library option.
Code example:
Callback:
Code: Select all
void WINAPI UninjectCallback(LPCVOID context)
{
if (config_files != nullptr)
{
free(config_files);
}
}
Code: Select all
RegisterUninjectCallback(UninjectCallback, nullptr);