超小可执行文件再探：从45字节到76字节，合规与精简的艰难平衡！

再探超小可执行文件

曾有人评论，最初创建的文件并非真正的 ELF 可执行文件，只是 Linux 内核“误认”的文件。这观点有道理，45 字节的文件不符合 ELF 规范，但怎能在发现更多可能性时停手呢？不过，为满足纯粹主义者和内心的完美主义，作者撰写了续作。

严格遵循标准下的文件精简

已将可执行文件精简到 45 字节，现在希望严格遵循标准并保持小巧。偏离正轨是从摆弄 ELF 头“未使用”字段开始，于是回到之前状态，得到 91 字节的版本。但这不是最小尺寸，将 ELF 头和程序头表重叠 8 字节，文件大小缩减到 83 字节。

继续缩减文件大小的尝试

似乎没什么可做了，无奈回头看 ELF 规范。发现初始寄存器中只有 edx 有相关说明，但无实质性保证。接着发现程序头表结构中的 p_paddr 字段内容“未指定”，有 4 个字节可利用，将其中 2 个字节放 jmp 指令，剩余 2 个字节放程序第一条指令，文件大小变为 81 字节。

尝试将 jmp 指令和 p_filesz 字段重叠不可行，考虑 p_paddr 字段之前的字段，发现“mov bl, 42”指令可接受，调整加载地址和代码，文件大小降到 79 字节。想再腾出 1 个字节放“inc eax”指令，尝试让程序最后一个字节溢出到下一个字段不可行，但发现 p_filesz 和 p_memsz 字段可互换，文件大小降到 76 字节。

此版本缺点是程序请求大量内存，但实际不访问，没造成危害。使用“cmp eax, imm32”指令，以一半“代价”跨越 p_filesz 值，将递增指令移出 p_memsz 字段，该字段值更合理。这是最终版本，大小 76 字节，为符合规范多付出 31 字节代价。

是否让纯粹主义者闭嘴？

一部分人闭嘴了，但仍有人指责 int 指令。直接系统调用并非与内核文档化接口的一部分，系统调用号在未来版本可能改变，虽基本功能这种情况极不可能发生，但类似情况出现过，如 uname 函数的系统调用。

若想完全合规，需严格遵循文档化的 ABI，使用 _exit 函数退出程序，这意味着重新引入动态链接开销。要了解 ELF 二进制文件动态链接实现方法，自己实现（希望占用更少空间）并非易事，只好留到下一篇文章讨论。