PE DLL entry point is not analyzed with the DllMain prototype

[CX330Blake]

Bug Description:

Binary Ninja does not appear to recognize/analyze the PE DLL entry point using the standard DllMain prototype.

For the provided sample, the DLL entry point at 0x10001520 is recovered as:

int32_t __stdcall sub_10001520(int32_t arg1, int32_t arg2)

The HLIL starts with:

int32_t temp1 = arg2;
arg2 -= 1;

if (temp1 == 1) {
    data_100132fc = arg1;
    HMODULE eax_2 = GetModuleHandleA(NULL);
    data_100132f8 = *(eax_2->__offset(0x3c).d + eax_2 + 0x28);
    data_100132b8 = ConvertThreadToFiber(NULL);

    int32_t lpFiber = CreateFiber(0, sub_10001010, NULL);
    int32_t edx_2 = data_100132f8 ^ 0x10ec;
    data_100132bc = lpFiber;

    *(edx_2 + lpFiber + 0xc4) = edx_2 + sub_10001490;
    SwitchToFiber(lpFiber);
}

return 1;

This strongly matches a normal DLL process-attach path: the second argument is checked against 1 (DLL_PROCESS_ATTACH), and the first argument is saved as the module instance/base.

However, the entry point is analyzed as a generic two-argument __stdcall function instead of the standard DLL entry-point signature:

BOOL WINAPI DllMain(
    HINSTANCE hinstDLL,
    DWORD fdwReason,
    LPVOID lpvReserved
);

In particular, the third lpvReserved argument is absent from the recovered function signature.

Steps To Reproduce:

1. Open the provided binary in Binary Ninja.
2. Navigate to the PE DLL entry point at 0x10001520.
3. View the function in HLIL / Pseudo C.
4. Observe that the function is recovered as:

   int32_t __stdcall sub_10001520(int32_t arg1, int32_t arg2)

   rather than being analyzed with the standard DllMain prototype.

Expected Behavior:

For a PE file identified as a DLL, the image entry point should be analyzed using the Windows DLL entry-point ABI/prototype, including all three parameters:

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved);

Even if lpvReserved is unused by the function, its presence should be preserved by the platform-defined entry-point prototype rather than inferred away.

It would also be useful if the second argument could be typed appropriately so constants such as 1 can be represented as DLL_PROCESS_ATTACH.

Binary:

Binary access phrase:

keen dome paginates magnificently

Additional Information:

The function uses Windows Fiber APIs (ConvertThreadToFiber, CreateFiber, and SwitchToFiber) and modifies data relative to the newly created fiber before switching to it, but the issue being reported here is specifically the incorrect DLL entry-point function analysis/prototype.