incorrectly detecting OpenSSL and MadCodeHook SW as a virus

when i build my executable using OpenSSL (found at http://www.openssl.org/ ) and a code hooking library called madcodehook (found at http://www.madshi.net/ ) your software detects my software as a virus. we have tried many times to send you samples with no response from your team about how to fix this or when a fix would be available which would fix this.

is there a way of solving this issue without involving lawyers?

 

Could you please PM me your email address? False positives are dealt with the highest priority so I'd need to make sure that we have actually received it.

 

sent.

 

Thanks, Marcos.

 

Marcos,

any update on this?

 

Are you still having a problem detecting GSClient.exe even with the latest version 3506? I've scanned it and the file was reported clean.

 

Marcos,

thank you. it appears as if all our release executables which link against openssl and madcodehook are no longer detected as a virus.

however you seemed to just add an exception for just my product GSC. as if i make a new executable using our libraries that uses openssl and madcodehook it is still detected as a virus (screenshot here http://www.fileswap.com/share/?id=86f3f50a6f945bbfa351e55faac043fb ) which implies to me that you still haven't fixed the issue. as i can not guarentee to our customers that this issue will not reappear.

i'm also confused about how i would know to test the executable again without you posting in this thread or PMing me the issue should be resolved?

can you please resolve the issue so any product our or others which use any version of openssl and madcodehook will no longer be detected as a virus?

 

Please submit the new executable as you did last time. We've made a quite generic fix for the files you've sent so I wonder how much they've changed that new versions are detected again.

 

followed instructions on this page http://www.eset.com/support/kb.php?option=com_kb&Itemid=29&page=articles&articleid=141
for submitting the executable. from my email address i PMed you.

 

We've analysed the file and came to the conclusion that detection of Madcodehook cannot be cosidered false positive. Madcodehook is often exploited by malware and there are apparent strings that confirm that. The dll itself is not detected, but it handles processes in a highly suspicious way. In addition, there are other highly suspicious functionalities that trigger heuristics.

 

Marcos,

i would highly recommend your company reexamine this issue.

 

i understand your decision, however shouldn't the executable not be flagged as a virus if it is using the library but not doing anything the virus related.

does the library contain a virus? i assume your answer is no. so why is it be detected as a virus.
does our executable do anything with this library in a virus fashion? no. so why do we continue to get flagged as a virus.
does the example executable do anything that can be considered a virus? no. so why is it being flagged a virus.

does that mean you detect usage of Microsoft Detours as a virus? or Value's steam SW as a virus? or xfire's client as a virus?

basically your software is creating a "no-fly list" for software that has the name madcodehook, and not the actual terriorist.

 

Are you aware that there are about a dozen (or more) security products on the market which are using madCodeHook, too? If you flag madCodeHook as malware then you will automatically flag some of your very competition as malware.

Let me ask you a question: If a virus used format.exe to format the harddisk of the user, would you classify format.exe as a virus, too? Or if a virus used the Microsoft hooking API "SetWindowsHookEx" to do bad stuff. Would you classify every application which calls "SetWindowsHookEx" as being malware? Because that's basically what you're doing right now with madCodeHook.

There is also malware which uses Microsoft Detours as a hooking library. So are you classifying all applications which are using Microsoft Detours as malware, too? That would include some of Microsoft's own software.

The real duty of a security software provider like you is to detect the actual malware. And not some general purpose libraries the malware might be (mis)using.

 

Amen...

 

Marcos,

can you company provide any insight about why you are classifying this and not other hooking libraries as a virus?

or does your company believe that all people who buy guns are murderers?
or does your company believe all people on "no-fly-list" are terrorist?
or does your company believe that all people who look into viruses are cyber terrorist?

because if the 3rd was true then your company are all cyber terrorist.

 

bumping thread

 

JFYI: Other AV products are doing the same thing:
http://www.sophos.com.au/security/analyses/adware-and-puas/madcodehook.html

http://vil.nai.com/vil/content/v_142162.htm

I agree with your argumentation, that if someone is just buying a weapon, he/she must not be a murder. But you should also understand the problem, Eset and other AV companys have to deal with:

Their job is to protect normal customers against different kind of threats.

You are using a API, which is often used by different malwares (that's a fact). There isn't a serious company behind this API. I think the API offers things, normal application didn't need and shouldn't use (I cannot image a reason, why a normal program should block a termination call for example).

If your application is special, explain it to your customers. Tell them, that they need to exclude the application folder from beeing scanned by ther AV product (that's the reason why there is a exclude function in most AV products). That shouldn't be a problem, because your application is "special"...

 

That's not the same at all. Click on the tab "more information" on the Sophos site. There is clearly says:

""MadCodeHook" is a legitimate library used to intercept system calls of various processes."

McAfee basically says the same. McAfee doesn't generally "detect" madCodeHook as malware. It only reports a problem if very specific APIs are hooked (FindFirstFileA/W) which you usually hook to hide files.

None of my customers has any problems with either Sophos or McAfee.

Misused, not used. But unfortunately it is correct that it has been misused by malware. That's about the only thing you said which is correct.

What am I? An easter bunny?

There are many many things API hooking can be useful for. E.g. it helps with monitoring and managing printing. It helps with automating applications. It helps with access protection. Blocking a termination call is crucial in specific situations: E.g. in an internet cafe or in a school there are control applications running, limiting access to some resources. These control applications must not be must terminated, obviously. The same applies to parental control systems.

And maybe you overlooked the fact that virtually every security product on the market uses API hooking. And about a dozen of them have licensed and are using my madCodeHook API hooking package.

That is not acceptable to any of my customers.

 

will continue to bump until nod32 agrees not to detect madcodehook.

 

You think that this is the right way?

Go to VirusTotal.com and upload your demo archive (for best result, scan single files). All the big players and even some small AV companies are detecting your applications.

Do you think that they are thinking "Hey, let's destroy the business of a small company all together!"?

When you offer your lib for free or sell it to bad guys, who abuse it for their malwares, it's becoming your problem. Someone could just change a bit in it's program, AV products would have problems detecting it. But because of the fact they cannot change your lib that way, it is easier to detect the lib.

And as I said before:
I don't see a problem in telling your customers the reason. You are offering special functions, so you have to deal a special way with it.

That's all I have to say.

 

musikit does not offer a lib. I am. But I don't offer it for free nor do I sell it to the bad guys. I did at one time offer my library for free (in the naive believe that the world would be good), but I did block some specific APIs from being hooked in the hope that that would prevent misuse of my library. But it didn't, sadly, so I've stopped the free version quite some time ago. These days I'm double checking every new customer to make sure that no malware programmer gets access to newer madCodeHook builds, anymore. The next major version of madCodeHook will even require madCodeHook users to sign their software with an official certificate (e.g. Verisign) to make it near to impossible to malware programmers to further misuse madCodeHook.

I think you have no idea of how business works. Such a thing is totally unacceptable to any commercial company.

The situation is very clear: musikit's software is totally legit. So it is morally and legally wrong for any anti-virus company to classify it as malware.

I wonder how you could possibly argue against that. Do you believe anti-virus companies may bypass the legal system "for the greater good"?

 

will continue to bump until nod32 agrees not to detect madcodehook.