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
Related
So my idea is to "lift" 64-bits Windows executable to LLVM bitcode (or whatever is higher than assembly) and then compile it back to 32-bit executable.
I found that RetDec and McSema can lift PE binary to LLVM IR (and optionally C), but McSema requires IDA pro so I haven't tried it yet.
I have installed MSVC v143 and Windows SDK version 10.0.19041.0:
Clang version:
clang version 13.0.1 (https://github.com/llvm/llvm-project 75e33f71c2dae584b13a7d1186ae0a038ba98838)
Target: x86_64-pc-windows-msvc
Thread model: posix
So I compile this Hello World code in C using Clang:
#include <stdio.h>
int main()
{
printf("Hello, world!\n");
}
then clang hello.c -o hello.exe
Check hello.exe file type with WSL:
$ file hello.exe
hello.exe: PE32+ executable (console) x86-64, for MS Windows
You can download it here.
Then I use RetDec to lift it to LLVM IR:
python retdec-decompiler.py --no-memory-limit hello.exe
Output: here
After that we get:
Compile bitcode back to executable:
clang hello.exe.bc -m32 -v -Wl,/SUBSYSTEM:CONSOLE -Wl,/errorlimit:0 -fuse-ld=lld -o hello.x86.exe
Output: here
I guess functions like _WriteConsoleW are Win32 APIs, but ___decompiler_undefined_function_0 might be generated from the decompiler by some way.
Also, the decompiled code has no main function, but it had entry_point function. From hello.exe.ll:
hello.exe.c also has entry_point instead of main:
And also, hello.exe.c doesn't have ___decompiler_undefined_function_0
I also tried running the bitcode with lli:
lli --entry-function=entry_point hello.exe.bc
Output: here
Here is the link to the files.
How to make this compile? Thanks!
That's very ambitious.
I'm going to go out on a limb and say that every windows application includes thousands of system header files, most of which use types whose size differs between 32- and 64-bit systems and many of which contains #ifdef or other platform-dependent differences. You'll have a large .ll file full of windows64-specific types and code.
If the developers at Microsoft saw windows64 as a good chance to drop some hacks that were needed for w95 code, then you'll have w32-incompatible code there, too.
What you have to do is what the wine developers did — add code to cater to each problem in turn. There will be thousands of cases to handle. Some of it will be very difficult. When you see the number 128 in the .ll file, was it sizeof(this_w64_struct) in the original source, sizeof(that_other_struct) or something else entirely? Should you change the number, and if so, to what?
You should expect this project to take at least years, maybe a decade or more. Good luck.
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.
Have Already read dozens of post on the subject but nothing seems to match my problem.
So, I've upgraded my VS2013 'VS2015'.
I have dozens of projects in my solution using boost as additional library.
I've also recompile boost.
when compiling my projects I get this error.
LINK : fatal error LNK1104: cannot open file 'libboost_thread-vc120-mt-s-1_55.lib'
lib libboost_thread-vc120-mt-s-1_55.lib used to exists when I compiled boost for VS2013. But after compiling boost for VS2015 the lib name has changed to
libboost_thread-vc140-mt-s-1_55.lib (which is great).
Question
Why does the linker looking for file libboost_thread-vc120-mt-s-1_55.lib. How does it knows which file to link?
I had the exact same problem converting from VS2013 to VS2015, and at the same time changing Boost version from 1.59 to 1.61.
After two days of googling, SO'ing and trying out different variants, I seem to have ended up with a working solution, although I don't know why.
I compiled Boost (I believe exactly like the four previous attempts) using VS2015 x86 Native Tools Command Prompt with:
> "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86
> .\bootstrap
> .\b2 install --prefix="<MY_BOOST_DIR>\msvc14" --buildtype=complete --build-dir="<MY_BOOST_DIR>\build" toolset=msvc-14.0 variant=release,debug link=shared -j4 --address-model=32
After this I tried compiling my very simple test
#include <boost\filesystem.hpp>
#include <iostream>
int main()
{
boost::filesystem::path rootpath = boost::filesystem::current_path();
std::cout << rootpath.string() << std::endl;
std::cin.ignore();
return 0;
}
With the appropriate Boost directories set for include and lib dirs. While the file 'libboost_filesystem-vc140-mt-gd-1_61.lib' verifiably is at the lib folder, VS2015 still complained it couldn't find the file.
As a last random poke at it, I changed my target platform to x64, after which the linker error changed to a warning about the conflict:
warning LNK4272: library machine type 'X86' conflicts with target machine type 'x64' ...so for some reason, now VS was able to find the file! After which changing the target back to X86 resulted in a working configuration, while nothing really changed.
Could somebody explain/verify this? Does this solve your case, #idanshmu?
all.
Compiling simple stuff using the gcc toolchain for several years, today I ran against a curious phenomenon.
I installed Kubuntu 14.04 to a common desktop i686 machine with gcc 4.8.2 in it. But then, trying to build some well coded stuff pulled out from my local repository, I ran against tons of 'undefined reference to' messages. The code compiles, links und runs well under Ubuntu 11.04 / gcc 4.5.2.
I checked the linking process (by -Wl,--verbose to gcc), think it works. It finds all libraries I specify in the link command. An objdump -t myLib.so brings exactly the symbols I'd expect - but the linker doesn't see them.
Checking the pthread library also brings according symbols, except they are suffixed with some #GLIBC... stuff. Didn't check linker/loader tricks so far.
A sample like
#include <stdio.h>
#include <unistd.h>
#include <pthread.h>
static void *fooo (void *xxx) {
char *txt = (char*)xxx;
printf("My job is to print this :'%s'. Bye now!\n", txt);
return 0;
}
int main (int argc, char *argv[]) {
pthread_t thd;
pthread_create(&thd, NULL, fooo, "A POSIX thread");
sleep(1);
return 0;
}
runs very well on the old system just saying
gcc -l pthread fooo.c && ./a.out
but breaks at the linking step with 4.8.2.
Any idea would be very welcome.
.M
Thanks to sfrehse, JoachimPileborg et al!
Indeed, success depends on argument order. I knew this fact for static linking, but it is new in processing of shared objects with gcc.
Does someone know what the background of this improvement is? It breaks innumerable build processes, and I guess thousands of tomatoes are being made ready against gcc.gnu.org .....
.M
For a week I've been struggling with compiling openCV programs. I've tried everything I could possibly find on the internet.
What I did is: I've downloaded OpenCV-2.3.1-win-superpack.exe and followed this official installation guide.
In the CMake (gui) my source was: D:\opencv and build destination was: C:\opencv.
I've also added C:\opencv\install\bin;C:\opencv\bin to my system's PATH variable.
What I want is to compile openCV programs on my Windows OS using MinGW's gcc/g++ compilers.
I've tried various gcc/g++ parameters that I've found on the internet and days playing with the -I and -L options the compiler can never find the openCV functions or structures.
What I am trying to compile:
#include <stdlib.h>
#include <stdio.h>
#include <math.h>
#include <cv.h>
#include <highgui.h>
int main(int argc, char *argv[])
{
// Nothing but create a window
cvNamedWindow("mainWin", CV_WINDOW_AUTOSIZE);
cvMoveWindow("mainWin", 100, 100);
cvWaitKey(0);
return 0;
}
Error:
Input:
gcc test.c -o test -I"C:\opencv\install\include" -I"C:\opencv\install\include\opencv" -L"C:\opencv\install\bin"
Output:
...\ccK4MfHv.o:test.c:(.text+0xa0b): undefined reference to `cvFree_'
Or with g++:
Input:
g++ test.c -o test -I"C:\opencv\install\include" -I"C:\opencv\install\include\opencv" -L"C:\opencv\install\bin"
Output:
...\ccXCTKa1.o:test.c:(.text+0x1e): undefined reference to `cvNamedWindow'
Side note: trying to compile in VS2005 I get the same error.
Thank you for your time!
In case someone else needs to solve this issue, here's how I got the posted OpenCV/HighGUI sample code to compile in Windows 7 x64 using MinGW, MSYS, and CMake:
build OpenCV from source using MinGW/MSYS/CMake. This is because I could not get the MinGW compiled version in the OpenCV-win-SuperPack to link properly in MinGW/MSYS/Windows 7 x64.
For full reference, here's how I compiled OpenCV:
make sure you have an up-to-date CMake (v2.6 or later) and MinGW (with GCC, G++, and MSYS options) installed
if you want the new Qt-based OpenCV HighGUI front-end, you will need to install Qt 4 (SDK).
download a OpenCV source/superpack version 2.2 or later (I used OpenCV-2.3.1-win-superpack.exe)
unzip the contents to [OPENCV_SOURCE_DIR] (I put it in C:/opencv, so there should be a file at C:/opencv/README for example)
create a [OPENCV_BUILD_DIR] directory elsewhere (I used C:/opencv/build/mingw)
use the CMake-GUI tool, specify the source directory as [OPENCV_SOURCE_DIR], the build directory as [OPENCV_BUILD_DIR], and click "Configure".
you may wish/need to go tweak the options (e.g. I ticked "Qt" and "Qt-OpenGL" entries, then clicked "Configure" again, then had to provide the path to the qmake executable)
once you have finished configuring OpenCV, click "Generate"
in a MSYS terminal, browse to [OPENCV_BUILD_DIR], and run "make" to build the code (this may take a while)
once the has been built properly, run "make install", which collects the built code/libraries/include dirs into [OPENCV_BUILD_DIR]/install folder (or a different folder if you changed the corresponding option when using the CMake-GUI tool)
add [OPENCV_BUILD_DIR]/install/bin folder to the PATH environmental variable. If you do not know how to do this, then I'd recommend using the Path Editor GUI tool.
if you end up using Qt, you will also need to put the bin folder of Qt SDK in the PATH environmental variable. This is the folder that includes qmake.exe.
put the following sample code into a file called test.c. I modified the includes slightly to make them compatible with OpenCV v2.2 and above.
#include <stdlib.h>
#include <stdio.h>
#include <math.h>
#include <opencv/cv.h>
#include <opencv/highgui.h>
int main(int argc, char *argv[])
{
// Nothing but create a window
cvNamedWindow("mainWin", CV_WINDOW_AUTOSIZE);
cvMoveWindow("mainWin", 100, 100);
cvWaitKey(0);
return 0;
}
in a MSYS terminal, browse to the folder where you put test.c, and run:
gcc -o test -I"[OPENCV_BUILD_DIR]/install/include" test.c \
-L"[OPENCV_BUILD_DIR]/install/lib" \
-lopencv_core[OPENCV_VERSION] \
-lopencv_imgproc[OPENCV_VERSION] \
-lopencv_highgui[OPENCV_VERSION]
So in my case:
gcc -o test -I"/c/opencv/build/mingw/install/include" test.c \
-L"/c/opencv/build/mingw/install/lib" \
-lopencv_core231
-lopencv_imgproc231
-lopencv_highgui231
Path Editor: http://www.redfernplace.com/software-projects/patheditor/
You have the directory, C:\opencv\install\bin, to locate libraries on the gcc/g++ command line, but I think you'll also need to specify the libraries to use as linker inputs as well. I'm not sure what libraries are part of the OpenCV distribution, but going by the example on the instruction page you linked to, one might be:
-lopencv_calib3d220.dll
You'll probably have to add one or more other ones (that follow the name pattern lib*.a in the C:\opencv\install\bin directory - or maybe some other lib directory that you should be passing in a -L option).