我正在研究一个程序,它将解析PE对象的各种信息.
虽然阅读规范,但我无法找出MZ字节存在的原因,因为我无法在这两个字节应该代表的机器类型列表中找到它.
任何人都可以澄清吗？
将PE二进制文件转换为ELF二进制文件的最佳工具是什么？
以下是此问题的简要动机:
由于所有分析都必须在Linux上运行,我更喜欢在Linux上运行的实用程序/工具.
谢谢
我有一个可移植的可执行文件,可以将数据保存到与可执行文件相同的文件夹中.有什么办法可以在关闭应用程序时将数据保存到可执行文件中吗？
这可能很奇怪,但是随身携带数据并且只有一个文件用于exe和数据会很棒.
如果这是用C#制作的,则更喜欢,但不是必需的.
令我感到困惑的是.NET中的"AnyCPU"功能如何工作:如果系统是32位,它将可执行文件加载为本机32位,如果系统是64位,则将其加载为64位(您可以轻松确认与任务管理器).显然,这并非不可能.
问题是,微软究竟是如何做到这一点的？Windows最初不了解.NET框架,因此Windows PE Loader不可能在CLR头的PE头中寻找任何额外的功能; 必须通过某种内核模式扩展添加此功能.但.NET框架似乎没有安装这样的东西......我完全失去了同一个可执行文件同时可以是原生的32位和64位,特别是因为mscoree.dll的反汇编没有甚至不显示对未记录的本机函数的引用.
有没有人对如何做到这一点有任何知识和/或合理的猜测？这显然是可能的(所以没有说"这是不可能的"),这让我想尝试编写一个原生的跨平台EXE ...
编辑:
作为一个侧面说明,考虑如何你不能在64位Windows PE环境中运行32位可执行文件...有有以某种方式来与某种"插件"扩展或修改PE装载器,对不对？
我有几个关于PE"子系统"字段的问题,它可能在某种程度上重叠.为了避免单独向每个问题发送垃圾邮件,我想我会一起问他们,然后分别重新询问任何无法解决的问题.希望这没关系......
我知道这IMAGE_SUBSYSTEM_WINDOWS_CUI会使操作系统"预先附加"进程到控制台,无论是父进程还是必要时创建新控制台.IMAGE_SUBSYSTEM_WINDOWS_GUI不这样做.
在现代版本的Windows中,这两者之间是否存在其他差异？过去还有更多吗？
其他值如何,Windows仅用于拒绝EXE,还是导致Windows模拟不同的API？这种"仿真"过程是否可以被最终用户扩展,或者这是否已经成为操作系统的难点？
我一直在阅读32位Windows应用程序限制为2 GB RAM,因为高2GB的寻址空间是为Windows操作系统(以及iirc,VRAM)保留的.如果在32位WinXp上使用/ 3GB标志,则最多可以使用3 GB的RAM进行寻址,但通常需要使用userva值进行调整.我听说在64位版本的Windows上,PE头中有一个大的地址识别标志和超过4 GB的RAM,应用程序可以使用所有4 GB的寻址空间进行自己的内存管理.
另一方面,我很确定当你调用windows API时,你必须在你提供的32位地址空间内调用内存位置.那么,32位大地址识别应用程序在64位环境中可以使用多少RAM呢？为什么？
谢谢.
我正在开发一台我没有管理权限的Windows机器上.我想使用CMake进行编译,由于管理限制,我不能简单地下载和安装它.
我还想避免从源代码编译CMake(如果可能的话).是否有可用于Windows的便携式二进制文件,只允许使用CMake？
根据我和其他人的经验(http://webster.cs.ucr.edu/Page_TechDocs/pe.txt),PE/COFF规范文档错误地声称序数表中包含的出口地址表索引是相对的到Ordinal Base,甚至给出了一个不正确的例子(第5.3节).实际上,Ordinal Table中的索引是基于0的索引到正常情况下的Ordinal Base = 1的地址表中.我在VS Studio生成的PE库和系统库(如Kernel32.dll)中看到了这一点.
我的问题是,你有没有观察过一个带有Ordinal Base的二进制数不等于1？我想知道这是一个off-by-one错误,还是Ordinal Base从未应用于Ordinal Table条目.
我需要字节大小,IMAGE_OPTIONAL_HEADER.SizeOfImage似乎向上舍入到(不确定)边界并且大于实际文件大小.