I comandi BusyBox sono davvero integrati?

Stavo leggendo la famosa leggenda di recupero di Unix e mi è venuto in mente di chiedermi:

Se avessi aperto una shell BusyBox e il binario BusyBox fosse stato eliminato, sarei comunque in grado di utilizzare tutti i comandi inclusi nel binario BusyBox?

Chiaramente non sarei in grado di usare la versione BB di questi comandi da un'altra shell in esecuzione come bash, poiché il file BusyBox stesso non sarebbe disponibile per bashl'apertura e l'esecuzione. Ma dall'istanza corrente di BusyBox, mi sembra che ci possano essere due metodi con cui BB eseguirà un comando:

1. Potrebbe eseguire il fork ed eseguire una nuova istanza di BusyBox, chiamandola utilizzando il nome appropriato e leggendo il file BusyBox dal disco per farlo.
2. Potrebbe eseguire il fork ed eseguire alcune logiche interne per eseguire il comando specificato (ad esempio, eseguendolo come una chiamata di funzione).

Se (1) è il modo in cui funziona BusyBox, mi aspetto che alcuni comandi forniti da BusyBox diventino non disponibili all'interno di un'istanza in esecuzione di BB dopo l'eliminazione del binario BB.

Se (2) funziona, BusyBox può essere utilizzato anche per il ripristino di un sistema in cui BB stesso era stato eliminato, a condizione che esistesse ancora un'istanza in esecuzione di BusyBox accessibile.

Questo è documentato ovunque? In caso contrario, c'è un modo per testarlo in sicurezza?

Per impostazione predefinita, BusyBox non fa nulla di speciale riguardo alle applet che ha incorporato (i comandi elencati con busybox --help).

Tuttavia, se le opzioni FEATURE_SH_STANDALONEe FEATURE_PREFER_APPLETSsono abilitate in fase di compilazione, quando BusyBox sh¹ esegue un comando che è un nome di applet noto, non esegue la PATHricerca normale , ma esegue invece le sue applet integrate tramite un collegamento:

• Le applet dichiarate come "noexec" nel codice sorgente vengono eseguite come chiamate di funzione in un processo biforcato. Come di BusyBox 1.22, i seguenti applet sono 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.
• Le applet dichiarate come "nofork" nel codice sorgente vengono eseguite come chiamate di funzione nello stesso processo. Come di BusyBox 1.22, i seguenti applet sono nofork: [[, [, basename, cat, dirname, echo, false, fsync, length, logname, mkdir, printenv, printf, pwd, rm, rmdir, seq, sync, test, true, usleep, whoami, yes.
• Altre applet vengono realmente eseguite (con forke execve), ma invece di fare una PATHricerca, BusyBox esegue /proc/self/exe, se disponibile (che è normalmente il caso su Linux), e un percorso definito in fase di compilazione altrimenti.

Questo è documentato in modo un po 'più dettagliato in docs/nofork_noexec.txt. Le dichiarazioni dell'applet sono contenute include/applets.src.hnel codice sorgente.

La maggior parte delle configurazioni predefinite disattiva queste funzionalità, in modo che BusyBox esegua comandi esterni come qualsiasi altra shell. Debian compie queste funzioni in entrambe le sue busyboxe busybox-staticpacchetti.

Quindi se hai un eseguibile BusyBox compilato con FEATURE_SH_STANDALONEe FEATURE_PREFER_APPLETS, allora puoi eseguire tutti i comandi BusyBox da una shell BusyBox anche se l'eseguibile viene eliminato (tranne che per le applet che non sono elencate sopra, se /proc/self/exenon è disponibile).

¹ _{In BusyBox ci sono due implementazioni di "sh" - ash e hush - ma si comportano allo stesso modo in questo senso.}

is there a way to safely test it? Con l'immagine openwrt x86 generica:

La maggior parte dei comandi non sono integrati, ma alcuni sono, come echoe printf. È possibile creare un file binario con contenuti arbitrari utilizzando printf, ma chmod +xsarà un problema.