我一直在努力进行小型破解以获取可执行文件的文件大小。我知道存在可以正常压缩可执行文件的工具，但这比我自己的享受更重要。
我的想法是用gzip压缩可执行文件，然后将其作为一个数组嵌入到另一个名为launcher的程序中。当发射器运行时，它会建立一个像这样的管道系统：
parent launcher -> fork 1 of launcher -> fork 2 of launcher
fork 1将自身转换为gzip，因此无论父进程是什么，它都会解压缩，并将解压缩的版本吐出到fork 2。
这里是黑客入侵的地方.Clock 2试图执行文件“/ dev / fd / n”，其中n是从fork 1到fork 2的管道的文件号。本质上这意味着fork 2将尝试执行任何二进制gzip吐出。
然而，这不起作用（令人惊讶的是惊喜。）我尝试了对我的示例实现进行操作，并且对“/ dev / fd / n”执行execv的行返回-1 EACCES（权限被拒绝）。但是，如果我打开终端并运行ls -l /dev/fd/，我会得到类似的内容：
lrwx------ 1 blackle users 64 Nov 10 05:14 0 -> /dev/pts/0
lrwx------ 1 blackle users 64 Nov 10 05:14 1 -> /dev/pts/0
lrwx------ 1 blackle users 64 Nov 10 05:14 2 -> /dev/pts/0
lr-x------ 1 blackle users 64 Nov 10 05:14 3 -> /proc/17138/fd
所有人都有权限+ x为用户（我）。这意味着它应该是可执行的，不是吗？或者这只是一个非常奇怪的内核边缘情况，说它没有获得权限，但实际上它无法执行，因为它不是真正的文件。
答案 0 :(得分：2)
只有mmap能够执行的文件才能执行。遗憾的是，管道由于其顺序性质和缓冲区大小有限而不能以这种方式进行mmapable（它可能需要再次重新读取早期的代码，现在读取它之后就会消失了。）
你会有更多的运气而不是使用管道在ramfs中创建文件，将其映射到父级的内存空间区域，将未压缩的代码复制到mmap中，然后最终让子exec执行在ramfs中的文件，最后取消链接父项中ramfs中的文件，以便在子项退出时自动释放。
希望这有帮助，如果有什么不清楚请发表评论。