ELF 文件必须以二进制模式读取前 4 字节确认为 \x7fELF，再解析 e_ident[4] 判断 32/64 位、e_ident[5] 校验字节序、e_ident[6] 验证版本，并用对应结构体读取 e_type 字段（ET_EXEC 或 ET_DYN 才可执行）。
怎么用 Magic Number 快速确认 ELF 文件
直接读文件头前 4 字节，看是不是 \x7fELF —— 这是 ELF 最硬的标识，比查后缀或 file 命令更底层、更可靠。但注意：它只说明“可能是 ELF”，不保证可执行（比如可能是 relocatable 目标文件）。
常见错误是只读 1 字节就判断，或者用文本方式打开导致编码干扰；必须以二进制模式读，且至少读 4 字节。
- 用
std::ifstream时务必加std::ios::binary标志 - 检查前先确保文件存在且可读，否则
read()可能静默失败 -
\x7fELF是小端序写法，但 Magic Number 本身与字节序无关，所有架构都一样
为什么不能只靠 Magic Number 判断“可执行”
\x7fELF 只表示 ELF 格式，不区分类型。真正决定是否可执行的是 ELF header 中的 e_type 字段：只有值为 ET_EXEC 或 ET_DYN（PIE）才算可执行程序；ET_REL 是 .o 文件，ET_CORE 是 core dump，都不能直接运行。
典型误判场景：把静态链接的库（ET_DYN）当成纯数据，或把内核模块（ET_REL）当成可执行体。
立即学习“C++免费学习笔记（深入）”；
- 需用
reinterpret_cast把读入的 header 内存映射为Elf64_Ehdr或Elf32_Ehdr结构体 - 注意结构体对齐：直接
read()到栈变量可能因 padding 导致字段错位，建议用memcpy或std::bit_cast（C++20） - 32/64 位 ELF header 长度不同（52 vs 64 字节），但 Magic Number 位置一致（offset 0）
跨平台读取 ELF header 的兼容性要点
Linux 上标准头定义在 <elf.h>，但 macOS / Windows 没这头文件；自己定义结构体最稳妥。关键是字段顺序和大小必须严格对齐 ELF spec，尤其 e_ident 数组长度固定为 16 字节，e_type 在 offset 16（小端序下低字节在前）。
性能上无压力——只读不到 100 字节，但兼容性差会导致字段解析全错，比如把 e_machine 当成 e_type。
- 不要依赖
sizeof(Elf64_Ehdr)，手动指定__attribute__((packed))或用alignas(1) - Windows 下若用 MinGW，
<elf.h>可能存在但字段名不一致，建议自定义 - 检查
e_ident[EI_CLASS]确认是ELFCLASS32还是ELFCLASS64，再决定用哪个结构体解析
实际检测函数里最容易漏掉的一步
很多人写了 Magic Number + e_type 检查就结束，但忘了验证 e_ident[EI_DATA] 是否为 ELFDATA2LSB（小端）或 ELFDATA2MSB（大端）——虽然 x86/x64 都是小端，但如果你的代码要跑在 PowerPC 或 SPARC 上，不校验这个，e_type 解析出来就是错的。
还有个隐形坑：e_type 是 uint16_t，但某些旧工具链会把它定义成 int，导致符号扩展问题（比如 0xfe00 被当负数）。
- 始终用
uint16_t类型读取e_type，避免隐式类型转换 - 读完
e_ident后立即校验EI_VERSION字段是否为EV_CURRENT（通常是 1），防止解析未来版本时出错 - 如果只是本机检测，可跳过字节序校验；但要做通用工具，这步绕不开
