AutoIt v3.3.10.0 Pain in the Avast!

[condoman]

Avast 2014.9.0.2011 no like compiling with 3.3.10.0. Had to exclude from scanning: C:Documents and Settingsuser~AU3* C:Documents and SettingsuserRCX* C:Program FilesAutoIt3* C:Documents and SettingsuserLocal SettingsApplication DataAutoIt v3Aut2Exe* and the exe destination folder. Scripts compile fine with these changes. On another note thanks to the team for the nice Christmas gift.

[Zedna]

Send them (to Avast) false positive report so they will know about this problem and they will fix it.

[adima]

Send them (to Avast) false positive report so they will know about this problem and they will fix it.

I have the same problem - ESET antivirus.

I think it was a bug, because why create a folder on this path X:Documents and SettingsUserLocal SettingsApplication Data AutoIt v3Aut2Exe * = these are temporary files and they should be in the folder TEMP example  X:UsersUserNameAppdataLocalTemp  (windows7) or X: Windows temp.

In this version v3.3.8.1 was no error

[Jon]

I had them in temp in the first betas but we got even more false positives so we moved it to a static location (easier to exclude a single Aut2Exe folder from AV rather than the entire temp folder).

In 3.3.8.1 the method used was different (and in theory, much more suspicious), and the final exe was created in-place at the destination folder rather than in temp/local profile. I'm starting to suspect that AV is treating .exe manipulation within temp/local profile as inherently more suspicious than in other file areas.

I might have to try and get some of these AV programs to see exactly which part of the process is tripping them up. The thought of paying for malware makes me a bit sick though :/

[iamtheky]

Still sounds like a user environment problem rather than a Dev issue.  Normal events being reported as suspicious is rarely worth the chase and unless the AV choice does not allow for exclusions, its too easy an issue to correct (it probably took longer to post about the problem than to fix). 

Edited December 24, 2013 by boththose

[Jon]

Yeah, maybe. But if I scan a newly created compiled .exe and also the underlying AutoItSC.bin file on virustotal.com, both Avast and ESET says it's clean. So is it an old definition problem, or is it just not liking something we are doing when we create the exe?

[Jos]

Yeah, maybe. But if I scan a newly created compiled .exe and also the underlying AutoItSC.bin file on virustotal.com, both Avast and ESET says it's clean. So is it an old definition problem, or is it just not liking something we are doing when we create the exe?

Or it is flagging the activity done by Aut2exe (or autoit3wrapper).... creating the file and doing program resources updates?

[Jon]

Yeah, I need a local repo to get anywhere with it. I'll probably add an error code to the error message in Aut2Exe that indicates the stage it failed at as well.

[kylomas]

Jon,

Screen shot when I compile.

Win7 x64

Avast

 

kylomas

[Jon]

That's the very first stage when the stub exe is extracted. Nightmare.

[Richard Robertson]

I have an interesting result. Installed new release, compiled a message box script, no errors during compile. Run it, can't open script file.

[Jon]

Avast is flagging the AutoItSC.bin file that is part of Aut2Exe - I can't even copy the bin file from my dev build files in explorer so it was never going to work. It needs reporting but my copy of avast won't let me do it (paid feature?) (Edit: I reported the file through the website contact form).

It doesn't seem related to the location/profile at least.

Edited December 24, 2013 by Jon

[adima]

I had them in temp in the first betas but we got even more false positives so we moved it to a static location (easier to exclude a single Aut2Exe folder from AV rather than the entire temp folder).

In 3.3.8.1 the method used was different (and in theory, much more suspicious), and the final exe was created in-place at the destination folder rather than in temp/local profile. I'm starting to suspect that AV is treating .exe manipulation within temp/local profile as inherently more suspicious than in other file areas.

I might have to try and get some of these AV programs to see exactly which part of the process is tripping them up. The thought of paying for malware makes me a bit sick though :/

Situation is a bit clearer:

1) Eset Antivirus is only triggered when I add custom icon (.ico file) in X:Program FilesAutoIt3Aut2ExeAut2Exe.exe

By pressing CONVERT see Error: Unable to add resources.X:UsersUserNameAppdataLocalAutoit v3Aut2Exeautxxxx.exe.

.ico tried standard of C:\Program Files\AutoIt3\Aut2Exe\Icons.

2)Compile in SciTE see Error:

Running:(3.3.10.0) X:Program FilesAutoIt3aut2exeaut2exe.exe  /in "X:DocumentsAUTOITMYsb.au3" /out "X:UsersUsername~AU3gwvioej.exe" /nopack /icon "X:Program FilesAutoIt3Aut2ExeIconssetup01.ico" /comp 4

!>00:00:00 Aut2exe.exe ended errors because the target exe wasn't created, abandon build. (X:UsersUserName~AU3gwvioej.exe)rc:9999

Solution for Eset Antivirus: add  X:UsersUserNameAppdataLocalAutoit v3Aut2Exe*.*  to exclusion paths

Edited December 24, 2013 by adima

[cetipabo2]

Hello,

i just installed the 3.3.10.0 version and i'm having a problem with AVAST too. looks like adding the path C:users<username> to the exclusion list is working, but it's not a good solution, this path is one of the first place where a virus will install itself...excluding this path from scaning is dangerous.

At least it would be nice to create a subfolder like C:users<username>autoit3 ,  that way we can only exclude this folder. Just an idea.

[Melba23]

cetipabo2,

Welcome to the AutoIt forum.

 

it would be nice to create a subfolder like C:users<username>autoit3 , that way we can only exclude this folder

This is already the case - most people with this problem find that excluding the more specific UserNameAppdataLocalAutoit v3Aut2Exe folder solves the problem.

M23

[cetipabo2]

unfortunately in my case (win 7 64bit), with Avast adding c:users<userName>AppdataLocalAutoit v3Aut2Exe in the exclusion list doesn't solve the problem.

if i watch the folder c:users<userName> during the compilation i can see that a file is created here and then Avast immediatly block it and move it in quarantine.

addind this path c:users<userName> and only this path fixes the problem.

[Jon]

The latest Avast definitions seem ok now.

If you use just Aut2Exe then the only temp files used are created in c:users<userName>AppdataLocalAutoit v3Aut2Exe. But if you use the wrapper scripts/full scite editor then that does some .exe manipulation of its own in C:usersusername.  That will be changing soon so that it also uses the Aut2Exe folder so there will be only a single place to exclude.

[Jos]

If you use just Aut2Exe then the only temp files used are created in c:users<userName>AppdataLocalAutoit v3Aut2Exe. But if you use the wrapper scripts/full scite editor then that does some .exe manipulation of its own in C:usersusername.  That will be changing soon so that it also uses the Aut2Exe folder so there will be only a single place to exclude.

Just release the updated installer that has the changes to point the temp files to "c:users<userName>AppdataLocalAutoit v3Aut2Exe"

Jos

Edited December 28, 2013 by Jos

[czardas]

I've had some (limited) interaction with the Avast team, and I'm pretty sure they do their best to fix false positives once they know about them. I believe many of the FPs are down to heuristics. The automatic quarantine can be a pain though - there have been several complaints about this behaviour. I recommend anyone using Avast to submit false positives and (if need be) ask a question on the forum. As long as you are respectful, you should get results. Don't react to anyone who doesn't know what they are talking about.

Edited December 30, 2013 by czardas

[saudumm]

I had the same problem with Kaspersky Anti Virus since Beta 3.3.9.23. I had to send them false positives for the next Beta versions until they fixed their signatures. The new stable version now works fine with Kaspersky.