BusyBox 命令是真正内置的吗？

Question

我在阅读著名的Unix Recovery Legend 时，突然想到：

如果我打开了一个 BusyBox shell，并且 BusyBox 二进制文件本身被删除了，我还能使用 BusyBox 二进制文件中包含的所有命令吗？

显然，我无法从另一个正在运行的 shell 中使用这些命令的 BB 版本，例如bash，因为 BusyBox 文件本身将无法bash打开和运行。但是在 BusyBox 的运行实例中，在我看来，BB 可以通过两种方法运行命令：

1. 它可以派生并执行一个新的 BusyBox 实例，使用适当的名称调用它——并从磁盘读取 BusyBox 文件来执行此操作。
2. 它可以分叉并执行一些内部逻辑来运行指定的命令（例如，通过将其作为函数调用运行）。

如果 (1) 是 BusyBox 的工作方式，我希望在删除 BB 二进制文件后，某些 BusyBox 提供的命令在 BB 的运行实例中将变得不可用。

如果 (2) 是它的工作原理，那么 BusyBox 甚至可以用于恢复 BB 本身已被删除的系统——前提是仍然可以访问 BusyBox 的一个正在运行的实例。

这在任何地方都有记录吗？如果没有，有没有办法安全地测试它？

Answer 1

默认情况下，BusyBox 不会对它内置的小程序（用 列出的命令busybox --help）做任何特别的事情。

但是，如果在编译时启用了FEATURE_SH_STANDALONE和FEATURE_PREFER_APPLETS选项，那么当 BusyBox sh¹ 执行一个已知小程序名称的命令时，它不会执行正常PATH查找，而是通过快捷方式运行其内置小程序：

• 在源代码中声明为“noexec”的小程序在分叉进程中作为函数调用执行。作为BusyBox的1.22，下面的小程序NOEXEC： ，chgrp，chmod，chown，cksum，cp，cut，dd，dos2unix，env，fold，hd，head，hexdump，ln，ls，md5sum，mkfifo，mknod，sha1sum，sha256sum，sha3sum，sha512sum，sort，。tacunix2dos
• 在源代码中声明为“nofork”的小程序在同一进程中作为函数调用执行。作为BusyBox的1.22，下面的小程序nofork： ，[[，[，basename，cat，dirname，echo，false，fsync，length，logname，mkdir，printenv，printf，pwd，rm，rmdir，seq，sync，test，true，usleep，。whoamiyes
• 其他小应用程序确实被执行（使用fork和execve），但不是执行PATH查找，而是BusyBox 执行/proc/self/exe，如果可用（Linux 上通常是这种情况），否则执行在编译时定义的路径。

这在docs/nofork_noexec.txt. 小程序声明include/applets.src.h在源代码中。

大多数默认配置关闭这些功能，以便 BusyBox 像任何其他 shell 一样执行外部命令。Debian 在其busybox和busybox-static软件包中都启用了这些功能。

因此，如果您有一个用FEATURE_SH_STANDALONE和编译的 BusyBox 可执行文件FEATURE_PREFER_APPLETS，那么即使该可执行文件被删除，您也可以从 BusyBox shell 执行所有 BusyBox 命令（除了上面未列出的小程序，如果/proc/self/exe不可用）。

¹ _{BusyBox 中实际上有两种“sh”的实现——ash 和 hush——但它们在这方面的行为方式相同。}

Answer 2

is there a way to safely test it? 使用通用的 x86 openwrt 镜像：

大多数命令不是内置的，但有些是内置的，比如echo和printf。可以使用 来创建具有任意内容的二进制文件printf，但chmod +x会出现问题。