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???
Is Windows Defender heavily impairing the speed of AHK scripts?
-
- Posts: 493
- Joined: 24 Aug 2016, 03:34
Is Windows Defender heavily impairing the speed of AHK scripts?
Last edited by newbieforever on 26 May 2018, 14:55, edited 1 time in total.
-
- Posts: 1472
- Joined: 05 May 2018, 12:23
Re: Trojan:Win32/Fuery.B!cl during compiling...
Yeah, it started about two weeks ago
-
- Posts: 493
- Joined: 24 Aug 2016, 03:34
Re: Trojan:Win32/Fuery.B!cl during compiling...
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 ...
-
- Posts: 493
- Joined: 24 Aug 2016, 03:34
Re: Trojan:Win32/Fuery.B!cl during compiling...
Not only compiling ist affected by WD:
If WD is activated, compiled scripts take much longer to start.
If WD is activated, compiled scripts take much longer to start.
Re: Trojan:Win32/Fuery.B!cl during compiling...
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/
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/
-
- Posts: 493
- Joined: 24 Aug 2016, 03:34
Re: Trojan:Win32/Fuery.B!cl during compiling...
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...
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.
}
Re: Trojan:Win32/Fuery.B!cl during compiling...
Are you able to disable this options (there might be a group policy preventing it)?[b]Microsoft[/b] wrote: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
Does it change the behaviour?
-
- Posts: 493
- Joined: 24 Aug 2016, 03:34
Re: Trojan:Win32/Fuery.B!cl during compiling...
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.)
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.)
Last edited by newbieforever on 26 May 2018, 14:24, edited 2 times in total.
-
- Posts: 493
- Joined: 24 Aug 2016, 03:34
Re: Trojan:Win32/Fuery.B!cl during compiling...
I will do that!just me wrote:Submit a file for malware analysis
?
-
- Posts: 493
- Joined: 24 Aug 2016, 03:34
Re: Trojan:Win32/Fuery.B!cl during compiling...
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
}
Re: Trojan:Win32/Fuery.B!cl during compiling...
Actually, this script is a 'compiling operation'.newbieforever wrote:This new script demonstrates the impact of WD not only on the compiling operations, ...
Does WD slow down each run of each compiled script on your system?
-
- Posts: 493
- Joined: 24 Aug 2016, 03:34
Re: Trojan:Win32/Fuery.B!cl during compiling...
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.just me wrote:Does WD slow down each run of each compiled script on your system?
So I think we have a huge problem here...
Re: Trojan:Win32/Fuery.B!cl during compiling...
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.
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.
Recommends AHK Studio
-
- Posts: 493
- Joined: 24 Aug 2016, 03:34
Re: Trojan:Win32/Fuery.B!cl during compiling...
[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.
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.
-
- Posts: 493
- Joined: 24 Aug 2016, 03:34
Re: Trojan:Win32/Fuery.B!cl during compiling...
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 %.
Btw, has somebody here observed this: the first start of a compiled script takes much more time?
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.
Re: Is Windows Defender heavily impairing the speed of AHK scripts?
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).newbieforever wrote:Btw, has somebody here observed this: the first start of a compiled script takes much more time?
Edit: I doubt that you're using the 'UpdateResource' technique only for testing.
-
- Posts: 1472
- Joined: 05 May 2018, 12:23
Re: Is Windows Defender heavily impairing the speed of AHK scripts?
Once I stopped using mpress, it seems WD is not causing problems
Re: Is Windows Defender heavily impairing the speed of AHK scripts?
I am not surprised.AHKStudent wrote:Once I stopped using mpress, it seems WD is not causing problems
gregster wrote:(if you compress your AHK code you can even create higher numbers of false positives )
https://autohotkey.com/docs/FAQ.htm#Virus wrote: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.
-
- Posts: 493
- Joined: 24 Aug 2016, 03:34
Re: Is Windows Defender heavily impairing the speed of AHK scripts?
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.
(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.)
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.
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.just me wrote:I doubt that you're using the 'UpdateResource' technique only for testing.
(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.)
Who is online
Users browsing this forum: Bing [Bot], Starker and 285 guests