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

[jcarpoff]

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]

Same here...

[ertwro]

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]

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 [email protected] 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]

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]

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]

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]

@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]

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

[tantoinet]

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]

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

[bugrasan]

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