Chrome/Windows Defender Detecting Virus

Hey guys. When I try to download HFS from the main page I get a virus detected error from Chrome and Windows Defender on Windows 10, but when I go to the forum and download a beta version it works fine and I am able to run it. Was the server hacked or something or is Windows nuts?

It's common to many antivirus to flag HFS as "suspicious", since HFS is a file server. But if your HFS executable match the above checksum, you can be sure it's only a "false positive" (safe to run).

Download it again, and if Windows Defender continues detecting virus, check the option "Allowed items", but do NOT run yet. Check if your downloaded file matches the above checksum. IF IT DOESN'T MATCH, DO NOT RUN IT!. Report back when you done that, or if it's solved.

in windows 10, i can personal say that HFS and Chrome are not virus, i have not had windows defender come up ans say x and x is infected, i would assume an extension in chrome would be the cause, and i would have you double check you system, as the windows defends picks up a registry issue as the virus.. (as seen via the picture in your post)

Windows defends has never "tagged" HFS as a problem, and i've made sure HFS (talking with Microsoft and with reports) wouldn't be flagged as long as "if" it didn't violate x and x rules...(this was done for windows 7 and 8 widnows 10 is still new...) there are other post with HFS was being considers a virus....(false positive)

Trojan:Win32/Skeeyah.C!plock"Trojans are a type of malware that try to look innocent to convince you to install them on your PC.They can steal your personal information, download more malware, or give a malicious hacker access to your PC."

since it "stop" with a working new fresh download, there is probably something wrong with your HFS excutable, there fore a trojan or virus that "hijacks HFS" (excutables specficaly), could be at fault here....

which leads me to believe that you machine may still have that virus...windows defends done't protect you from everything...

I doubt that. This is a fresh install of 10 with next to nothing on it yet. I was more intrigued by why I did not raise any flags downloading and using the beta build but I encountered the problem with the release version.

i forgot to say that I experienced the same problem reported by celsup85, and it happened when downloading the exe from the official website. Doesn't happen if you download it from sourceforge (where it is zipped).The reported exe is safe anyway, i compared it with the one downloaded from SF, and they are the same file.This should answer some questions.

i forgot to say that I experienced the same problem reported by celsup85, and it happened when downloading the exe from the official website. Doesn't happen if you download it from sourceforge (where it is zipped).

That sounds weird. As suggestion, maybe you should start posting SHA1/MD5 information along every release (like other developers do) to make sure everyone gets the correct file. I did a test, downloading the EXE file from every known mirror (outside SF), and all the mirrors are OK (all have the SHA1 = 0201A9B06AF1B7B15BF00420CE439A98609C82FE).

All this leads me to this crazy idea: what if your ISP is caching the file, and serving an infected file? I think this can be solved, setting up a "no-cache" configuration in your server. I don't know exactly how that can be done, but I did some Google searches, here, here, and here (which can be of help). And maybe adding something like this (in the 'rejetto.com/hfs/download' script), prevents the ISP caching system:

i don't know of ISPs caching files without asking you to configure a proxy in your browser.Anyway, i don't see how this case could be related to the problem, as i compared the 2 files and there was no difference.

i don't know of ISPs caching files without asking you to configure a proxy in your browser.

This has nothing to do with a proxy or a setting in your browser. Sadly, many ISP do this automatically and without asking for permission (and without user intervention), to reduce bandwidth (and you don't even notice when they do it).

One link I've posted above, explains it better: "It is a common practice of ISP's to cache any possible file from downloading it again. As an overall result this will save ISP's lots of bandwidth although you paid for your internet download not for ISP to client download".

For example:

> Some Tiscali user asks for the file http://example.com/program.exe. If the ISP (Tiscali) has the file cached, they deliver his cached version (and not the file stored in the example.com server). This way, the ISP saves bandwidth (they do this mostly with data stored in another country, generally to save on international bandwidth traffic).

> Another exaple, some Wind user, asks for the same file, but his ISP is good and doesn't cache any file, so, the user is actually downloading the file directly from the example.com server (and not from the ISP cache).

(Both examples are fictional. I have mentioned ISPs from Italy, but it can be any ISP worldwide. I exactly don't know if those two ISP, are actually caching files)

Anyway, i don't see how this case could be related to the problem, as i compared the 2 files and there was no difference.

It may be related (or not), but you can't be 100% sure the ISP cache always delivers a clean file, and to known if the end-user is actually downloading the file from your server or the ISP cache. That's why MD5/SHA1 checksums are important, and mostly important to prevent any ISP to cache the file (using the no-cache setting), IMHO.

When I loaded 2.3f, Avast and Avira both gave me grief. When I switched to 2.3g, it did not get flagged, but perhaps the exceptions I added for 2.3f carried over, since it ended up having the same name. Hard to say unless I experiment.

virus alerts about hfs from the fact that it acts as a web server, and also because sometimes rejetto compress it with upx executable software to take up less space, downloaded from the official site of rejetto, hfs poses no major risk of viral infection