Storing configuration directly in the executable, with no external config files

Question

Back in the days when dinos talked fluently English, Arabic, Spanish and a bunch of other languages, when one could change tapes of a PDP-11 on the fly there was a programming language Turbo Pascal.

I remember a technique (with the aid of some obscure helper functions) were in Turbo Pascal variables are put in the EXE (like all variables were put in a file). But one could change the variable while running the program and then store the changed variable in the EXE. Essentially, no external config files were needed by using this technique.

Does someone remembers how this technique was called? (In fact, I'm searching something similar for a compiled Python program, but I guess it's a start to know the name of the technique.)

Answer 1

Well, I don't think there ever was a specific term for that.

What Turbo Pascal calls "typed constants" (which are, in fact, variables, and a non-standard Turbo Pascal extension of the language) are put as one single block into the program executable by the compiler in the exact order the compiler comes across them at compile time.

CONST 
   beaconStr : String [20] = 'config starts here';
   configVar : INTEGER = 1;

"Normal" constants are spread all over the place in the executable by the compiler and are by far not as easy to locate in the binary. Typed constants, however, are collected into one single block at compile time and loaded by the runtimes to the bottom of the data segment.

What you did was, just as shown above, that you put a magic marker (or beacon) at the beginning of the typed constants to be able to find them in the executable, then patched what you found after that. Note this was a bit of a unique feature in Turbo Pascal - other languages and compilers don't necessarily have everything so conveniently put into one place. This "one place" was required because older MSDOS binary formats for COM and .EXE files did not include enough (or rather, any) information on where in the binary the initialized data segment contents is to be found.

I doubt this technique would be reproducible easily with today's operating systems: Program files are typically write-protected for security reasons (which makes the technique much harder today - you need admin privilege to patch an executable), on the other hand, modern object formats actually mark the initialized data segments specifically for the loader, so, constants to patch would actually be easier to find in a documented way, even without a beacon.

Answer 2

There may be no specific name for it.

DOS .EXE programs are just files on disk, and any program can be used to change the contents of .EXE file in any way, like a hex editor.

But as it is possible for a Turbo Pascal program to know in which memory address the variable is stored during runtime, and so the program can fetch information to which memory address it is loaded to, the program can use this information to calculate where in the .EXE file the the contents of the variable is, and simply overwrite the data for that variable.

This obviously works only for the original uncompressed .EXE file.

Another way to do it is to just leave the original executable part untouched, and just add custom data of known size after it. Many programs like demos used this method if they had a single large .EXE file for code and resources, but of course used it only for reading. This way the .EXE can be first compressed before appending any user data to it.

Answer 3

It wasn't special then

DOS had none of the protection mechanisms known from modern operating systems. There was no distinction between data and code - you could mix them and jump to data segment or wherever you want, no write protection of executable. EXE was just a file like any other, and you could write to the file from which your code was loaded. Since executable file name was given to you, you could open it for write without any problems. Writing to your own executable seemed like a great idea, and just like writing to the separate config file, need no special name other than 'writing to the file'.

Of course, it was a paradise for homegrown virus creators, since it required no more knowledge than knowing the structure of EXE file and how the code gets executed.

Answer 4

Many operating systems have some concept like a “resource” that can be attached to an executable, but read and updated like a file. This would be the most natural way to save configuration settings in the executable file itself under Windows or MacOS. But since a compiler and linker know where in the executable the constant data is stored, one could, if it wanted to, enable you to write a self-modifying program.

If you tried to alter the executable file itself, most modern operating systems would at least make you use Administrator permissions to do it. Some would only update a shadow copy in your own personal directory.

Answer 5

There was no termcap file but tinst.com. This installer was patching an executable, some kind of "self-modification".