I am currently trying to get an executable running in memory. Because it is high likely that someone will ask later: Yes, it will be used for malicious software in order to hide it from AV. It is only for educational purposes, in specific for a school project (will be part of my graduation).
However the question concerns something else. I found a really good source at Github: https://github.com/aaaddress1/RunPE-In-Memory, which works perfectly for my uses (I already changed it for my purposes etc), except for the trojan I want to run. I tried it with several, e.g Darkcomet or Darktrack (It needs to be something old what is already well known to demonstrate how you could reuse them). I thought because Darkcomet it coded in Delphi (which outputs a native?), it would work like any other EXE-File (Like the ones provided at Github), but it just does not start. In Darkcomet there is also an option for making the malicious server file noticeable, so it is safe that I did not fail at any port-forwarding stuff.
My first intention then was to open the EXE in a text editor and look if it is even the same architecture. I can find "PE L" in both binaries, so as far as I know it is both 32bit. A thing what seemed strange to me were the two lines
"This program cannot be run in DOS mode." for the compiled runPE loader
and
"This program must be run under Win32" for the trojan executable.
Furthermore the two Binaries differ in the first chars: MZ and MZP.
After opening up more binaries and testing them, I came to the conclusion that the ones with "This program must be run under Win32" do not work.
As far as i know and also googled, there are DOS and Windows executables. But if there are only these two types, why is there a difference?
"must be run under Win32" == "cannot be run in DOS mode." in my opinion.
I also looked up those two terms , but I only get Threads about people who try to run these Windows-PEs in DOSBox or similar things.
So, my actual two quesions are:
-What is the difference between "This program must be run under Win32"(Type1) and "This program cannot be run in DOS mode."(Type2)
-Why does it not work if I want to push a (Type1)program into the Memory with the (Type2)RunPe-InMemory executable which I made from the Github repository.
What is the difference between ... (Type1) and ... (Type2)
Nothing:
A "PE" executable consists of some MS-DOS EXE file followed by a 32- or 64-bit part.
If you start the "PE" executable under MS-DOS (or any compatible operating system), DOS will ignore the 32- or 64-bit part and execute the MS-DOS EXE file at the start of the "PE" executable file.
A few programs are written in a way that the DOS EXE file at the start of the PE file is doing the same as the Windows part, so you can use the same EXE file both under DOS and Windows.
However, in most cases the DOS part only prints some error message saying that the program cannot be started under MS-DOS.
What you see here are two different MS-DOS programs at the start of the PE EXE files; one program prints the error message "This program must be run under Win32", the other one prints "This program cannot be run in DOS mode."
Furthermore the two Binaries differ in the first chars: MZ and MZP
This is also not a difference:
The third byte of MS-DOS files is one of many bytes describing the length of an MS-DOS program. Because you have different MS-DOS programs, they also have different lengths.
In one case the byte has the value 80, which is shown as "P" in a text editor.
In the other case the byte might have the value 10 (as an example), which is not shown as character in a text editor.
Why does the runPE not work with a specific type of executables?
Not having seen the trojan, I cannot answer this.
However, I have seen many trojans which do not use a correct "PE" file format.
(However, in these cases the "errors" were after the "PE L", not in the "MZ"-part.)
Related
I am making a retro text adventure game in Turbo Pascal that will be played in MS-DOS, and I want it to be in the COM file format. I've looked it up and have found nothing on this subject. If you can help me that would be greatly appreciated.
Something other than that, whenever I try to run my program (compiled into EXE) from DosBox it can't run due to "This program cannot be run in DOS mode". Is this because I'm using Turbo Pascal 7 and need to downgrade? Thanks a lot of you can figure this out.
Set your TP7 to target dos, not windows. Note that you might have an Windows only TP product (also known as TPW)
COM files will still be out of your reach, but at least DOS exe files should run in dosbox. Keep in mind that COM files have a 64k limitation, and therefore are of limited interest.
Free Pascal is working on a DOS16-bit Dos compiler that can generate com files directly from (64-bit) Windows, and while it is working, it is not released yet.
Is it possible to convert a DOS Application to a Win32 Console Application? I have an old program I wrote a long time ago, lost the source to it and asked myself now if it's possible to convert the DOS Binary to an actual Windows Binary, which runs in Command Line Prompt?
This is not possible. The DOS program will attempt to use DOS system calls that do not exist under Windows. The program will need to be updated and rebuilt for Windows. You might have some success running the original program in a DOS emulator.
See other answers about running a DOS program under Windows.
To convert a DOS program to a Win32 console application, one would have to convert the 16-bit (8086) code within the DOS program to 32-bit (i386) code. This is a very hard task to do right, and probably that's why there is no converter readily available. (Alternatively, an emulator can run 16-bit code without conversion, see the other answers and comments.)
However, not all DOS programs contain 16-bit code, for example programs using DOS extenders built with the Watcom C/C++ compiler (or, equivalently, with OpenWatcom: owcc -bdos4g prog.c) contain only 32-bit code. Windows can run 32-bit code directly, but API calls (e.g. opening and reading a file, allocating memory, getting the current time, writing colorful text to the console) have to be converted from the DOS+DPMI API to the Win32 API. Such a conversion is technically possible and feasible (even on the final .exe file, without access to the source code), and it is much easier to do correctly than the conversion of 16-bit code to 32-bit code. However, I still don't know of a converter readily available.
Please also note that conversion graphics and audio code to the Win32 API is very hard, but that's out of scope in this question.
As part of my research in the university I wrote an application that can iterate over a large amount of .exe files, execute each one individually and collect runtime data using Procmon. That data is later runs through a machine learning.
The problem is I need at least 100 .exe files, that none of them will be an installation wizard and preferably that none of them will be a virus. :-)
I would also like not to search the internet manually, and that none of the .exe files will be a windows application (such as notepad.exe and regedit.exe).
I'd appreciate some ideas on how to collect such large amount of executable files easily or alternatively where to find an online archive of executable files.
Maybe this can helps you: http://gnuwin32.sourceforge.net/packages.html. You can find about 100 *.exe in CoreUtils package.
Your problem is that executables started without purpose won't do anything useful, most will just complain about lack of command-line arguments, or open a UI that waits for user input.
So your profiling data will collect the behavior of the program doing nothing, not what it's intended to do. Such profiling data is worse than useless.
(I would hate for my compiler's profile-guided-optimization to train only on the code that checks number of arguments and prints a usage message to the console! You may not be working on a compiler, but the principle is the same.)
Write a simple C program in VS or any other compiler and built it. It will create an exe file for u in the bin folder. Rename this exe 100x with different names. None of them will installation widzard, or virus(cuz u wrote the C program...he he he)
If you know any programming language you can write a simple program to pause for a random period, say 1-5 seconds, then just duplicate the EXE file 100 times and give them different names.
Edit: Based on needing already made EXE files, there are a number of them in the Windows/System32 directory, it would be a really interesting experiment to run every EXE file in the Windows directory and see what happens to the stability of your computer (I think most of them are protected so they wouldn't be able to do any damage if called from the command line).
I've always been curious as to how one extension, EXE, can be as versatile as it is in that if you assemble an assembly program, you get an EXE in machine code for your processor but if you compile a C# or other .Net program, you also get an EXE except that it is run in the proper runtime environment. I'm not sure if this is different from OS to OS (I imagine it is), but when an EXE is executed, how is it determined how to execute it?
On a related note, if I were writing my own programming language, how would I tie in my runtime environment into this mechanism?
When compiling a .NET program to an EXE, it's more than just a blob of bytecode (like Java). There's actually native executable created that will load the .NET runtime and hand off the .NET bytecode to it, or display a friendly-ish error message indicating that the framework is not available.
The format is even more flexible than that, as every Windows EXE actually includes a DOS program at the beginning which will display an error ("cannot run in DOS mode") when executed as a DOS program.
You can read more details on the PE format on Wikipedia: http://en.wikipedia.org/wiki/Portable_Executable
I remember a few years ago(2002) there was a multipartite virus that could be run natively on linux and windows. I don't know if a compiler could be specially craft an executable so that it could be read as both ELF and PE, so that the os would start executing at different entry points. Or a program that could merge two programs, one compiled using mingw, one compiled in native linux, to one program.
I don't know if such a program exists, or could it exist, and I'm know this could be implemented in Java or some scripting language, but that's not a native program.
Imagine the possibilities, I could deploy a program with linux and window (and perhaps os/x)libraries, and one main executable that could be run on any os. The cross-platform support would compensate the bigger size.
Windows programs have a DOS stub in the beginning, and I just ran an ELF executable through debug.com, which said that the first instruction of this exe was JG 0x147. Just maybe something could be done with this...
No.
Windows and Linux use vastly different binary file formats. See Portable Executable (Windows) and Executable and Linkable Format (Linux).
Something like WINE will run Windows executables on Linux but that's not the same thing.
This is actually a really terrible idea for multiple reasons.
Cross-compiling across operating system boundaries is extremely difficult to do properly.
If you go for the second route (building separate PE binaries on Windows and ELF on Linux, and then somehow merging them) you have to maintain two machines, each running a different OS and the full build stack, and you'd have to make sure that you tested both versions separately before gluing them together.
Dynamic linking is already a pain to properly manage, on Windows and on Linux; static linking can generate binaries that are much more inconvenient to deal with than whatever imaginary benefits you get from providing one single file type to your end-user.
If you want to run the same binary executable file on multiple OSes, your options are Java, Mono, and potentially NativeClient, the browser plug-in Google's developing to work around the "webapps are too slow" problem.