when making any 32-bit binary with the option -mwindows, the resulted binary triggers avast's autosendbox feature. Obviously the antivirus thinks there is something suspicious within the binary. Although the problem is probably on the avast! side, avast! is very spread so many people using mingw-w64 (and especially apps built with it) can be affected.
For example having this noop program triggers that:
The problem does not occur without the option -mwindows, nor when building 64-bit binary.
Reproduced on 64-bit Windows 7 with mingw-w32-1.0-bin_i686-mingw_20110808.zip. Tried also many older versions of the toolchain with the same result.
Anyone knows what exactly -mwindows does? (I know it adds some libs to linker but as the previous code does not call any function from them, linker does not really add them, so I suppose the option has to do more…)
Regards,
Morous
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tried with more recent toolchain packages:
- mingw-w32-bin_i686-mingw_20110812.zip
- mingw-w32-1.0-bin_i686-mingw_20110812.zip
and the issue still can be reproduced.
Also tried toolchain from mingw.org project (gcc 4.5.2) and the problem does NOT occur.
So another question is: What's difference between -mwindows with mingw and mingw-w64??
Morous
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It sets the subsystem to GUI mode too, please send samples to Avast to get it out of their false positives, there is nothing mingw-w64 or mingw.org can do about it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Of course I have reported them (and forgot to mention).
But still it is interesting gcc from mingw dos not trigger it although the PE structures should be about the same… So I wrote here too. And anyway it's probably something what mingw-w64 users might want to know…
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To be honest, your little test code compiled with my native compilers (both 32 and 64-bit) doesn't trigger any message from Avast 6.0.1125 with definitions 110825-1 on my WIndows 7 64-bit SP1.
Perhaps your system is infected by something else?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But I think that's unlikely. I haven't see any complains of avast! for really very long time - with the exception of the current issue and some pathetic spam mails which I do not open, and which are blocked by avast! anyway.
I.e. that 'something' (as you refer to it) would be infecting _all_ 32bit binaries generated by 32bit-targeting toolchains from mingw-w64 when (and only when) -mwindows is used, and ignoring all the other toolchains completely (MSVC2010 Express, mingw.org as well as all other programs installed).
Or you mean the particular gcc or its linker is already infected so that it infects all binaries it generates? Never heart about such kind of malware, but in that case you should scan the machine where you build Home / Toolchains targetting Win32 / Automated Builds.
As I see the above unlikely, there are probably two other possible explanations:
(1) The problem is solely with the 32bit-targeting automated builds, and you (I guess) use your personal build which may not expose the issue (as well as the build from mingw.org does not)
(2) avast reacted fast and provided an update so you can't see the problem anymore (assuming you could download the update in the mean time)
So please can you specify what build exactly you have (or share it somewhere) so I can test with it if it makes the difference after I come home tonight?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem still persists. Tested with up-to-date virus definition:
* Avast program version: 6.0.1203
* Virus definitions: 110826-0
* System is 64bit WIndows 7 SP1
System scan has not found any problem.
I tried to scan the particular binaries in the avast gui and it said "no treat".
When running them the sendbox still appears.
i normally add my builddir to the antivirus ignore list since i had the same problem.
It seems to happen mostly with antivirus solutions that make heavy use of heuristics, probably
because some function names seem similar to known malware etc.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Antivirus and other software can cause havoc during a build cycle. As revelator states be sure to include your development environment path in the exclusion of your antivirus software. Otherwise your configure will see a lot of Permission Denied when trying to remove conftest files and that may cause the wrong configuration to occur. See also a list of "Bloda" as documented by Cygwin here http://cygwin.com/faq/faq.using.html#faq.using.bloda because you may need to disable or perhaps remove some device.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
when making any 32-bit binary with the option -mwindows, the resulted binary triggers avast's autosendbox feature. Obviously the antivirus thinks there is something suspicious within the binary. Although the problem is probably on the avast! side, avast! is very spread so many people using mingw-w64 (and especially apps built with it) can be affected.
For example having this noop program triggers that:
=== File a.c ===
int
main(int argc, chart** argv)
{
return 0;
}
=== EOF ===
$ i686-w64-mingw32-gcc -mwindows a.c
When running a.exe, a warning about possibly danger apperas and recommends to open the app. in sendbox'ed environment (see http://techdows.com/wp-content/uploads/2011/02/avast-sandbox.png)
The problem does not occur without the option -mwindows, nor when building 64-bit binary.
Reproduced on 64-bit Windows 7 with mingw-w32-1.0-bin_i686-mingw_20110808.zip. Tried also many older versions of the toolchain with the same result.
Anyone knows what exactly -mwindows does? (I know it adds some libs to linker but as the previous code does not call any function from them, linker does not really add them, so I suppose the option has to do more…)
Regards,
Morous
Tried with more recent toolchain packages:
- mingw-w32-bin_i686-mingw_20110812.zip
- mingw-w32-1.0-bin_i686-mingw_20110812.zip
and the issue still can be reproduced.
Also tried toolchain from mingw.org project (gcc 4.5.2) and the problem does NOT occur.
So another question is: What's difference between -mwindows with mingw and mingw-w64??
Morous
It sets the subsystem to GUI mode too, please send samples to Avast to get it out of their false positives, there is nothing mingw-w64 or mingw.org can do about it.
Of course I have reported them (and forgot to mention).
But still it is interesting gcc from mingw dos not trigger it although the PE structures should be about the same… So I wrote here too. And anyway it's probably something what mingw-w64 users might want to know…
To be honest, your little test code compiled with my native compilers (both 32 and 64-bit) doesn't trigger any message from Avast 6.0.1125 with definitions 110825-1 on my WIndows 7 64-bit SP1.
Perhaps your system is infected by something else?
Thx for info Ruben.
But I think that's unlikely. I haven't see any complains of avast! for really very long time - with the exception of the current issue and some pathetic spam mails which I do not open, and which are blocked by avast! anyway.
I.e. that 'something' (as you refer to it) would be infecting _all_ 32bit binaries generated by 32bit-targeting toolchains from mingw-w64 when (and only when) -mwindows is used, and ignoring all the other toolchains completely (MSVC2010 Express, mingw.org as well as all other programs installed).
Or you mean the particular gcc or its linker is already infected so that it infects all binaries it generates? Never heart about such kind of malware, but in that case you should scan the machine where you build Home / Toolchains targetting Win32 / Automated Builds.
As I see the above unlikely, there are probably two other possible explanations:
(1) The problem is solely with the 32bit-targeting automated builds, and you (I guess) use your personal build which may not expose the issue (as well as the build from mingw.org does not)
(2) avast reacted fast and provided an update so you can't see the problem anymore (assuming you could download the update in the mean time)
So please can you specify what build exactly you have (or share it somewhere) so I can test with it if it makes the difference after I come home tonight?
The problem still persists. Tested with up-to-date virus definition:
* Avast program version: 6.0.1203
* Virus definitions: 110826-0
* System is 64bit WIndows 7 SP1
System scan has not found any problem.
I tried to scan the particular binaries in the avast gui and it said "no treat".
When running them the sendbox still appears.
Also downloaded some Ruben's personal build (https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/4.6.2-2/i686-w64-mingw32-gcc-4.6.2-2_rubenvb.7z/download) and the problem is there too.
BTW the problem appears also for binaries I have placed on sf.net (http://sourceforge.net/projects/mctrl/files/0.8.2/mCtrl-0.8.2-x86.zip/download) few days ago. So it might be helpful if you can test with them whether you can the same problem as I do.
I also analyzed some some files on virustotal.com:
* http://www.virustotal.com/file-scan/report.html?id=2ddc38c7cb52f01b2fcf74e20ada73956265d13cd4099c3793cef9135f8ac81c-1314371952 (the ZIP package linked above).
* http://www.virustotal.com/file-scan/report.html?id=85763905e4e86215dd5fef416ef53d4e70770318bb6e2b7264b7409955f5f021-1314372189 (the trivial program with empty main, listed in one of previous posts).
* and few more.
Every time (sic!) few of the AV found some treat, but avast never did (but locally still recommends sendbox if 32bit and -mwindows).
(Hmmm, so far the result is that I start thinking whether I really want any antivirus installed on my machine…)
i normally add my builddir to the antivirus ignore list since i had the same problem.
It seems to happen mostly with antivirus solutions that make heavy use of heuristics, probably
because some function names seem similar to known malware etc.
Antivirus and other software can cause havoc during a build cycle. As revelator states be sure to include your development environment path in the exclusion of your antivirus software. Otherwise your configure will see a lot of Permission Denied when trying to remove conftest files and that may cause the wrong configuration to occur. See also a list of "Bloda" as documented by Cygwin here http://cygwin.com/faq/faq.using.html#faq.using.bloda because you may need to disable or perhaps remove some device.