Language Update (#924)

Update Vietnamese language for kernelsu.org and README_VI.md
This commit is contained in:
Nguyễn Viết Thắng
2023-09-01 13:23:45 +07:00
committed by GitHub
parent 5d988002c7
commit 71c14d96ab
13 changed files with 688 additions and 86 deletions

View File

@@ -1,18 +1,18 @@
**English** | [Español](README_ES.md) | [简体中文](README_CN.md) | [繁體中文](README_TW.md) | [日本語](README_JP.md) | [Polski](README_PL.md) | [Portuguese-Brazil](README_PT-BR.md) | [Türkçe](README_TR.md) | [Русский](README_RU.md) | [Tiếng Việt](README_VI.md) | [Indonesia](README_ID.md)
[English](README.md) | [Español](README_ES.md) | [简体中文](README_CN.md) | [繁體中文](README_TW.md) | [日本語](README_JP.md) | [Polski](README_PL.md) | [Portuguese-Brazil](README_PT-BR.md) | [Türkçe](README_TR.md) | [Русский](README_RU.md) | **Tiếng Việt** | [Indonesia](README_ID.md)
# KernelSU
Giải pháp root thông qua thay đổi trên nhân hệ điều hành cho các thiết bị Android.
Giải pháp root thông qua thay đổi trên Kernel hệ điều hành cho các thiết bị Android.
## Tính năng
1. Hỗ trợ gói thực thi `su` và quản lý quyền root.
2. Hệ thống mô-đun thông qua overlayfs.
3. [Hồ sơ ứng dụng](https://kernelsu.org/guide/app-profile.html): Hạn chế quyền root của ứng dụng.
3. [App Profile](https://kernelsu.org/guide/app-profile.html): Hạn chế quyền root của ứng dụng.
## Tình trạng tương thích
KernelSU chính thức hỗ trợ các thiết bị Android với nhân GKI 2.0(phiên bản nhân 5.10+), các phiên bản nhân cũ hơn(4.14+) cũng tương thích, nhưng bạn cần phải tự biên dịch.
KernelSU chính thức hỗ trợ các thiết bị Android với kernel GKI 2.0 (phiên bản kernel 5.10+), các phiên bản kernel cũ hơn (4.14+) cũng tương thích, nhưng bạn cần phải tự biên dịch.
WSA, ChromeOS và Android dựa trên container(container-based) cũng được hỗ trợ bởi KernelSU.
@@ -22,11 +22,11 @@ Hiên tại Giao diện nhị phân của ứng dụng (ABI) được hỗ trợ
- [Hướng dẫn cài đặt](https://kernelsu.org/vi_VN/guide/installation.html)
- [Cách để build?](https://kernelsu.org/vi_VN/guide/how-to-build.html)
- [Website chính thức](https://kernelsu.org/)
- [Website Chính Thức](https://kernelsu.org/vi_VN/)
## Hỗ trợ dịch
Nếu bạn muốn hỗ trợ dịch KernelSU sang một ngôn ngữ khác hoặc cải thiện bản dịch trước, vui lòng sử dụng [Weblate](https://hosted.weblate.org/engage/kernelsu/).
Nếu bạn muốn hỗ trợ dịch KernelSU sang một ngôn ngữ khác hoặc cải thiện các bản dịch trước, vui lòng sử dụng [Weblate](https://hosted.weblate.org/engage/kernelsu/).
## Thảo luận
@@ -39,7 +39,7 @@ Nếu bạn muốn hỗ trợ dịch KernelSU sang một ngôn ngữ khác hoặ
## Lời cảm ơn
- [kernel-assisted-superuser](https://git.zx2c4.com/kernel-assisted-superuser/about/): ý tưởng cho KernelSU.
- [Magisk](https://github.com/topjohnwu/Magisk): một công cụ root mạnh mẽ.
- [genuine](https://github.com/brevent/genuine/): phương pháp xác thực apk v2.
- [Diamorphine](https://github.com/m0nad/Diamorphine): các phương pháp che giấu của rootkit .
- [kernel-assisted-superuser](https://git.zx2c4.com/kernel-assisted-superuser/about/): ý tưởng cho KernelSU.
- [Magisk](https://github.com/topjohnwu/Magisk): công cụ root mạnh mẽ.
- [genuine](https://github.com/brevent/genuine/): phương pháp xác thực apk v2.
- [Diamorphine](https://github.com/m0nad/Diamorphine): các phương pháp ẩn của rootkit .

View File

@@ -0,0 +1,118 @@
# App Profile
App Profile là một cơ chế do KernelSU cung cấp để tùy chỉnh cấu hình của các ứng dụng khác nhau.
Đối với các ứng dụng được cấp quyền root (tức là có thể sử dụng `su`), App Profile cũng có thể được gọi là Root Profile. Nó cho phép tùy chỉnh các quy tắc `uid`, `gid`, `groups`, `capabilities``SELinux` của lệnh `su`, do đó hạn chế các đặc quyền của người dùng root. Ví dụ: nó có thể chỉ cấp quyền mạng cho các ứng dụng tường lửa trong khi từ chối quyền truy cập tệp hoặc có thể cấp quyền shell thay vì quyền truy cập root đầy đủ cho các ứng dụng đóng băng: **giữ nguồn điện theo nguyên tắc đặc quyền tối thiểu.**
Đối với các ứng dụng thông thường không có quyền root, App Profile có thể kiểm soát hành vi của hệ thống kernel và mô-đun đối với các ứng dụng này. Ví dụ, nó có thể xác định liệu các sửa đổi do mô-đun tạo ra có nên được giải quyết hay không. Hệ thống kernel và mô-đun có thể đưa ra quyết định dựa trên cấu hình này, chẳng hạn như thực hiện các hoạt động tương tự như "hiding"
## Root Profile
### UID, GID, và Groups
Hệ thống Linux có hai khái niệm: người dùng (user) và nhóm (group). Mỗi người dùng có một user ID (UID) và một người dùng có thể thuộc nhiều nhóm, mỗi nhóm có group ID (GID) riêng. Những ID này được sử dụng để xác định người dùng trong hệ thống và xác định tài nguyên hệ thống nào họ có thể truy cập.
Người dùng có UID bằng 0 được gọi là người dùng root và các nhóm có GID bằng 0 được gọi là nhóm root. Nhóm người dùng root thường giữ các đặc quyền hệ thống cao nhất.
Trong trường hợp hệ thống Android, mỗi ứng dụng là một người dùng riêng biệt (không bao gồm các trường hợp UID dùng chung) với một UID duy nhất. Ví dụ: `0` đại diện cho người dùng root, `1000` đại diện cho `system`, `2000` đại diện cho ADB shell và các UID từ 10000 đến 19999 đại diện cho các ứng dụng thông thường.
:::info
Ở đây, UID được đề cập không giống với khái niệm nhiều người dùng hoặc hồ sơ công việc (Work profile) trong hệ thống Android. Hồ sơ công việc thực sự được triển khai bằng cách phân vùng phạm vi UID. Ví dụ: 10000-19999 đại diện cho người dùng chính, trong khi 110000-119999 đại diện cho hồ sơ công việc. Mỗi ứng dụng thông thường trong số đó đều có UID riêng.
:::
Mỗi ứng dụng có thể có nhiều nhóm, với GID đại diện cho nhóm chính, thường khớp với UID. Các nhóm khác được gọi là nhóm bổ sung. Một số quyền nhất định được kiểm soát thông qua các nhóm, chẳng hạn như quyền truy cập mạng hoặc truy cập Bluetooth.
Ví dụ: nếu chúng ta thực thi lệnh `id` trong shell ADB, kết quả đầu ra có thể trông như thế này:
```sh
oriole:/ $ id
uid=2000(shell) gid=2000(shell) groups=2000(shell),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),1078(ext_data_rw),1079(ext_obb_rw),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid),3012(readtracefs) context=u:r:shell:s0
```
Ở đây, UID là `2000` và GID (ID nhóm chính) cũng là `2000`. Ngoài ra, nó thuộc một số nhóm bổ sung, chẳng hạn như `inet` (biểu thị khả năng tạo ổ cắm `AF_INET``AF_INET6`) và `sdcard_rw` (biểu thị quyền đọc/ghi đối với thẻ SD).
Root Profile của KernelSU cho phép tùy chỉnh UID, GID và các nhóm cho quy trình gốc sau khi thực thi `su`. Ví dụ: Cấu hình gốc của ứng dụng gốc có thể đặt UID của nó thành `2000`, có nghĩa là khi sử dụng `su`, các quyền thực tế của ứng dụng sẽ ở cấp shell ADB. Nhóm `inet` có thể bị xóa, ngăn lệnh `su` truy cập mạng.
:::tip Ghi chú
Hồ sơ ứng dụng chỉ kiểm soát các quyền của tiến trình gốc sau khi sử dụng `su`; nó không kiểm soát các quyền của ứng dụng. Nếu một ứng dụng đã yêu cầu quyền truy cập mạng, ứng dụng đó vẫn có thể truy cập mạng ngay cả khi không sử dụng `su`. Việc xóa nhóm `inet` khỏi `su` chỉ ngăn `su` truy cập mạng.
:::
Root Profile được thực thi trong kernel và không dựa vào hành vi tự nguyện của các ứng dụng root, không giống như việc chuyển đổi người dùng hoặc nhóm thông qua `su`, việc cấp quyền `su` hoàn toàn phụ thuộc vào người dùng chứ không phải nhà phát triển.
### Capabilities
Capabilities (khả năng) là một cơ chế phân tách đặc quyền trong Linux.
Với mục đích thực hiện kiểm tra quyền, việc triển khai UNIX truyền thống phân biệt hai loại quy trình: quy trình đặc quyền (có ID người dùng hiệu quả là 0, được gọi là siêu người dùng hoặc root) và quy trình không có đặc quyền (có UID hiệu dụng khác 0). Các quy trình đặc quyền bỏ qua tất cả các bước kiểm tra quyền của kernel, trong khi các quy trình không có đặc quyền phải chịu sự kiểm tra quyền đầy đủ dựa trên thông tin xác thực của quy trình (thường là: UID hiệu quả, GID hiệu quả và danh sách nhóm bổ sung).
Bắt đầu với Linux 2.2, Linux chia các đặc quyền truyền thống được liên kết với siêu người dùng thành các đơn vị riêng biệt, được gọi là các khả năng, có thể được bật và tắt một cách độc lập.
Mỗi Khả năng đại diện cho một hoặc nhiều đặc quyền. Ví dụ: `CAP_DAC_READ_SEARCH` thể hiện khả năng bỏ qua việc kiểm tra quyền để đọc tệp cũng như quyền đọc và thực thi thư mục. Nếu người dùng có UID hiệu dụng là `0` (người dùng root) thiếu khả năng `CAP_DAC_READ_SEARCH` hoặc cao hơn, điều này có nghĩa là ngay cả khi họ là root, họ không thể tùy ý đọc tệp.
Cấu hình gốc của KernelSU cho phép tùy chỉnh các Khả năng của tiến trình gốc sau khi thực thi `su`, nhờ đó đạt được việc cấp một phần "quyền root". Không giống như UID và GID đã nói ở trên, một số ứng dụng gốc nhất định yêu cầu UID là `0` sau khi sử dụng `su`. Trong những trường hợp như vậy, việc giới hạn Khả năng của người dùng root này bằng UID `0` có thể hạn chế các hoạt động được phép của họ.
:::tip Rất Khuyến Nghị
Capabilities của Linux [tài liệu chính thức](https://man7.org/linux/man-pages/man7/capabilities.7.html) cung cấp giải thích chi tiết về các khả năng mà mỗi Capabilities thể hiện. Nếu bạn có ý định tùy chỉnh Capabilities, bạn nên đọc tài liệu này trước.
:::
### SELinux
SELinux là một cơ chế Kiểm Soát Truy Cập Bắt Buộc (Mandatory Access Control: MAC) mạnh mẽ. Nó hoạt động theo nguyên tắc **từ chối mặc định**: bất kỳ hành động nào không được cho phép rõ ràng đều bị từ chối.
SELinux có thể chạy ở hai chế độ chung:
1. Chế độ cho phép (Permissive mode): Các sự kiện từ chối được ghi lại nhưng không được thực thi.
2. Chế độ thực thi (Enforcing mode): Các sự kiện từ chối được ghi lại và thực thi.
:::warning Cảnh báo
Các hệ thống Android hiện đại phụ thuộc rất nhiều vào SELinux để đảm bảo an ninh hệ thống tổng thể. Chúng tôi khuyên bạn không nên sử dụng bất kỳ hệ thống tùy chỉnh nào chạy ở "chế độ cho phép" vì nó không mang lại lợi thế đáng kể nào so với hệ thống mở hoàn toàn.
:::
Việc giải thích khái niệm đầy đủ về SELinux rất phức tạp và nằm ngoài phạm vi của tài liệu này. Trước tiên nên hiểu hoạt động của nó thông qua các tài nguyên sau:
1. [Wikipedia](https://en.wikipedia.org/wiki/Security-Enhanced_Linux)
2. [Red Hat: What Is SELinux?](https://www.redhat.com/en/topics/linux/what-is-selinux)
3. [ArchLinux: SELinux](https://wiki.archlinux.org/title/SELinux)
Root Profile của KernelSU cho phép tùy chỉnh ngữ cảnh SELinux của tiến trình gốc sau khi thực thi `su`. Các quy tắc kiểm soát truy cập cụ thể có thể được đặt cho bối cảnh này để cho phép kiểm soát chi tiết hơn các quyền .
Trong các trường hợp điển hình, khi một ứng dụng thực thi `su`, nó sẽ chuyển quy trình sang miền SELinux với **quyền truy cập không hạn chế**, chẳng hạn như `u:r:su:s0`. Thông qua Root Profile, miền này có thể được chuyển sang miền tùy chỉnh, chẳng hạn như `u:r:app1:s0` và một loạt quy tắc có thể được xác định cho miền này:
```sh
type app1
enforce app1
typeattribute app1 mlstrustedsubject
allow app1 * * *
```
Lưu ý rằng quy tắc `allow app1 * * *` chỉ được sử dụng cho mục đích minh họa. Trong thực tế, quy tắc này không nên được sử dụng rộng rãi vì nó không khác nhiều so với chế độ cho phép.
### Escalation
Nếu cấu hình của Root Profile không được đặt đúng cách, một tình huống escalation (leo thang) có thể xảy ra: các hạn chế do Root Profile áp đặt có thể vô tình bị lỗi.
Ví dụ: nếu bạn cấp quyền root cho người dùng shell ADB (đây là trường hợp phổ biến), sau đó bạn cấp quyền root cho một ứng dụng thông thường nhưng định cấu hình cấu hình gốc của nó bằng UID 2000 (là UID của người dùng shell ADB) , ứng dụng có thể có được quyền truy cập root đầy đủ bằng cách thực hiện lệnh `su` hai lần:
1. Lần thực thi `su` đầu tiên phải tuân theo sự thực thi của App Profile và sẽ chuyển sang UID `2000` (adb shell) thay vì `0` (root).
2. Lần thực thi `su` thứ hai, vì UID là `2000` và bạn đã cấp quyền truy cập root cho UID `2000` (adb shell) trong cấu hình, ứng dụng sẽ có toàn quyền root.
:::warning Ghi chú
Hành vi này hoàn toàn được mong đợi và không phải là lỗi. Vì vậy, chúng tôi khuyến nghị như sau:
Nếu bạn thực sự cần cấp quyền root cho ADB (ví dụ: với tư cách là nhà phát triển), bạn không nên thay đổi UID thành `2000` khi định cấu hình Root Profile. Sử dụng `1000` (hệ thống) sẽ là lựa chọn tốt hơn.
:::
## Non-Root Profile
### Umount Modules
KernelSU cung cấp một cơ chế systemless để sửa đổi các phân vùng hệ thống, đạt được thông qua việc gắn overlayfs. Tuy nhiên, một số ứng dụng có thể nhạy cảm với hành vi đó. Do đó, chúng ta có thể dỡ bỏ các mô-đun được gắn trên các ứng dụng này bằng cách đặt tùy chọn "umount modules".
Ngoài ra, giao diện cài đặt của trình quản lý KernelSU cung cấp một công tắc cho "umount modules by default". Theo mặc định, công tắc này được **bật**, có nghĩa là KernelSU hoặc một số mô-đun sẽ hủy tải các mô-đun cho ứng dụng này trừ khi áp dụng cài đặt bổ sung. Nếu bạn không thích cài đặt này hoặc nếu nó ảnh hưởng đến một số ứng dụng nhất định, bạn có các tùy chọn sau:
1. Giữ nút chuyển cho "umount modules by default" và tắt riêng tùy chọn "umount modules" trong App Profile đối với các ứng dụng yêu cầu tải mô-đun (hoạt động như "whitelist").
2. Tắt khóa chuyển cho "umount modules by default" và bật riêng tùy chọn "umount modules" trong App Profile cho các ứng dụng yêu cầu dỡ bỏ mô-đun (hoạt động như "blacklist").
:::info
Trong các thiết bị sử dụng kernel phiên bản 5.10 trở lên, kernel thực hiện việc dỡ tải các mô-đun. Tuy nhiên, đối với các thiết bị chạy phiên bản kernel dưới 5.10, công tắc này chỉ đơn thuần là một tùy chọn cấu hình và bản thân KernelSU không thực hiện bất kỳ hành động nào. Một số mô-đun, chẳng hạn như Zygisksu, có thể sử dụng công tắc này để xác định xem có cần thiết phải dỡ bỏ mô-đun hay không.
:::

View File

@@ -0,0 +1,28 @@
# Sự khác biệt với Magisk
Mặc dù có nhiều điểm tương đồng giữa mô-đun KernelSU và mô-đun Magisk nhưng chắc chắn vẫn có một số khác biệt do cơ chế triển khai hoàn toàn khác nhau của chúng. Nếu muốn mô-đun của mình chạy trên cả Magisk và KernelSU, bạn phải hiểu những khác biệt này.
## Điểm tương đồng
- Định dạng file mô-đun: đều sử dụng định dạng zip để sắp xếp các mô-đun và định dạng của các mô-đun gần như giống nhau
- Thư mục cài đặt mô-đun: cả hai đều nằm trong `/data/adb/modules`
- systemless: cả hai đều hỗ trợ sửa đổi /system theo cách không có hệ thống thông qua các mô-đun
- post-fs-data.sh: thời gian thực hiện và ngữ nghĩa hoàn toàn giống nhau
- service.sh: thời gian thực hiện và ngữ nghĩa hoàn toàn giống nhau
- system.prop: hoàn toàn giống nhau
- sepolicy.rule: hoàn toàn giống nhau
- BusyBox: các tập lệnh được chạy trong BusyBox với "standalone mode" được bật trong cả hai trường hợp
## Điểm khác biệt
Trước khi hiểu sự khác biệt, bạn cần biết cách phân biệt mô-đun của bạn đang chạy trong KernelSU hay Magisk. Bạn có thể sử dụng biến môi trường `KSU` để phân biệt nó ở tất cả những nơi bạn có thể chạy tập lệnh mô-đun (`customize.sh`, `post-fs-data.sh`, `service.sh`). Trong KernelSU, biến môi trường này sẽ được đặt thành `true`.
Dưới đây là một số khác biệt:
- Không thể cài đặt các mô-đun KernelSU ở chế độ Recovery.
- Các mô-đun KernelSU không có hỗ trợ tích hợp cho Zygisk (nhưng bạn có thể sử dụng các mô-đun Zygisk thông qua [ZygiskOnKernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU).
- Phương pháp thay thế hoặc xóa file trong module KernelSU hoàn toàn khác với Magisk. KernelSU không hỗ trợ phương thức `.replace`. Thay vào đó, bạn cần tạo một file cùng tên với `mknod filename c 0 0` để xóa file tương ứng.
- Các thư mục của BusyBox khác nhau. BusyBox tích hợp trong KernelSU nằm ở `/data/adb/ksu/bin/busybox`, trong khi ở Magisk nó nằm ở `/data/adb/magisk/busybox`. **Lưu ý rằng đây là hoạt động nội bộ của KernelSU và có thể thay đổi trong tương lai!**
- KernelSU không hỗ trợ file `.replace`; tuy nhiên, KernelSU hỗ trợ biến `REMOVE``REPLACE` để xóa hoặc thay thế các tệp và thư mục.
- KernelSU thêm giai đoạn `boot-completed` để chạy một số script khi khởi động xong.
- KernelSU thêm giai đoạn `post-mount` để chạy một số tập lệnh sau khi gắn overlayfs

View File

@@ -1,64 +1,67 @@
# FAQ - Câu hỏi thường gặp
# FAQ
## KernelSU có hỗ trợ thiết bị của tôi không?
Trước tiên, bạn nên mở khóa bootloader . Nếu bạn không thể thì nó sẽ không được hỗ trợ.
Đầu tiên, thiết bị của bạn sẽ có thể mở khóa bootloader. Nếu không thể thì nó không được hỗ trợ.
Nếu có thể thì cài đặt KernelSU Manager vào thiết bị của bạn và mở nó, nếu nó hiển thị `Unsupported` thì thiết bị của bạn không được hỗ trợ và sẽ có khả năng không được hỗ trợ trong tương lai.
Sau đó, cài đặt Ứng dụng KernelSU manager vào thiết bị của bạn và mở nó, nếu nó hiển thị `Unsupported` thì thiết bị của bạn chưa được hỗ trợ ngay, nhưng bạn có thể tạo nguồn kernel và tích hợp KernelSU để nó hoạt động hoặc sử dụng [unofficially-support-devices](unofficially-support-devices).
## KernelSU có cần mở khóa Bootloader không?
Chắc chắn có.
Chắc chắn có.
## KernelSU có hỗ trợ các modules không?
## KernelSU có hỗ trợ các mô-đun không?
Có, nhưng ở những phiên bản thử nghiệm này có thể có rất nhiều lỗi. Vậy nên tốt hơn hết là đợi nó ổn định đã :)
Có, nhưng đây là phiên bản đầu tiên nên có thể bị lỗi. Đợi nó ổn định nhé :)
## KernelSU có hỗ trợ Xposed không?
Có, [Dreamland](https://github.com/canyie/Dreamland) và [TaiChi](https://taichi.cool) hiện đã hoạt động được một phần nào đó. Với Lsposed, bạn có thể thử [Zygisk trên KernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU)
Có, [Dreamland](https://github.com/canyie/Dreamland) và [TaiChi](https://taichi.cool) hiện đã hoạt động. Đối với LSPosed, bạn có thể làm cho nó hoạt động bằng [Zygisk on KernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU)
## KernelSU có hỗ trợ Zygisk không?
KernelSU không có hỗ trợ Zygisk tích hợp sẵn nhưng thay vào đó, bạn có thể sử dụng [Zygisk on KernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU).
## KernelSU có tương thích với Magisk không?
Hệ thống module của KernelSU xung đột với magic mount của Magisk, nếu có bất kỳ module nào được bật trong KernelSU thì toàn bộ Magisk sẽ không thể hoạt động.
Hệ thống mô-đun của KernelSU xung đột với magic mount của Magisk, nếu có bất kỳ mô-đun nào được kích hoạt trong KernelSU thì toàn bộ Magisk sẽ không hoạt động.
Nhưng nếu bạn chỉ sử dụng `su` của KernelSU thì nó sẽ hoạt động tốt với Magisk: KernelSU sửa đổi `kernel` và Magisk sửa đổi `ramdisk`, chúng có thể hoạt động cùng nhau.
## KernelSU sẽ thay thế Magisk?
Chúng tôi không nghĩ như vậy và đó không phải là mục tiêu của chúng tôi. Magisk đã đủ tốt cho giải pháp userspace root và nó sẽ tồn tại lâu dài. Mục tiêu của KernelSU là cung cấp giao diện kernel cho người dùng chứ không phải để thay thế Magisk.
Chúng tôi không nghĩ như vậy và đó không phải là mục tiêu của chúng tôi. Magisk đủ tốt cho giải pháp root userspace và nó sẽ tồn tại lâu dài. Mục tiêu của KernelSU là cung cấp giao diện kernel cho người dùng chứ không thay thế Magisk.
## KernelSU có thể hỗ trợ các thiết bị không sử dụng GKI không?
## KernelSU có thể hỗ trợ các thiết bị không phải GKI không?
Điều đó là có thể. Nhưng bạn nên tải xuống mã nguồn kernel và tích hợp KernelSU vào source rồi tự compile.
Điều đó là có thể. Nhưng bạn nên tải nguồn kernel về và tích hợp KernelSU vào source tree rồi tự biên dịch kernel.
## KernelSU có thể hỗ trợ các thiết bị chạy Android 12 trở xuống không?
## KernelSU có thể hỗ trợ các thiết bị dưới Android 12 không?
Kernel của thiết bị ảnh hưởng đến khả năng tương thích của KernelSU và nó sẽ không liên quan gì đến phiên bản Android. Hạn chế duy nhất là các thiết bị chạy Android 12 phải là nhân 5.10 trở lên (thiết bị dùng GKI). Vì thế:
Chính kernel của thiết bị ảnh hưởng đến khả năng tương thích của KernelSU và nó không liên quan gì đến phiên bản Android. Hạn chế duy nhất là các thiết bị chạy Android 12 phải là kernel 5.10+(thiết bị GKI). Vì thế:
1. Các thiết bị chạy Android 12 phải được hỗ trợ.
2. Các thiết bị có kernel cũ (Một số thiết bị Android 12 cũng là kernel cũ) có thể tương thích (Bạn nên tự xây dựng kernel)
2. Các thiết bị có kernel cũ (Một số thiết bị Android 12 cũng là kernel cũ) tương thích (Bạn nên tự build kernel)
## KernelSU có thể hỗ trợ kernel cũ không?
Có thể, KernelSU hiện đã được backport xuống kernel 4.14, đối với kernel cũ hơn, bạn cần backport một cách thủ công và các Pull-Requests luôn được hoan nghênh!
Có thể, KernelSU hiện đã được backport sang kernel 4.14, đối với kernel cũ hơn, bạn cần backport một cách cẩn thận và PR rất đáng hoan nghênh!
## Làm cách nào để tích hợp KernelSU cho kernel cũ?
Vui lòng tham khảo [hướng dẫn này](how-to-integrate-for-non-gki)
Vui lòng tham khảo [hướng dẫn](how-to-integrate-for-non-gki)
## Tại sao tôi đang chạy Android 13 nhưng kernel lại ghi "android12-5.10" ?
## Tại sao phiên bản Android của tôi là 13 và kernel hiển thị "android12-5.10"?
Phiên bản kernel hoàn toàn không liên quan gì đến phiên bản Android, nếu bạn muốn flash kernel thì hãy luôn để ý đến **phiên bản kernel**, phiên bản Android ở phần đầu (VD : android12-\*) thường không quan trọng lắm.
Phiên bản Kernel không liên quan gì đến phiên bản Android, nếu bạn cần flash kernel thì dùng luôn phiên bản kernel, phiên bản Android không quá quan trọng.
## Đã có mount namespace --mount-master/global trên KernelSU chưa?
Hiện tại chưa có (hoặc có thể sẽ có trong tương li), nhưng bạn có thể dùng `nsenter -t 1 -m sh` để vào global mount namespace.
Hiện tại thì không (có thể có trong tương lai), nhưng có nhiều cách để chuyển sang global mount namespace một cách thủ công, chẳng hạn như:
## KernelSU có hỗ trợ Zygisk không ?
1. `nsenter -t 1 -m sh` để lấy shell trong global mount namespace.
2. Thêm `nsenter --mount=/proc/1/ns/mnt` vào lệnh bạn muốn thực thi, sau đó lệnh được thực thi trong global mount namespace. KernelSU cũng [sử dụng cách này](https://github.com/tiann/KernelSU/blob/77056a710073d7a5f7ee38f9e77c9fd0b3256576/manager/app/src/main/java/me/weishu/kernelsu/ui/util/KsuCli.kt#L115)
KernelSU không có Zygisk bên trong, nhưng bạn có thể dùng [Zygisk trên KernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU)
## Tôi là GKI1.0, tôi có thể sử dụng cái này không?
## Tôi đang ở GKI 1.0, tôi dùng được cái này chứ ?
GKI1 khác hoàn toàn với GKI2 nên bạn sẽ phải tự compile kernel cho mình.
GKI1 khác hoàn toàn với GKI2, bạn phải tự biên dịch kernel.

View File

@@ -0,0 +1,7 @@
# Tính Năng Ẩn
## .ksurc
Theo mặc định, `/system/bin/sh` tải `/system/etc/mkshrc`.
Bạn có thể tạo su tải tệp rc tùy chỉnh bằng cách tạo tệp `/data/adb/ksu/.ksurc`.

View File

@@ -1,15 +1,17 @@
# Làm cách nào để build KernelSU ?
# Làm thế nào để xây dựng KernelSU?
Trước tiên, bạn nên đọc tài liệu Chính thức của Android để xây dựng kernel:
Trước tiên, bạn nên đọc tài liệu chính thức của Android để xây dựng kernel:
1. [Building Kernels](https://source.android.com/docs/setup/build/building-kernels)
2. [GKI Release Builds](https://source.android.com/docs/core/architecture/kernel/gki-release-builds)
1. [Building Kernels](https://source.android.com/docs/setup/build/building-kernels?hl=vi)
2. [GKI Release Builds](https://source.android.com/docs/core/architecture/kernel/gki-release-builds?hl=vi)
> Trang này dành cho thiết bị GKI, nếu bạn dùng kernel cũ, vui lòng tham khảo [Làm thế nào để tích hợp KernelSU vào thiết bị không sử dụng GKI ?](how-to-integrate-for-non-gki)
::: warning
Trang này dành cho thiết bị GKI, nếu bạn sử dụng kernel cũ, vui lòng tham khảo [cách tích hợp KernelSU cho kernel cũ](how-to-integrate-for-non-gki)
:::
## Build Kernel
### Đồng bộ mã nguồn
### Đồng bộ hóa mã nguồn kernel
```sh
repo init -u https://android.googlesource.com/kernel/manifest
@@ -18,21 +20,19 @@ repo init -m manifest.xml
repo sync
```
The `<kernel_manifest.xml>` is a manifest file which can determine a build uniquely, you can use the manifest to do a re-preducable build. You should download the manifest file from [Google GKI release builds](https://source.android.com/docs/core/architecture/kernel/gki-release-builds)
`<kernel_manifest.xml>` là một tệp kê khai có thể xác định duy nhất một bản dựng, bạn có thể sử dụng tệp kê khai để thực hiện một bản dựng có thể tái sản xuất. Bạn nên tải xuống tệp kê khai từ [Google GKI release builds](https://source.android.com/docs/core/architecture/kernel/gki-release-builds)
`<kernel_manifest.xml>` là một tệp kê khai có thể xác định duy nhất một bản dựng, bạn có thể sử dụng tệp kê khai đó để thực hiện một bản dựng có thể dự đoán lại. Bạn nên tải xuống tệp kê khai từ [Google GKI release builds](https://source.android.com/docs/core/architecture/kernel/gki-release-builds?hl=vi)
### Build
Vui lòng kiểm tra [tài liệu chính thức](https://source.android.com/docs/setup/build/building-kernels) trước.
Trước tiên, vui lòng kiểm tra [tài liệu chính thức](https://source.android.com/docs/setup/build/building-kernels?hl=vi).
Ví dụ: Đầu tiên chúng ta cần build một image cho aarch64:
Ví dụ: chúng ta cần xây dựng kernel image aarch64:
```sh
LTO=thin BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
```
Đừng quên thêm `LTO=thin`, nếu không quá trình xây dựng có thể thất bại trong trường hợp bộ nhớ máy tính của bạn nhỏ hơn 24Gb.
Đừng quên thêm cờ `LTO=thin`, nếu không quá trình xây dựng có thể thất bại nếu bộ nhớ máy tính của bạn nhỏ hơn 24Gb.
Bắt đầu từ Android 13, kernel được xây dựng bởi `bazel`:
@@ -40,26 +40,26 @@ Bắt đầu từ Android 13, kernel được xây dựng bởi `bazel`:
tools/bazel build --config=fast //common:kernel_aarch64_dist
```
## Build kernel cùng với KernelSU
## Build Kernel với KernelSU
Nếu bạn có thể build được kernel hoàn chỉnh, thì việc tích hợp KernelSU rất dễ dàng, chạy lệnh sau tại thư mục chứa mã nguồn kernel:
Nếu bạn có thể build kernel thành công thì việc xây dựng KernelSU thật dễ dàng, Chọn bất kỳ một lần chạy trong thư mục gốc nguồn Kernel:
- Latest tag(stable)
- Thẻ mới nhất (ổn định)
```sh
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -
```
- main branch(dev)
- nhánh chính (dev)
```sh
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s main
```
- Select tag(Such as v0.5.2)
- Chọn thẻ (chẳng hạn như v0.5.2)
```sh
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s v0.5.2
```
rồi build lại, bạn sẽ có được một image chứa KernelSU
sau đó build lại kernel và bạn sẽ có được image kernel với KernelSU!

View File

@@ -18,19 +18,19 @@ KernelSU sử dụng kprobe để thực hiện hook kernel, nếu *kprobe* ch
Đầu tiên, thêm KernelSU vào mã nguồn kernel của bạn:
- Latest tag(stable)
- Thẻ mới nhất (ổn định)
```sh
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -
```
- main branch(dev)
- Nhánh chính (dev)
```sh
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s main
```
- Select tag(Such as v0.5.2)
- Chọn thẻ (chẳng hạn như v0.5.2)
```sh
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s v0.5.2

View File

@@ -1,32 +1,171 @@
# Cách cài đặt
## Kiểm tra xem thiết bị có hỗ trợ không
## Kiểm tra xem thiết bị của bạn có được hỗ trợ không
Tải KernelSU Manager từ [trang Releases trên Github](https://github.com/tiann/KernelSU/releases) hoặc [Github Actions](https://github.com/tiann/KernelSU/actions/workflows/build-manager.yml)
Tải xuống APP KernelSU manager từ [GitHub Releases](https://github.com/tiann/KernelSU/releases) hoặc [Coolapk market](https://www.coolapk.com/apk/me.weishu.kernelsu) và cài đặt nó vào thiết bị của bạn:
- Nếu ứng dụng hiện `Unsupported`, nghĩa là **Bạn phải tự compile kernel**, KernelSU sẽ không và không bao giờ cung cấp cho bạn một boot image dành riêng cho bạn để flash.
- Nếu ứng dụng hiện `Not installed`, thì thiết bị của bạn đã chính thức hỗ trợ bởi KernelSU.
- Nếu ứng dụng hiển thị `Unsupported`, nghĩa là **Bạn nên tự biên dịch kernel**, KernelSU sẽ không và không bao giờ cung cấp boot image để bạn flash.
- Nếu ứng dụng hiển thị `Not installed` thì thiết bị của bạn đã được KernelSU hỗ trợ chính thức.
## Tìm một boot.img
:::info
Đối với các thiết bị hiển thị `Unsupported`, đây là [Thiết-bị-hỗ-trợ-không-chính-thức](unofficially-support-devices.md), bạn có thể tự biên dịch kernel.
:::
KernelSU cung cấp một boot.img chung cho các thiết bị GKI, bạn nên flash boot.img này vào trong phân vùng boot của bạn.
## Sao lưu stock boot.img
Bạn có thể tải boot.img từ [Github Actions cho Kernel](https://github.com/tiann/KernelSU/actions/workflows/build-kernel.yml), lưu ý là hãy dùng đúng phiên bản boot.img. Ví dụ, nếu phiên bản kernel bạn dùng là `5.10.101`, thì bạn nên sử dụng `5.10.101-xxxx.boot.xxxx`.
Trước khi flash, trước tiên bạn phải sao lưu stock boot.img. Nếu bạn gặp phải bootloop (vòng lặp khởi động), bạn luôn có thể khôi phục hệ thống bằng cách quay lại trạng thái khởi động ban đầu bằng fastboot.
Và tiện thể hãy kiểm tra định dạng gốc của boot.img trong máy bạn, bạn nên sử dụng đúng định dạng như là `lz4` hoặc `gz`.
::: warning
Việc flash có thể gây mất dữ liệu, hãy đảm bảo thực hiện tốt bước này trước khi chuyển sang bước tiếp theo!! Bạn cũng có thể sao lưu tất cả dữ liệu trên điện thoại nếu cần.
:::
## Flash boot.img này vào thiết bị
## Kiến thức cần thiết
Kết nối thiết bị với `adb` và chạy `adb reboot bootloader` để vào chế độ fastboot, và rồi dùng câu lệnh này để flash KernelSU:
### ADB và fastboot
Theo mặc định, bạn sẽ sử dụng các công cụ ADB và fastboot trong hướng dẫn này, vì vậy nếu bạn không biết về chúng, chúng tôi khuyên bạn nên sử dụng công cụ tìm kiếm để tìm hiểu về chúng trước tiên.
### KMI
Kernel Module Interface (KMI), các phiên bản kernel có cùng KMI đều **tương thích** Đây là ý nghĩa của "general" trong GKI; ngược lại, nếu KMI khác thì các kernel này không tương thích với nhau và việc flash kernel image có KMI khác với thiết bị của bạn có thể gây ra bootloop.
Cụ thể, đối với thiết bị GKI, định dạng phiên bản kernel phải như sau:
```txt
KernelRelease :=
Version.PatchLevel.SubLevel-AndroidRelease-KmiGeneration-suffix
w .x .y -zzz -k -something
```
`w.x-zzz-k` là phiên bản KMI. Ví dụ: nếu phiên bản kernel của thiết bị là `5.10.101-android12-9-g30979850fc20`, thì KMI của nó là `5.10-android12-9`; về mặt lý thuyết, nó có thể khởi động bình thường với các kernel KMI khác.
::: tip
Lưu ý rằng SubLevel trong phiên bản kernel không phải là một phần của KMI! Điều đó có nghĩa là `5.10.101-android12-9-g30979850fc20` có cùng KMI với `5.10.137-android12-9-g30979850fc20`!
:::
### Phiên bản kernel vs Phiên bản Android
Xin lưu ý: **Phiên bản kernel và phiên bản Android không nhất thiết phải giống nhau!**
Nếu bạn nhận thấy phiên bản kernel của mình là `android12-5.10.101` nhưng phiên bản hệ thống Android của bạn là Android 13 hoặc phiên bản khác; xin đừng ngạc nhiên, vì số phiên bản của hệ thống Android không nhất thiết phải giống với số phiên bản của kernel Linux; Số phiên bản của kernel Linux nhìn chung nhất quán với phiên bản của hệ thống Android đi kèm với **thiết bị khi nó được xuất xưởng**. Nếu hệ thống Android được nâng cấp sau này, phiên bản kernel thường sẽ không thay đổi. Nếu bạn cần flash, **vui lòng tham khảo phiên bản kernel!!**
## Giới thiệu
Có một số phương pháp cài đặt KernelSU, mỗi phương pháp phù hợp với một kịch bản khác nhau, vì vậy vui lòng chọn khi cần.
1. Cài đặt với Recovery tùy chỉnh (ví dụ TWRP)
2. Cài đặt bằng ứng dụng flash kernel, chẳng hạn như Franco Kernel Manager
3. Cài đặt thông qua fastboot bằng boot.img do KernelSU cung cấp
4. Sửa boot.img theo cách thủ công và cài đặt nó
## Cài đặt với Recovery tùy chỉnh
Điều kiện chắc chắn: Thiết bị của bạn phải có Recovery tùy chỉnh, chẳng hạn như TWRP; nếu không hoặc chỉ có Recovery chính thức, hãy sử dụng phương pháp khác.
Các bước:
1. Từ [Release page](https://github.com/tiann/KernelSU/releases) của KernelSU, tải xuống gói zip bắt đầu bằng AnyKernel3 phù hợp với phiên bản điện thoại của bạn; ví dụ: phiên bản kernel của điện thoại là `android12-5.10. 66`, thì bạn nên tải xuống tệp `AnyKernel3-android12-5.10.66_yyyy-MM.zip` (trong đó `yyyy` là năm và `MM` là tháng).
2. Khởi động lại điện thoại vào TWRP.
3. Sử dụng adb để đặt AnyKernel3-*.zip vào điện thoại /sdcard và chọn cài đặt nó trong GUI TWRP; hoặc bạn có thể trực tiếp `adb sideload AnyKernel-*.zip` để cài đặt.
PS. Phương pháp này phù hợp với mọi cài đặt (không giới hạn cài đặt ban đầu hoặc các nâng cấp tiếp theo), miễn là bạn sử dụng TWRP.
## Cài đặt bằng Kernel Flasher
Điều kiện chắc chắn: Thiết bị của bạn phải được root. Ví dụ: bạn đã cài đặt Magisk để root hoặc bạn đã cài đặt phiên bản KernelSU cũ và cần nâng cấp lên phiên bản KernelSU khác; nếu thiết bị của bạn chưa được root, vui lòng thử các phương pháp khác.
Các bước:
1. Tải xuống zip AnyKernel3; hãy tham khảo phần *Cài đặt bằng Custom Recovery* để biết hướng dẫn tải xuống.
2. Mở Ứng dụng Kernel Flash và sử dụng zip AnyKernel3 được cung cấp để flash.
Nếu trước đây bạn chưa từng sử dụng Ứng dụng Kernel flash thì sau đây là những ứng dụng phổ biến hơn.
1. [Kernel Flasher](https://github.com/capntrips/KernelFlasher/releases)
2. [Franco Kernel Manager](https://play.google.com/store/apps/details?id=com.franco.kernel)
3. [Ex Kernel Manager](https://play.google.com/store/apps/details?id=flar2.exkernelmanager)
PS. Phương pháp này thuận tiện hơn khi nâng cấp KernelSU và có thể thực hiện mà không cần máy tính (sao lưu trước!). .
Các bước:
## Cài đặt bằng boot.img do KernelSU cung cấp
Phương pháp này không yêu cầu bạn phải có TWRP, cũng như không yêu cầu điện thoại của bạn phải có quyền root; nó phù hợp cho lần cài đặt KernelSU đầu tiên của bạn.
### Tìm boot.img thích hợp
KernelSU cung cấp boot.img chung cho các thiết bị GKI và bạn nên chuyển boot.img vào phân vùng boot của thiết bị.
Bạn có thể tải xuống boot.img từ [GitHub Release](https://github.com/tiann/KernelSU/releases), xin lưu ý rằng bạn nên sử dụng đúng phiên bản boot.img. Ví dụ: nếu thiết bị của bạn hiển thị kernel `android12-5.10.101` , bạn cần tải xuống `android-5.10.101_yyyy-MM.boot-<format>.img`. (Giữ KMI nhất quán!)
Trong đó `<format>` đề cập đến định dạng nén kernel của boot.img chính thức của bạn, vui lòng kiểm tra định dạng nén kernel của boot.img ban đầu của bạn, bạn nên sử dụng đúng định dạng, ví dụ: `lz4`, `gz`; nếu bạn sử dụng định dạng nén không chính xác, bạn có thể gặp phải bootloop.
::: info
1. Bạn có thể sử dụng magiskboot để lấy định dạng nén của boot ban đầu; Tất nhiên, bạn cũng có thể hỏi những người khác, có kinh nghiệm hơn có cùng kiểu máy với thiết bị của bạn. Ngoài ra, định dạng nén của kernel thường không thay đổi nên nếu bạn khởi động thành công với một định dạng nén nào đó thì bạn có thể thử định dạng đó sau.
2. Các thiết bị Xiaomi thường sử dụng `gz` hoặc **uncompressed** (không nén).
3. Đối với thiết bị Pixel, hãy làm theo hướng dẫn bên dưới.
:::
### flash boot.img vào thiết bị
Sử dụng `adb` để kết nối thiết bị của bạn, sau đó thực thi `adb restart bootloader` để vào chế độ fastboot, sau đó sử dụng lệnh này để flash KernelSU:
```sh
fastboot flash boot boot.img
```
## Khởi động lại
::: info
Nếu thiết bị của bạn hỗ trợ `fastboot boot`, trước tiên bạn có thể sử dụng `fastboot boot boot.img` để thử sử dụng boot.img để khởi động hệ thống trước. Nếu có điều gì bất ngờ xảy ra, hãy khởi động lại để boot.
:::
Khi flash xong, hãy khởi động lại thiết bị :
### khởi động lại
Sau khi flash xong bạn nên khởi động lại máy:
```sh
fastboot reboot
```
## Vá boot.img theo cách thủ công
Đối với một số thiết bị, định dạng boot.img không quá phổ biến, chẳng hạn như không `lz4`, `gz` và không nén; điển hình nhất là Pixel, định dạng boot.img của nó là nén `lz4_legacy`, ramdisk có thể là `gz` cũng có thể là nén `lz4_legacy`; tại thời điểm này, nếu bạn trực tiếp flash boot.img do KernelSU cung cấp, điện thoại có thể không khởi động được; Tại thời điểm này, bạn có thể vá boot.img theo cách thủ công để dùng được.
Nhìn chung có hai phương pháp vá:
1. [Android-Image-Kitchen](https://forum.xda-developers.com/t/tool-android-image-kitchen-unpack-repack-kernel-ramdisk-win-android-linux-mac.2073775/)
2. [magiskboot](https://github.com/topjohnwu/Magisk/releases)
Trong số đó, Android-Image-Kitchen phù hợp để hoạt động trên PC và magiskboot cần sự kết nối của điện thoại di động.
### Chuẩn bị
1. Lấy stock boot.img của điện thoại; bạn có thể lấy nó từ nhà sản xuất thiết bị của mình, bạn có thể cần [payload-dumper-go](https://github.com/ssut/payload-dumper-go)
2. Tải xuống tệp zip AnyKernel3 do KernelSU cung cấp phù hợp với phiên bản KMI của thiết bị của bạn (bạn có thể tham khảo *Cài đặt với Khôi phục tùy chỉnh*).
3. Giải nén gói AnyKernel3 và lấy tệp `Image`, đây là tệp kernel của KernelSU.
### Sử dụng Android-Image-Kitchen
1. Tải Android-Image-Kitchen về máy tính.
2. Đặt stock boot.img vào thư mục gốc của Android-Image-Kitchen.
3. Thực thi `./unpackimg.sh boot.img` tại thư mục gốc của Android-Image-Kitchen, lệnh này sẽ giải nén boot.img và bạn sẽ nhận được một số tệp.
4. Thay thế `boot.img-kernel` trong thư mục `split_img` bằng `Image` bạn đã trích xuất từ AnyKernel3 (lưu ý đổi tên thành boot.img-kernel).
5. Thực thi `./repackimg.sh` tại thư mục gốc của 在 Android-Image-Kitchen; Và bạn sẽ nhận được một file có tên `image-new.img`; Flash boot.img này bằng fastboot(Tham khảo phần trước).
### Sử dụng magiskboot
1. Tải xuống Magisk mới nhất từ [Trang phát hành](https://github.com/topjohnwu/Magisk/releases)
2. Đổi tên Magisk-*.apk thành Magisk-vesion.zip và giải nén nó.
3. Đẩy `Magisk-v25.2/lib/arm64-v8a/libmagiskboot.so` vào thiết bị của bạn bằng adb: `adb push Magisk-v25.2/lib/arm64-v8a/libmagiskboot.so /data/local/tmp /magiskboot`
4. Đẩy stock boot.img và Image trong AnyKernel3 vào thiết bị của bạn.
5. Nhập thư mục adb shell và cd `/data/local/tmp/`, sau đó `chmod +x magiskboot`
6. Nhập adb shell và cd `/data/local/tmp/`, thực thi `./magiskboot unpack boot.img` để giải nén `boot.img`, bạn sẽ nhận được file `kernel`, đây là kernel gốc của bạn.
7. Thay thế `kernel` bằng `Image`: `mv -f Image kernel`
8. Thực thi `./magiskboot repack boot.img` để đóng gói lại boot img và bạn sẽ nhận được một tệp `new-boot.img`, flash tệp này vào thiết bị bằng fastboot.
## Các phương pháp khác
Trên thực tế, tất cả các phương pháp cài đặt này chỉ có một ý tưởng chính, đó là **thay thế kernel gốc bằng kernel do KernelSU cung cấp**; chỉ cần đạt được điều này là có thể cài đặt được; ví dụ, sau đây là các phương pháp có thể khác.
1. Trước tiên hãy cài đặt Magisk, nhận quyền root thông qua Magisk, sau đó sử dụng flasher kernel để flash trong zip AnyKernel từ KernelSU.
2. Sử dụng một số bộ công cụ flash trên PC để flash trong kernel do KernelSU cung cấp.

View File

@@ -0,0 +1,257 @@
# Hướng dẫn mô-đun
KernelSU cung cấp một cơ chế mô-đun giúp đạt được hiệu quả sửa đổi thư mục hệ thống trong khi vẫn duy trì tính toàn vẹn của phân vùng system. Cơ chế này thường được gọi là "systemless".
Cơ chế mô-đun của KernelSU gần giống với Magisk. Nếu bạn đã quen với việc phát triển mô-đun Magisk thì việc phát triển các mô-đun KernelSU cũng rất tương tự. Bạn có thể bỏ qua phần giới thiệu các mô-đun bên dưới và chỉ cần đọc [difference-with-magisk](difference-with-magisk.md).
## Busybox
KernelSU cung cấp tính năng nhị phân BusyBox hoàn chỉnh (bao gồm hỗ trợ SELinux đầy đủ). Tệp thực thi được đặt tại `/data/adb/ksu/bin/busybox`. BusyBox của KernelSU hỗ trợ "ASH Standalone Shell Mode" có thể chuyển đổi thời gian chạy. Standalone mode này có nghĩa là khi chạy trong shell `ash` của BusyBox, mọi lệnh sẽ trực tiếp sử dụng applet trong BusyBox, bất kể cái gì được đặt là `PATH`. Ví dụ: các lệnh như `ls`, `rm`, `chmod` sẽ **KHÔNG** sử dụng những gì có trong `PATH` (trong trường hợp Android theo mặc định, nó sẽ là `/system/bin/ls`, ` /system/bin/rm``/system/bin/chmod` tương ứng), nhưng thay vào đó sẽ gọi trực tiếp các ứng dụng BusyBox nội bộ. Điều này đảm bảo rằng các tập lệnh luôn chạy trong môi trường có thể dự đoán được và luôn có bộ lệnh đầy đủ cho dù nó đang chạy trên phiên bản Android nào. Để buộc lệnh _not_ sử dụng BusyBox, bạn phải gọi tệp thực thi có đường dẫn đầy đủ.
Mỗi tập lệnh shell đơn lẻ chạy trong ngữ cảnh của KernelSU sẽ được thực thi trong shell `ash` của BusyBox với standalone mode được bật. Đối với những gì liên quan đến nhà phát triển bên thứ 3, điều này bao gồm tất cả các tập lệnh khởi động và tập lệnh cài đặt mô-đun.
Đối với những người muốn sử dụng tính năng "Standalone mode" này bên ngoài KernelSU, có 2 cách để kích hoạt tính năng này:
1. Đặt biến môi trường `ASH_STANDALONE` thành `1`<br>Ví dụ: `ASH_STANDALONE=1 /data/adb/ksu/bin/busybox sh <script>`
2. Chuyển đổi bằng các tùy chọn dòng lệnh:<br>`/data/adb/ksu/bin/busybox sh -o độc lập <script>`
Để đảm bảo tất cả shell `sh` tiếp theo được thực thi cũng chạy ở standalone mode, tùy chọn 1 là phương thức ưu tiên (và đây là những gì KernelSU và KernelSU manager sử dụng nội bộ) vì các biến môi trường được kế thừa xuống các tiến trình con.
::: tip sự khác biệt với Magisk
BusyBox của KernelSU hiện đang sử dụng tệp nhị phân được biên dịch trực tiếp từ dự án Magisk. **Cảm ơn Magisk!** Vì vậy, bạn không phải lo lắng về vấn đề tương thích giữa các tập lệnh BusyBox trong Magisk và KernelSU vì chúng hoàn toàn giống nhau!
:::
## Mô-đun hạt nhânSU
Mô-đun KernelSU là một thư mục được đặt trong `/data/adb/modules` với cấu trúc bên dưới:
```txt
/data/adb/modules
├── .
├── .
|
├── $MODID <--- Thư mục được đặt tên bằng ID của mô-đun
│ │
│ │ *** Nhận Dạng Mô-đun ***
│ │
│ ├── module.prop <--- Tệp này lưu trữ metadata của mô-đun
│ │
│ │ *** Nội Dung Chính ***
│ │
│ ├── system <--- Thư mục này sẽ được gắn kết nếu skip_mount không tồn tại
│ │ ├── ...
│ │ ├── ...
│ │ └── ...
│ │
│ │ *** Cờ Trạng Thái ***
│ │
│ ├── skip_mount <--- Nếu tồn tại, KernelSU sẽ KHÔNG gắn kết thư mục hệ thống của bạn
│ ├── disable <--- Nếu tồn tại, mô-đun sẽ bị vô hiệu hóa
│ ├── remove <--- Nếu tồn tại, mô-đun sẽ bị xóa trong lần khởi động lại tiếp theo
│ │
│ │ *** Tệp Tùy Chọn ***
│ │
│ ├── post-fs-data.sh <--- Tập lệnh này sẽ được thực thi trong post-fs-data
│ ├── post-mount.sh <--- Tập lệnh này sẽ được thực thi trong post-mount
│ ├── service.sh <--- Tập lệnh này sẽ được thực thi trong dịch vụ late_start
│ ├── boot-completed.sh <--- Tập lệnh này sẽ được thực thi khi khởi động xong
| ├── uninstall.sh <--- Tập lệnh này sẽ được thực thi khi KernelSU xóa mô-đun của bạn
│ ├── system.prop <--- Các thuộc tính trong tệp này sẽ được tải dưới dạng thuộc tính hệ thống bằng resetprop
│ ├── sepolicy.rule <--- Quy tắc riêng biệt tùy chỉnh bổ sung
│ │
│ │ *** Được Tạo Tự Động, KHÔNG TẠO HOẶC SỬA ĐỔI THỦ CÔNG ***
│ │
│ ├── vendor <--- Một liên kết tượng trưng đến $MODID/system/vendor
│ ├── product <--- Một liên kết tượng trưng đến $MODID/system/product
│ ├── system_ext <--- Một liên kết tượng trưng đến $MODID/system/system_ext
│ │
│ │ *** Mọi tập tin / thư mục bổ sung đều được phép ***
│ │
│ ├── ...
│ └── ...
|
├── another_module
│ ├── .
│ └── .
├── .
├── .
```
::: tip sự khác biệt với Magisk
KernelSU không có hỗ trợ tích hợp cho Zygisk nên không có nội dung liên quan đến Zygisk trong mô-đun. Tuy nhiên, bạn có thể sử dụng [ZygiskOnKernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU) để hỗ trợ các mô-đun Zygisk. Trong trường hợp này, nội dung của mô-đun Zygisk giống hệt với nội dung được Magisk hỗ trợ.
:::
### module.prop
module.prop là tệp cấu hình cho mô-đun. Trong KernelSU, nếu một mô-đun không chứa tệp này, nó sẽ không được nhận dạng là mô-đun. Định dạng của tập tin này như sau:
```txt
id=<string>
name=<string>
version=<string>
versionCode=<int>
author=<string>
description=<string>
```
- `id` phải khớp với biểu thức chính quy này: `^[a-zA-Z][a-zA-Z0-9._-]+$`<br>
ví dụ: ✓ `a_module`, ✓ `a.module`, ✓ `module-101`, ✗ `a module`, ✗ `1_module`, ✗ `-a-module`<br>
Đây là **mã định danh duy nhất** của mô-đun của bạn. Bạn không nên thay đổi nó sau khi được xuất bản.
- `versionCode` phải là **số nguyên**. Điều này được sử dụng để so sánh các phiên bản
- Các chuỗi khác không được đề cập ở trên có thể là chuỗi **một dòng** bất kỳ.
- Đảm bảo sử dụng kiểu ngắt dòng `UNIX (LF)` chứ không phải `Windows (CR+LF)` hoặc `Macintosh (CR)`.
### Tập lệnh Shell
Vui lòng đọc phần [Boot Scripts](#boot-scripts) để hiểu sự khác biệt giữa `post-fs-data.sh``service.sh`. Đối với hầu hết các nhà phát triển mô-đun, `service.sh` sẽ đủ tốt nếu bạn chỉ cần chạy tập lệnh khởi động, nếu bạn cần chạy tập lệnh sau khi khởi động xong, vui lòng sử dụng `boot-completed.sh`. Nếu bạn muốn làm gì đó sau khi gắn các lớp phủ, vui lòng sử dụng `post-mount.sh`.
Trong tất cả các tập lệnh của mô-đun của bạn, vui lòng sử dụng `MODDIR=${0%/*}` để lấy đường dẫn thư mục cơ sở của mô-đun của bạn; **KHÔNG** mã hóa cứng đường dẫn mô-đun của bạn trong tập lệnh.
::: tip sự khác biệt với Magisk
Bạn có thể sử dụng biến môi trường KSU để xác định xem tập lệnh đang chạy trong KernelSU hay Magisk. Nếu chạy trong KernelSU, giá trị này sẽ được đặt thành true.
:::
### thư mục `system`
Nội dung của thư mục này sẽ được phủ lên trên phân vùng /system của hệ thống bằng cách sử dụng overlayfs sau khi hệ thống được khởi động. Điều này có nghĩa rằng:
1. Các file có cùng tên với các file trong thư mục tương ứng trong hệ thống sẽ bị ghi đè bởi các file trong thư mục này.
2. Các thư mục có cùng tên với thư mục tương ứng trong hệ thống sẽ được gộp với các thư mục trong thư mục này.
Nếu bạn muốn xóa một tập tin hoặc thư mục trong thư mục hệ thống gốc, bạn cần tạo một tập tin có cùng tên với tập tin/thư mục trong thư mục mô-đun bằng cách sử dụng `mknod filename c 0 0`. Bằng cách này, hệ thống lớp phủ sẽ tự động "whiteout" (Xóa trắng) tệp này như thể nó đã bị xóa (phân vùng /system không thực sự bị thay đổi).
Bạn cũng có thể khai báo một biến có tên `REMOVE` chứa danh sách các thư mục trong `customize.sh` để thực hiện các thao tác xóa và KernelSU sẽ tự động thực thi `mknod <TARGET> c 0 0` trong các thư mục tương ứng của mô-đun. Ví dụ:
```sh
REMOVE="
/system/app/YouTube
/system/app/Bloatware
"
```
Danh sách trên sẽ thực thi `mknod $MODPATH/system/app/YouTuBe c 0 0``mknod $MODPATH/system/app/Bloatware c 0 0`; và `/system/app/YouTube``/system/app/Bloatware` sẽ bị xóa sau khi mô-đun này có hiệu lực.
Nếu bạn muốn thay thế một thư mục trong hệ thống, bạn cần tạo một thư mục có cùng đường dẫn trong thư mục mô-đun của mình, sau đó đặt thuộc tính `setfattr -ntrust.overlay.opaque -v y <TARGET>` cho thư mục này. Bằng cách này, hệ thống Overlayfs sẽ tự động thay thế thư mục tương ứng trong hệ thống (mà không thay đổi phân vùng /system).
Bạn có thể khai báo một biến có tên `REPLACE` trong tệp `customize.sh` của mình, bao gồm danh sách các thư mục sẽ được thay thế và KernelSU sẽ tự động thực hiện các thao tác tương ứng trong thư mục mô-đun của bạn. Ví dụ:
REPLACE="
/system/app/YouTube
/system/app/Bloatware
"
Danh sách này sẽ tự động tạo các thư mục `$MODPATH/system/app/YouTube``$MODPATH/system/app/Bloatware`, sau đó thực thi `setfattr -ntrusted.overlay.opaque -v y $MODPATH/system/app/ YouTube``setfattr -n Trust.overlay.opaque -v y $MODPATH/system/app/Bloatware`. Sau khi mô-đun có hiệu lực, `/system/app/YouTube``/system/app/Bloatware` sẽ được thay thế bằng các thư mục trống.
::: tip sự khác biệt với Magisk
Cơ chế không hệ thống của KernelSU được triển khai thông qua các overlayfs của kernel, trong khi Magisk hiện sử dụng magic mount (bind mount). Hai phương pháp triển khai có những khác biệt đáng kể, nhưng mục tiêu cuối cùng đều giống nhau: sửa đổi các tệp /system mà không sửa đổi vật lý phân vùng /system.
:::
Nếu bạn quan tâm đến overlayfs, bạn nên đọc [documentation on overlayfs](https://docs.kernel.org/filesystems/overlayfs.html) của Kernel Linux.
### system.prop
Tệp này có cùng định dạng với `build.prop`. Mỗi dòng bao gồm `[key]=[value]`.
### sepolicy.rule
Nếu mô-đun của bạn yêu cầu một số bản vá lỗi chính sách bổ sung, vui lòng thêm các quy tắc đó vào tệp này. Mỗi dòng trong tệp này sẽ được coi là một tuyên bố chính sách.
## Trình cài đặt mô-đun
Trình cài đặt mô-đun KernelSU là mô-đun KernelSU được đóng gói trong tệp zip có thể được flash trong APP KernelSU manager. Trình cài đặt mô-đun KernelSU đơn giản chỉ là mô-đun KernelSU được đóng gói dưới dạng tệp zip.
```txt
module.zip
├── customize.sh <--- (Tùy chọn, biết thêm chi tiết sau)
│ Tập lệnh này sẽ có nguồn gốc từ update-binary
├── ...
├── ... /* Các tập tin còn lại của mô-đun */
```
:::warning
Mô-đun KernelSU KHÔNG được hỗ trợ để cài đặt trong khôi phục tùy chỉnh!!
:::
### Tùy chỉnh
Nếu bạn cần tùy chỉnh quá trình cài đặt mô-đun, bạn có thể tùy ý tạo một tập lệnh trong trình cài đặt có tên `customize.sh`. Tập lệnh này sẽ được _sourced_ (không được thực thi!) bởi tập lệnh cài đặt mô-đun sau khi tất cả các tệp được trích xuất và các quyền mặc định cũng như văn bản thứ hai được áp dụng. Điều này rất hữu ích nếu mô-đun của bạn yêu cầu thiết lập bổ sung dựa trên ABI của thiết bị hoặc bạn cần đặt các quyền/văn bản thứ hai đặc biệt cho một số tệp mô-đun của mình.
Nếu bạn muốn kiểm soát và tùy chỉnh hoàn toàn quá trình cài đặt, hãy khai báo `SKIPUNZIP=1` trong `customize.sh` để bỏ qua tất cả các bước cài đặt mặc định. Bằng cách đó, `customize.sh` của bạn sẽ chịu trách nhiệm cài đặt mọi thứ.
Tập lệnh `customize.sh` chạy trong shell `ash` BusyBox của KernelSU với "Chế độ độc lập" được bật. Có sẵn các biến và hàm sau:
#### Biến
- `KSU` (bool): biến để đánh dấu script đang chạy trong môi trường KernelSU, và giá trị của biến này sẽ luôn đúng. Bạn có thể sử dụng nó để phân biệt giữa KernelSU và Magisk.
- `KSU_VER` (chuỗi): chuỗi phiên bản của KernelSU được cài đặt hiện tại (ví dụ: `v0.4.0`)
- `KSU_VER_CODE` (int): mã phiên bản của KernelSU được cài đặt hiện tại trong không gian người dùng (ví dụ: `10672`)
- `KSU_KERNEL_VER_CODE` (int): mã phiên bản của KernelSU được cài đặt hiện tại trong không gian kernel (ví dụ: `10672`)
- `BOOTMODE` (bool): luôn là `true` trong KernelSU
- `MODPATH` (đường dẫn): đường dẫn nơi các tập tin mô-đun của bạn sẽ được cài đặt
- `TMPDIR` (đường dẫn): nơi bạn có thể lưu trữ tạm thời các tập tin
- `ZIPFILE` (đường dẫn): zip cài đặt mô-đun của bạn
- `ARCH` (chuỗi): kiến trúc CPU của thiết bị. Giá trị là `arm`, `arm64`, `x86` hoặc `x64`
- `IS64BIT` (bool): `true` nếu `$ARCH``arm64` hoặc `x64`
- `API` (int): cấp độ API (phiên bản Android) của thiết bị (ví dụ: `23` cho Android 6.0)
::: warning
Trong KernelSU, MAGISK_VER_CODE luôn là 25200 và MAGISK_VER luôn là v25.2. Vui lòng không sử dụng hai biến này để xác định xem nó có chạy trên KernelSU hay không.
:::
#### Hàm
```txt
ui_print <msg>
in <msg> ra console
Tránh sử dụng 'echo' vì nó sẽ không hiển thị trong console của recovery tùy chỉnh
abort <msg>
in thông báo lỗi <msg> ra bàn điều khiển và chấm dứt cài đặt
Tránh sử dụng 'exit' vì nó sẽ bỏ qua các bước dọn dẹp chấm dứt
set_perm <target> <owner> <group> <permission> [context]
nếu [context] không được đặt, mặc định là "u:object_r:system_file:s0"
chức năng này là một shorthand cho các lệnh sau:
chown owner.group target
chmod permission target
chcon context target
set_perm_recursive <directory> <owner> <group> <dirpermission> <filepermission> [context]
nếu [context] không được đặt, mặc định là "u:object_r:system_file:s0"
đối với tất cả các tệp trong <directory>, nó sẽ gọi:
bối cảnh cấp phép tệp của nhóm chủ sở hữu tệp set_perm
đối với tất cả các thư mục trong <directory> (bao gồm cả chính nó), nó sẽ gọi:
set_perm bối cảnh phân quyền của nhóm chủ sở hữu thư mục
```
## Tập lệnh khởi động
Trong KernelSU, tập lệnh được chia thành hai loại dựa trên chế độ chạy của chúng: chế độ post-fs-data và chế độ dịch vụ late_start:
- chế độ post-fs-data
- Giai đoạn này là BLOCKING. Quá trình khởi động bị tạm dừng trước khi thực thi xong hoặc đã trôi qua 10 giây.
- Các tập lệnh chạy trước khi bất kỳ mô-đun nào được gắn kết. Điều này cho phép nhà phát triển mô-đun tự động điều chỉnh các mô-đun của họ trước khi nó được gắn kết.
- Giai đoạn này xảy ra trước khi Zygote được khởi động, điều này gần như có ý nghĩa đối với mọi thứ trong Android
- **CẢNH BÁO:** sử dụng `setprop` sẽ làm quá trình khởi động bị nghẽn! Thay vào đó, vui lòng sử dụng `resetprop -n <prop_name> <prop_value>`.
- **Chỉ chạy tập lệnh ở chế độ này nếu cần thiết.**
- chế độ dịch vụ late_start
- Giai đoạn này là NON-BLOCKING. Tập lệnh của bạn chạy song song với phần còn lại của quá trình khởi động.
- **Đây là giai đoạn được khuyến nghị để chạy hầu hết các tập lệnh.**
Trong KernelSU, tập lệnh khởi động được chia thành hai loại dựa trên vị trí lưu trữ của chúng: tập lệnh chung và tập lệnh mô-đun:
- Kịch Bản Chung
- Được đặt trong `/data/adb/post-fs-data.d`, `/data/adb/service.d`, `/data/adb/post-mount.d` hoặc `/data/adb/boot- đã hoàn thành.d`
- Chỉ được thực thi nếu tập lệnh được đặt là có thể thực thi được (`chmod +x script.sh`)
- Các tập lệnh trong `post-fs-data.d` chạy ở chế độ post-fs-data và các tập lệnh trong `service.d` chạy ở chế độ dịch vụ late_start.
- Các mô-đun **KHÔNG** thêm các tập lệnh chung trong quá trình cài đặt
- Tập Lệnh Mô-đun
- Được đặt trong thư mục riêng của mô-đun
- Chỉ thực hiện nếu mô-đun được kích hoạt
- `post-fs-data.sh` chạy ở chế độ post-fs-data, `service.sh` chạy ở chế độ dịch vụ late_start, `boot-completed.sh` chạy khi khởi động xong, `post-mount.sh` chạy trên overlayfs được gắn kết.
Tất cả các tập lệnh khởi động sẽ chạy trong shell `ash` BusyBox của KernelSU với "Standalone Mode" được bật.

View File

@@ -0,0 +1,50 @@
# Cứu khỏi bootloop (Vòng lặp khởi động)
Khi flash một thiết bị, chúng ta có thể gặp phải tình trạng máy "bị brick". Về lý thuyết, nếu bạn chỉ sử dụng fastboot để flash phân vùng boot hoặc cài đặt các mô-đun không phù hợp khiến máy không khởi động được thì điều này có thể được khắc phục bằng các thao tác thích hợp. Tài liệu này nhằm mục đích cung cấp một số phương pháp khẩn cấp để giúp bạn khôi phục từ thiết bị "bị brick".
## Brick bởi flash vào phân vùng boot
Trong KernelSU, các tình huống sau có thể gây ra lỗi khởi động khi flash phân vùng khởi động:
1. Bạn flash image boot sai định dạng. Ví dụ: nếu định dạng khởi động điện thoại của bạn là `gz`, nhưng bạn flash image định dạng `lz4` thì điện thoại sẽ không thể khởi động.
2. Điện thoại của bạn cần tắt xác minh AVB để khởi động bình thường (thường yêu cầu xóa tất cả dữ liệu trên điện thoại).
3. Kernel của bạn có một số lỗi hoặc không phù hợp để flash điện thoại của bạn.
Bất kể tình huống thế nào, bạn có thể khôi phục bằng cách **flash boot image gốc**. Do đó, khi bắt đầu hướng dẫn cài đặt, chúng tôi thực sự khuyên bạn nên sao lưu boot image gốc trước khi flash. Nếu chưa sao lưu, bạn có thể lấy boot image gốc từ người dùng khác có cùng thiết bị với bạn hoặc từ chương trình cơ sở chính thức (official firmware).
## Brick bởi mô-đun
Việc cài đặt mô-đun có thể là nguyên nhân phổ biến hơn khiến thiết bị của bạn bị brick, nhưng chúng tôi phải nghiêm túc cảnh báo bạn: **Không cài đặt mô-đun từ các nguồn không xác định**! Vì các mô-đun có đặc quyền root nên chúng có thể gây ra thiệt hại không thể khắc phục cho thiết bị của bạn!
### Mô-đun bình thường
Nếu bạn đã flash một mô-đun đã được chứng minh là an toàn nhưng khiến thiết bị của bạn không khởi động được thì tình huống này có thể dễ dàng phục hồi trong KernelSU mà không phải lo lắng gì. KernelSU có các cơ chế tích hợp sẵn để giải cứu thiết bị của bạn, bao gồm:
1. Cập nhật AB
2. Cứu bằng cách nhấn Giảm âm lượng
#### Cập nhật AB
Các bản cập nhật mô-đun của KernelSU lấy cảm hứng từ cơ chế cập nhật AB của hệ thống Android được sử dụng trong các bản cập nhật OTA. Nếu bạn cài đặt một mô-đun mới hoặc cập nhật mô-đun hiện có, nó sẽ không trực tiếp sửa đổi tệp mô-đun hiện đang sử dụng. Thay vào đó, tất cả các mô-đun sẽ được tích hợp vào một hình ảnh cập nhật khác. Sau khi hệ thống được khởi động lại, nó sẽ cố gắng bắt đầu sử dụng hình ảnh cập nhật này. Nếu hệ thống Android khởi động thành công, các mô-đun sẽ được cập nhật thực sự.
Vì vậy, phương pháp đơn giản và được sử dụng phổ biến nhất để cứu thiết bị của bạn là **buộc khởi động lại**. Nếu bạn không thể khởi động hệ thống của mình sau khi flash một mô-đun, bạn có thể nhấn và giữ nút nguồn trong hơn 10 giây và hệ thống sẽ tự động khởi động lại; sau khi khởi động lại, nó sẽ quay trở lại trạng thái trước khi cập nhật mô-đun và các mô-đun được cập nhật trước đó sẽ tự động bị tắt.
#### Cứu bằng cách nhấn Giảm âm lượng
Nếu bản cập nhật AB vẫn không giải quyết được vấn đề, bạn có thể thử sử dụng **Chế độ an toàn**. Ở Chế độ an toàn, tất cả các mô-đun đều bị tắt.
Có hai cách để vào Chế độ an toàn:
1. Chế Độ An Toàn tích hợp (built-in Safe Mode) của một số hệ thống; một số hệ thống có Chế độ an toàn tích hợp có thể được truy cập bằng cách nhấn và giữ nút giảm âm lượng, trong khi những hệ thống khác (chẳng hạn như MIUI) có thể bật Chế Độ An Toàn trong Recovery. Khi vào Chế Độ An Toàn của hệ thống, KernelSU cũng sẽ vào Chế Độ An Toàn và tự động tắt các mô-đun.
2. Chế Độ An Toàn tích hợp (built-in Safe Mode) của KernelSU; phương pháp thao tác là **nhấn phím giảm âm lượng liên tục hơn ba lần** sau màn hình khởi động đầu tiên. Lưu ý là nhấn-thả, nhấn-thả, nhấn-thả chứ không phải nhấn giữ.
Sau khi vào chế độ an toàn, tất cả các mô-đun trên trang mô-đun của KernelSU Manager đều bị tắt nhưng bạn có thể thực hiện thao tác "gỡ cài đặt" để gỡ cài đặt bất kỳ mô-đun nào có thể gây ra sự cố.
Chế độ an toàn tích hợp được triển khai trong kernel, do đó không có khả năng thiếu các sự kiện chính do bị chặn. Tuy nhiên, đối với các hạt nhân không phải GKI, có thể cần phải tích hợp mã thủ công và bạn có thể tham khảo tài liệu chính thức để được hướng dẫn.
### Mô-đun độc hại
Nếu các phương pháp trên không thể cứu được thiết bị của bạn thì rất có thể mô-đun bạn cài đặt có hoạt động độc hại hoặc đã làm hỏng thiết bị của bạn thông qua các phương tiện khác. Trong trường hợp này, chỉ có hai gợi ý:
1. Xóa sạch dữ liệu và flash hệ thống chính thức.
2. Tham khảo dịch vụ hậu mãi.

View File

@@ -6,7 +6,7 @@
:::
::: warning
Trang này chỉ để cho bạn tìm thấy source cho thiết bị của bạn, nó **HOÀN TOÀN KHÔNG** được review bởi _lập trình viên của KernelSU_. Vậy nên hãy tự chấp nhận rủi ro khi sử dụng chúng.
Trang này chỉ để cho bạn tìm thấy source cho thiết bị của bạn, nó **HOÀN TOÀN KHÔNG** được review bởi _lập trình viên của KernelSU_. Vậy nên hãy chấp nhận rủi ro khi sử dụng chúng.
:::
@@ -17,8 +17,8 @@ import data from '../../repos.json'
<table>
<thead>
<tr>
<th>Maintainer</th>
<th>Repository</th>
<th>Người bảo trì</th>
<th>Kho lưu trữ</th>
<th>Thiết bị hỗ trợ</th>
</tr>
</thead>

View File

@@ -1,12 +1,12 @@
# KernelSU là gì?
KernelSU là một giải pháp root dành cho các thiết bị Android GKI, nó hoạt động ở chế độ kernel và sẽ cho phép truy cập quyền root cho ứng dụng ở userspace ngay trên không gian của kernel.
KernelSU là một giải pháp root cho các thiết bị Android GKI, nó hoạt động ở chế độ kernel và cấp quyền root cho ứng dụng không gian người dùng trực tiếp trong không gian kernel.
## Tính năng
Tính năng chính của KernelSU là **Kernel-based** (dựa trên Kernel ?). KernelSU hoạt động ở chế độ kernel, vật nên nó sẽ cung cấp các giao diên của kernel mà từ trước tới nay ta chưa từng có. Ví dụ, chúng ta có thể thêm hardware breakpoint vào bất kì tiến trình nào trong chế độ kernel; Chúng ta có thể truy cập vào bố nhớ vật lí của bất kì tiến trình nào mà không ai có thể phát hiện ra; Hoặc chúng ta có thể chặn bất kì syscall nào không gian kernel; etc.
Tính năng chính của KernelSU là **Kernel-based** (dựa trên Kernel). KernelSU hoạt động ở chế độ kernel nên nó có thể cung cấp giao din kernel mà chúng ta chưa từng có trước đây. Ví dụ: chúng ta có thể thêm điểm dừng phần cứng vào bất kỳ quy trình nào chế độ kernel; Chúng ta có thể truy cập bộ nhớ vật lý của bất kỳ quy trình nào mà không bị phát hiện; Chúng ta còn có thể chặn bất k syscall nào trong không gian kernel; v.v.
Đồng thời, KernelSU cung cấp một hệ thống module sử dụng overlayfs, cho phép bạn có thể thêm plugin của bạn vào trong hệ thống. Nó còn có thể cung cấp một cơ chế giúp chỉnh sửa được các file trên phân vùng `/system`
Ngoài ra, KernelSU còn cung cấp hệ thống mô-đun thông qua lớp phủ, cho phép bạn tải plugin tùy chỉnh vào hệ thống. Nó cũng cung cấp một cơ chế để sửa đổi các tập tin trong phân vùng `/system`.
## Hướng dẫn sử dụng

View File

@@ -1,10 +1,10 @@
---
layout: home
title: Giải pháp root trực tiếp trên kernel cho Android
title: Giải pháp root dựa trên kernel dành cho Android
hero:
name: KernelSU
text: Giải pháp root trực tiếp trên kernel cho Android
text: Giải pháp root dựa trên kernel dành cho Android
tagline: ""
image:
src: /logo.png
@@ -12,18 +12,18 @@ hero:
actions:
- theme: brand
text: Bắt Đầu
link: /vi_VN/guide/what-is-kernelsu
link: /guide/what-is-kernelsu
- theme: alt
text: Xem trên Github
text: Xem trên GitHub
link: https://github.com/tiann/KernelSU
features:
- title: Kernel-based
details: KernelSU hoạt động trong linux kernel, nó sẽ có nhiều quyền truy cập hơn vào các ứng dụng userspace.
- title: Điều khiển truy cập bằng whitelist
details: Chỉ ứng dụng đã được cho phép mới được sử dụng "su", những ứng dụng khác đều sẽ không thể sử dụng được.
- title: Hỗ trợ module
details: KernelSU hỗ trợ chỉnh sửa phân vùng /system một cách systemless bằng overlayfs, nó còn hỗ trợ ghi vào /system nữa.
- title: Mã nguồn mở
details: KernelSU là một dự án mã nguồn mở sử dụng giấy phép GPL-3
- title: Dựa trên Kernel
details: KernelSU đang hoạt động ở chế độ kernel Linux, nó có nhiều quyền kiểm soát hơn đối với các ứng dụng userspace.
- title: Kiểm soát truy cập bằng whitelist
details: Chỉ ứng dụng được cấp quyền root mới có thể truy cập `su`, các ứng dụng khác không thể nhận được su.
- title: Quyền root bị hạn chế
details: KernelSU cho phép bạn tùy chỉnh uid, gid, group, capabilities và các quy tắc SELinux của su. Giới hạn sức mạnh của root.
- title: Mô-đun & Nguồn mở
details: KernelSU hỗ trợ sửa đổi /system một cách systemless bằng overlayfs và nó có nguồn mở theo GPL-3.