Virus being detected in glfw32.dll (Only when run from command line)

[SHC]

I have faced a different situation today, I gave a demo of my game (uses raw LWJGL with my own engine) to a friend and he said he had different results regarding it. My game extracts the natives itself to a temp directory and loads them from there (Also sets lwjgl.library.path).

The case is, it is running as it should, fine when double clicked on the JAR, but giving an exception when launched from command line. The exception is as follows:



This is weird, because if the file really had a virus, it shouldn't even run when double clicked on the JAR which is not the case, it only happens when he launched the game from command line.

Info: He is using 32-bit Windows 10, and is using the built-in Windows Defender as the antivirus.

Anybody ran into this issue?

[spasi]

This is weird, because if the file really had a virus, it shouldn't even run when double clicked on the JAR which is not the case, it only happens when he launched the game from command line.

Info: He is using 32-bit Windows 10, and is using the built-in Windows Defender as the antivirus.

I have just tried using x86 build with Windows Defender enabled and it works fine (though, on 64-bit Windows 10). Does it help if you use upx to decompress the binaries? Use:

upx -d glfw32.dll

and do the same for the other libraries.

It's interesting that it happens with the GLFW dll though. There have been complains about antivirus false positives before but GLFW was statically linked into the LWJGL dll then.

My game extracts the natives itself to a temp directory and loads them from there (Also sets lwjgl.library.path).

Where is the temp directory created? Btw, LWJGL does this automatically since the latest stable build. The only thing you need to do is include a jar with the binaries in the classpath.

[SHC]

Sorry for the late reply, he responded to me just today. I've sent him another build with decompressed DLL files, and he said that he is still having the same issue, but this time with lwjgl32.dll. It is really weird that it works when he double click the JAR, but not from the command line.

I've told him that it is a false positive, but is there any way that we can avoid this? Decompressing the DLLs get it working, but it's raising errors when launching from command line.

[spasi]

Are you sure there is no difference when running from the command line? Are the shared libraries extracted and loaded in the same way?

Just noticed in the stacktrace above that you're using System.load with the extracted libraries. You shouldn't have to do that. Also, have you tried LWJGL's built-in native extraction?

he said that he is still having the same issue, but this time with lwjgl32.dll.

Does that mean that with the compressed libraries lwjgl32.dll is loaded without issues (and fails with glfw32.dll)?

I've told him that it is a false positive, but is there any way that we can avoid this?

It would be nice if I were able to reproduce this. Is there any chance you could send me your application to test locally?

[Kai]

Notice that when "double-clicking" a jar file on Windows the executable javaw.exe is used, whereas you likely used "java.exe" with cmd. Maybe try "javaw.exe"
The only difference between those two executables is the different subsystem declaration in the exe file. java.exe uses "console" whereas javaw.exe uses "windows."
With a "windows" subsystem the process has no stdout/stdin, since a GUI windows application usually has no console, and therefore cmd would return immediately, had one executed javaw.exe with cmd.
However I also don't know why the virus scanner behaves differently then.

[Cornix]

Perhaps one is executed with Administrator rights and the other isnt?
(Or just different rights in general)

[SHC]

Are you sure there is no difference when running from the command line? Are the shared libraries extracted and loaded in the same way?

The shared libraries are loaded in the following order using System.load, glfw32.dll, lwjgl32.dll, OpenAL32.dll and jemalloc32.dll. There should be no difference when running from the command line, they are extracted and passed into System.load for each dll separately. If one dll fails to load, the next ones will not even be extracted.

Does that mean that with the compressed libraries lwjgl32.dll is loaded without issues (and fails with glfw32.dll)?

Nope, to test whether it was UPX compression that was preventing glfw32.dll from loading, I have sent him a build where I had all other DLLs except glfw32.dll compressed with UPX, and then the loading was failed at lwjgl32.dll which was UPX compressed but glfw32.dll which was not was loaded successfully.

Just noticed in the stacktrace above that you're using System.load with the extracted libraries. You shouldn't have to do that. Also, have you tried LWJGL's built-in native extraction?

Nope I didn't, I wanted to keep this NativesLoader class in my project, because I'm planning to make an Android port which doesn't use LWJGL from the same code base of my game, and I'm gonna integrate JBullet into the list soon so I kept this class for myself. I don't think that should be an issue.

It would be nice if I were able to reproduce this. Is there any chance you could send me your application to test locally?

Yeah sure. The latest build (with glfw32.dll uncompressed and others compressed) is available from this link (Requires Java 8 to work): https://www.dropbox.com/s/z2k5bo142zr6lcn/Blox.jar?dl=0

[spasi]

Nope, to test whether it was UPX compression that was preventing glfw32.dll from loading, I have sent him a build where I had all other DLLs except glfw32.dll compressed with UPX, and then the loading was failed at lwjgl32.dll which was UPX compressed but glfw32.dll which was not was loaded successfully.

That's why my suggestion was to decompress all libraries, not only glfw32.dll. I'm looking for confirmation that it is indeed upx to blame and not something particular about GLFW. Could you do another test please?

Nope I didn't, I wanted to keep this NativesLoader class in my project, because I'm planning to make an Android port which doesn't use LWJGL from the same code base of my game, and I'm gonna integrate JBullet into the list soon so I kept this class for myself. I don't think that should be an issue.

You could let LWJGL extract its own libraries and handle the rest however you like, it shouldn't be an issue.

In any case, manual extraction is fine if that's what you want to do, but at least do not use System.load with GLFW, OpenAL and jemalloc. That is, do not manually load any library that comes with LWJGL that isn't lwjgl(32).dll/so/dylib.

edit: this recommendation is unrelated to the virus misdetection problem