2

If I hex-edit an EXE for DOS or Windows, by adding or removing some text for example, it will no longer run.

If I just change a single char around to a different one, it may run.

Is this some anti-tampering mechanism built into the EXE itself, or by MS-DOS/Windows? Does it have some kind of built-in checksum baked into it which must match for it to run, so that additions and removals cannot be done (easily)? And that's why it works (sometimes) if I just change "moo" to "foo", for example (same number of chars)?

And is this the same on all platforms? Or unique for DOS/Windows?

6
  • 6
    Could you be a bit more specific, e.g. describe the changes you’re making in more detail? I get the impression you’re changing the lengths of strings, is that correct? There’s is a checksum in MZ files, but it’s not checked by DOS AFAIK. Oct 19 '20 at 15:10
  • 10
    How do you "add or remove text"? If that means actually adding or removing bytes, you've presumably buggered any pointers within the file. Oct 19 '20 at 15:23
  • 5
    Why does this have anything at all to do with "retrocomputing"?
    – pipe
    Oct 20 '20 at 0:45
  • 3
    One way to think about this is replacing a few parts of a car engine with a few random bits of metal or plastic or toaster parts or something. You wouldn't be surprised if the engine no longer ran, unless you lucked out (or knew enough about the engine) to only replace something that doesn't matter, like the wiper fluid reservoir or something. Oct 20 '20 at 5:23
  • 1
    Voted to close due to missing clarity. How do you add or remove text? Probably this is more a basic computer science question, not anything specific for retrocomputing.
    – UncleBod
    Oct 20 '20 at 7:09
13

If you change the lengths of strings in a binary, or indeed move any part of a binary around in any way, then you’re likely to break it: offsets to the data (and code) that the program expects to find are stored in the binary, and won’t be adjusted when you alter it.

Thus changing text (or anything else, including code) while preserving the lengths is possible, but anything else is more complex.

EXE files using the MZ header (starting with MZ) have a checksum at offset 12h, but DOS doesn’t check it as far as I know. Some programs do their own checksumming as a way of resisting tampering, but causing that to fail should produce obvious results (except with some games...).

Some strings in Windows files can be modified without breaking the program, using a resource editor: the editor will know how to update everything needed for the program to find its updated resources. Other features of Windows files are also typically represented using resources, and can be modified too: icons, bitmaps...

The general constraint on changing binaries isn’t limited to DOS and Windows, it’s quite general: you can’t open a binary in a hex editor, move parts around and expect it to work.

2
  • 3
    It's worth pointing out that MS-DOS programs aren't normally built as position-independent code. Indeed, the same holds true for modern Windows software. Oct 19 '20 at 22:27
  • 2
    @JohnDallman Even position independent code on Linux can't deal with parts of the image (executable or shared object) moving relative to other parts. Only the entire image can be relocated as a single chunk.
    – user722
    Oct 20 '20 at 3:02
7

Adding or removing some text has the effect that things coming later in the EXE file are now found at a different absolute location, machine code as well as the EXE file format rely a lot on absolute locations.

So, it's important to keep the exact same byte length of the file. So, replacing characters is mostly safe (if you're sure that the bytes are really meant to represent user-interface text). Replacing text with a shorter version might work if you pad it at the end with 00 bytes (but that depends on the source language: e.g. with C it's okay, with Pascal it's likely to fail). Replacing text with a longer version is impossible.

It has nothing to do with checksums. If it were a checksum or similar, then even changing a single character e.g. from "moo" to "foo" would also reject the program.

Modifying a program that you only have in binary form (like EXE file) is a time-consuming and error-prone task. For any change beyond the most simple text changes, it might be easier to rewrite the program from scratch.

1
  • 1
    Making edits to binaries is actually one of the tricks covered in Paul Somerson's "DOS Power Tools" where he walks users through hex-editing things like COMMAND.COM as a free way to secure your computer against casual intrusion by doing things like renaming the DIR command to DUR or some other three-character sequence. It's been a while, but I think he also talks readers through how to alter the background and foreground colors set by COMMAND.COM.
    – ssokolow
    Oct 20 '20 at 13:52

Not the answer you're looking for? Browse other questions tagged or ask your own question.