当公司打包二进制可执行文件时，它们通常会被加密、压缩、加扰或以其他方式制作，以便您的懒惰黑客无法简单地在 Notepad++ 中打开程序并查看代码。
然而，在我看过的所有代码中，它们都有一些未加密、未压缩和人类可读的关键代码组件。在这里，通过创建无意义的变量名称并试图使代码尽可能难以理解，该方法似乎更加“通过混淆来确保安全”。但事实仍然是它以纯文本形式存在，需要破译。
这是必然吗？我在想它可能必须是这种方式，以便操作系统可以执行一些明智的操作（然后具有进一步解压缩/解密其余可执行文件的指令），但我对此知之甚少，无法确定。或者有什么方法可以在没有任何人类可读组件的情况下真正打乱整个可执行文件？
最终，CPU 运行代码。CPU 需要“明文”的指令。您可以设想一些应用程序代码，其中可执行文件的一小部分初始部分首先解密其余代码，但这有几个问题：
实验上，这种加密方式对攻击者的阻碍不大，所以普遍的看法是“不值得”。除非您处于“攻击者”是可能被这些捉迷藏方法愚弄的无意识自动机的非常特定的场景中，否则就是病毒的情况，其中“攻击者”是防病毒软件。
如果 CPU 在内部通过一些密钥管理自己进行解密，则真正加密的代码是可能的。例如，这就是在 PS3 控制台中发生的事情。
您在谈论两个不同的组件。一个是loader，它不是人类可读的，但必须是机器可读的（因此未加密）才能执行。正如你所说，这必须是这样的：否则你会得到一大块不可执行的数据。
还可能存在其他几个“纯文本组件”，例如版权、清单、文件信息等等，它们是人类可读但不敏感的 - 即，如果您能够阅读，开发人员不会在意他的名字。实际上，他可能更喜欢这样。
加载器执行自我完整性检查、调试器检查等多项任务，然后解密内存中的“真实”可执行文件。
可执行文件的加密程度取决于用例。例如，二进制文件可能只对某些与复制保护、定制或品牌有关的关键例程进行加密；这样您就可以使用二进制编辑器打开文件并查看所有资源、字符串、光标等。
或者可以使用标准的“二进制不可知论所以我将只加密一切”可执行打包器/加密器对其进行加密，在这种情况下，您将以纯文本形式看到属于解密器代码的字符串，但不是那些的原始可执行文件。当然，解密器通常会被进一步混淆，以使普通黑客更难识别加密器并获得合适的解密器（加密器越分散，它就越可能存在）。
在某些时候，可执行文件必须看起来像可执行文件，否则系统将不知道如何处理它。这通常需要一个标头来指出它的可执行文件（例如 Windows EXE 中的 MZ 标头），以及一些包含指向各种引用的指针的结构，例如执行的起点，然后是一个二进制数据块，即可执行主体的文件。
很多时候，它还附加了操作系统使用的元数据，如身份验证签名，以及发布者、版本等属性。
至少，它需要那些标头位和可执行主体。该可执行主体将需要足够的明文代码来执行解密/解压缩机制，然后输入新代码以执行。
可执行文件的编译方式以及其中可见的内容因平台和所涉及的编程语言而异。“加密加扰”端口并没有真正加密和加扰。这只是非文本数据。它是机器代码，由操作系统执行。
例如，在 Windows 上...如果您能够获得在 .NET 中创建的 .dll，一个在 VB6 中进行比较，一个在 C++ 中进行比较，您可能会发现“纯文本”的数量有很大差异。如果您在记事本中打开它，则可见。
.NET .dll 文件或 .exe 文件并没有真正编译为机器代码，它们被编译为 MSIL - 一种由 .NET 运行时编译为机器代码的字节码形式。Java 字节码的工作方式相同。那里有很容易反编译的信息，对于知道如何读取字节码或 msil 的人来说，这根本不是胡言乱语。
另一方面，C++ 文件被编译为机器代码，并且通过在记事本中打开更不容易阅读（如果有的话）。
换句话说，它与加密或加扰无关，它与如何准备文件以供 PC 读取和执行它有关。
当涉及文件中的纯文本时，您是正确的。这看起来确实存在安全风险，但正如在 StackOverflow 上多次指出的那样，实际上不可能阻止人们反编译/检查您的代码，尤其是使用 .NET 或 Java 之类的语言时。您必须假设您的代码对技术人员完全开放。（正如我在询问有关如何保护使用 .NET 构建的 Windows 应用程序中的敏感数据的问题时向我指出的那样）
至于显示什么信息，这在很大程度上取决于用于制作 .exe 的编译器和工具。