-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Virus/trojan false positives: SMLRC has many false positives on Windows #26
Comments
How do you fix stupid? |
Ouch! |
Right, stupid antiviri. I don't know how to fix them. |
Let's keep this issue open and see if anyone knows how. |
Anyways, did you mean to insult me on purpose? |
@Shineonline I'm very sorry, stupid was not directed at you at all. Stupid is how those AVs are made and work. |
It's OK, I take mild insults like paper balls to the chest anyways |
So, here's the problem as I understand it... Figuring out what a program does or if it's somehow malicious is a problem that does not have a cheap solution (it's NP complete or some such). It's generally impossible to tell if a program even terminates or loops forever (see the halting problem). Instead those AVs rely more on finding code/data patterns that have already been seen in malicious or infected software. This is a much cheaper "solution". Those (sub)patterns, however, can be benign, hence false positives and the quotation marks. The thinking goes, as long as popular software like Windows itself isn't affected by false positives, all is fine. While this is helpful on the large scale of things, this approach can't work satisfactorily with arbitrary and never before seen software. I have played with the PE file structure a bit, but so far haven't found a reliable way to generate executables without false positives per virustotal. Even the simplest hello-world-like programs written in assembly (e.g. FASM demos) are flagged for no good reason. Unless someone figures out the precise pattern that the virustotal minions dislike, this issue isn't going to be resolved. Also, there may be something in the generated code and not the file format/structure. I'm definitely not going to write a vastly different code generator just to fix that. |
There's one clue, the "Rich header", which I haven't tried. OTOH, not every compiler generates it, since it's officially undocumented nor is functionally required. |
With the latest changes in .EXE generation there are some notable improvements: Before improvements, as of commit 4f1ab17, After improvements, as of commit 1776503, |
You should still keep the issue open, but that's an improvement |
virustotal seems to be fncking with us. At first, after another round of improvements in PE generation, it shows a good low number of false positives, then, 3 days later it magically finds another 10-15 false positives that it didn't show the first time. WTF. |
I think the idea is then to not make these online virus counters a metric of quality for your product. Ignore them? :) Develop independently of them seems a good idea. As you first said, "How do you fix stupid?" |
The problem is that based on these false positives, other software doesn't let one download and use the binaries. Also some people probably shy away from the binaries because they can't know any better and can only trust the AVs. |
I know, but then it's just like "propagation of stupid". You could create a parallel track. Otherwise, your development could be off-tracked by trying to meet these spurious ever changing criteria. I just think it's the wrong thing to optimize. Obviously it's not my project, it's up to you. Just wanted to contribute my attempt to help - the fear is that you'll start down this road and you'll never see the end of it. Anyway, I like what you're doing with smallerc i hope it succeeds!!! :) |
https://www.virustotal.com/gui/file/e96b3b77fe77d643ba8c3eea4f1a1b35ffe532cab6bfd65bb4b9b75264640554/detection
The text was updated successfully, but these errors were encountered: