Store data in executable

c++
10,483

Solution 1

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.

Solution 2

Ya, you can do it. It's risky.

You could screw up and make the app unrunable.

Modifying executables is something that virus and trojans tend to do. It is likely that their virus scanner will notice, stop it, and brand you as an evil doer.

I know a little bit about evil :)

Solution 3

In case of windows PE files, you can write data at the end of the file. You need to know the EXE size before writing your own data so that in the 2nd writes onwards you know from which position in the exe file to start writing.

Also you can't modify the file when it's running. Your main program needs to extract and run a temporary exe somewhere so that when the main program finished, the temp exe writes configuration to the main exe file.

Solution 4

Yes, it's possible. You probably shouldn't do it.

Mac OS X does have the concept of "bundles" where they combine an executable and its resources into one "package" (file ending in .app), but I'm not sure it's typical for applications to modifying their own bundles, and most other operating systems don't work that way either as far as I know. It's more of a facility to store images and audio and so forth along with the code, as opposed to storing configuration data that is going to be modified when the program runs.

Share:
10,483

Related videos on Youtube

MBZ
Author by

MBZ

PhD Student in Computer Science at UIUC

Updated on June 04, 2022

Comments

  • MBZ
    MBZ almost 2 years

    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?

  • Tyler Eaves
    Tyler Eaves about 13 years
    Well, normal users shouldn't have write permissions to application binaries for one, and for another it will make things like patching/upgrading much more difficult.
  • John
    John about 13 years
    It might be a security risk of sorts. A bad guy could compare two executables and deduce something ... maybe a password or some other sensitive information?
  • MBZ
    MBZ about 13 years
    by the way it can be quite useful is some other cases as well.
  • John Zwinck
    John Zwinck about 13 years
    In what cases can it be quite useful? In cases where you might want your program to not run properly on locked-down systems?
  • John Zwinck
    John Zwinck about 13 years
    He's not talking about modifying the code itself, it seems like. So it wouldn't interfere with the actual code much. He'd want to just jam more "files" into the executable file, which depending on the executable format (ELF for example), should be quite possible.
  • MBZ
    MBZ about 13 years
    now I got the "You probably shouldn't do it." part of John answer!
  • MBZ
    MBZ about 13 years
    tnx for your answer, but I didn't quite get the "how" part. Considering that there is no access or AV problem, where the data stored? how this happens?
  • Rup
    Rup about 13 years
    Yes, I forgot about this one. This is how self-extracting archives store their data - appended to the extracting code. Again you can compute the real length of your binary (without the appended data) from the exe headers when you need it.
  • James Kanze
    James Kanze about 13 years
    Re the Windows caching mechanism: .exe files contain writable data, as well as code. You'd basically have to declare a variable (initialized, but not const) which would occupy enough space for what you want to do, then read the file to find that variable, and write your new data there. It's not going to be easy.