I would like to know how can i generate an executable using python or c/c++ (or any other langagues) from a program already compiled.
For instance: I have an executable program.exe with a textbox and a button. You type any text you want in the textbox and when you click the button, it generates an executable that can display text you have typed before.
Many keylogger or malware builder does this, they generate a server.exe depends on parameters you have given (email / ftp address).
I would have suggested to generate a source code on a file and compiled it after but what if you don't have the compiler installed in your computer?
Do you have any clues doing this?
One way you could do this is by replacing a dummy value in the compiled program. e.g.
char* ipAddress = "255.255.255.255";
You can than find this string in the application and replace it with the real IP address, or whatever you need. (For C and a lot of other languages, make sure your string is 0 byte terminated.)
The only problem is that it breaks signing, but there are ways around that.
Related
When debugging C++ source in Code::Blocks, points passed a function parameter or a members of data structures are just displayed as their address.
After some research I found I can enter the a custom watch as <pointer-name>#<numerical-size of variable-containing-size> to get it to display as an array, however I can't edit the default display on the structure.
I was wondering if there is some way to mark up the source code with special comments that can be parsed during debug to automate this and make complex object easier to view during debugging.
i.e.
struct {
size_t n;
int *p; /* I want gdb to interpreted this symbols as p#n by default */
}
I would also like to be able to make similar specification for function parameters.
First is this even possible, I can't find any thing online about marking up the source for helping gdb, and suspect it never even looks at the source since the debugging information is either stored in the executable or a debug database.
If there is some way of doing this, how would I do it?
Note: if there is a Code::Blocks specific solution, I would be happy with that.
The issue that you have seems not to be related to quality of debug information but merely how debugger displays values of variables of certain type. That is usually configurable or scriptable.
Code::Blocks uses squirrel script for Debugger scripting. By extending that script you can make debugger to command GDB in specific manner and then to parse and display the outcome how you like. That gdb_types.script in scripts folder is ran by Code::Blocks.
If you want to script GDB itself then that can be done in "Settings -> Compiler & Debugger -> Debugger -> Initial commands" of Code::Blocks, provided script will be ran by GDB. Then you can call the functions defined in that script from the gdb_types.script.
I want to build an C#/Wpf Packer.
I am using a C++ application which will start the packed/crypted C# application.
Currently I have to build this C++ app everytime I want to release my Main-App.
(C#/Wpf-App is included as external Array of Bytes)
Now I want to build a simple tool to do this work, but I dont want to build the "launcher" all the time!
So my idea is just to modify the launcher.
For that I need a way to modify this executable and I need to be able to use this modified data inside the launcher, like it would be compiled.
I dont want to reserve a static sized array inside the launcher, cause I dont know what could be the biggest data-size.
There are different ways to do that. Unfortunately none of them is straightforward nor standard except one: use a makefile that automatically builds the launcher. IMHO, unless you have special requirements such as building the launcher on a system with no development environment, it is probably the most simple and robust way.
As you explicitely ask for other solutions, I will give 2:
on Windows, you could store the c# app as a resource. Once that's done, you can use a resource editor to change it on the fly or build a custom editor using the WinAPI functions BeginUpdateResource, UpdateResource and EndUpdateResource. You later load the resource with LoadResource in the launcher.
you could make the laucher program know its real size and just seek behind that size and load what follows as the C# app. To build it, you just need to copy the actual C++ executable and whatever you want it to process. The hard part here is that there is no portable way to identify the size or the end of an executable at compile time. You could try a two pass build:
first pass, you set the size to an arbitrary value. You build and look at the real size
second pass, you set the size to what has been observed in first pass. As you only modify a size_t value, the size of the executable should not change. But I strongly urge you to control that size twice. Repeat if it is not the same (it could happen if the compiler was too clever and merged identical constants).
But as I already said, my choice would be to use a makefile to automatically generate the launcher each time the C# app is rebuilt
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.
What I'm trying to do is to sign my compiled executable's first 32 bytes with a version signature, say "1.2.0" and I need to modify this signature in runtime, keeping in mind that:
this will be done by the executable itself
the executable resides on the client side, meaning no recompilation is possible
using an external file to track the version instead of encoding it in the binary itself is also not an option
the solution has to be platform-independent; I'm aware that Windows/VC allows you to version an executable using a .rc resource, but I'm unaware of an equivalent for Mac (maybe Info.plist?) and Linux
The solution in my head was to write the version signature in the first or last 32 bytes of the binary (which I didn't figure out how to do yet) and then I'll modify those bytes when I need to. Sadly it's not that simple as I'm trying to modify the same binary that I'm executing.
If you know of how I can do this, or of a cleaner/mainstream solution for this problem, I'd be very grateful. FWIW, the application is a patcher/launcher for a game; I chose to encode the version in the patcher itself instead of the game executable as I'd like it to be self-contained and target-independent.
Update: from your helpful answers and comments, I see that messing with the header/footer of the binary is not the way to go. But regarding the write permission for the running users, the game has to be patched one way or another and the game files need to be modified, there's no way to circumvent that: to update the game, you'll need admin privileges.
I would opt for using an external file to hold the signature, and modify that with every update, but I can't see how I can guard against the user spoofing with that file: if they mess up the version numbers, how can I detect which version I'm running?
Update2: Thanks for all your answers and comments, in truth there are 2 ways to do this: either use an external resource to track the version or embed it in the main application's binary itself. I could choose only 1 answer on SO so I did the one I'm going with, although it's not the only one. :-)
Modern Windows versions will not allow you to update an installed program file unless you're running with administrator privileges. I believe all versions of Windows block modifications to a running file altogether; this is why you're forced to reboot after an update. I think you're asking for the impossible.
This is going to be a bit of a challenge, for a number of reasons. First, writing to the first N bytes of the binary is likely to step on the binary file's header information, which is used by the program loader to determine where the code & data segments, etc. are located within the file. This will be different on different platforms (see the ELF format and executable format comparison)--there are a lot of different binary format standards.
Assuming you can overcome that one, you're likely to run afoul of security/antivirus systems if you start modifying a program's code at runtime. I don't believe most current operating systems will allow you to overwrite a currently-running executable. At the very least, they might allow you to do so with elevated permissions--not likely to be present while gaming.
If your application is meant to patch a game, why not embed the version in there while you're at it? You can use a string like #Juliano shows and modify that from the patcher while the game is not running - which should be the case if you're currently patching anyways. :P
Edit: If you're working with Visual Studio, it's really easy to embed such a string in the executable with a #pragma comment, according to this MSDN page:
#pragma comment(user, "Version: 1.4.1")
Since the second argument is a simple string literal, it can be concatenated, and I'd have the version in a simple #define:
// somehwere
#define MY_EXE_VERSION "1.4.1"
// somewhere else
#pragma comment(user, "Version: " MY_EXE_VERSION)
I'll give just some ideas on how to do this.
I think it's not possible to change some arbitrary bytes in the executable without side effects. To overcome this, I would create some string in your source code, like:
char *Version = "Version: AA.BB.CC";
I don't know if this is a rule, but you can look for this string in your binary code (open it in a text editor and you will see). So, you search and change this bytes for your version number in the binary file. Probably, their position will vary each time you compile the application, so this it is possible only if that location is not a problem for you.
Because the file is being used (it's running), you have to launch an external program that would do this. After modifying the file, this external program could relaunch the original application.
The version will be stored in your binary code in some part. Is that useful? How will you retrieve the version number?
I am looking for a program where I can enter a C++ code snippet
in one window, press a button, and get output in another window.
Compilation should somehow be hidden behind the button. On a
per-snippet basis would be fine, full interactive probably asking
too much. It should run under Linux/Unix. Main use case would be
learning/testing/short debugging, etc.
Related stuff I found:
-- the Reinteract project for python (which i'm told sage has features similar to)
-- the same thread for C# here: C# Console?
-- the CINT interpreter from the CERN ROOT project
(which may be close, but maybe there are more comfortable apps around)
-- some programs called Quickly Compile or Code Snippet, which are M$.
http://codepad.org/ works nicely for this purpose. By default, it will run what you paste when you hit submit and display the result (or any errors you might have).
Dinkumware has a page for this AND you can choose the compiler
http://dinkumware.com/exam/default.aspx
Do something like this ?
test a C# snippet code by just copying it to the clipboard and then type csc.exe:
http://reboltutorial.com/blog/redirect-shell-to-rebol-console/
Cling (interactive C++ interpreter, built on the top of LLVM and Clang libraries): https://root.cern.ch/drupal/content/cling
Just configure your code editor to compile and run your code snippets.
Most code editors have the capability of 'sending' the current buffer/file to an external tool. I configure one editor key binding to compile the current buffer, and another key binding to execute whatever was last compiled (actually to run whatever has the same base filename as the current buffer with an '.exe' extension). My experience is with Windows, but the same or similar can be done on Unix/Linux.
Then it becomes one keystroke to compile and another to run what I jut compiled. This could also easily be just a single keystroke to compile & run, but I have several key bindings set to compile using various different compilers. That way I can easily test snippets using the latest MSVC, MSVC 6, MinGW GCC, Comeau and Digital Mars compilers to check for differences.
I would do it like this:
Capture the 'snippit' as text
Create a.cpp with the following:
int main() {
snippitCode();
return 0;
}
void snippitCode() {
// INSERT SNIPPIT HERE
}
Use 'exec' to launch a compiler and pipe the output to an output file.
Use 'exec' to run the application and pipe the output to an output file.
In the 'output' window, you can run 'tail -f' on the output file to continuously update when new output arrives.