Os comandos do BusyBox são realmente integrados?

Eu estava lendo a famosa lenda do Unix Recovery , e me ocorreu pensar:

Se eu tivesse um shell do BusyBox aberto e o próprio binário do BusyBox fosse excluído, ainda seria possível usar todos os comandos incluídos no binário do BusyBox?

Claramente, eu não seria capaz de usar a versão BB desses comandos de outro shell em execução, como bash, uma vez que o próprio arquivo BusyBox não estaria disponível para bashabrir e executar. Mas, a partir da instância em execução do BusyBox, parece-me que poderia haver dois métodos pelos quais o BB executaria um comando:

1. Ele poderia bifurcar e executar uma nova instância do BusyBox, chamando-a usando o nome apropriado - e lendo o arquivo BusyBox do disco para fazer isso.
2. Ele poderia bifurcar e executar alguma lógica interna para executar o comando especificado (por exemplo, executando-o como uma chamada de função).

Se (1) for o modo como o BusyBox funciona, eu esperaria que determinados comandos fornecidos pelo BusyBox fiquem indisponíveis a partir de uma instância em execução do BB após a exclusão do binário do BB.

Se (2) é assim que funciona, o BusyBox pode ser usado até para recuperar um sistema em que o próprio BB foi excluído - desde que ainda exista uma instância em execução do BusyBox acessível.

Isso está documentado em algum lugar? Caso contrário, existe uma maneira de testá-lo com segurança?

Por padrão, o BusyBox não faz nada de especial em relação aos applets incorporados (os comandos listados busybox --help).

No entanto, se as opções FEATURE_SH_STANDALONEe FEATURE_PREFER_APPLETSestiverem ativadas no momento da compilação, quando o BusyBox executar um comando que é um nome conhecido de applet, ele não fará a PATHpesquisa normal , mas executará seus applets internos por meio de um atalho:

• Os applets declarados como "noexec" no código-fonte são executados como chamadas de função em um processo bifurcado. A partir de 1,22 BusyBox, os seguintes applets são 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.
• Os applets declarados como "nofork" no código-fonte são executados como chamadas de função no mesmo processo. A partir de 1,22 BusyBox, os seguintes applets são nofork: [[, [, basename, cat, dirname, echo, false, fsync, length, logname, mkdir, printenv, printf, pwd, rm, rmdir, seq, sync, test, true, usleep, whoami, yes.
• Outros applets são realmente executados (com forke execve), mas, em vez de fazer uma PATHpesquisa, o BusyBox executa /proc/self/exe, se disponível (o que normalmente acontece no Linux), e um caminho definido no momento da compilação.

Isso está documentado com mais detalhes em docs/nofork_noexec.txt. As declarações do applet estão no include/applets.src.hcódigo-fonte.

A maioria das configurações padrão desativa esses recursos, para que o BusyBox execute comandos externos como qualquer outro shell. O Debian ativa esses recursos nos pacotes its busyboxebusybox-static

Portanto, se você tiver um executável do BusyBox compilado com FEATURE_SH_STANDALONEe FEATURE_PREFER_APPLETS, poderá executar todos os comandos do BusyBox a partir de um shell do BusyBox, mesmo que o executável seja excluído (exceto os applets que não estão listados acima, se /proc/self/exenão estiver disponível).

¹ _{Na verdade, existem duas implementações de "sh" no BusyBox - cinzas e silêncio - mas eles se comportam da mesma maneira a este respeito.}

is there a way to safely test it? Com a imagem openwrt genérica x86:

A maioria dos comandos não é incorporada, mas alguns são, como echoe printf. Um arquivo binário com conteúdo arbitrário pode ser criado usando printf, mas chmod +xserá um problema.