Các lệnh BusyBox có thực sự được xây dựng không?

Tôi đang đọc Truyền thuyết phục hồi Unix nổi tiếng và tôi tự hỏi:

Nếu tôi mở shell BusyBox và nhị phân BusyBox bị xóa, tôi vẫn có thể sử dụng tất cả các lệnh có trong nhị phân BusyBox chứ?

Rõ ràng tôi sẽ không thể sử dụng phiên bản BB của các lệnh đó từ một shell đang chạy khác, chẳng hạn như bash, vì tệp BusyBox sẽ không có sẵn bashđể mở và chạy. Nhưng từ trong phiên bản đang chạy của BusyBox, tôi thấy có thể có hai phương thức để BB chạy lệnh:

1. Nó có thể rẽ nhánh và thực thi một phiên bản mới của BusyBox, gọi nó bằng cách sử dụng tên thích hợp và đọc tệp BusyBox từ đĩa để làm như vậy.
2. Nó có thể rẽ nhánh và thực hiện một số logic bên trong để chạy lệnh được chỉ định (ví dụ: bằng cách chạy nó dưới dạng gọi hàm).

Nếu (1) là cách BusyBox hoạt động, tôi hy vọng rằng một số lệnh do BusyBox cung cấp sẽ không khả dụng trong một phiên bản BB đang chạy sau khi nhị phân BB bị xóa.

Nếu (2) là cách nó hoạt động, BusyBox có thể được sử dụng ngay cả để phục hồi hệ thống mà bản thân BB đã bị xóa, miễn là vẫn có thể truy cập BusyBox.

Đây có phải là tài liệu ở bất cứ đâu? Nếu không, có cách nào để kiểm tra nó một cách an toàn không?

Theo mặc định, BusyBox không làm bất cứ điều gì đặc biệt liên quan đến các applet mà nó đã tích hợp (các lệnh được liệt kê cùng busybox --help).

Tuy nhiên, nếu các tùy chọn FEATURE_SH_STANDALONEvà FEATURE_PREFER_APPLETSđược bật vào thời gian biên dịch, thì khi BusyBox thực hiện một lệnh là tên applet đã biết, nó không thực hiện PATHtra cứu thông thường , mà thay vào đó, chạy các applet tích hợp của nó thông qua một phím tắt:

• Các ứng dụng được khai báo là không có mã noexec trong mã nguồn được thực thi như các lệnh gọi hàm trong một quá trình rẽ nhánh. Tính đến BusyBox 1.22, các applet Sau đây là 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.
• Các ứng dụng được khai báo là nofork, trong mã nguồn được thực thi như các lệnh gọi hàm trong cùng một quy trình. Tính đến BusyBox 1.22, các applet sau nofork: [[, [, basename, cat, dirname, echo, false, fsync, length, logname, mkdir, printenv, printf, pwd, rm, rmdir, seq, sync, test, true, usleep, whoami, yes.
• Các applet khác thực sự được thực thi (có forkvà execve), nhưng thay vì thực hiện PATHtra cứu, BusyBox sẽ thực thi /proc/self/exe, nếu có (thường là trường hợp trên Linux) và một đường dẫn được xác định theo thời gian biên dịch theo cách khác.

Điều này được ghi lại chi tiết hơn một chút trong docs/nofork_noexec.txt. Các khai báo applet nằm trong include/applets.src.hmã nguồn.

Hầu hết các cấu hình mặc định đều tắt các tính năng này, để BusyBox thực thi các lệnh bên ngoài như mọi shell khác. Debian bật các tính năng này trong cả gói busyboxvà busybox-staticgói.

Vì vậy, nếu bạn có một BusyBox thực thi biên soạn với FEATURE_SH_STANDALONEvà FEATURE_PREFER_APPLETS, sau đó bạn có thể thực hiện tất cả các lệnh BusyBox từ một vỏ BusyBox ngay cả khi thực thi sẽ bị xóa (trừ các applet không được liệt kê ở trên, nếu /proc/self/exekhông có sẵn).

¹ _{Thực tế, có hai hiện thực của "sh" trong BusyBox - tro và im lặng - nhưng họ cư xử theo cùng một cách trong lĩnh vực này.}

is there a way to safely test it? Với hình ảnh openwrt x86 chung:

Hầu hết các lệnh không được tích hợp sẵn, nhưng một số lệnh, như echovà printf. Một tệp nhị phân với nội dung tùy ý có thể được tạo bằng cách sử dụng printf, nhưng chmod +xsẽ là một vấn đề.