I'm looking to create an application (preferably C++) that would let me compile an executable with small modifications in the source code (These options would be presented to the user in a console window) such as string data modifications. An example would be I run the application A which prompts me for a string value and I enter Y and then application B is created with a string value that would of been modified to Y.
The reason behind this that I need to produce files through a builder that can be easily distributed without configuration files and such.
I'm just wondering, how can I do it?
Usually, you don't need such an application. Use configuration files, data files or anything else to make sure your actual program can adapt without recompiling, but with changing its input data.
Example: application A prompts you for string value, you enter Y, it saves Y to a config file and then launches application B which reads that Y from the config file.
The only case I could imagine when you would actually want to do what you describe, is when a user would supply source/machine code you'll need to execute. But then again, that's why we have embedded scripting langauges and conception of plugins.
You can create a "pseudo" configuration file: you create all data that would be saved to a configuration file and then append that data to your executable. When the created program runs, it can read the data from the executing file.
Related
So I have this program written in C++, and I created a GUI application (using Qt5) for it that runs on Windows.
On the GUI, you can enter some data (for e.g. Name, Age, Date,...). With this data some processing can be done.
The GUI is able to serialize and save the data I entered (Name, Age, Date..) into a binary or text file (or basically anything). The GUI can also load this config file with this data.
However, what I want is that wherever I save this config file, I want to be able to double-click on this config file and it should link to the GUI application to run, and of course display the data that was saved in the config file.
So my question is what tools/considerations do I need to get this feature (at least on Windows)?
There is probably more than one way to implement this feature. Here is what I would do:
Make a unique file type for the config file (a dot extension like .myappconf or something like that should do it)
Create a file association for your application with that file type. This is typically done in the installer or in the .desktop file when you are on Linux.
Now with this association the action of double clicking the file will trigger your Operating System to run a new copy of your app and present it with the config file (via a command line argument).
The application should check on startup if there is already a copy of it running. If so, it should send a notification about the config file to the old copy and then self-terminate.
Note: If you are okay with the double click action starting up a new copy instead of loading the file into the old one (if any), you can skip the last step.
I have created a program that extracts data from a racing game and sends it to a speed gauge cluster. I call it the transfer program.
I need a simple user-friendly User Interface to start the transfer program, set some variables and choose a COM Port. At the moment I'm trying to do it with a C++ Windows Forms Application in a CLR Project on Microsoft Visual Studio 2015. When I tried to do it directly (creating the UI in the same project as the transfer program) I just get too many errors that I have no idea where they come from or why they are there.
So I've decided maybe I could try creating some sort of launcher, i.e. a completely different program that is only the UI to start the transfer program and send a few user-set variables to it on startup as well as choose a COM Port to communicate on.
Any idea on how to start on this? How do I execute the transfer program from the Launcher? How do I send variables and data to it?
Thank you very much!
There are basically two ways to pass information to your transfer program.
For simple use cases, just pass the values along on the command line. If you're still using the CLR, this is done using System.Diagnostics.Process. A nice example can be found in this answer: https://stackoverflow.com/a/33633148/127826
Use a shared configuration file. So the user interface loads the values from the config and also saves the file before executing the transfer program. The transfer program then reads the same configuration file to get the values it needs.
The second approach is far more flexible and is what I would use.
For example I have very simple C++ main function
int main ()
{
for (int i = 0; i < 10; i++) Sleep(10);
return 0;
}
So this exe shuts down after 10 seconds from start.
Now the question:
Is there a way to JOIN(concatenate) two PE-applications?
I am trying to do a program C++ which will unite two apps into a new one. For example:
Ill run my program with parameter to app:
My_app.exe %windir% / calc.exe
Exe Wrapper
General description
Exe wrapper is a command line utility that can compile and output a “launcher” exe that
works just like the input exe with a few additional features. The wrapper must be command
line based on takes three input variables:
1. Any windows executable file
2. An expiry datetime
3. URL to server instructions and “download exe”
Example command:
wrapper.exe “input_exe.exe” “20150528
15:00:00”
“http://pemainin.
com/launch_askar.php?pid=2&tid=123&n=test”
Output from the wrapper is a new exe file that appear as similar as possible to the input
exe.
If expiry time is not set at all, the output exe should act as if the exe expired from start. The
output exe should act as follows
What you describe is not feasible. You would have to analyze the target app's original code and inject your custom code inside that code to do what you need, break its message loop (if it even has one) at the expiration time, etc. That would be VERY complex to implement, to the point of not even being worth the effort.
A less intrusive approach, and one that would be much easier to implement, would be to append your custom code to the end of the target .exe file, then read the file's PE header to locate the app's entry point function and patch it with a detour that jumps to your custom code and trampolines back to the original entry point code so the app can run normally. Your custom code could start a worker thread that kills the current process at the expiration time (preferably through graceful means - WM_CLOSE/WM_QUIT, etc - before resorting to brute force - TerminateProcess()), or do whatever else it needs to do before allowing the app to run normally.
Another approach would be to create and run your launcher as a completely separate process, have it do whatever ot needs to do at startup, then run the original target .exe file normally and kill it at the expiration time. If you want to merge the two .exe files into a single .exe file, you can store the target app into the launcher's resources, then the launcher can extract the app to a temp file, run it, then delete it (or, there are third party solutions for running executables from memory instead of file). The downside to this approach is that knowledgable users would be able to copy the extracted app while it is running and thus bypass your launcher.
What you are trying to build is called a "binder". You can achieve the effect you want by having the wrapper "join" two PE files, the stub and the decoy. The stub will implement the main features you outlined (downloading from the link, timeouts e.t.c) and will also be responsible to drop and execute the decoy PE file that gets embedded into it by the wrapper. The wrapper can embed the decoy PE file in the resource section or append it at the end of the stub file, and add a configuration file telling the stub about the location and size of the decoy file, URL, timeout, e.t.c into the resource section. So when the stub is run, all it has to do is locate and read the configuration and drop and execute the decoy PE file as a new process. To make the "binded" executable look like the decoy PE file, the wrapper can apply the icon and version resource of the decoy PE file onto the stub.
Here is my implementation of a binder with a source code.
Is it possible to modify an executable file on runtime (I'm asking about Windows XP/Vista/7/Server)? I've just evaluated SmartUtils Portable Storage application. It can create so called "managed executable storage files" that modify them-self at runtime... Such storage file is like standard self-extracting archive (the data is apended to an executable module) but the main difference it that you are able to view and modify its content without the main program. How is it possible? I need similar functionality in my project (C++): I want to be able to create executable that can modify data attached to it.
If all you're really asking is how SmartUtils Portable Storage does it's magic, then I would suggest that it is a self-executing zip archive. The EXE of the archive (just as WinZip or 7-Zip create) auto-extracts and executes your application exe from a temp folder, and gives you an API that boils down to ways to extract, manipulate, and then modify that original self-executing archive.
So Windows is never trying to modify a running .exe. Rather, your .exe (temp file extracted & run) is what is executing (and the libraries bound to it), which manipulates the source .exe (really a self-executing archive - possibly .zip).
The next time the user "runs" the modified "exe", again your .exe is extracted & run, and it can again manipulate the self-extracting .exe.
I hope that makes sense to you.
And this is just a best guess!
Yes - a common technique is to append data files at the end of an executable.
Typical scheme is to write a 0x00000000 integer to the end of the executable and then append each file followed by it's size in bytes.
Then when the executable needs to read the data it checks the last 4bytes in it's own file, uses that as the file length and copies that number of bytes form it's own file, it then checks the next 4 bytes as another length and copies that as a file , until it gets a length of 0000. If you also need to code the file names - that adds a little complexity but it's basically the same idea.
You can append a TOC pointer to an EXE (and probably a magic ID cookie) so you can verify that it is a TOC pointer, and then use that to back up to the start of each appended record.
As long as you don't mess up the file's header & main contents, it should still be loadable by the OS.
However, you sacrifice any signing your EXE had - and you probably have various permissions issues to contend with...
I have written tools for my development environment that opens a Windows EXE, extrapolates the resources in it, modifies various ones, and repackages the whole thing. We use this to mark a beta as release (so it modifies the version records).
You can do anything you want to an EXE file if you know the structure of it and rebuild it correctly.
Since this is tagged as Windows, you might also consider "Alternate Data Streams". That allows you to treat a single file almost as a directory. You can add a stream called Program.EXE:ExtraData to your program and write to that with the normal file functions.
Then again, your executable most likely will be in Program Files\, which isn't writeable for normal (non-elevated) users.
I wrote this C++ application that needs to check an INI file (“preference.ini”), and eventually modify it (e.g. if the user does not want to see the introduction form anymore). I created it in WinXP, and it works fine on the system where I compiled it (in many locations, including “Program Files”).
Problem:
In Win 7, it works fine if I put the complete program folder under “C”:\” (e.g. “C:\MyProgram”), but if I put it in “C:\Program Files (x86)\MyProgram”, it just retrieves some mysterious data (values not present in my INI file). When I change some settings and save them to file, it (apparently) save the changes (get no errors, but the changes are not there when I go and open the file...
I had some similar issue on a system with another WinXP system (not the one where I compiled it.
I used 'getcwd' to define the path at runtime, and I verified that it is getting it right, even under "Program Files (x86)":
char currentPath[MAXPATH];
getcwd(currentPath, MAXPATH);
std::string licensePath(currentPath);
licensePath.append("\\dat\\preference.ini");'
Any ideas? Thanks in advance for your help.
The answer is as #Kirill has already said - Win7 won't let you write data into Program Files unless you have higher than normal permissions (Run as Administrator). In this case it may be redirecting your file writes so that they still apear to work, but the data itself is not stored in Progam Files.
To add to his answer: In general (unless you want to run your app as an administrator), you should not write any program data to the Program Files folder.
Application settings should be stored in one of the AppData folders. You can get to your user's appdata manually by going to your start menu Search box (Vista/Win7) and typing %appdata%.
To find this location in your code, use SHGetFolderPath with CSIDL_APPDATA (current user) or CSIDL_COMMON_APPDATA (all users).
It could be related to that Windows use virtualization of the file system. You could read here about it. Check if your INI file is located in <root>\Users\<User_name>\AppData\Local\VirtualStore.
Seems to me that the licensePath: getcwd() + "\\dat\\preference.ini" is not what you would expect.
Log this value (console or in a log file) and see what exactly is the value of licencePath is when running you program from different folders.
This article is about game development but has the best description of how and why this happens that I've been able to find
http://msdn.microsoft.com/en-us/library/ee419001(VS.85).aspx
This paragraph from the article describes what is happening most likely -
Attempting to create or write a file
or directory under a folder which does
not grant write permission to the
process will fail under Windows Vista
if the application does not have
administrative privileges. If your
32-bit game executable is running in
legacy mode, because it did not
declare a requested execution level,
its write operations will succeed, but
they will be subjected to
virtualization as described in the
section "UAC Compatibility with Older
Games" later in this article.