¿Están realmente integrados los comandos de BusyBox?

Estaba leyendo la famosa Leyenda de recuperación de Unix , y se me ocurrió preguntarme:

Si tuviera un shell de BusyBox abierto, y el binario de BusyBox se eliminara, ¿podría seguir usando todos los comandos incluidos en el binario de BusyBox?

Claramente, no podría usar la versión BB de esos comandos desde otro shell en ejecución como bash, ya que el archivo BusyBox en sí no estaría disponible para bashabrir y ejecutar. Pero desde la instancia en ejecución de BusyBox, me parece que podría haber dos métodos por los cuales BB ejecutaría un comando:

1. Podría bifurcar y ejecutar una nueva instancia de BusyBox, llamándolo con el nombre apropiado y leyendo el archivo BusyBox desde el disco para hacerlo.
2. Podría bifurcar y realizar alguna lógica interna para ejecutar el comando especificado (por ejemplo, ejecutándolo como una llamada de función).

Si (1) es la forma en que funciona BusyBox, esperaría que ciertos comandos proporcionados por BusyBox no estén disponibles desde una instancia en ejecución de BB después de que se eliminen los binarios de BB.

Si (2) es cómo funciona, BusyBox podría usarse incluso para la recuperación de un sistema en el que la propia BB había sido eliminada, siempre que todavía hubiera una instancia de BusyBox accesible.

¿Está documentado en alguna parte? Si no, ¿hay alguna manera de probarlo de manera segura?

Por defecto, BusyBox no hace nada especial con respecto a los applets que ha incorporado (los comandos enumerados con busybox --help).

Sin embargo, si las opciones FEATURE_SH_STANDALONEy FEATURE_PREFER_APPLETSestán habilitadas en el momento de la compilación, cuando BusyBox sh¹ ejecuta un comando que es un nombre de applet conocido, no realiza la PATHbúsqueda normal , sino que ejecuta sus applets integrados a través de un acceso directo:

• Los applets que se declaran como "noexec" en el código fuente se ejecutan como llamadas de función en un proceso bifurcado. A partir de BusyBox 1,22, los siguientes applets son noexec: chgrp, chmod, chown, cksum, cp, cut, dd, dos2unix, env, fold, hd, head, hexdump, ln, ls, md5sum, mkfifo, mknod, sha1sum, sha256sum, sha3sum, sha512sum, sort, tac, unix2dos.
• Los applets que se declaran como "nofork" en el código fuente se ejecutan como llamadas de función en el mismo proceso. A partir de BusyBox 1,22, los siguientes applets son nofork: [[, [, basename, cat, dirname, echo, false, fsync, length, logname, mkdir, printenv, printf, pwd, rm, rmdir, seq, sync, test, true, usleep, whoami, yes.
• Otros applets se ejecutan realmente (con forky execve), pero en lugar de hacer una PATHbúsqueda, BusyBox se ejecuta /proc/self/exe, si está disponible (que normalmente es el caso en Linux), y una ruta definida en el momento de la compilación de lo contrario.

Esto se documenta con un poco más de detalle en docs/nofork_noexec.txt. Las declaraciones de applet están include/applets.src.hen el código fuente.

La mayoría de las configuraciones predeterminadas desactivan estas funciones, de modo que BusyBox ejecuta comandos externos como cualquier otro shell. Debian convierte estas características en tanto en sus busyboxy busybox-staticpaquetes.

Entonces, si tiene un ejecutable de BusyBox compilado con FEATURE_SH_STANDALONEy FEATURE_PREFER_APPLETS, entonces puede ejecutar todos los comandos de BusyBox desde un shell de BusyBox, incluso si el ejecutable se elimina (excepto los applets que no se enumeran arriba, si /proc/self/exeno está disponible).

Actually _{En realidad, hay dos implementaciones de "sh" en BusyBox - ash y hush - pero se comportan de la misma manera a este respecto.}

is there a way to safely test it? Con la imagen genérica x86 openwrt:

La mayoría de los comandos no están integrados, pero algunos son, como echoy printf. Se puede crear un archivo binario con contenido arbitrario printf, pero chmod +xserá un problema.