Application built using Launch4j and WinDPAPI4j may have an issue with DLL hijacking.

[Bluetopia]

This is a bit of a weird one, but I at least wanted to make you aware of something I'm currently discussing with the Launch4j maintainer that might be addressable by your library as well. You can find the Launch4j conversation here: https://sourceforge.net/p/launch4j/discussion/332683/thread/17833e817b/?limit=25

Issue: An application using WinDPAPI4j that is wrapped using Launch4j (Gui, with splash screen) may be vulnerable to DLL hijacking by placing a dummy/malicious cryptbase.dll file alongside the executable.

Prerequisites:

• Java application encrypts/decrypts string via WinDPAPI4j on startup.
• Java application is wrapped into Windows EXE using Launch4j with the <headerType>gui</headerType> and options configured.
• Sample code is available, though I have not put it online yet given it might expose a potential security risk.

Steps to reproduce:

1. Confirm that the EXE runs normally. (Sample code available would display a JavaFX dialog with String, DPAPI encrypted string, DPAPI decrypted string.)
2. Create a 0-byte "cryptbase.dll" file in the same folder as the EXE file.
3. Attempt to run the EXE again.

Expected Result:

• Application ignores the dummy file and runs normally.

Actual result:

• For a 0-byte file named cryptbase.dll: Application generates a windows error: "/cryptbase.dll is either not designed to run on Windows or it contains an error. Try installing the program again using the original installation media or contact your system administrator or the software vendor for support. Error status 0xc0000020."
• For a built DLL file renamed cryptbase.dll: Application crashes silently.

Further details / thoughts:

• The problem only occurs if Launch4j is configured with headerType:gui and a splash screen. By removing the element from the Launch4J configuration, the dummy file is not picked up by the executable. Similarly, the problem is not reproducible using headerType:console.
• Crypt32.dll appears to possibly have a dependency on cryptbase.dll via DPAPI.dll, though I'm not well versed enough on using the dependencies tool or windows programming in general to know how cryptbase might be brought in.
• Windows provides the means of specifying a search path for DLLs when loaded, and it appears JNA might also support these flags.
• One of the flags is LOAD_LIBRARY_SEARCH_SYSTEM32, which might help keep the DLL search constrained to the only location it should be pulling these libraries from: windows' system directory. (Constraining the DLL search path either by default or by option is what I think WinDPAPI4j might be able to do to address this issue)

Do you think there is something here that you can look into, or would you need some further details from the launch4j investigation first? I do have sample source code that can reliably reproduce this issue that I can provide.

Thank you!