Is Windows Defender heavily impairing the speed of AHK scripts?

[newbieforever]

I am using Windows 10 Home 10.0.16299.
Since a few days there seems to be a problem with Windows Defender:
It reports a Trojan:Win32/Fuery.B!cl during compiling (indicating tmp files in Temp dir).
And the compiling time is enormously increased.

Deactivating the cloud-based protection of WD seems to stop trojan warnings, but the compiling time remains increased. Only if the WD is deactivated completely the problem disappears.

This is an enormous shock to me ... Will the use of AHK scripts become unreliable?

No other reports of this problem???

[AHKStudent]

Yeah, it started about two weeks ago

[newbieforever]

But there are no reports on this here!? Shouldn't all of us be concerned that in future WD could become a problem for the usability of compiled scripts, and generally of AHK? At the moment only scripts applying DllCall("UpdateResource"... are affected, but ...

[newbieforever]

Not only compiling ist affected by WD:

If WD is activated, compiled scripts take much longer to start.

[gregster]

Today, anti-virus software often uses heuristic approaches. If there is some AHK-based malware going around that uses this technique (I heard that AHK is quite popular with bad guys at the moment, for cryptomining malware), there is not much you can do but wait until the wave is over.
On the other hand, you can probably sent your file to the AV vendor for inspection to help them improve their recognition rate.

We had countless false positives for AHK in the past (for most versions, anyway) - so that is probably always a problem with a powerful script language; the very powerful Nirsoft tools and other programmers have similar problems btw (if you compress your AHK code you can even create higher numbers of false positives ), but after some time the false positives for a specific AHK version usually disappear.
The AV vendors constantly update their databases and approaches, but heuristic searches are simply not reliable. If there is a false positive, simply put, the AV vendor has to solve the problem with his product To help them, look at their websites - they have usually a special e-mail contact or upload form to send files in question, like here: https://www.microsoft.com/en-us/wdsi/filesubmission

With that said, there is always the possibility that your system got infected by some malware. I personally never had a problem with AHK false positives (with Nirsoft programs, yes), but then... I rarely compile.

Edit: I think, a forum member already linked to this: https://www.bleepingcomputer.com/news/s ... w-a-thing/

[newbieforever]

Thank you, AHKStudent & gregster, for your feedback.

The following script demonstrates what a problem we have with the newest behavior of Windows Defender. In the script this is shown for compilation, but other AHK issues are affected too (e.g. starting time of compiled scripts). The main problem are not false positive virus detections, but the fact that WD affects the behavior and performance of AHK scripts!

I'm curious what other users using Win10 with Windows Defender (updated in the last weeks) will report...

Code: Select all

BinFile := A_ScriptDir . "\AutoHotkeySC.bin"

If !FileExist(BinFile)
{
   MsgBox AutoHotkeySC.bin should be in this script's folder!
   ExitApp
}

ExeFile := A_ScriptDir . "\CompiledScript.exe"
FileCopy, %BinFile%, %ExeFile%, 1
ScrString := "MsgBox A COMPILED SCRIPT"

Compile(ExeFile, ScrString)

RETURN

Compile(ExeF, ScrStr)
{
   VarSetCapacity(BinScrStr, BinScrStr_Len := StrPut(ScrStr, "UTF-8") - 1)
   StrPut(ScrStr, &BinScrStr, "UTF-8")
   Module := DllCall("BeginUpdateResource", "str", ExeF, "uint", 0, "ptr")
   If !Module
      MsgBox ERR MODULE
   If !DllCall("UpdateResource", "ptr", Module, "ptr", 10, "str", IcoFile ? ">AHK WITH ICON<" : ">AUTOHOTKEY SCRIPT<"
                , "ushort", 0x409, "ptr", &BinScrStr, "uint", BinScrStr_Len, "uint")
      MsgBox ERR UPDATE
   Sleep, 150	
   t0 := A_TickCount
   If !DllCall("EndUpdateResource", "ptr", Module, "uint", 0)
      MsgBox ERR ENDUPDATE
   t := A_TickCount - t0
   MsgBox TIME needed to compile (EndUpdateResource):`r`r%t% ms`r`rWhen Windows Defender is activated, this time is increased from about 35 ms to about 3500 ms!`r`rAnd: Trojan:Win32/Fuery.B!cl is detected in some cases when running the generated compiled script. (Maybe only if a precompressed AutoHotkeySC.bin is used for compiling.)`r`rTested on Windows 10 Home 10.0.16299.
}

[just me]

Secure configuration

To get the best and fastest protection from Windows Defender Antivirus, connect to the cloud protection service.

Use the Windows search box to find and open the Windows Defender Security Center. Navigate to the Virus & threat protection settings.

• Cloud-delivered protection
• Automatic sample submission

Are you able to disable this options (there might be a group policy preventing it)?

Does it change the behaviour?

[newbieforever]

just me: Yes, the cloud-based protection can be disabled independently of the normal real-time detection. If it is disabled, I think, ther are (maybe) no trojan warnings, but, as I already pointed out:

The performance of AHK scripts in general is obviously heavily affected!

You can tell to the users of your compiled scripts that warnings should be ignored, but the loss of performance remains. (In my case a sulution which I intended to use doesn't work on systems with WD, and I see no other solution for this my problem.)

[just me]

Submit a file for malware analysis
?

[newbieforever]

Submit a file for malware analysis
?

I will do that!

[newbieforever]

This new script demonstrates the impact of WD not only on the compiling operations, but also on the general performance of AHK scripts. It shows that some scripts will completely fail because an operation intended to take 200 ms will take 4 s!

Code: Select all

BinFile := A_ScriptDir . "\AutoHotkeySC.bin"

If !FileExist(BinFile)
{
   MsgBox AutoHotkeySC.bin should be in this script's folder!
   ExitApp
}

ExeFile := A_ScriptDir . "\CompiledScript.exe"
FileCopy, %BinFile%, %ExeFile%, 1
ScrString := "MsgBox A COMPILED SCRIPT"

t0 := A_TickCount
Compile(ExeFile, ScrString)
t_tot := A_TickCount - t0
MsgBox TOTAL TIME needed to execute this script:`r%t_tot% ms`rTIME neded to execute EndUpdateResource:`r%t_endupd% ms`r`rWhen Windows Defender (real-time protection) is deactivated, this times are about`r200 ms`r30 ms`rwhen it is activated they increas to`r4000 ms`r3500 ms`r!!!`r`rAnd: Trojan:Win32/Fuery.B!cl is detected in some cases when running this script or the generated compiled script. (Maybe this warnings are associated only to compressed scripts and/or to activation of WD's cloud-based protection.)`r`rTested on Windows 10 Home 10.0.16299.

RETURN

Compile(ExeF, ScrStr)
{
   Global t_endupd
   VarSetCapacity(BinScrStr, BinScrStr_Len := StrPut(ScrStr, "UTF-8") - 1)
   StrPut(ScrStr, &BinScrStr, "UTF-8")
   Module := DllCall("BeginUpdateResource", "str", ExeF, "uint", 0, "ptr")
   If !Module
      MsgBox ERR MODULE
   If !DllCall("UpdateResource", "ptr", Module, "ptr", 10, "str", IcoFile ? ">AHK WITH ICON<" : ">AUTOHOTKEY SCRIPT<"
                , "ushort", 0x409, "ptr", &BinScrStr, "uint", BinScrStr_Len, "uint")
      MsgBox ERR UPDATE
   Sleep, 150	
   t0 := A_TickCount
   If !DllCall("EndUpdateResource", "ptr", Module, "uint", 0)
      MsgBox ERR ENDUPDATE
   t_endupd := A_TickCount - t0
}

[just me]

This new script demonstrates the impact of WD not only on the compiling operations, ...

Actually, this script is a 'compiling operation'.

Does WD slow down each run of each compiled script on your system?

[newbieforever]

Does WD slow down each run of each compiled script on your system?

Yes, I think so, and this is the point. My last demo script demonstrates that not only the time to execute EndUpdateResource (i.e. compiling in the narrow sense) is increased (by a factor of 100), but also the remaining operations of the script (from about 170 ms to about 500 ms in this case). I have observed this behavior in the last weeks, but I was not aware that this is a permanent issue.

So I think we have a huge problem here...

[nnnik]

We dont have any sort of problem here.
It's just that anti malware software decreases the speed of running programs since it checks on the actions that a specific tool does.
AHK is using suspicious code that could be used to build a keylogger - thats why anti virus programs check AHK especially thorough.
In the end if it really takes 4 second every time it essentially shows us that Windows Defender is not a viable Anti Virus Software or they will fix their bugs.
AutoHotkey is not able to do anything to change this though.

[newbieforever]

[quote="nnnik"]We dont have any sort of problem here.
It's just that anti malware software decreases the speed of running programs since ...
AutoHotkey is not able to do anything to change this though.[/quote]
I apologize for saying that we have a problem (OK, I only said that I think that…), and it wasn’t my intention to hurt the honor of Microsoft, Windows Defender or AutoHotkey. I understand your explanation and am happy to know now that it is a feature, not a bug.

For the two or three other users (beside me) which would prefer to have another feature:

I submitted to MS some files demonstrating the favorable impact of WD on AHK.

[newbieforever]

For the two or three other users (beside me) which would prefer to have another "feature":

The following script demonstrates the impact of WD on the speed of even simple operations--not something like compiling ahk scripts, but simple renaming of text files and appending a number to them. The execution time increases on my system by 75 to 125 %.

Code: Select all

SetWorkingDir, %A_Temp%

MsgBox, After closing this MsgBox a test is started in which a text file is renamed 300 times and each time a number is appended to it.

t0 := A_TickCount

File := A_Temp . "\Test1.txt"
Run, %A_Temp%
FileAppend, 1, %File%
While !FileExist(File)
   Sleep, 100
   
Loop, 300
{
   ToolTip, LOOP ...%A_Index%...
   IndexN := A_Index + 1
   FileN := RegExReplace(File, "Test" . A_Index, "Test" . IndexN)
   FileMove, %File%, %FileN%
   While !FileExist(FileN)
      Sleep, 100
   FileAppend, %A_Space%%IndexN%, %FileN%
   File := FileN
}

ToolTip

time := A_TickCount - t0

MsgBox Execution time: %time% ms.`r`rRepeat this test with Windows Defender activated or not activated (real-time protection and/or cloud-based protection) and compare the execution times.

Btw, has somebody here observed this: the first start of a compiled script takes much more time?

[just me]

Btw, has somebody here observed this: the first start of a compiled script takes much more time?

I believe it's the common behaviour of real-time detection to completely check an executable only once unless it has been changed. WD is running on my system but I also installed Avira AV which is used for real-time detection. I cannot observe noticable delays (as yet).

Edit: I doubt that you're using the 'UpdateResource' technique only for testing.

[AHKStudent]

Once I stopped using mpress, it seems WD is not causing problems

[gregster]

Once I stopped using mpress, it seems WD is not causing problems

I am not surprised.

(if you compress your AHK code you can even create higher numbers of false positives )

False positives might be more common for compiled scripts which have been compressed, such as with UPX (default for AutoHotkey 1.0 but not 1.1) or MPRESS (optional for AutoHotkey 1.1). As the default AutoHotkey installation does not include a compressor, compiled scripts are not compressed by default.

[newbieforever]

Trojan detection by WD:

Yes, I think too that the trojan detection by WD was associated to mpress. Ahk2Exe generates a tmp file in A_Temp and another one if mpress is used, called mprxxxx.tmp, which was the reason for the detection. (Maybe the actual reason was the compression method which is used by Ahk2Exe, where the entire file is compressed; during my tests with the -r option for mpress, there was no detection.)

However, on my system this behavior changed from yesterday to today, after intensive testings on this issue. Even a mprxxxx.tmp file which according to WD was infected (but for which I decided not to be removed), according to WD is safe today (yesterday WD said the file is infected but allowed by me). At the moment I am unable to invoke any new trojan detection associated to mpress! I am unable to say what was the reason for this change. Is somebody other here observing the same change? Theoretically it would be possible that after my submission at MS (in which I described the problem associated to tmp files and AHK/mpress) the WD definitions were changed already; and there was a new update last night...)

WD's impact on speed:

For myself, this is my real concern and problem! I'm wondering: All others here seems not to be worried about this. Would all of your scripts work as expected when some techiques used in them suddenly (on the system of a user, after a new WD definition update) would take two or three (or perhaps even 100) times longer? Are you using no techniques where increasing execution time by a factor of 2 would cause usability problems?

Anyway, this impact of WD hasn't changed on my system since yesterday, unfortunately.

I doubt that you're using the 'UpdateResource' technique only for testing.

What do you mean? ... I don't understand the question. You know my project from my other topic. I am developing a script with an integrated small script editor to be able, from this compiled script, to write new small scripts, which later should be compiled for further use. But prior to this I have to test them in an easy way ('on the fly') during writing. Since AutoHotkey.exe will not be available for this, I use another available compiled script and replace its script resource. As I said at the beginning of my other topic, this is working, but it takes too long; 3500 ms instead of 35 ms, plus a first-run effect of xx seconds--that's not 'on the fly'. I know now that the reason is WD. With WD deactivated my solution would be perfect, but... That's all.
(Thank you very much for your comment to the question of the first-run behavior! I wasn't aware that this is associated to WD too. I will use your information to work on a solution for my problem.)