Tại sao nhị phân su không thể được sao chép đơn giản (vui lòng phản hồi về mặt kỹ thuật)


18

Tôi đã root một số thiết bị của Samsung và "mục tiêu" cơ bản để nói dường như là để có được sunhị phân trong /system/xbinvà cài đặt Superuser.apk .

Câu hỏi của tôi là tại sao người ta phải nhảy qua tất cả các vòng để root điện thoại (cài đặt phục hồi tùy chỉnh và flash ROM đã root sẵn hoặc khai thác cài đặt hiện tại)? Không ai có thể tải xuống một su được biên dịch sẵn, di chuyển nó vào thẻ SD và chạy nó qua adb? Điều dường như làm cho ROM "được root" là nó có Superuser và nhị phân su trong đường dẫn hệ thống tương ứng của chúng. Tôi không thấy lý do tại sao nó lại quan trọng đến vậy /system/xbin.

Câu trả lời:


24

Nhị phân su cần cả thực thi và tập quyền bit setuid. Điều đầu tiên là cần thiết để tệp có thể được thực thi và thứ hai là nó tự động chạy với quyền của chủ sở hữu tệp (đặt id người dùng hoặc setuid. Trong trường hợp này, chủ sở hữu là root. Đọc thêm tại đây ).

Các tệp trên bộ lưu trữ ngoài không có các bit quyền thực thi và setuid được đặt và nó không thể được cấp nếu không có quyền root. Cũng lưu ý rằng thẻ SD được gắn cờ 'noexec' để ngăn việc thực thi thường khởi động:

shell@android:/sdcard $ ./su
/system/bin/sh: ./su: can't execute: Permission denied
126|shell@android:/sdcard $ chmod 4755 su
Unable to chmod su: Operation not permitted
10|shell@android:/sdcard $ mount | grep /mnt/sdcard
/dev/block/mmcblk0p1 /mnt/sdcard vfat [...],noexec,[...]

Về cơ bản, đó là lý do tại sao bạn không thể sao chép suvào thẻ SD và sau đó chạy nó để cấp quyền cho chính mình.


Vì vậy, đó là điều duy nhất ngăn chặn root, thực tế là / sdcard không thể thực thi và bạn không thể chmod? Một khi su ở vị trí thích hợp, nơi nó có thể được điều chỉnh bằng vàng. Tôi nghĩ sẽ có một lớp bảo mật để ngăn người khác chạy đơn giản. Trên máy chủ và hộp debian của tôi, tôi không thể chạy su như một người dùng bình thường, tôi được nhắc nhập mật khẩu. Tôi đoán giả định là nếu ai đó có thể cài đặt su họ có thể ghi đè lên tập tin bóng để thay đổi mật khẩu không?
user974896

3
@ user974896: Không có nơi nào khác cho người dùng không phải là hệ thống để đặt nó có thể được thực thi và Android thậm chí không có passwdhoặc có shadowtệp nào. Bạn thực sự cần root để đặt suvào một vị trí có thể thực thi được, đó là lý do tại sao các phương thức root lại liên quan đến khai thác leo thang đặc quyền hoặc vào phục hồi tùy chỉnh (trong đó tất cả các cược về cơ bản đều bị tắt).
eldarerathis

Vâng. Đây là câu trả lời.
Android Quesito

3
@ user974896: ngoài / sdcard được gắn noexec, lệnh gọi hệ thống setuid chỉ có thể được gọi khi bit quyền suid được đặt trong tệp thực thi và lệnh gọi hệ thống chown và chmod sẽ chỉ cho phép root thiết lập bit setuid của tệp được sở hữu bởi root (một cách hiệu quả, chỉ root mới có thể tạo một tệp thực thi có thể chạy với quyền root). Bất cứ ai cũng có thể gọi su, nhưng trừ khi người gọi được phép làm như vậy trong cơ sở dữ liệu của Superuser (hoặc trong Linux truyền thống, trong cơ sở dữ liệu passwd / bóng), cuộc gọi sẽ không thành công. Chỉ ứng dụng Superuser (và các quy trình đặc quyền) mới có thể sửa đổi cơ sở dữ liệu của Superuser.
Lie Ryan

3
@ user974896: Ngoài hệ thống bảo mật thông thường trong Android mà mỗi ứng dụng dalvik chạy như người dùng của chính nó, có nghĩa là các ứng dụng chỉ có ứng dụng trong danh sách trắng của Superuser có thể tự leo thang lên root mà không cần nhắc nhở, nếu mọi người khác sẽ bị từ chối (nếu đó là trong danh sách đen) hoặc sẽ khiến Superuser nhắc người dùng cho phép.
Lie Ryan

5

Root liên quan đến việc khai thác điểm yếu tùy thuộc vào phiên bản Android, do đó " nhảy qua tất cả các vòng để root điện thoại "

Đó là một quả trứng gà!

Để khai thác root, bạn cần một trình nền adb không bảo mật (nghĩa là khả năng kết nối lại /system) trên thiết bị cầm tay và để có một adb không bảo mật, bạn cần root! VÀ cũng vậy, bạn cần một bộ tải khởi động đã mở khóa.

Hãy xem một khai thác được gọi là zergRush được tìm thấy trên github; chức năng quan tâm được gọi là do_fault()nơi cố gắng thực hiện để "phá vỡ" khung ngăn xếp voldcủa daemon bằng cách kết nối với đường ống do nó sở hữu và khiến nó bị sập bằng cách ghi đè con trỏ ngăn xếp để trỏ đến một bản sao phiên bản của vỏ boomshmà sau đó chạy từ /data/local/tmp.

Sau khi đọc nguồn, bây giờ bạn sẽ nhận ra, tại sao sao chép sunhị phân là không đủ để thiết bị cầm tay "root" và tại sao hoops phải được nhảy qua. Ngoài ra, vì bit thực thi ở cấp hệ thống tệp cho SDcard bị chặn, do đó, không đi đến đó - đó là lý do rõ ràng! :)


Cảm ơn các liên kết tôi sẽ đọc chúng sau. Vì vậy, ngay cả khi sdcard được chmod 777 từ nhà máy, tôi vẫn không thể trở thành root bằng cách tải xuống và thực thi nó?
dùng974896

1
chính xác! Không đi! Không tạo ra sự khác biệt và vì ROM được cài đặt tại nhà máy sẽ bảo vệ một lá bạn cần root để đạt được điều đó chmod- cho phép các quyền của SDcard để làm điều đó! :)
t0mm13b

1
Chà, điều gì làm cho su trở nên đặc biệt nếu nó trong / system / xbin? Nếu bạn nhập adb shell (hoặc chạy một ứng dụng như một người dùng bình thường), bạn là một người dùng không có kinh nghiệm. Tại sao thực thi su khi nó trong / system / xbin khiến bạn root chứ không phải chạy nó trong lý thuyết chmod 777 / sdcard của chúng tôi?
user974896

/system/xbinlà thư mục chứa các tiện ích busybox đi vào và ... trong một thiết bị cầm tay đã được root, việc phát hành này echo $PATHsẽ mang lại / sbin: / eller / bin: / system / sbin: / system / bin: / system / xbin <- hãy chú ý điều đó! Đó là trong con đường! Để có được điều đó, bạn cần root do đó có rất nhiều tình huống trứng gà ...: D
t0mm13b

Vâng, tôi biết đó là nơi nó đi theo mặc định. Ý tôi là điều đặc biệt khi chạy nó ở đó. Tại sao lại thực thi ./su trong / sdcard /, / data / hoặc bất kỳ thư mục bắt buộc không root nào không hoạt động giả sử nhà máy vận chuyển ROM với thư mục được chmodded ở 777. Về cơ bản, điều tôi muốn nói là điều duy nhất ngăn một người tải xuống và đang chạy ./su là thực tế là các thư mục mà người dùng nonroot có thể thực hiện việc này không thể thực thi được hoặc có một bức tranh lớn hơn.
dùng974896
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.