Sind BusyBox-Befehle wirklich eingebaut?

Ich habe die berühmte Unix Recovery Legend gelesen und mich gefragt:

Wenn ich eine BusyBox-Shell geöffnet hätte und die BusyBox-Binärdatei selbst gelöscht würde, wäre ich dann weiterhin in der Lage, alle in der BusyBox-Binärdatei enthaltenen Befehle zu verwenden?

Es ist klar, dass ich die BB-Version dieser Befehle nicht von einer anderen laufenden Shell wie zum Beispiel verwenden könnte bash, da die BusyBox-Datei selbst nicht bashzum Öffnen und Ausführen verfügbar wäre . Aber innerhalb der laufenden Instanz von BusyBox scheint es für mich zwei Methoden zu geben, mit denen BB einen Befehl ausführen kann:

1. Es könnte eine neue Instanz von BusyBox auflösen und ausführen, indem es sie unter dem entsprechenden Namen aufruft - und dazu die BusyBox-Datei von der Festplatte liest.
2. Es könnte eine interne Logik zum Ausführen des angegebenen Befehls aufteilen und ausführen (z. B. durch Ausführen als Funktionsaufruf).

Wenn (1) die Art und Weise ist, wie BusyBox funktioniert, würde ich erwarten, dass bestimmte von BusyBox bereitgestellte Befehle in einer laufenden Instanz von BB nicht mehr verfügbar sind, nachdem die BB-Binärdatei gelöscht wurde.

Wenn (2) so funktioniert, kann BusyBox auch zur Wiederherstellung eines Systems verwendet werden, auf dem BB selbst gelöscht wurde - vorausgesetzt, es ist noch eine laufende Instanz von BusyBox verfügbar.

Ist das irgendwo dokumentiert? Wenn nicht, gibt es eine Möglichkeit, es sicher zu testen?

Standardmäßig führt BusyBox in Bezug auf die eingebauten Applets (die mit aufgelisteten Befehle busybox --help) keine besonderen Aktionen aus .

Wenn jedoch die Optionen FEATURE_SH_STANDALONEund FEATURE_PREFER_APPLETSzur Kompilierungszeit aktiviert sind, führt BusyBox sh¹ beim Ausführen eines Befehls, bei dem es sich um einen bekannten Applet-Namen handelt, nicht die normale PATHSuche durch, sondern führt die integrierten Applets über eine Verknüpfung aus:

• Applets, die im Quellcode als "noexec" deklariert sind, werden als Funktionsaufrufe in einem gegabelten Prozess ausgeführt. Ab BusyBox 1.22 werden die folgenden Applets sind 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.
• Applets, die im Quellcode als "nofork" deklariert sind, werden im selben Prozess als Funktionsaufrufe ausgeführt. Ab BusyBox 1,22 sind die folgenden Applets nofork: [[, [, basename, cat, dirname, echo, false, fsync, length, logname, mkdir, printenv, printf, pwd, rm, rmdir, seq, sync, test, true, usleep, whoami, yes.
• Andere Applets werden tatsächlich ausgeführt (mit forkund execve). Anstatt jedoch eine PATHSuche durchzuführen, wird BusyBox ausgeführt /proc/self/exe, sofern verfügbar (was normalerweise unter Linux der Fall ist), und ansonsten wird ein Pfad zur Kompilierungszeit definiert.

Dies ist in etwas ausführlicher dokumentiert docs/nofork_noexec.txt. Die Applet-Deklarationen befinden sich im include/applets.src.hQuellcode.

Die meisten Standardkonfigurationen deaktivieren diese Funktionen, sodass BusyBox wie jede andere Shell externe Befehle ausführt. Debian aktiviert diese Funktionen sowohl in seiner busyboxals auch in seinen busybox-staticPaketen.

Wenn Sie also eine ausführbare BusyBox-Datei mit FEATURE_SH_STANDALONEund kompiliert haben FEATURE_PREFER_APPLETS, können Sie alle BusyBox-Befehle von einer BusyBox-Shell aus ausführen, auch wenn die ausführbare Datei gelöscht wird (mit Ausnahme der oben nicht aufgeführten Applets, sofern diese /proc/self/exenicht verfügbar sind).

¹ _{In BusyBox gibt es zwei Implementierungen von "sh" - ash und hush -, die sich jedoch in dieser Hinsicht gleich verhalten.}

is there a way to safely test it? Mit dem generischen x86-OpenWRT-Image:

Die meisten Befehle sind nicht integriert, einige jedoch wie echound printf. Eine Binärdatei mit beliebigen Inhalten kann mit erstellt werden printf, ist jedoch chmod +xein Problem.