Is writing bytes at the end of EXE file safe?

I've heard that if we append some bytes at the end of an EXE file, it can still work properly. Is开发者_开发问答 it true in all case? And is it a safe way?

I intend to write the demo using data in the program execution file, so it can be safe (at least to normal user) and I don't have to store data anywhere else.

---

This is impossible to answer with a certain Yes or No.

I assume you will store data at the end of your executable in lieu of storing program state in a configuration file. I further assume you're doing this for fun and the end result does not need to be perfect.

Any code signing mechanism that might be in place on your platform will cry foul with these sorts of tricks. The signatures will only be valid if the executable does not materially change. (At least, in the code signing mechanism I helped implement, the cryptographic signature was computed over the entire contents of the executable -- with the exception of the signature itself -- not just segments marked as executable or data in the program headers.)

Any anti-virus mechanisms that might be in place on your platform will cry foul with these sorts of tricks. Self-modifying code is definitely associated with programs attempting to remain hidden or obscure, and code that writes to itself is going to trigger alarms in behavioral anti-virus tools.

Tools such as tripwire or mtree will always complain about your program. rpm -qa or debsums will always report problems with your executable. It will be difficult to reliably transfer this program from site to site.

The permissions on standard executables in most environments would outright forbid this behavior. User accounts do not have privileges to modify most executables on the system -- only executables owned by the user that will run the executable could be written as well. (And even then, a mandatory access control system such as AppArmor, SELinux, TOMOYO, or SMACK could forbid a process from writing to the program file, if properly configured. And almost every reasonable security profile would forbid it.)

No system administrator would let two users execute and write to the executable.

You also have the pragmatic problem of finding the executable file in the first place. At least Linux provides /proc/self/exe, but (a) system administrators may not have it mounted (b) system administrators may not let most processes use it (c) if the executable file is replaced while the program is executing finding the correct file to modify may be difficult.

You have to decide between two methods of updating the executable: either you modify the existing file (ftell(3) and fseek(3)) or you write the changed contents to a new file and replace the executable. Both approaches are troublesome: if you modify the file, you might have several copies executing simultaneously, trying to write conflicting edits to the file. Clever programming can avoid huge problems, but the entire executable might not be in a consistent state. If you replace the file, you might have several copies executing simultaneously, and the disk copies of the executable might not be freed and actually removable until the system is rebooted. You could have a dozen copies of your executable program file invisibly taking up disk space. None of them could share memory while executing, increasing memory pressure.

Yes, it's possible to keep configuration data in the program executable, and even make it work in some environments. But it isn't production-quality.