virus detected in latest lwjgl.zip download by ms edge

[goofyseeker311]

Version

3.3.4

Platform

Windows x64

JDK

oracle openjdk 22

Module

lwjgl core

Bug description

ms edge browser claims there is a virus on the main 300mb download package.
verify that its not the case and if ms edge has marked the file without reason.
custom zip files from the main website do not give that warning with same browser.
maybe check if the github redistributable everything file has problems.

Stacktrace or crash log output

ms edge does not tell much more than virus detected.
windows security says the file contains: Trojan:Win32/Vigorf.A

[goofyseeker311]

not even turning ms defender smartscreen off in the ms edge browser settings changes that, still says virus detected.

[Daedelus1]

MS Defender detected multiple files it labeled a Trojan when I attempted to unzip the file.

[Spasi]

Hey @goofyseeker311 @Daedelus1,

I've been trying to figure out what is going on and I've also asked people from LWJGL's discord server to help. So far, there hasn't been any evidence that these are real infections. Something appears to be triggering false positives, with the most likely reason being the switch to compilation with clang-cl (i.e. Visual Studio's Clang/LLVM compiler for Windows) in 3.3.4. Another oddity is that most detections happen with the x86 binaries, much fewer with the x64 ones.

This is of course a very serious matter and investigation is ongoing. If anyone can help and/or has information to share, please contact me directly (preferably on Discord).

For now, I have the removed the offending zip file from the Github release. You can find the same file, as well as the individual dlls from the LWJGL website: https://www.lwjgl.org/browse/release/3.3.4

[goofyseeker311]

same for the main site latest releases lwjgl.zip and lwjgl-3.3.4.zip, virus detected by edge/windows defender, only the custom packages pass. just to be aware that this happens, I will only use the custom packages that are not detected. not risking it.

these urls are complained by edge/msdefender:
https://build.lwjgl.org/release/latest/lwjgl.zip
https://build.lwjgl.org/release/3.3.4/lwjgl-3.3.4.zip

[JakeTheDondorian]

I've had multiply problems out of the blue recently with windows defender, which seems to have gone haywire. They're probably experimenting with some AI stuff.

First I got false-flag malware in the documentation html files of lwjgl, claimed to me android multiverse. I removed those from my jar and was fine for a bit. Now microsoft has renewed their efforts and lwjgl.dll is a Trojan.

I have a game called Songs of Syx, which has some windows players, so I can quickly and easily test tweaks. I'll join the discord now as "jake" in case I can be of service.

[goofyseeker311]

I still dont have any issues with windows defender with the custom download lwjgl package. including all the dlls and other files. maybe something is going on with the distribution packages specifically.

[donotfuckme]

came across with the same issue with my gradle project during gradle build command

FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':desktop:compileJava'.

Could not resolve all files for configuration ':desktop:compileClasspath'.
Could not download lwjgl-3.3.4-natives-windows-x86.jar (org.lwjgl:lwjgl:3.3.4)
Could not get resource 'https://repo.maven.apache.org/maven2/org/lwjgl/lwjgl/3.3.4/lwjgl-3.3.4-natives-windows-x86.jar'.
java.io.FileNotFoundException: C:\Users\user.gradle.tmp\gradle_download8543268596508239190bin (Operation did not complete successfully because the file contains a virus or potentially unwanted software)

OS: Windows 11 Pro x64
Version: 23H2
OS build: 22631.4460
Java: corretto 1.8.0_432

[OndrejSpanel]

I have reported the issue as false positive to Microsoft using https://www.microsoft.com/en-us/wdsi/filesubmission - let us see what they do.

[goofyseeker311]

When I somehow double clicked on extracted lwjgl-natives-windows-x86.jar file from the lwjgl-3.3.4-everything custom download, windows defender claims to find Trojan:Win32:Vigorf.A and guarantine the file. not during normal temp dll java native load operation, or just the files being extracted in the directory. loading and using other files, mainly just the windows x64 natives seems to not generate any windows defender warnings or actions. possibly java tries to run the lib jar on its own and windows defender does not like it. possibly windows also thinks that the native dll jar is to be run on its own and guarantines it. its not a valid program so win defender might think its malicious trojan. running native dll stuff is literally what the "executes commands from an attacker" is. would be much better if the bindings were natively in the java vm runtime.

consider talking with the oracle openjdk team to get the bindings to be distributed directly in the java vm runtime distribution package internally natively, in the local compiled way, not the external dll loading way.

[Spasi]

LWJGL 3.3.5 is now available. Please let me know if the misdetections persist.

[goofyseeker311]

github 3.3.5 download (and ea from the main website) does not trigger windows defender (currently).

(note: virus programs are known to react negatively to java temp dir native dll loading. expect this to be a norm).

so what if openjdk would use a local directly in its install folder to load the dlls, instead of the temp dir? would be better for native lib dll installing into java. some path that is already in the native dll search path.

[tommyettinger]

Great. Now lwjgl-stb-natives-windows.jar (so, x64) in the 3.3.5 release is flagged by multiple AV vendors (including MS and Google), but the x86 one is fine.

https://www.virustotal.com/gui/file/4cc056ced54c5d2882415529c4a528db83b61b157ecd01043f22233568419bfc

Is it possible to just set useClang=false for some, I don't know, variant on 3.3.5 that people can test-drive? If we've been suspecting Clang for 3 months, maybe someone should try disabling it, to see if it's the actual cause?

[goofyseeker311]

I extracted the contents of the jar files locally (dlls and .so), alongside the app jar, then apps do run like the dlls/.so were apps native local installs. This prevents any snooping by anti-virus software.

[JakeTheDondorian]

Great. Now lwjgl-stb-natives-windows.jar (so, x64) in the 3.3.5 release is flagged by multiple AV vendors (including MS and Google), but the x86 one is fine.

https://www.virustotal.com/gui/file/4cc056ced54c5d2882415529c4a528db83b61b157ecd01043f22233568419bfc

Is it possible to just set useClang=false for some, I don't know, variant on 3.3.5 that people can test-drive? If we've been suspecting Clang for 3 months, maybe someone should try disabling it, to see if it's the actual cause?

I'm not getting anything from virus total with what I downloaded the day after "release". It was still beta then on the webpage.

https://www.virustotal.com/gui/file/a3d43147f06f7f82a9dc61e29e6b10cf71297dda8441469808e0b1924a81244d/detection

[tommyettinger]

Using this config for version 3.3.5 stable (on the configuration page) gives me a .zip that Windows Defender or some kind of browser blacklist refuses to download, and deletes upon completion. But, if I switch to the nightly build (from before 3.3.5 was released by 2 hours, 28 minutes), that completes fine. What might have changed in those 2 hours, 28 minutes?

lwjgl-release-custom-zip.json

[JakeTheDondorian]

The above has been my suspicion all along.
Without know what I'm talking about, I believe the vendors are looking at the date modified of files. It might have approved fileX in the lwjgl package after a human review, but only for a certain date (version) of the file.

I suspect lwjgl content gets flagged, because there might be pirated apps that ship with lwjgl, and the pirates add malware. So as soon as someone gets infected by that, that lwjgl version (modification date) gets flagged, which would explain why an identical build, 2h old is differently treated.

Just wanted to share that with someone.

[Spasi]

FWIW, the release natives are the exact same files produced by the last nightly/snapshot build. There is no native compilation during a snapshot/release:

• Snapshots source natives from https://build.lwjgl.org/nightly/
• Releases source natives from https://build.lwjgl.org/stable/

The stable folder is a full copy of nightly (using aws s3 sync <src> <trg> --delete for those familiar with S3 commands). The release process also copies stable to the final release folder for that version (e.g. https://build.lwjgl.org/release/3.3.5/). The modified date might be different, but the files should be identical otherwise.

The last snapshot happens right before release. I can't imagine how a vendor would have already reviewed/approved those binaries and somehow treat the actual release differently.

[tommyettinger]

The native files appear to be identical; the SHA1 files are the same and the file sizes on the .dll files are the same, though I haven't checked that the SHA1 matches. However, there's a .class file in META-INF that is different:

The build.txt file is also different, but that's expected.

That might be the only thing needed to trigger a false positive by something like an exact filesize match with a known trojan. I don't know what heuristics are employed by AV programs, but they seem rather unreliable.

[Spasi]

Hey @tommyettinger,

The difference in module-info.class sizes is expected too. It is compiled with --module-version <value> and that <value> is encoded in the class file:

Snapshot build versions include the -snapshot suffix.

[Spasi]

LWJGL 3.3.6 has been released.

All Windows binaries in this release have been built with MSVC instead of Clang-CL. Please let me know if it made a difference.

[goofyseeker311]

Custom everything download of 3.3.6 from the website (all natives and add-ons) downloads fine and no defender complaints, so far.

[stephengold]

Microsoft Defender exhibits a high rate of false positives. To investigate an issue like this one, the first thing I would do is submit the file in question to https://www.virustotal.com/

[goofyseeker311]

virustotal, whats that. and heuristical virus detection algorithm says that any dll injection loading system is suspect. nothing unusual, but unfortunate in this case. fastest cure would be to transform the dll/so library as a runtime distribution package.

[stephengold]

VirusTotal is a website that will analyze any file you upload using analysis tools from dozens of anti-virus vendors.
If Microsoft Defender detects a virus and 30 other tools report "Undetected" then chances are good it's a false positive.

[goofyseeker311]

So who do you trust or ask to trust in? thats where viruses or other malicious action comes from. not all are honest. sadly.

but enough of this. you know what to do.

[tommyettinger]

3.3.6 seems to work well for me so far! Every JAR file in it I have run through VirusTotal has been perfectly free of detections. A JAR I built depending on 3.3.6 also has no detections. Hooray!

[Spasi]

There have been no false positives reported for 3.3.6, so it looks like we can close this.

This was a critical issue that affected a lot of people, so a quick recap:

• It started happening with LWJGL 3.3.4, which switched from cl (MSVC) to clang-cl (LLVM/Clang) for building the Windows binaries.
• In LWJGL 3.3.6 the compiler was reverted to cl. This was the only significant change compared to 3.3.5 (which also suffered from this issue).
• The clang-cl compiler that was used for 3.3.4 and 3.3.5 is the one that comes bundled with Microsoft's Visual Studio.
• All software used to build LWJGL binaries is either preinstalled on Github Action runners, or installed/built from official sources.
• All LWJGL binaries are reproducible, using the Github Action workflow scripts available under the LWJGL-CI account.

Apologies for the inconvenience and for taking so long to figure out the culprit.