See pinned #369. No app can control what anti virus tools do. You need to report the false positive to the anti virus tool, not to the affected app.

from clink.

Every once in a while I write a longer response on this topic, to try to help raise awareness and understanding. This is one of those times:

I’m sorry, but how is closing every issue raised that reports it as a Trojan a real solution?

Sending AV reports to me is useless: Only reporting them to the AV software is productive. They can do analysis and identify whether there's a real infection or a false positive. And if it's a false positive, then they can fix their detection logic. All I can do is close the issue, and try to share educational material about how AV systems work and how Clink works.

Can’t you re-compile it differently to get away from this virus signature?

There are many articles on how anti virus systems work (and different systems work differently). Here's an introductory article which might be helpful: https://www.kaspersky.com/blog/signature-virus-disinfection/13233/

If there were some technique Clink could use to stop getting flagged as malicious, then malicious programs would use the technique as well. But there isn't.

(It clearly isn't about re-compiling: v1.6.10 wasn't originally detected as a false positive. Windows Defender published a new AV signature file [which happens frequently, and sometimes even multiple times per day] and the new signature file suddenly started misinterpreting Clink v1.6.10. If/when the signature file gets fixed, then Defender will stop reporting about false positives in v1.6.10 -- without any changes in Clink.)

Have you tried installing it yourself on a non-dev machine with the GitHub download?

Have you considered that Windows Defender periodically deletes Clink from my machines as well?

Note that Clink is digitally code-signed as of v1.5.0 (I spend money for that every year, as a gift to everyone). You can check whether GitHub got compromised simply by checking the digital signatures on the Clink executable files.

This “pinned” message is worthless by the way. It is from Dec 2022 and many good updates have occurred since then. A past record false positives is no reason to trust the current situation. GitHub had been compromised many times recently.

The pinned message is trying to explain what to do in response to an AV report. And it's trying to share that (1) there's nothing Clink can do about it and (2) you have to contact the AV software about the report, not me.

Would it help to reorder and rephrase the troubleshooting steps to state "you have to contact the AV software about reports so they can analyze whether the report is real or a false positive, and so they can fix the AV software if it's inaccurately claiming the presence of malware"?

Q: Why is Clink particularly susceptible to AV false positives?

Because Clink does two things:

1. Clink injects a remote thread into another process, specifically the cmd.exe process. That's also a technique sometimes used by malware to gain more privilege on the computer, or to hide what it's really doing.
2. Clink hooks system APIs and replaces them with alternative implementations. That's also a technique sometimes used by malware to intercept data or alter behavior.

Clink is doing those operations for a legitimate purpose*, but some other programs do them for malicious purposes. And AV systems cannot simply say "oh the name of this file is clink_x64.exe and I know Clink is supposed to be good, so I'll ignore it". The AV system has to analyze and monitor Clink and form its own conclusions.

* No one has to trust me or take my word for it whether Clink is legitimate or benevolent: The source code is freely available for review -- you can observe it for yourself.

Q: Can't you redesign Clink to work differently?

No.

1. Injecting a remote thread is the only way to get into the cmd.exe process.
2. Hooking system APIs is the only way to override the behavior in cmd.exe.

There's no way for a program to tell an AV system "ignore me, I'm a good guy, trust me". If there were, then malware would do that. How's the AV system supposed to know whether to trust the program that says "trust me"...?

Q: Can't you test Clink to make sure it doesn't trigger false positives in AV systems?

No. Be realistic.

There are tons of different AV systems, and each publishes updated signatures very frequently (sometimes multiple times per day). Detecting malware is very complex (check the article linked above for a quick intro). I have better things to do with my very limited time on this earth than babysit AV systems.

AV systems know that false positives happen, and each AV system has a way to send them an AV report so they can analyze whether it's real or a false positive, and so they can update the signatures if it's indeed a false positive. There's no way for me to analyze other people's computers, and even if there were you shouldn't trust me because you have no way to know for sure that whoever you're talking with is really me (assuming you agree that I'm trustworthy in the first place).

AV systems rely on crowd-sourced feedback. They need lots of people sending potential false positives so they can analyze them.

from clink.

I appreciate your response and your dedication to this project. Thank you.

As of now, Windows Defender no longer reports it as a virus. The Dec 2022 message seemed out dated, and this was the first time for me that it has ever reported Clink as a virus. Windows Defender is the default AV for most everybody I believe, and so for an event like this, it may make sense to leave the "Clink reported as virus" issue open for a few days until others have seen it. I discovered that others had reported the same problem by sorting through the "closed issues" post.

from clink.

from clink.

I’m sorry, but how is closing every issue raised that reports it as a Trojan a real solution? This is reported by Windows Defender and anyone with Clink and an up-to-date system will get this message. Have you tried installing it yourself on a non-dev machine with the GitHub download?

Can’t you re-compile it differently to get away from this virus signature? Right now I will stop the automatic update messages until there is a new version that doesn’t register as a virus.

This “pinned” message is worthless by the way. It is from Dec 2022 and many good updates have occurred since then. A past record false positives is no reason to trust the current situation. GitHub had been compromised many times recently.

from clink.

I'll reopen this one for now, until enough people send reports to Defender for analysis and Defender fixes the signatures.

In case some people check existing open issues before adding new ones. But I'm not leaving more than one issue open for this (and there were multiple open duplicates already before I started closing them). Especially since the problem is in the AV software, not Clink, and opening issues here is useless -- they have to be sent to the AV software itself, not to me.

from clink.

for an event like this, it may make sense to leave the "Clink reported as virus" issue open for a few days until others have seen it. I discovered that others had reported the same problem by sorting through the "closed issues" post.

Yes, that's what I'll do differently in the future (leave one issue open temporarily, and link others as duplicates of it).

When I looked at issues the first time yesterday, there were already multiple duplicate open issues. I didn't think to leave one open in case people check open issues before adding a new issue.

I'll explore rephrasing things in the pinned issue (including its title) to be more clear as a general "what to do next" after experiencing an AV alert.

from clink.