Compiling with MinGW gcc Makes windows defender suspect of virus [duplicate] - windows

I had compiled a simple hello world program in C with the MinGW compiler using the command line. As it had finished compiling, windows defender popped up and detected a virus (Trojan:Win32/Fuery.C!cl).
#include <stdio.h>
#include <stdlib.h>
int main() {
printf("Hello World");
return 0;
}
https://imgur.com/a/05yDjw5
I had taken action on this (Removed) as windows defender suggested, but when I compile again the same happened, multiple times.
I had downloaded an AntiVirus (Malwarebytes) and scanned my whole system and it detected some registry key errors, but not this.
I've tried compiling C++ files too, but windows defender did not detect any virus there. This only happens when I compile in C.
I've also tried checking the compiled executable at VirusTotal.
https://www.virustotal.com/gui/file/476d47215dad80db49c9fd508ab5e10e5aeb5b623248ca156830a28b70affe5f/detection
I tried CodeBlock's MinGW compiler and 0 engines detected it. (Same C file)
https://www.virustotal.com/gui/file/8ba4b0fa24b1b6b69152acce2353fcca8447bbecbfc4e5ec48d33cc75d94f2f1/detection
EDIT: I deleted the path variable of C:/MinGW and added CodeBlock's MinGW compiler. I then used the command line to compile the same C file again and had uploaded the .exe file to VirusTotal. This time, 0 engines detected. So I have come to the conclusion that, the MinGW compiler that I had installed was creating this problem.
https://www.virustotal.com/gui/file/34d383f6c09f897d8c9a44ed0e7850574320e50fdf439eeb1f06705fdcc95386/detection
I don't know why this happens. Is there a malware in my computer that affects my C programs or is this a false detection?

There is no malware, it is a false positive. The executable generated by your version of MinGW looks very similar to a particular virus.
To avoid the problem, add the directory where you build your code to the list of exclusion in the antivirus.
Also consider using mingw-w64 instead of mingw.org .

I came across with the same problem, compiler tdm gcc v9.2.
The following compilation triggers a warning (kaspersky).
gcc temp.c -o temp.exe
The following does not
gcc -O3 temp.c -o temp.exe
Where temp.c is
#include <stdlib.h>
#include <stdio.h>
#include <math.h>
int main() {
int a, b;
scanf("%d %d", &a, &b);
printf("mod %4d, %4d is %4d\n", a, b, a%b);
return 0;
}
The same code with g++ passes the test with both compilations. The antivirus software does not detect the same virus elsewhere but only in temp.exe (first compilation).

I may have solved my problem.
This is what I did: I removed the PATH Variable of C:\MinGW and added CodeBlock's MinGW compiler (CodeBlocks/MinGW/bin). I used the command line to compile the same C file, and had uploaded the .exe to VirusTotal. No engines detected this file!
https://www.virustotal.com/gui/file/34d383f6c09f897d8c9a44ed0e7850574320e50fdf439eeb1f06705fdcc95386/detection
So I have come to a conclusion that, MinGW was the compiler that was causing this problem. I have removed it.
However, I am not quite sure if this problem is FULLY solved. There is still a possibility of malware affecting my executable (or perhaps not). I cannot be sure.
If anyone has any answers, please comment or answer

I ran into this after installing MinGW on 01-08-20(dd-mm-yy).
For me it was also Windows Defender, the way to - hopefully temporarily- get rid of this is to add an exception for the folder your compilation output will reside in.
The Microsoft website states these steps to add an exclusion:
Go to Start > Settings > Update & Security > Windows Security > Virus & threat protection.
Under Virus & threat protection settings, select Manage settings, and then under Exclusions, select Add or remove exclusions

I had a similar problem. I figured out that the following dll was missing: mingw32-libmingwex-dll. Once I installed it via "MinGW Installation Package", I didn't have the problem anymore.
I hope this can help others.

Since you wrote that program and you know it isn't actually a Trojan, it's obviously a false positive. You should submit the file to them at https://www.microsoft.com/wdsi/filesubmission so they can figure out why it's triggering the false positive and fix it. (If it happens with everything you compile, just sending them one will suffice.) In the meantime, you should add an exclusion to Windows Defender for the folder that you compile your executables in.

Related

VC++ dependencies linking issue?

My project is using some libs of libavcodec on Visual Studio 2010.
After updating the libs (replacing the lib and includes from Libav) and resolving all Compiler Errors (after 3 years a few things changed in libavcodec), the project compiles without a problem, but my compiled dll does not work.
I am 99% sure it is some dependency problem. Sure i did not only update the linked libs of my project but also placed the correct new dlls into the build folder.
The strange thing i have never seen is that dependency walker detects totally wrong imports from the different dlls, see image.
As you can see, all linked libs seem to indicate the same imports - functions that those libs just don't export.
The only thing i do in that direction besides specifying the libs in the linker section is including the .h files in my program and then of course use them heavily;-)
extern "C" {
#include <libavcodec/avcodec.h>
#include <libavutil/opt.h>
#include <libavutil/imgutils.h>
#include <libavformat/avformat.h>
#include <libswscale/swscale.h>
#include <libswresample\swresample.h>
}
What i tried:
Make sure the correct libs and headers are used by the project
clean the build path, tried debug und release build
checked if there are new includes that i may have forgotten to link (this would have ended up in a compiler errror anyways)
restart VStudio
built a test program that links to the same dlls, there the correct imports are shown automatically
compiled with VS 2013, no change at all
Custom building binaries depending upon your current project settings is key to avoiding annoying linker errors like the one your are facing.
You can use vcpkg.exe from github to build the ffmpeg project and rebuild binaries for x86 or x64 machine.
After installing vcpkg on your system, goto to the Powershell prompt and enter .\vcpkg install ffmpeg. After completion of installation enter ".\vcpkg integrate install" so that your latest ffmpeg libraries are available for use.

MinGW GCC wildcard

I'm using MinGW GCC compiler on windows how to compile all C files in a directory.
I used
gcc *.c -o Output
after I entered the required folder and I got this error
gcc: error: *.c: Invalid argument
gcc: fatal error: no input files
compilation terminated.
the used version of GCC is 4.7.1
For anyone else like me who's come across this problem:
I ran into this problem when I installed MinGW-w64 on my tablet after having run it for a few years on my desktop.
Basically, I have a ruby script that does some basic compilation stuff for me, and it was breaking at the linking stage on my tablet (developed on, and ran fine on the desktop).
The error: Invalid Argument, no input files (as in the original question).
If you check around, you'll find a few places that tell you that the issue is due to the way CMD on Windows handles passing wildcards to programs (vs UNIX shells).
Basically Windows leaves interpretation of the wildcard up to the program.
Some builds of MinGW can handle a wildcard from CMD, whereas others won't.
I'm able to use wildcards using the MinGW-W64-builds installer for MinGW-W64.
This should work with older mingw-w64 versions:
#ifdef __MINGW64_VERSION_MAJOR
int _dowildcard = -1; /* enable wildcard expansion for mingw-w64 */
#endif

What do you need to install to use Clang on windows to build c++14 for 64 bit?

UPDATE:
I've written a detailed tutorial that incorporates the top two answers on this question: http://blog.johannesmp.com/2015/09/01/installing-clang-on-windows-pt1/
TL;DR
On Windows, Given the following program:
#include <iostream>
int main()
{
int arr[] = {1, 2, 3, 4, 5};
for(auto el : arr)
{
std::cout << el << std::endl;
}
return 0;
}
I want to be able to do the following:
clang++ hello.cpp -o hello.exe -std=c++14
And get a 64 bit executable that just works. I don't want to have to append a ton of -I includes to tell clang where to find iostream or other standard c++ headers; I don't want to have to link in multiple steps.
I don't care so much about performance, efficiency, what linker is used, etc. I just want to be able to have clang/gcc/whatever set up correctly so that I can use a single, quick and dirty, console command like the one above.
What do I need to install for that to just work?
The Problem
As a predominately mac/linux user I'm used to being able to just use a package manager to install the latest version of clang, which just works.
I'm now trying to set up clang/gnu compiler on windows and it seems to be far more difficult, If only because there is little to no straightforward documentation out there (that I've been able to find)
I've tried to follow this tutorial: https://yongweiwu.wordpress.com/2014/12/24/installing-clang-3-5-for-windows - and was able to use it to get clang to build and link (using gcc 4.8.2), but the resulting binaries were 32 bit.
I've tried installing the latest prebuilt binaries of clang (3.6.2) and the 64 bit version of mingw-w64 (4.9.3 for 64 bit with posix and sjlj for exceptions), and am getting:
hello.cpp:1:10: fatal error: 'iostream' file not found
#include <iostream>
^
1 error generated.
Which seems to indicate that clang is not seeing gcc's files. It seems that some versions of LLVM/clang are looking for only certain versions of gcc, but that doesn't seem to be documented anywhere?
Similarly someone mentioned to me on the LLVM IRC that you need to modify clang's driver to look for gcc in certain paths?
What I'm looking for
I'm fine with building LLVM/Clang from source if necessary, but I'm really just looking for clear, step-by-step instructions that allow me to use clang++ as easily as I'm able to do with mac/linux
Something like:
Build this version of LLVM/Clang and place it in that directory
Download and install this version of cygwin (or mingw32 or mingw-w64) and install these packages.
etc..
Try installing MSYS2 and then installing the mingw-w64-x86_64-clang (binary) package:
pacman -S mingw-w64-x86_64-clang
It is a bit old at the moment (3.6.2), but it might be good enough for you. Then when you run the Win64 shell provided by MSYS2, clang will be on your path.
If it's not good enough, I have recently been building a 64-bit version of clang with MSYS2 and using it to compile native 64-bit Windows executables. My process was something like:
Use pacman to install base-devel, mingw-w64-x86_64-ninja, mingw-x86_64-cmake and perhaps some other packages that are needed by the build process.
Grab my PKGBUILD script for clang and the files in the same directory. This is based on the mingw-w64-clang-svn package from MSYS2, which is largely the work of Martell Malone. You can find him on the MSYS2 IRC channel and ask him more about it.
In a Win64, shell, go to the directory with my PKGDUILD, run export MINGW_INSTALLS=mingw64 (so you are only compiling the 64-bit version), and then run makepkg-mingw.
It is unlikely you will get everything right on the first try, and some files might need to be edited. Clang may have changed since the last time I did this and some patches might not apply cleanly.
if you use the upcoming clang 3.7.0, simply set PATH to include mingw-w64's bin, clang will work as you expect
You can install llvm pre-release binary for Windows here. MinGW-w64 can be downloaded here. Of course, you should make sure the paths are properly set up.
For the latest version of clang, e.g., clang 6.0.0. The above solution by #user5271266 will not be enough. Now the default target for clang Windows is x86_64-pc-windows-msvc (Assume that you are using 64 bit Windows).
In order to compile C++ source files, according to here, we should change the target:
clang++ -target x86_64-pc-windows-gnu -std=c++14 test.cc -o test.exe

trying to make frama-c work on Windows 7, using Perl or MinGW or

I want to use frama-c for static C code analysis. It already took me some effort to install it (hopefully) properly. The files are located at C:\CodeAnalysis\frama-c. I want to apply it via Windows console, e.g.:
C:\CodeAnalysis\frama-c\bin\frama-c hello.c
hello.c is just a simple hello-world-program (I am no C programmer btw and a newbie in programming)
#include <stdio.h>
main()
{
printf("Hello World \n");
}
So when running the above command there is the following output:
[kernel] preprocessing with "gcc -C -E -I. hello.c"
C:/Strawberry/c/x86_64-w64-mingw32/include/stdio.h:141:[kernel] user error: syntax error
[kernel] user error: skipping file "hello.c" that has errors.
[kernel] Frama-C aborted: invalid user input
Yes, I have Perl installed but have no idea why Frama uses it. To me it seems that there is somehow something wrong with the stdio.h. Can this be? But I can compile my program successfully.
C:\Strawberry\c\bin\gcc hello.c produces a nicely working exe file.
When removing the include statement from the file, there is the following output:
[kernel] preprocessing with "gcc -C -E I. hello.c"
hello.c:5:[kernel] warning: Calling undeclared function printf. Old style K&R code?
So frama itself does work and this is the kind of output I expected to have.
I also have MinGW installed and tried to make Frama use this for compiling. So I removed the Strawberry entries in my Windows Path. After that calling frama-c produces the same output.
When completely uninstalling Strawberry Perl, frama doesn't work (stating gcc is an unknown command), although C:\MinGW\mingw64\bin is also added to my Windows Path, even as very first entry.
C:\MinGW\mingw64\bin\gcc hello.c works, gcc hello.c doesn't.
When Perl is installed gcc hello.c works, even when I delete the Strawberry parts from the Windows Path variable. Wtf?
How can I make things work properly?
There are several issues here, and we have to isolate them in order to fix things.
Strawberry Perl installs its own gcc (based on MinGW), binutils, C headers, etc., by default on directory C:\Strawberry\c\bin. It adds this directory (among others) to the Windows Path variable. Frama-C expects gcc to be in the path, and it is Windows who decides which gcc to choose, if there are several directories in the path which contain a gcc binary. This is why Frama-C seems to use it.
One common mistake (not Windows-specific, but which happens more often in Windows due to the nature of its graphical applications) is to modify environment variables and forget to restart the processes which still have old copies of them (such as Command Prompt). echo %path% should confirm which directories are present in the path for the current command prompt, if there are any doubts about its value.
In case echo %path% contains the expected value, this is what might have happened (unfortunately I cannot reproduce your configuration to test it thoroughly): during installation of Frama-C, it may use the settings present during installation time to choose which directory contains gcc (in your case, C:\Strawberry\c\bin) and later hardcode this directory in its scripts.
This could explain why, after uninstalling Strawberry Perl, even if another gcc was in the path, it was not considered by Frama-C. Ideally, reinstalling Frama-C with a single gcc in the path could allow it to find the right version this time. Note that this is just a hypothesis, I may be completely wrong here.
In any case, the major problem you're having is not with gcc itself, but with the headers included with Strawberry Perl, as explained in the next item.
Concerning the error message:
C:/Strawberry/c/x86_64-w64-mingw32/include/stdio.h:141:[kernel] user error: syntax error
[kernel] user error: skipping file "hello.c" that has errors.
It is indeed not extremely informative and might change in future versions, but it does point to the source line which causes the error (file stdio.h, line 141):
int __cdecl __mingw_vsscanf (const char * __restrict__ _Str,
const char * __restrict__ Format,va_list argp);
In particular, it seems that __restrict__ is the source of the error here (Frama-C Sodium accepts restrict and __restrict, but not __restrict__; this may change in future versions).
Unfortunately, even fixing this (by adding e.g. #define __restrict__ restrict before #include <stdio.h> in your file) does not guarantee that the rest of the file will be parsed, since it seems to be a Windows-specific, C++-prone header that likely contains other C definitions/extensions that are not in the C99 standard, and possibly not accepted by Frama-C.
The best solution would be to ensure Frama-C uses its own stdio.h header, instead of Strawberry Perl's. It is usually installed in share/frama-c/libc (that is, it could be in C:\CodeAnalysis\frama-c\share\frama-c\libc in your installation), but depending on your configuration the headers might not have been found during execution, and Strawberry Perl's headers were included instead.
A quick hack for this specific case might be replacing:
#include <stdio.h>
with:
#include "C:\CodeAnalysis\frama-c\share\frama-c\libc\stdio.h"
But it is far from ideal and likely to lead to other errors.
If you manage to find out how to prevent Strawberry Perl's headers from being included, and ensure Frama-C's header files are included instead, you should be able to run Frama-C.
Note about Cygwin/MinGW path issues
I've had some issues when using a MinGW compiler and a Cygwin build (which is not necessarily a good idea), so here are some quick instructions on how to build Frama-C Sodium with a MinGW-based OCaml compiler using a Cygwin shell (but not a Cygwin-based OCaml compiler), in case it might help someone:
When running ./configure, you'll need to specify a --prefix using a Windows-based path instead of a Cygwin-based one, such as:
./configure --prefix="C:/CodeAnalysis/build"
If you don't, when running Frama-C (after make/make install) it will fail to find the libc/__fc_builtin_for_normalization.i file because it will try to use the Cygwin-based path, which will not work with the MinGW-based OCaml compiler.
Note that you cannot use backslashes (\) when specifying the prefix path, since they will not be correctly converted later.
I had to use the following command to ensure the makefile worked correctly:
make FRAMAC_TOP_SRCDIR="$(cygpath -a -m $PWD)"
Again, this is due to Cygwin paths not being recognized by the MinGW compiler (in particular, the absolute paths used by the plug-ins).
The previous steps are sufficient to compile and run Frama-C (plus the GUI, if you have lablgtk and other dependencies installed). However, there are still some issues, e.g. absolute Windows filenames are not always handled correctly. This can often be avoided by specifying the file names directly in the command line with relative paths (e.g. frama-c-gui -val hello.c), but in the general case, MinGW+Cygwin is not a very robust combination and other issues may arise.
Overall, mixing Cygwin and MinGW is not a good idea due to path issues, but it is nevertheless possible to compile and run Frama-C in such conditions.

Same simple source code, different binaries on Windows

I have a question about the source-code binary on Windows.
#include <stdio.h>
int main()
{
printf("Hello, world!\n");
return 0;
}
The same source code, I compiled twice on Windows (VS 2008 Cmmand Prompt: "CL"), but I got different binaries.
cl new.cpp
Can you guys tell me why, and how to avoid that?
The timestamp is part of PE format. You'll always get different values regardless if compiling as release or not.
Did you compile as release? Debug has timestamps built in which can change your exe per compile
I googled, and found a mid-way solution:
DUMPBIN /RAWDATA MyApp.EXE > first.txt
DUMPBIN /RAWDATA MyApp.EXE > second.txt
http://support.microsoft.com/kb/164151
How to compare binary images of the same project builds

Resources