在EXE文件的末尾写入字节是否安全？ [英] Is writing bytes at the end of EXE file safe?

问题描述

我听说如果我们在EXE文件末尾添加一些字节，它仍然可以正常工作。这是真的吗？这是一个安全的方式吗？

我打算使用程序执行文件中的数据编写演示程序，所以它可以是安全的（至少对于普通用户），我不必在其他地方存储数据。

解决方案

这是无法用某个Yes或No来回答的。 >

我假设您将数据存储在可执行文件的末尾，而不是将程序状态存储在配置文件中。我进一步假设你这样做是为了好玩，最终的结果并不需要是完美的。

任何代码签名机制可能会在您的平台上的地方将这些伎俩哭。签名只有在可执行文件没有实质性改变时才有效。 （至少，在我帮助实施的代码签名机制中 ，加密签名是在可执行文件的整个内容上计算出来的 - 除了签名本身 - 不仅仅是标记为可执行文件或程序头文件中的数据。）

任何可能在您的平台上的反病毒机制都会因这些伎俩而受到谴责。 自修改代码与试图保持隐藏或模糊的程序无疑是相关联的，写入自己的代码正在进行触发行为反病毒工具中的警报。

诸如 tripwire 或 mtree 会一直抱怨你的程序。 rpm -qa 或 debsums 将始终报告可执行文件的问题。很难可靠地将这个程序从一个站点传输到另一个站点。

在大多数环境中，标准可执行文件的权限将彻底禁止这种行为。用户帐户没有权限修改系统上的大多数可执行文件 - 用户可以运行可执行文件的只有可执行文件拥有，也可以写入。 （即使如此，也可以使用强制访问控制系统，如 AppArmor ， SELinux ，TOMOYO 或 SMACK 可以禁止写入程序文件的过程如果配置正确的话，几乎所有合理的安全配置文件都会禁止它。）

没有系统管理员让两个用户执行和写到可执行文件中。

您还有一个实际的问题，首先找到可执行文件 。至少Linux提供了 / proc / self / exe ，但是（a）系统管理员可能没有安装它（b）系统管理员可能不会让大多数进程使用它（c）如果可执行文件被替换，而程序正在执行找到正确的文件进行修改可能是困难的。

您必须决定两种方法更新可执行文件：要么修改现有文件（ ftell（3）和 fseek（3）），或者将更改后的内容写入新文件，并将可执行文件替换为。两种方法都很麻烦：如果修​​改文件，可能会同时执行多个副本，试图将冲突的编辑写入文件。聪明的编程可以避免巨大的问题，但整个可执行文件可能不是一个一致状态。如果您替换文件，则可能会同时执行多个副本，并且可执行文件的磁盘副本可能不会被释放，而是在系统重新引导之前实际上可移除。你可能会有十几个副本的可执行程序文件无形地占用磁盘空间。没有一个可以在执行时共享内存，增加内存压力。

是的，可以保持程序中的配置数据可执行，甚至可以使其在某些环境下工作。但这不是生产质量。

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.

这篇关于在EXE文件的末尾写入字节是否安全？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！