c++ - 试图导出一个函数并调用它

Question

我正在尝试调用我的 dll 中的函数。

DLL 被注入(inject)到ANOTHER PROCESS 中，因此我需要能够在它被注入(inject)目标进程后调用导出的函数。

我导出的函数如下所示:

#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
    }
}

我试着这样调用它:

#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;
}

我遇到错误:

ret 0x000003e6 : Invalid access to memory location.     HRESULT

在这一行:

pModule = LoadLibrary("baram.dll");

有人可以告诉我我做错了什么吗？

帮助赞赏!

Answer 1

你用谷歌搜索过吗？

MS support说原因是:

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.

你应该

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.