9.0.2 bugn.exe detected as Trojan:Win32/Occamy.C by Windows Defender

jcarpoff commented 5 years ago

I'm assuming this is some false positive related to being a compiled autohotkey script (a casual search indicates this happens from time to time).

Also at the moment according to VirusTotal 28 other virus engines are triggered by this version of the executable.

Assuming this is a false positive perhaps a note confirming this would be nice.

The VirusTotal results: https://www.virustotal.com/#/file/23a183d7e6de87a0b200cec985a0b01b5e5357b54d79fa3fa4ddd552e156b884/detection

arruw commented 5 years ago

Same here...

ertwro commented 5 years ago

I think there's actually a reason for concern @joten. The sha256sums for the bugn.exe file built by SILKIE_jn included with the release and the one built by using tools/build.ahk differ.

❯ sha256sum Downloads/bug.n-9.0.2/bugn.exe         
23a183d7e6de87a0b200cec985a0b01b5e5357b54d79fa3fa4ddd552e156b884  Downloads/bug.n-9.0.2/bugn.exe
Mon,03:22 in ~ 
❯ sha256sum Downloads/bug.n-9.0.2/bugn.exe
a7db6b9edc18f7563067501438d31a6d35589f806df19ab3db9056bb7cdb93be  Downloads/bug.n-9.0.2/bugn.exe

Also the files and contents differ when changing bugn.exe to a bugn.zip file. I've compared with previous releases and even in another pc.

fuhsjr00 commented 5 years ago

It's typical for different builds to produce slightly different results based on the metadata that gets recorded. I think specifically that Windows PE/COFF (.exe) format includes a timestamp, so different builds are almost guaranteed to produce different hashes.

I believe there are tools that will do executable content hashes, but I haven't used them in a while. Keep in mind that if anything is different about the build tools or environment (AHK version, some Windows libs versions), you can legitimately get different hash results.

I would instead try to find out why the bug.n binary is matching this trojan and try to address that.

On Mon, Jun 10, 2019 at 4:37 AM J.P. Silva notifications@github.com wrote:

I think there's actually a reason for concern @joten https://github.com/joten. The sha256sums for bugn.exe built by SILKIE_jn and in the release and the one built by using tools/build.ahk differ.

❯ sha256sum Downloads/bug.n-9.0.2/bugn.exe

23a183d7e6de87a0b200cec985a0b01b5e5357b54d79fa3fa4ddd552e156b884 Downloads/bug.n-9.0.2/bugn.exe

Mon,03:22 in ~

❯ sha256sum Downloads/bug.n-9.0.2/bugn.exe

a7db6b9edc18f7563067501438d31a6d35589f806df19ab3db9056bb7cdb93be Downloads/bug.n-9.0.2/bugn.exe

Also the files and contents differ. When changing the .exe to a .zip file.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/fuhsjr00/bug.n/issues/212?email_source=notifications&email_token=AAMRJSVIRUPAIXLZJ6PVWYLPZYHCZA5CNFSM4HN3M2A2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXJIZXY#issuecomment-500337887, or mute the thread https://github.com/notifications/unsubscribe-auth/AAMRJSQIBN53XUBT45V2M43PZYHCZANCNFSM4HN3M2AQ .

joten commented 5 years ago

I did some testing (see doc/_Development).

I downloaded the zip from release v9.0.2 and rebuilt the exe on silkie_jn. The hashes are identical. => No tempering with the release files, I think.
I removed parts of the code, i.e. the SetTimer commands and Manager_registerShellHook function, rebuilt the exe and uploaded it to VirusTotal; instead of 32/ 71 I got 5/ 66. Still bad, but at least I could identify some critical parts - though without them bug.n cannot do dynamic tiling or update session and system status information. Removing the functions in RessourceMonitor.ahk did not seem to have any effect regarding malware detection.

I did encounter several problems:

I could not easily download the zip from GitHub releases via Chrome or Internet Explorer, since the download was blocked; in the end I used Firefox.
Windows Defender detected bugn.exe as malware when unpacking the relase zip or rebuilding the exe.

Comments:

I did not have the problems above when creating the release v9.0.2.
The release files now seem worthless.
Distributing bug.n via scoop could solve the problem, but would need additional software to be installed, which would not be userfriendly. Anyone, who could go through the scoop-package-installation-process, could also directly install AutoHotkey and run the bug.n-script.

ertwro commented 5 years ago

Since compiling bug.n doesn't seem to increase performance maybe an alternative could be to include a portable version of AHK and just use main.ahk (which could be seen as overkill). While scoop is a really cool tool and alternative for installation I would hate the idea of limiting the number of people that have access to the program or nerfing the code due to false positives😥.

matyhaty commented 5 years ago

Also experiecing this, and thus cant use. Also I store portable apps like this on a G DRive stream drive and it got auto removed, so this is not localised to a Window Defender issue.

ertwro commented 5 years ago

@matyhaty You don't need the compiled executable version. If you have Autohotkey installed you can run main.ahk in the ..\bugn\src folder

shytikov commented 5 years ago

Have tried to install bug.n via scoop. Same problem: Windows Defender kicks in and quarantines executable...

tantoinet commented 4 years ago

It should be whitelisted now. The binary file was also submitted to kaspersky, symantec and mcafee for whitelisting. Is there a way to digitally sign the binary? so AV won't FP on it?

yehya commented 4 years ago

Chrome still detects the zip as a virus and blocks the download.

bugrasan commented 4 years ago

same for FF; zip & tar.gz are detected as virus/malware and are blocked.

fuhsjr00 / bug.n

9.0.2 bugn.exe detected as Trojan:Win32/Occamy.C by Windows Defender #212