11

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?

MBZ
  • 26,084
  • 47
  • 114
  • 191
  • If it is a Windows executable you could put it into a resource https://learn.microsoft.com/en-us/windows/win32/menurc/adding-deleting-and-replacing-resources – Jerry Jeremiah Sep 10 '20 at 02:10

6 Answers6

12

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.

Rup
  • 33,765
  • 9
  • 83
  • 112
  • 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? – MBZ Mar 15 '11 at 18:38
  • 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. – James Kanze Mar 15 '11 at 19:31
5

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 :)

EvilTeach
  • 28,120
  • 21
  • 85
  • 141
2

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.

Hossein
  • 4,097
  • 2
  • 24
  • 46
  • 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. – Rup Mar 15 '11 at 18:54
1

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.

John Zwinck
  • 239,568
  • 38
  • 324
  • 436
  • 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. – Tyler Eaves Mar 15 '11 at 18:20
  • 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? – John Mar 15 '11 at 18:21
  • by the way it can be quite useful is some other cases as well. – MBZ Mar 15 '11 at 18:22
  • 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 Mar 15 '11 at 18:23
0

Modifying the executable file while it's running is a pain. The task is further complicated by any compiler optimizations your compiler may apply since it changes the structure of the program and might not allow you to have an "empty space" in which to write.

Argote
  • 2,155
  • 1
  • 15
  • 20
  • 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. – John Zwinck Mar 15 '11 at 18:26
-1

Difficult. Difficult. Difficult.

But in order to do this you basically have to read in the file into a buffer, or into another file, you can use direct fstream. However make sure you use the ios::binary flag. And append the buffer or file, I mean it's a horribly simple matter of actually appending the data. The problem lies in adding to itself.

Here's what I'd do:

first write a program to pack programs into other programs. You probably possess the knowledge already. Once you have that, have it pack itself into another program, be sure you've arranged for outside messaging or passing of arguments. Then on your main program you can simply unpack that program and pass in a link to a file you create (temporary) which you would like to append yourself with. kill your current program. Let the slave append the data and call your program again.

blam appended executable.

ultifinitus
  • 1,813
  • 2
  • 19
  • 32