Linux下判断ELF文件是否可执行需先验证魔数0x7f+'E'+'L'+'F'，再检查e_type字段是否为ET_EXEC（2）或ET_DYN（3）；Windows下则需确认PE魔数“MZ”及“PE\0\0”，并校验Subsystem为GUI/CUI且Characteristics中IMAGE_FILE_EXECUTABLE_IMAGE置位。
Linux下用魔数判断ELF文件是否可执行
ELF文件的可执行性不只看扩展名，关键在文件头魔数和类型字段。直接读取前几个字节就能快速判断：0x7f + 'E' + 'L' + 'F' 是基本魔数，但仅靠这个只能说明是ELF格式，不能确定是否可执行。
真正要检查的是ELF header中的e_type字段：值为ET_EXEC（2）或ET_DYN（3）才表示可被加载运行（后者常用于PIE可执行文件或共享库，但现代系统默认以可执行方式加载）。ET_REL（1）是重定位文件（如.o），不可直接执行。
实操建议：
- 用
std::ifstream以std::ios::binary打开文件，读取前20字节足够解析e_ident和e_type - 注意字节序：
e_type是小端存储，x86_64和ARM64都适用，无需手动翻转 - 别依赖
file命令输出——它可能基于后缀或heuristic推测，而你代码需要确定性判断 - 常见误判点：某些打包工具生成的“伪ELF”（如Android的.elf打包壳）魔数正确但
e_type非法，应额外校验e_type是否为1/2/3
Windows下检查PE文件的Subsystem和Characteristics
PE文件头部有更细粒度的执行语义控制。光有"MZ"魔数（0x4d 0x5a）只说明是PE格式，是否能双击运行取决于两个关键字段：
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
OptionalHeader.Subsystem：值为IMAGE_SUBSYSTEM_WINDOWS_CUI（3）或IMAGE_SUBSYSTEM_WINDOWS_GUI（2）才表示用户模式可执行程序；IMAGE_SUBSYSTEM_NATIVE（1）是内核驱动，普通用户无法直接运行 -
FileHeader.Characteristics中的IMAGE_FILE_EXECUTABLE_IMAGE标志位（bit 0x0002）必须置位，否则链接器认为该文件无效
实操建议：
- 跳过DOS stub（通常前64字节），通过DOS header的
e_lfanew字段定位PE signature（"PE\0\0"） - 不要跳过NT headers校验：如果
e_lfanew指向非法偏移，或signature不是0x00004550（小端），直接拒绝 - 32位和64位PE共用同一套header结构，但
OptionalHeader长度不同（32位是224字节，64位是240字节），需先读OptionalHeader.Magic（0x010b或0x020b）再决定偏移 - 注意：.dll文件也有
IMAGE_FILE_EXECUTABLE_IMAGE置位，但它不是“可执行文件”——得结合Subsystem判断；纯资源DLL的Subsystem可能是IMAGE_SUBSYSTEM_UNKNOWN（0）
跨平台判断时避免硬编码路径或命令调用
有人习惯调用file、readelf或dumpbin做判断，这在CI或嵌入式环境里极易失败：命令不存在、版本差异、输出格式变动（比如新版file加了color escape序列）都会导致解析崩溃。
更稳的做法是纯C++解析，且封装成轻量函数：
- Linux侧：只依赖
<fstream>和<cstdint>，读20字节→检查魔数→提取e_type→比对 - Windows侧：同样只用标准IO，按PE规范逐字段跳转，不依赖
<windows.h>（避免引入整个SDK） - 若需支持fat binary（macOS）或Mach-O，那是另一套魔数（
0xfeedfacf等）和LC_LOAD_DYLINKER逻辑，不在ELF/PE范围内，不应混为一谈 - 权限不是判断依据：
chmod +x只是让shell尝试执行，对ELF/PE本身无影响；反过来，没权限的ELF文件仍可能是合法可执行格式
容易被忽略的边界情况
真实环境中最常踩坑的不是主流程，而是这些细节：
- 文件为空或小于16字节 → 读取会失败，必须先检查
ifstream::good()和实际读取字节数 - 符号链接未解引用 →
stat()显示大小为0，但read()仍可读内容；C++里std::ifstream默认跟随symlink，无需额外处理 - 内存映射文件（如/dev/mem或某些debugfs节点）可能有ELF魔数但根本不是磁盘文件 → 判断前先用
stat()确认st_mode & S_IFREG - Android的.apk本质是zip，但里面
lib/xxx/libxxx.so是ELF；你的函数若传入apk路径，会因魔数不符返回false——这不是bug，是设计如此
判断可执行性这件事，核心永远落在二进制头部字段上，而不是文件名、权限位或外部命令输出。字段含义清晰，但每个平台校验点不同，漏掉任何一个都可能把so/dll当exe，或者把PIE二进制当成数据文件。
