Apakah perintah BusyBox benar-benar terintegrasi?

Saya sedang membaca Legenda Pemulihan Unix yang terkenal , dan terpikir oleh saya untuk bertanya:

Jika saya memiliki shell BusyBox terbuka, dan biner BusyBox itu sendiri dihapus, apakah saya masih dapat menggunakan semua perintah yang termasuk dalam biner BusyBox?

Jelas saya tidak akan dapat menggunakan versi BB perintah orang-orang dari lain shell berjalan seperti bash, karena file BusyBox itu sendiri akan tersedia untuk bashuntuk membuka dan menjalankan. Tapi dari dalam instance BusyBox yang sedang berjalan, menurut saya mungkin ada dua metode yang digunakan BB untuk menjalankan perintah:

1. Itu dapat melakukan fork dan mengeksekusi instance baru BusyBox, menyebutnya menggunakan nama yang sesuai — dan membaca file BusyBox dari disk untuk melakukannya.
2. Itu bisa fork dan melakukan beberapa logika internal untuk menjalankan perintah yang ditentukan (misalnya, dengan menjalankannya sebagai panggilan fungsi).

Jika (1) adalah cara BusyBox bekerja, saya berharap bahwa perintah-perintah yang disediakan BusyBox tertentu tidak akan tersedia dari dalam instance BB yang berjalan setelah biner BB dihapus.

Jika (2) cara kerjanya, BusyBox dapat digunakan bahkan untuk pemulihan sistem di mana BB itu sendiri telah dihapus — asalkan masih ada instance berjalan BusyBox yang dapat diakses.

Apakah ini didokumentasikan di mana saja? Jika tidak, adakah cara untuk mengujinya dengan aman?

Secara default, BusyBox tidak melakukan sesuatu yang spesial sehubungan dengan applet yang telah dibangunnya (perintah-perintah terdaftar dengan busybox --help).

Namun, jika opsi FEATURE_SH_STANDALONEdan FEATURE_PREFER_APPLETSdiaktifkan pada waktu kompilasi, maka ketika BusyBox sh¹ mengeksekusi perintah yang merupakan nama applet yang dikenal, itu tidak melakukan PATHpencarian normal , tetapi menjalankan applet built-in melalui shortcut:

• Applet yang dideklarasikan sebagai "noexec" dalam kode sumber dieksekusi sebagai pemanggilan fungsi dalam proses bercabang. Pada BusyBox 1,22, applet berikut 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.
• Applet yang dideklarasikan sebagai "nofork" dalam kode sumber dieksekusi sebagai pemanggilan fungsi dalam proses yang sama. Pada BusyBox 1,22, applet berikut nofork: [[, [, basename, cat, dirname, echo, false, fsync, length, logname, mkdir, printenv, printf, pwd, rm, rmdir, seq, sync, test, true, usleep, whoami, yes.
• Applet lain benar-benar dieksekusi (dengan forkdan execve), tetapi alih-alih melakukan PATHpencarian, BusyBox mengeksekusi /proc/self/exe, jika tersedia (yang biasanya terjadi di Linux), dan jalur yang ditentukan pada waktu kompilasi sebaliknya.

Ini didokumentasikan sedikit lebih detail di docs/nofork_noexec.txt. Deklarasi applet ada di include/applets.src.hdalam kode sumber.

Sebagian besar konfigurasi default mematikan fitur-fitur ini, sehingga BusyBox menjalankan perintah eksternal seperti shell lainnya. Debian mengaktifkan fitur-fitur ini baik dalam paketnya busyboxmaupun busybox-static.

Jadi jika Anda memiliki BusyBox yang dapat dieksekusi dikompilasi dengan FEATURE_SH_STANDALONEdan FEATURE_PREFER_APPLETS, maka Anda dapat menjalankan semua perintah BusyBox dari shell BusyBox bahkan jika executable dihapus (kecuali untuk applet yang tidak tercantum di atas, jika /proc/self/exetidak tersedia).

¹ _{Sebenarnya ada dua implementasi "sh" di BusyBox - ash dan hush - tetapi mereka berperilaku yang sama dalam hal ini.}

is there a way to safely test it? Dengan gambar openwrt x86 generik:

Sebagian besar perintah tidak built-in, tetapi ada juga yang seperti echodan printf. File biner dengan konten sewenang-wenang dapat dibuat menggunakan printf, tetapi chmod +xakan menjadi masalah.