https://bugs.winehq.org/show_bug.cgi?id=40969
Bug ID: 40969 Summary: Wine: DLL Injection on suspended process provides NULL arg for static library's DLLMain's lpvReserved value Product: Wine Version: 1.9.14 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: aheinerm@gmail.com Distribution: ---
WINE does not respect the behaviour of the lpvReserved argument in DLLMain.
From the documentation of DllMain
(https://msdn.microsoft.com/en-us/library/windows/desktop/ms682583(v=vs.85).a...) ~~~ lpvReserved [in] If fdwReason is DLL_PROCESS_ATTACH, lpvReserved is NULL for dynamic loads and non-NULL for static loads.
If fdwReason is DLL_PROCESS_DETACH, lpvReserved is NULL if FreeLibrary has been called or the DLL load failed and non-NULL if the process is terminating. ~~~~
WINE does NOT respect this behaviour.
# EXAMPLE Given the following: A.exe, B.dll, C.dll
C.dll is statically linked from both A.exe and B.dll. A.exe's process is started and suspended. B.dll is injected into the A.exe process.
At some point the DllMain of C.dll is called. In WINE, the lpvReserved argument is NULL, even though C.dll is statically loaded. In Windows 7, 8, and 10, the lpvReserved argument is non-null.
# REAL WORLD IMPACT https://github.com/bwapi/bwapi/issues/598 https://bugs.winehq.org/show_bug.cgi?id=40259
Blizzard Entertainment's Storm.dll library uses the lpvReserved to invoke a different behaviour in its DllMain (why, I have no idea). Their video game Starcraft: Broodwar is statically linked to this library. The third-party hack DLL called BWAPI.dll is also statically linked to Storm.dll. The Hack launcher called ChaosLauncher starts and suspends the Starcraft process and injects various hacks (one being BWAPI). The error in the tracking issue above is surfaced.
The issue surfaced because Storm performs some alternative initialization logic that corrupts its ability to function correctly later. In order to temporarily work around the issue I have forcefully undone the logic made in the other DLL to cause it to malfunction.
In this case the executable and statically linked library are owned by a company and their source codes are not available. It should be possible to reproduce the issue in a more trivial example.
https://bugs.winehq.org/show_bug.cgi?id=40969
Adam Heinermann aheinerm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aheinerm@gmail.com See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=40259 URL| |https://github.com/bwapi/bw | |api/issues/598
https://bugs.winehq.org/show_bug.cgi?id=40969
--- Comment #1 from Adam Heinermann aheinerm@gmail.com --- Forgot to mention:
The library is being loaded in a remote thread with LoadLibraryA. I want to re-iterate that the additional statically linked library is being treated as if it's dynamically loaded when it should be treated as if it were statically loaded.
https://bugs.winehq.org/show_bug.cgi?id=40969
Adam Heinermann aheinerm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |kernel32
https://bugs.winehq.org/show_bug.cgi?id=40969
Adam Heinermann aheinerm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL|https://github.com/bwapi/bw |https://github.com/bwapi/bw |api/issues/598 |api/issues/672
https://bugs.winehq.org/show_bug.cgi?id=40969
--- Comment #2 from Adam Heinermann aheinerm@gmail.com --- By statically linked, I mean statically loaded**.
https://bugs.winehq.org/show_bug.cgi?id=40969
Saulius K. saulius2@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |saulius2@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=40969
--- Comment #3 from Saulius K. saulius2@gmail.com --- Is this still an issue?