I'm trying to call a function in my dll.
the DLL is injected into ANOTHER PROCESS so i need to be able to call the exported function after it's been injected into a target process.
my exported function looks like this:
#define EXTERN_DLL_EXPORT extern "C" __declspec(dllexport)
EXTERN_DLL_EXPORT void InjectPacketToServer(unsigned char *packet, int length)
{
int value;
int senderoffset = 0x0075F8D8;
__asm
{
mov eax, senderoffset
mov value, eax
}
memcpy((void*)SEND_CODE_CAVE, (void*)packet, length);
int SenderID = *(int*)value;
int PacketLength = length;
int Send = 0x00577A90;
__asm
{
mov edx, PacketLength
push edx
mov eax, SEND_CODE_CAVE
push eax
mov ecx, [SenderID]
call Send
}
}
I am trying to call it like this:
#include <Windows.h>
typedef int (*InjectPacketToServer)(unsigned char *packet, int length);
InjectPacketToServer Inject;
BYTE packet[3] = { 0x13, 0x01, 0x01};
int length = 3;
int main()
{
HRESULT ret;
HMODULE pModule;
pModule = LoadLibrary("baram.dll");
ret = GetLastError();
Inject = (InjectPacketToServer)GetProcAddress(pModule, "InjectPacketToServer");
ret = GetLastError();
Inject(packet, length);
return ret;
}
I'm getting errors:
ret 0x000003e6 : Invalid access to memory location. HRESULT
on this line:
pModule = LoadLibrary("baram.dll");
can somebody Please tell me what I'm doing wrong here?
help appreciated!
Did you google?
MS support says the cause is:
The Windows NT status code STATUS_ACCESS_VIOLATION is mapped to the Win32 error code ERROR_NOACCESS. As a result, if the operating system loader encounters an access violation (exception C0000005) while mapping the specified DLL file image or executing the startup code, the loader will set the last error to 998 (ERROR_NOACCESS) and the LoadLibrary() function will fail with a return value of NULL.
and you should
To troubleshoot the LoadLibrary() failure, run the application under a debugger and enable first chance exception handling for the C0000005 Access Violation exception. If an access violation occurs when the LoadLibrary() function is called, the application will break into the debugger. The debugger's call stack can then be used to trace where the exception occurred. The stack trace should help you narrow down the actual problem related to the exception being encountered.
User contributions licensed under CC BY-SA 3.0