Studies against AV false positives

[Blankname]

Only way to beat this plaque is to tackle it head on. Write little applications that serve a basic function and upload them to virustotal. If a specific engine detects it as a false positive, go to that companies website and report the false positive. I did this with Avira, and less than 3 days later they shipped out a new update to their clients that removed the detection. The more you complain and submit your test executable to these companies, the more it will cut back on future false positives. PureBasic isn't the only one that has these speed bumps with antivirus engines. And it wont be the last time, as dozens of new signatures are added to databases almost daily.

[jpd]

Hi ,

Norman not recognize the file anymore and the “old CRC algorithm” is removed in the new engine.

Is that your local IP? as in its trying to connect to your debugger?

Sorry my fault!
the list of event regarding the debug-machine used and not the file itself


Best
jpd

[Mohawk70]

However, I encourage everyone to fill out those detail informations in the compiler options (like company name, etc.) as it seems to be one of the aspects heuristics look for.
On one hand understandable that this might be an aspect but on the other hand a rather weak one

It seems the above might actually have some effect ... referencing my posts in this thread http://purebasic.fr/english/viewtopic.p ... e+positive I resubmitted the same empty executable - except with 'Version Information' ( all of the predefined fields ) set - to the three online scanners and got these results.

VirusTotal 0 Threats Found

MetaScan 0 Threats Found

Jotti 1 Threat Found (False Positive) : ClamAV : PUA.Win32.Packer.Purebasic-1

[MachineCode]

ClamAV always falsely flags PureBasic exes as a virus. It's a crap scanner. Unfortunately, most people will believe it.

[Mohawk70]

ClamAV always falsely flags PureBasic exes as a virus. It's a crap scanner. Unfortunately, most people will believe it.

Yep - but by taking the procedures I mentioned in my last post ( brought to the boards attention by another user ) it got rid of ALL of the other previous false positive detections. I wasn't trying to point out that Clam AV still flags it erroneously.

[SFSxOI]

1. If you are basing your "study" upon results from on-line AV scanners you are wasting your time.

2. The premise in this thread for determining suitability for determining a false positive is flawed by assuming that because some don't detect a false positive it means there is no real reason for a false positive, or that because some do detect it and it is a false positive then the detection is flawed. This is not a true assumption and is flawed fundamental logic because it specifically excludes the existence of conditions which caused the detection or lack of detection in the first place by any AV package. The very act of an AV package not reporting a false positive does not mean the underlying reason for a false positive is not present or still does not exist simply because its not reported, whereas the reporting of a false positive is an indicator almost 98% of the time the fundamental reason for the false positive still exists.

3. "Empty .exe files" are the least desirable thing to use in testing for false positives and then assume its 'emptiness' will be a true test foundation.

4. False positives generally in a broad sense are false positives in the sense they are not malware. However, not all false positives are actually false positives nor are they actual malware but sometimes coding does mimic actual malware signatures unintentionally especially when a non-standard language (such as PureBasic) is used because of the way the language addresses the underlying API or uses non-standard language specific methods in addressing the underlying API.

Not all false positives are caused by the file its self or the user coding structure in the file. Sometimes its a weird combination of various things that seems to trigger a false positive, but that's most likely not the actual cause even if compensating measures seem to get rid of the false positive notification/reporting. The true underlying cause of the false positive is still 95% of the time caused by the manner in addressing the underlying API by the language methods used in the language its self. It can be as small as a single implementation, and is especially true in non-standard languages addressing underlying API across a wide range of operating system versions/generations, and may in some cases even be aggravated for certain combinations of things installed in the operating system or for the language its self by user. Sometimes the language API addressing methods causing a false positive may not manifest its self until a certain combination in coding structure is used where other uses of the same language functions may be fine for others. Although a change or coding in the AV package to compensate in some way and exclude the false positive detection may have caused the false positive to not occur in a notification/reporting sense the fundamental reason for the false positive is still there, and thus the reason why one AV package may seems to "detect" it and another may not seem to "detect" it simply because one essentially masks its notification/reporting and another doesn't due to the way the AV package implements the detection exclusions. Those AV packages that don't report it still detect it but just don't report it and skip it but they still detect it because its still there (the underlying cause), a false positive never truly goes away until the underlying cause is removed its just not notified or reported by those AV packages that don't notify about it or report it. So results for an AV package that doesn't report it vs one that does report it is overall moot in terms of actual detection analysis of the false positive because they all detect the false positive its just that some don't notify about it or report it and some do. In a weird ironic way a false positive is not actually a false positive but instead still a positive detection, just not one to be concerned about from or involving a malware aspect so its only false in that aspect.

[Didelphodon]

Man you must have studied philosophy, did you?

However, imho a study tries to cover each (or at least most of the) relevant aspects bound to the underlying topic.

So in this terms it makes perfect sense to start with "empty" builds and change/enhance them step by step because otherwise its kinda hard to identify the actual reason(s) for a changing habit of the corresponding blackbox. And yes in this case we're dealing with a blackbox. So what we are doing here is just comparable to reverse engineering a blackbox.

Having said this every aspect one might contribute to this study is welcome. Imho we're heading in the right direction but we're definitely not done yet. Just to keep this in mind.

Cheers,
Didel

[SFSxOI]

Nah, we do this type of stuff for a living professionally. We contract to a lot of these AV package companies to examine these types of things every day.

[IdeasVacuum]

If you are basing your "study" upon results from on-line AV scanners you are wasting your time.

It isn't a waste of time because your customers may well use these services to check your app - so, better if your app is shown clean, regardless of how effective online services really are.

[SFSxOI]

I meant it was a waste of time using such to base a study on, because it excludes the conditional environment for finding the real trigger cause and settles for the cosmetic notification/reporting instead. That's all your actually seeing with AV packages that do not report/notify for 'false positives', a cosmetic effect of simply not reporting it while the real cause still exists and is detected anyway and simply not reported.

[IdeasVacuum]

Imho we're heading in the right direction

That is true, kudos to you, I didn't think it would be useful but it clearly is.

One issue not mentioned is the standard of coding of AV apps, some of which is very sloppy. Hundreds of thousands of Users have accepted an auto-update from their AV vendor, only to get issues from the AV app itself ~ who could forget the BitDefender BSOD? On a smaller scale, I have found that when an AV App has a new full release, some of what the old app 'knew' has somehow been lost..... quite frankly, I think a lot of the AV stuff is below par at best, and possibly some of it is a sham. It wouldn't suprise me if at sometime in the future we hear that certain viruses were created/distributed by an AV vendor - do they already use false-positive flags to scare Users into continuing their subscription?

[Didelphodon]

Nah, we do this type of stuff for a living professionally. We contract to a lot of these AV package companies to examine these types of things every day.

My daily business is malware analysis, reverse engineering and computer forensics, so what. No need to be that dismissive!

According to what you said you should be aware that a lot of samples the AV industries receive come directly from virus total. So it makes perfectly sense to (also) focus on this stuff as its highly probably that one might throw a downloaded executable (ie our PB built ones) into virus total to get an initial glance. And bam, then its on its way to the AV companies.
I do see this habit of people all the time.

However, as you also are kinda close to AV and things in this fields Im looking forward to your productive contribution to this thread helping us by mitigations or even solutions but not trying to sap our efforts on this which btw already brought some quite interesting details.

Cheers,
Didel

[SFSxOI]

I wasn't being dismissive, I apologize if you assumed it as such.

That's our daily business too, with approximately, world wide, several hundred people doing it, some of them recognized experts in the field and even representatives from the various AV package companies working with us, among other things dealing with the same area and so much more extending beyond your stated 'qualifications'. Some of those fixes for 'false positives', and actual malware, they began at or were developed by us for some of those AV package companies. Anyway, i'm not really trying to contribute in this particular discussion as our company rules prohibit such in this aspect, just trying to point out indirectly and that's because we already know why some PureBasic files may detect as a false positive or not. If your daily business is malware analysis it would have been somewhat obvious to you too. Anyway, have fun.

[Didelphodon]

I wasn't being dismissive ... If your daily business is malware analysis it would have been somewhat obvious to you too.

So how would you call that?

[SFSxOI]

.[/quote]
My daily business is malware analysis, reverse engineering and computer forensics, so what. No need to be that dismissive!
[/quote]

I wasn't being dismissive ... If your daily business is malware analysis it would have been somewhat obvious to you too.

So how would you call that?

I wish you had not asked that question, I did not want to do this. However, you asked, so here is the answer as nicely as I can put it.

How I would call that? The truth, that's how I would call that. If this is a "study" and you are a malware analysis person and its your daily business you would have known from the very beginning you can't analyze a 'false positive' (or even an actual malware positive) for a study while specifically excluding the conditional environment yet you specifically excluded such by using and then indirectly declairing 'Virus Total' as correct when you have no empirical proof that it is and you would have known that depending on the cosmetic results of if something is reported as or not reported as a false positive does not tell you if the cause still exists or not when in reality the cause still exists. You would have accounted for this in any true analysis if you were a malware analysis person, but you didn't, so your results for analysis are flawed and the premise of analysis conduct was based upon a flawed methodology to begin with.