Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Store data in executable

Tags:

c++

I'm just curious about this for a long time.

Is it possible for an application to store some changeable data (like configurations and options) inside its own executable?

for example: is it possible to design a single executable which if a user ran, set some configurations, copied it into another PC, then the application runs by its last set config in new PC.

is this possible by any means?

Update: it seems that it's possible. then How?

like image 710
MBZ Avatar asked Mar 15 '11 18:03

MBZ


People also ask

What is stored in executable file?

Executable files contain binary machine code that has been compiled from source code. This low-level code instructs a computer's central processing unit on how to run a program. The processor interprets the machine code and tells the computer's hardware what to do.

What is an executable process?

An executable is the file that the compiler creates from these source files containing machine instructs that can execute on the CPU. A process is the active execution of the executable on the CPU and in the memory. It includes the memory management information, the current PC, SP, HP, registers, etc.

Where is executable file stored?

If the app's EXE file isn't easily available you can browse two locations either C:\Program Files or C:\Program Files (x86) on your system to find the application's main program folder. Then look for the folder with the name that's similar to the publisher of the program. Or the name of the application itself.


1 Answers

Yes and no -

  • Yes, there's plenty of space in an executable image you can put data. You can add a pre-initialised data segment for this, say, and write the data into there; or a resource, or you can abuse some of the segment padding space to store values in. You control the linker settings so you can guarantee there will be space.

  • No, you probably can't do this at run-time:

    1. Windows' caching mechanism will lock the files on disk of any executable loaded. This is so that it doesn't need to worry about writing out the data into cache if it ever needs to unload a segment - it can guarantee that it can get the same data back from the same location on disk. You may be able to get around this by running with one of the .exe load copy-to-temp flags (from CD, from Network) if the OS actually respects that, or you can write out a helper exe to temp to transfer control to, unload the original and then modify the unloaded file. (This is much easier on Linux etc. where inodes are effectively a reference count - even if they have the same default locking strategy you can copy your executable, edit the settings into the copy and then move it over the original whilst still executing.)

    2. Virus checkers will almost certainly jump on you for this.

In general I think it's a much better idea to just write settings to the registry or somewhere and provide and import / export settings option if you think it'd be needed.


Expanding on the 'how' part -

In order to know where to write the data into your file you've got two or three options really:

  1. Use a magic string, e.g. declare a global static variable with a known sequence at the start, e.g. "---my data here---", followed by enough empty space to store your settings in. Open the file on disk, scan it for that sequence (taking care that the scanning code doesn't actually contain the string in one piece, i.e. so you don't find the scanning code instead) - then you've found your buffer to write to. When the modified copy is executed it'll have the data already in your global static.

  2. Understand and parse the executable header data in your binary to find the location you've used. One way would be to add a named section to your binary in the linker, e.g. a 4K section called 'mySettings' flagged it as initialised data. You can (although this is a beyond my knowledge) wire this up as an external buffer you can refer to by name in your code to read from. To write, find the section table in the executable headers, find the one called 'mySettings' and you'll have the offset in the binary that you need to modify.

  3. Hard-code the offset of the buffer that you need to read / write. Build the file once, find the offset in a hex editor and then hard-code it into your program. Since program segments are usually rounded up to 4K you'll probably get away with the same hard-coded value through minor changes, though it may well just change underneath you.

like image 70
Rup Avatar answered Sep 21 '22 12:09

Rup