When I was working on this program, I did a Make at one point to sanity-check the syntax after some changes I had made in the Worker Project here. This triggered Defender (Windows 10 2004):
Trojan:Win32/Vibem.C
The application consists of 2 Projects, Client.vbp and Worker.vbp, which work together.
Client.exe starts an instance of Worker.exe, they rendezvous via broadcasts of a custom registered window message, and then they communicate further using WM_COPYDATA and a few application messages numbered starting at WM_APP.
Worker simulates a long-running background workload. It gets a count of desired rows and columns, creates a 2D Double array, fills it with Rnd() values, to simulate a slow crunching activity it calls Sleep(1000) after each row, and reports progress and checks for a Cancel indication from Client. Finally, if not canceled, it returns the array contents to Client where the values are displayed in a grid control.
Seems like pretty generic stuff, really.
So why did this trigger a malware warning? Why did this go away after making a few more changes?
Any ideas?
I'd like to think that it was merely due to chance that something in the compiled program matched a malware signature. A "something" that was no longer there after more program changes.
The problem did not occur until I added the use of my WM_APP_SYNC message. That's probably mere coincidence though since the working "non-offending" programs work fine and Defender doesn't cry at all.
Last edited by dilettante; Oct 19th, 2020 at 02:25 AM.
all my programs gets reports, but usually from antivirus that are unknown.
so if I upload my exe to virustotal, theres at least a few reports.
but, sometimes I get a lot, if I use API that "could" be harmful. I could get 1/3 of all the antiviruses in (virustotal) that alerts as malicious.
this is quite known that antivirus dont like VB6.
also, you can get alerts from a empty project (no API, nothing) that do absolutely nothing.
sometimes it can help if u compile with native or pcode. could help with a few less reports.
We have a large applications split into several DLLs/OCXs which are 5-20MB in size. Although we use a lot of thunking and other virus-like techniques these never get flagged by any AV on VirusTotal.
I guess the false-positives are more likely for small executables, more like the ones used by actual malware.
Well we don't know what antivirus software uses exactly, and it would probably aid in defeating them anyway.
Size might be just one more thing adding to the "hazard score" along with other things like being VB6 code. I was more curious why the program got flagged as belonging to that specific category of malware though, and just as curious why it mysteriously stopped being flagged after some minor changes.
Most probably imperfect signatures combined with flawed heuristics. It's impossible to know if a piece of code is malicious. They try to use AI for guessing and fail spectacularly sometimes.
When I was working on this program, I did a Make at one point to sanity-check the syntax after some changes I had made in the Worker Project here. This triggered Defender (Windows 10 2004):
The application consists of 2 Projects, Client.vbp and Worker.vbp, which work together.
Client.exe starts an instance of Worker.exe, they rendezvous via broadcasts of a custom registered window message, and then they communicate further using WM_COPYDATA and a few application messages numbered starting at WM_APP.
Worker simulates a long-running background workload. It gets a count of desired rows and columns, creates a 2D Double array, fills it with Rnd() values, to simulate a slow crunching activity it calls Sleep(1000) after each row, and reports progress and checks for a Cancel indication from Client. Finally, if not canceled, it returns the array contents to Client where the values are displayed in a grid control.
Seems like pretty generic stuff, really.
So why did this trigger a malware warning? Why did this go away after making a few more changes?
Any ideas?
I'd like to think that it was merely due to chance that something in the compiled program matched a malware signature. A "something" that was no longer there after more program changes.
The problem did not occur until I added the use of my WM_APP_SYNC message. That's probably mere coincidence though since the working "non-offending" programs work fine and Defender doesn't cry at all.
Apply for a digital signature. Another digression. If there are multiple subroutines communicating with the control program, it is estimated to use mutual exclusion
Another digression. If there are multiple subroutines communicating with the control program, it is estimated to use mutual exclusion
That isn't what I'd consider a "finished" version. Later versions addressed the matter of separation among multiple instances of the Client (so each gets its own Worker rather than getting "their wires crossed"). The goal was a separate Worker for each Client, not a shared Worker server. That's probably easy enough to do as well though.
Perhaps you are asking about multiple Worker processes used by a single Client (UI process)?
That's easy enough too, but it probably makes more sense to have Workers that can perform several kinds of operations rather than one Worker per kind of background activity. Why get greedy? Do you really need multiple background activities running in parallel?
The main reason for this is keeping the UI responsive in a program that needs to do large amounts of crunching. If things get too intense you might be better off using several separate Worker machines. At that point you can use DCOM, TCP, Named Pipes, MSMQ, etc. to link processes together.
But you can do whatever you want.
This was just an example of something that got flagged and I wondered if there was anything specific it does that might cause it to be flagged as malware.
That isn't what I'd consider a "finished" version. Later versions addressed the matter of separation among multiple instances of the Client (so each gets its own Worker rather than getting "their wires crossed"). The goal was a separate Worker for each Client, not a shared Worker server. That's probably easy enough to do as well though.
Perhaps you are asking about multiple Worker processes used by a single Client (UI process)?
That's easy enough too, but it probably makes more sense to have Workers that can perform several kinds of operations rather than one Worker per kind of background activity. Why get greedy? Do you really need multiple background activities running in parallel?
The main reason for this is keeping the UI responsive in a program that needs to do large amounts of crunching. If things get too intense you might be better off using several separate Worker machines. At that point you can use DCOM, TCP, Named Pipes, MSMQ, etc. to link processes together.
But you can do whatever you want.
This was just an example of something that got flagged and I wondered if there was anything specific it does that might cause it to be flagged as malware.
You are right. But I did it by using mutual exclusion.