[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.vb.general.discussion

[OT] What's your experience with false positives?

(nobody)

9/20/2011 5:42:00 PM

Recently I switched from using MS Winsock control to CSocket class with
minor modifications to it. I am only using it for UDP. I still use MS
Winsock control for TCP because it would require "a lot" of code changes. I
have a client EXE and server EXE. The client EXE doesn't trigger any false
positives, but the server EXE triggers false positives in 4 out of 44
antivirus products according to http://www.viru... I am compiling in
a clean machine with no Internet access and digitally signing the
executables. Both the client and server use CSocket for UDP.

I commented out the body of all routines in CSocket and MSocketSupport
module(between Sub/End Sub for all routines), and that didn't help. Then I
commented the API declarations and the false positives are gone. I tried to
put these API declarations in a different sequence and in another module,
but that didn't help.

I also made a second attempt, commenting out TCP functionality because I
don't use it, and that reduced the number of false positives by one.
Further, I removed CSocket and moved its functionality into MSocketSupport,
and renamed MSocketSupport to Module10, but that didn't make any difference.

I can report these false positives, but I am worried that they would only
exclude this version, perhaps based on the file checksum, and that I would
have to report the false positives again for every future version until I
find what triggers these false positives. I am not sure if I would have to
do that, this is the main question I am asking.

Here are the products that triggered these false positives:

Commtouch
F-Prot
K7AntiVirus
VIPRE

The first two seem to be the same product with a different name. The last
one is the one that objected to TCP functionality, and removing it no longer
triggers false positives for that product.

Other than CSocket change in this version, I changed file I/O calls to use
the W version of API functions in case some file and folder names are in
Unicode rather than use VB's own file I/O statements, but this change is in
both client and server, and only the server triggers the false positives.
The prior client/server version doesn't trigger any false positives.
11 Answers

(nobody)

9/20/2011 10:01:00 PM

0

"Nobody" <nobody@nobody.com> wrote in message
news:j5aj97$1qq$1@speranza.aioe.org...
> Here are the products that triggered these false positives:
>
> Commtouch
> F-Prot
> K7AntiVirus
> VIPRE

After spending several days to see if I can change anything to make the
false positives go away, I narrowed it down to 3 API functions:

WSAStartup()
listen()
recvfrom()

Using an alias like "MyFunc" doesn't work. Here is the breakdown by
antivirus product(copy to Notepad to view it easily):

WSAStartup listen recvfrom
Commtouch Y Y Y
F-Prot Y Y Y
K7AntiVirus Y Y Y
VIPRE N Y N

"Y" means reporting false positive.

Obviously there is something besides these API functions that triggers the
false positives as they are present in the client without problems. After I
discovered the above, I reverted back to the backup copy with CSocket with
minor changes, and recompiled with only 6 lines of code commented out. These
are the 3 API functions above, and the places they appeared in, and the
false positives are gone. I can use WSARecvFrom() instead of recvfrom(),
which the antivirus programs didn't object to, but there are no alternatives
for WSAStartup(), or listen(). I may have to make a small DLL wrapper and
call these functions directly, but I don't need to use listen(). I am using
MS Winsock control, and it's probably calling WSAStartup() for me. I will
know soon enough if I need a separate DLL.

Henning

9/20/2011 10:18:00 PM

0


"Nobody" <nobody@nobody.com> skrev i meddelandet
news:j5b2fk$ar3$1@speranza.aioe.org...
> "Nobody" <nobody@nobody.com> wrote in message
> news:j5aj97$1qq$1@speranza.aioe.org...
>> Here are the products that triggered these false positives:
>>
>> Commtouch
>> F-Prot
>> K7AntiVirus
>> VIPRE
>
> After spending several days to see if I can change anything to make the
> false positives go away, I narrowed it down to 3 API functions:
>
> WSAStartup()
> listen()
> recvfrom()
>
> Using an alias like "MyFunc" doesn't work. Here is the breakdown by
> antivirus product(copy to Notepad to view it easily):
>
> WSAStartup listen recvfrom
> Commtouch Y Y Y
> F-Prot Y Y Y
> K7AntiVirus Y Y Y
> VIPRE N Y N
>
> "Y" means reporting false positive.
>
> Obviously there is something besides these API functions that triggers the
> false positives as they are present in the client without problems. After
> I discovered the above, I reverted back to the backup copy with CSocket
> with minor changes, and recompiled with only 6 lines of code commented
> out. These are the 3 API functions above, and the places they appeared in,
> and the false positives are gone. I can use WSARecvFrom() instead of
> recvfrom(), which the antivirus programs didn't object to, but there are
> no alternatives for WSAStartup(), or listen(). I may have to make a small
> DLL wrapper and call these functions directly, but I don't need to use
> listen(). I am using MS Winsock control, and it's probably calling
> WSAStartup() for me. I will know soon enough if I need a separate DLL.
>
>

My thougth is that the problem is for the *few* antivir apps to solve, since
they are false.

/Henning

Bob Butler

9/20/2011 10:37:00 PM

0


"Nobody" <nobody@nobody.com> wrote in message
news:j5aj97$1qq$1@speranza.aioe.org...
> Recently I switched from using MS Winsock control to CSocket class with
> minor modifications to it.

Just a couple of weeks ago I put together a quick little app to scan a
directory of log flees and extract specific error entries from the text.
McAfee reported the app clean but the filters on the corporate exchange
servers reported that it was infected with some generic virus signature. It
did nothing but standard file I/O. I ended up adding a form to display
progress and re-arranged a lot of the code and the problem finally went
away. It was a pain in the butt.

argusy

9/21/2011 1:47:00 AM

0

On 21/09/11 8:06 AM, Bob Butler wrote:
>
> "Nobody" <nobody@nobody.com> wrote in message
> news:j5aj97$1qq$1@speranza.aioe.org...
>> Recently I switched from using MS Winsock control to CSocket class with minor
>> modifications to it.
>
> Just a couple of weeks ago I put together a quick little app to scan a directory
> of log flees and extract specific error entries from the text. McAfee reported
> the app clean but the filters on the corporate exchange servers reported that it
> was infected with some generic virus signature. It did nothing but standard file
> I/O. I ended up adding a form to display progress and re-arranged a lot of the
> code and the problem finally went away. It was a pain in the butt.
>
directory of log flees (sic)?

Source of the infection? <grin>

<groan)... there's sure to be other responses....

Graham

(nobody)

9/21/2011 2:04:00 AM

0

"Nobody" <nobody@nobody.com> wrote in message
news:j5b2fk$ar3$1@speranza.aioe.org...
> I can use WSARecvFrom() instead of recvfrom(), which the antivirus
> programs didn't object to, but there are no alternatives for WSAStartup(),
> or listen(). I may have to make a small DLL wrapper and call these
> functions directly, but I don't need to use listen(). I am using MS
> Winsock control, and it's probably calling WSAStartup() for me. I will
> know soon enough if I need a separate DLL.

I just used WSARecvFrom() instead of recvfrom(), and commented out
listen/WSAStartup/WSACleanup and the software is working fine. Apparently MS
Winsock control is calling WSAStartup early enough. I am using CSocket
functions before MS Winsock control in Form_Load that contains the MS
Winsock control, but I could put them the other way around. Anyway, no more
false positives for me.

Bob Butler

9/21/2011 3:11:00 AM

0


"Nobody" <nobody@nobody.com> wrote in message
news:j5bgmr$cm9$1@speranza.aioe.org...
> "Nobody" <nobody@nobody.com> wrote in message
> news:j5b2fk$ar3$1@speranza.aioe.org...
>> I can use WSARecvFrom() instead of recvfrom(), which the antivirus
>> programs didn't object to, but there are no alternatives for
>> WSAStartup(), or listen(). I may have to make a small DLL wrapper and
>> call these functions directly, but I don't need to use listen(). I am
>> using MS Winsock control, and it's probably calling WSAStartup() for me.
>> I will know soon enough if I need a separate DLL.
>
> I just used WSARecvFrom() instead of recvfrom(), and commented out
> listen/WSAStartup/WSACleanup and the software is working fine. Apparently
> MS Winsock control is calling WSAStartup early enough. I am using CSocket
> functions before MS Winsock control in Form_Load that contains the MS
> Winsock control, but I could put them the other way around. Anyway, no
> more false positives for me.
>
>

Bob Butler

9/21/2011 3:11:00 AM

0


"argusy" <argusy@slmember.on.net> wrote in message
news:4e794275$0$11111$c3e8da3@news.astraweb.com...
> On 21/09/11 8:06 AM, Bob Butler wrote:
>>
>> "Nobody" <nobody@nobody.com> wrote in message
>> news:j5aj97$1qq$1@speranza.aioe.org...
>>> Recently I switched from using MS Winsock control to CSocket class with
>>> minor
>>> modifications to it.
>>
>> Just a couple of weeks ago I put together a quick little app to scan a
>> directory
>> of log flees and extract specific error entries from the text. McAfee
>> reported
>> the app clean but the filters on the corporate exchange servers reported
>> that it
>> was infected with some generic virus signature. It did nothing but
>> standard file
>> I/O. I ended up adding a form to display progress and re-arranged a lot
>> of the
>> code and the problem finally went away. It was a pain in the butt.
>>
> directory of log flees (sic)?
>

*^%&^%& spell checker!

Wolfgang Enzinger

9/21/2011 7:17:00 PM

0

"Nobody" <nobody@nobody.com> wrote:

>I can report these false positives, but I am worried that they would only
>exclude this version, perhaps based on the file checksum, and that I would
>have to report the false positives again for every future version until I
>find what triggers these false positives.

This is a realistic assumtion, sadly. A couple of months ago I had exactly a
problem of this kind with one of my applications; the TrendMicro scanner
marked it as suspicious malware (BUZUS or something the like). I reported this
several times, they did indeed confirm the application was clean, but
everytime all they did was to whiteliste the EXE checksum; consequently the
next version was again falsely detected as malware.

However I did not not accept that, and at some point I sent them a new compile
at least once a week; finally they investigated the case a little deeper. The
solution was to move my VB project to a different directory (!); originally
there was the word "encrypted" in the path (because the app handles an
encrypted SQLite database), and since VB compiles the project path into the
EXE for whatever reason, this triggered the false positive. Duh. There's for
sure no way to find that out without a pointer.

>F-Prot

Contrary to what I wrote above, I seem to remember a similar incident with
F-Prot a while ago, and after my *first* report they obviously changed their
recognition logic; at any rate the problem was gone (also after recompiling)
without any change on my side.

I absolutely agree with Henning: the problem is not in your app, but in the
respective antivir software; it should be solved on the side where it
originated.

(nobody)

9/21/2011 10:16:00 PM

0

"Wolfgang Enzinger" <we_usenet@nurfuerspam.de> wrote in message
news:fhbk77t9pndjtnncrmhe19pl49g29mnco5@4ax.com...
> However I did not not accept that, and at some point I sent them a new
> compile
> at least once a week; finally they investigated the case a little deeper.
> The
> solution was to move my VB project to a different directory (!);
> originally
> there was the word "encrypted" in the path (because the app handles an
> encrypted SQLite database), and since VB compiles the project path into
> the
> EXE for whatever reason, this triggered the false positive. Duh. There's
> for
> sure no way to find that out without a pointer.

VB doesn't include the project path into the EXE, but form, module,class,
UserControls and project names are(Such as Form1, Module1, Project1, etc.),
and also any Public Function/Sub/Property name in object modules(form,
class, UserControls). Public Function/Sub/Property in standard modules are
not included.

Also, Debug.Print statements are not removed in the EXE, so any string you
have in them ends up in the EXE. Debug.Assert statements however are
removed.

Dee Earley

9/22/2011 7:55:00 AM

0

On 21/09/2011 23:15, Nobody wrote:
> VB doesn't include the project path into the EXE

It does if you have symbolic debug info enabled.
It also seems to include a full path to most of the COM DLLs I use.

> Also, Debug.Print statements are not removed in the EXE, so any string you
> have in them ends up in the EXE. Debug.Assert statements however are
> removed.

They aren't evaluated though.
I accidental Debug Printed the result of an important function to figure
out what it was doing, and took me a while to figure out why it wasn't
being called at all when compiled.

--
Dee Earley (dee.earley@icode.co.uk)
i-Catcher Development Team
http://www.icode.co.uk...

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)