Updated doc reflecting issues #185 and #212

This commit is contained in:
joten 2019-05-27 13:08:01 +02:00 committed by GitHub
parent 4ea59680de
commit 5d0b5f732f
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23

View file

@ -76,3 +76,13 @@ check box and click **Finish**.
**OK**.
* **Run only when user is logged on**
* **Run with highest privileges**
### Expected behaviour
bug.n is compiled to an executable by using [ahk2exe](https://www.autohotkey.com/docs/Scripts.htm#ahk2exe) resulting in the file `bugn.exe` deliverd with a release. The compilation process packages the script files together with the AutoHotkey executable, which are unpacked to RAM and executed from there, when running the compiled script's executable (as it would be, if running bug.n as an AutoHotkey script).
One side effect of this method is that the resulting executable shares a lot of bytes with other compiled AutoHotkey scripts. It may be that an anti-malware tool detects bugn.exe e.g. as described at [Virus Total](https://www.virustotal.com/gui/file/23a183d7e6de87a0b200cec985a0b01b5e5357b54d79fa3fa4ddd552e156b884/detection); there you can inspect the [detected behaviour](https://www.virustotal.com/gui/file/23a183d7e6de87a0b200cec985a0b01b5e5357b54d79fa3fa4ddd552e156b884/behavior/Rising%20MOVES) i.a. the shell hook, used to find newly opened or closed windows, and the keyboard hook, used for reacting to hotkeys. This is the intended behaviour of bug.n.
You may of course review the code and recompile the executable. It should result in the same file with the same SHA fingerprint. There is a build script in the tools directory; mpress is used to compress the file and the AutHotkey executable is the 32-bit-unicode version.
Of course, bug,n does use the keyboard hook, which comes with AutoHotkey to allow keyboard shortcuts, and it does do some DLL calls, including a shellhook to register newly created and destroyed windows; that could be seen as malicious.