WL 9.5 | lib.pluginsupport.exe false identification as ransomware by Trend Micro

WaveLab obviously does not incorporate ransomware, but it would be nice to get the false positives worked out.

When WaveLab scans plugins (“Checking Plug-ins” process), Trend Micro security software identifies lib.pluginsupport.exe (c:\program files\steinberg\wavelab pro 9.5\system\lib.pluginsupport.exe) as ransomware. Perhaps this is because of some encryption or filechanging process that the .exe performs?

lib.pluginsupport.exe is a very standard file without any encryption.

It only means it is a false positive by Trend Micro. I think it will react on many more things or software to be false positive in this way.

Thanks, Philippe, Denis! I appreciate the fast replies.

Yes, I know it’s a false positive and that the executable is standard. I’m a big fan of WaveLab and know that it’s not a platform for malware.

Denis, to address your specific point: No, Trend Micro security products actually don’t react to many things in this way; in fact, in about 6 years of running this particular security suite (with yearly upgrades and continual updates, of course), the only application that has ever been identified like this is WaveLab’s lib.pluginsupport.exe. I recognize that your suggestion might be to remove any security software from a true mastering system; however, because of various environments I work in with a particular mobile rig, I need the security software installed.

Philippe, on your standard file note: Trend Micro reported (but I didn’t screenshot quick enough to capture the message) that the .exe was in the process of “encrypting of changing certain system or user files” that caused the security software to trigger the ransomware warning. Trend Micro is probably looking for processes that are systematically going through files and making some sort of changes - which it looks like lib.pluginsupport.exe was doing (or causing/triggering) in these two locations:

C:\Users\computer\AppData\Local\Temp\JVI43leO6kk
C:\ProgramData\PACE Anti-Piracy\nJVI43le

The files noted as being changed in a ransomware-like pattern were:
kLIjX9h7.html
r7oehbpagddig.xls

This occurred during initial plugin scanning after upgrade to WaveLab Pro 9.5. Specifically, the warning was triggered when WaveLab scanned Antares AVOX Articulator 4.0.2 (VST3 version).

After clearing lib.pluginsupport.exe in Trend Micro, I ran the WaveLab plugin scan again, and everything worked with no Trend Micro warnings. However, the plugin scan halted again when scanning AVOX Articulator 4.0.2 (VST3 version). WaveLab offered the option to wait until scanning of Articulator finished or to continue on. I waited several minutes, and the scan of Articulator never finished, so I finally opted to skip it. At this time, I cannot use Articulator VST3 in WaveLab.


Here’s my guess: When WaveLab 9.5 scans the plugins, it also performs (or causes) processes with PACE licensing that result in a variety of temporary, randomly-named files such as “kLIjX9h7.html” to be generated and/or changed, perhaps involving encryption mechanisms. Because of those files’ location(s), and because of the rapidity of the processing that the plugin scanner performs, security software like Trend Micro detects the processing as a false positive for malware - ransomware in this case. It actually makes sense; the process would loosely fit the profile of a program that is systematically making changes to user/system files, so it gets halted to ensure the user wants this program running.

So, two requests:

  1. Articulator VST3 simply doesn’t work in WaveLab after this false positive, even after multiple scan attempts. (It does continue to work in other hosts such as Cubase.) My guess is that the needed changes to the randomly-name files above did not complete during the first scan What can I do to restore it in WaveLab, since scanning it always fails now in WaveLab?

  2. Would it be possible, on release of a major WaveLab version such as 9.5, to simply collaborate with the various major antivirus providers (there are only about a dozen major players: Avast, AVG, Avira, Bitdefender, Comodo, ESET, F-Secure, G Data, McAfee, Norton, ThreatTrack, Trend Micro) and provide them with the WaveLab executables so any such false positives would be stamped out at release? This could be a standard process incorporated into the release schedule, and most of these companies make submissions really easy for developers.

I solved this issue and wanted to post here for anyone else who runs into the problem.

In my case, WaveLab’s lib.pluginsupport.exe had been halted by Trend Micro while lib.pluginsupport.exe was making (or causing/triggering) changes here:
C:\ProgramData\PACE Anti-Piracy
specifically to a randomly-named file called kLIjX9h7.html in a folder called nJVI43le.

I renamed the “nJVI43le” folder to “nJVI43le-old” and re-ran the WaveLab plugin scanning process. This time, it successfully scanned Antares AVOX Articulator (VST3 version). In the process, a new “nJVI43le” folder was created in C:\ProgramData\PACE Anti-Piracy, and a new file called “tMVdJFGe.html” was placed there. Articulator VST3 now works again in WaveLab.

So obviously Trend Micro halted some PACE anti-piracy mechanism mid-processing during the WaveLab plugin scan, which caused a file to become corrupted in the C:\ProgramData\PACE Anti-Piracy folder. Obviously would like to avoid this again in the future, so…


I’d still like to submit this request to Philippe.

This sounds more like a PACE issue than a Wavelab issue. The Wavelab file is only shown as the culprit because it’s loading the PACE-protected plugin.

Boys
I use Kaspersky and never has this behaviour.

Steven

Thanks, Romantique Tp. I agree, although the plugin scanners of several other DAWs and audio platforms haven’t triggered the warning - only WaveLab’s.

Steven - but then you have to deal with keeping the backdoor closed! :open_mouth:

:confused: http://tinyurl.com/yamdzwfy
:frowning: http://tinyurl.com/y8pblc4e
:nerd: http://tinyurl.com/y89ervqc


Regardless, if WaveLab were simply submitted to the AV companies for whitelisting, wouldn’t be an issue.

What’s the problem in simply clicking the ‘Unblock’ button?

Arjan, thanks for your question.

  1. I did click the Unblock button. However, subsequently I had to find a manual workaround to fix a plugin issue (described above) caused by the initial halting of the plugin scan. Other users may not figure out what to do.
  2. As security software increasingly looks for ransomware-style (and other malware) patterns, it just makes sense for Steinberg (as a major software publisher) to collaborate with security software companies to have their applications whitelisted. Imagine if a customer brand-new to Steinberg bought WaveLab and received this “ransomware” warning - they’d probably be very suspicious of the product immediately. This situation is very easily avoided by simply working with security software companies for whitelisting.