Translation of instructions into Russian (#761)
This project is quite extensive, decided to translate it into Russian (further adjustments may be required)
This commit is contained in:
@@ -1,4 +1,4 @@
|
|||||||
**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)
|
**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)
|
||||||
|
|
||||||
# KernelSU
|
# KernelSU
|
||||||
|
|
||||||
|
|||||||
@@ -1,4 +1,4 @@
|
|||||||
[English](README.md) | [Español](README_ES.md) | **简体中文** | [繁體中文](README_TW.md) | [日本語](README_JP.md) | [Polski](README_PL.md) | [Portuguese-Brazil](README_PT-BR.md) | [Türkçe](README_TR.md)
|
[English](README.md) | [Español](README_ES.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)
|
||||||
|
|
||||||
# KernelSU
|
# KernelSU
|
||||||
|
|
||||||
|
|||||||
@@ -1,4 +1,4 @@
|
|||||||
[ 🇬🇧 English](README.md) | 🇪🇸 **Español** | [🇨🇳 简体中文](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)
|
[ 🇬🇧 English](README.md) | 🇪🇸 **Español** | [🇨🇳 简体中文](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)
|
||||||
|
|
||||||
<div style="display: flex; align-items: center;">
|
<div style="display: flex; align-items: center;">
|
||||||
<img src="https://kernelsu.org/logo.png" style="width: 96px;" alt="">
|
<img src="https://kernelsu.org/logo.png" style="width: 96px;" alt="">
|
||||||
|
|||||||
@@ -1,4 +1,4 @@
|
|||||||
[English](README.md) | [Español](README_ES.md) | [简体中文](README_CN.md) | [繁體中文](README_TW.md) | **日本語** | [Polski](README_PL.md) | [Portuguese-Brazil](README_PT-BR.md) | [Türkçe](README_TR.md)
|
[English](README.md) | [Español](README_ES.md) | [简体中文](README_CN.md) | [繁體中文](README_TW.md) | **日本語** | [Polski](README_PL.md) | [Portuguese-Brazil](README_PT-BR.md) | [Türkçe](README_TR.md) | [Русский](README_RU.md)
|
||||||
|
|
||||||
# KernelSU
|
# KernelSU
|
||||||
|
|
||||||
|
|||||||
@@ -1,4 +1,4 @@
|
|||||||
[English](README.md) | [Español](README_ES.md) | [简体中文](README_CN.md) | [繁體中文](README_TW.md) | [日本語](README_JP.md) | **Polski** | [Portuguese-Brazil](README_PT-BR.md) | [Türkçe](README_TR.md)
|
[English](README.md) | [Español](README_ES.md) | [简体中文](README_CN.md) | [繁體中文](README_TW.md) | [日本語](README_JP.md) | **Polski** | [Portuguese-Brazil](README_PT-BR.md) | [Türkçe](README_TR.md) | [Русский](README_RU.md)
|
||||||
|
|
||||||
# KernelSU
|
# KernelSU
|
||||||
|
|
||||||
|
|||||||
@@ -1,4 +1,4 @@
|
|||||||
[English](README.md) | [Español](README_ES.md) | [简体中文](README_CN.md) | [繁體中文](README_TW.md) | [日本語](README_JP.md) | [Polski](README_PL.md) | **Portuguese-Brazil** | [Türkçe](README_TR.md)
|
[English](README.md) | [Español](README_ES.md) | [简体中文](README_CN.md) | [繁體中文](README_TW.md) | [日本語](README_JP.md) | [Polski](README_PL.md) | **Portuguese-Brazil** | [Türkçe](README_TR.md) | [Русский](README_RU.md)
|
||||||
|
|
||||||
# KernelSU
|
# KernelSU
|
||||||
|
|
||||||
|
|||||||
42
README_RU.md
Normal file
42
README_RU.md
Normal file
@@ -0,0 +1,42 @@
|
|||||||
|
[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) | **Русский**
|
||||||
|
|
||||||
|
# KernelSU
|
||||||
|
|
||||||
|
Решение на основе ядра root для Android-устройств.
|
||||||
|
|
||||||
|
## Особенности
|
||||||
|
|
||||||
|
1. Управление `su` и root-доступом на основе ядра.
|
||||||
|
2. Система модулей на основе overlayfs.
|
||||||
|
|
||||||
|
## Совместимость
|
||||||
|
|
||||||
|
KernelSU официально поддерживает устройства на базе Android GKI 2.0 (с ядром 5.10+), старые ядра (4.14+) также совместимы, но для этого необходимо собрать ядро самостоятельно.
|
||||||
|
|
||||||
|
WSA и Android на основе контейнеров также должны работать с интегрированным KernelSU.
|
||||||
|
|
||||||
|
В настоящее время поддерживаются следующие ABI: `arm64-v8a` и `x86_64`.
|
||||||
|
|
||||||
|
## Использование
|
||||||
|
|
||||||
|
[Установка](https://kernelsu.org/ru_RU/guide/installation.html)
|
||||||
|
|
||||||
|
## Сборка
|
||||||
|
|
||||||
|
[Как собрать?](https://kernelsu.org/ru_RU/guide/how-to-build.html)
|
||||||
|
|
||||||
|
## Обсуждение
|
||||||
|
|
||||||
|
- Telegram: [@KernelSU](https://t.me/KernelSU)
|
||||||
|
|
||||||
|
## Лицензия
|
||||||
|
|
||||||
|
- Файлы в директории `kernel` - [GPL-2](https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html)
|
||||||
|
- Все остальные части, кроме директории `kernel` - [GPL-3](https://www.gnu.org/licenses/gpl-3.0.html)
|
||||||
|
|
||||||
|
## Благодарности
|
||||||
|
|
||||||
|
- [kernel-assisted-superuser](https://git.zx2c4.com/kernel-assisted-superuser/about/): идея KernelSU.
|
||||||
|
- [genuine](https://github.com/brevent/genuine/): проверка подписи apk v2.
|
||||||
|
- [Diamorphine](https://github.com/m0nad/Diamorphine): некоторые навыки руткита.
|
||||||
|
- [Magisk](https://github.com/topjohnwu/Magisk): реализация sepolicy.
|
||||||
@@ -1,4 +1,4 @@
|
|||||||
[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**
|
[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_RU.md)
|
||||||
|
|
||||||
# KernelSU
|
# KernelSU
|
||||||
|
|
||||||
|
|||||||
@@ -1,4 +1,4 @@
|
|||||||
[English](README.md) | [Español](README_ES.md) | [简体中文](README_CN.md) | **繁體中文** | [日本語](README_JP.md) | [Polski](README_PL.md) | [Portuguese-Brazil](README_PT-BR.md) | [Türkçe](README_TR.md)
|
[English](README.md) | [Español](README_ES.md) | [简体中文](README_CN.md) | **繁體中文** | [日本語](README_JP.md) | [Polski](README_PL.md) | [Portuguese-Brazil](README_PT-BR.md) | [Türkçe](README_TR.md) | [Русский](README_RU.md)
|
||||||
|
|
||||||
# KernelSU
|
# KernelSU
|
||||||
|
|
||||||
|
|||||||
118
website/docs/ru_RU/guide/app-profile.md
Normal file
118
website/docs/ru_RU/guide/app-profile.md
Normal file
@@ -0,0 +1,118 @@
|
|||||||
|
# Профиль приложений
|
||||||
|
|
||||||
|
Профиль приложений - это механизм, предоставляемый KernelSU для настройки конфигурации различных приложений.
|
||||||
|
|
||||||
|
Для приложений, получивших права root (т.е. имеющих возможность использовать `su`), App Profile может также называться Root Profile. Он позволяет настраивать правила `uid`, `gid`, `groups`, `capabilities` и `SELinux` команды `su`, тем самым ограничивая привилегии пользователя root. Например, она может предоставлять сетевые права только приложениям межсетевого экрана, отказывая в праве доступа к файлам, или предоставлять права shell вместо полного root-доступа для приложений freeze: **сохранение власти в рамках принципа наименьших привилегий*.
|
||||||
|
|
||||||
|
Для обычных приложений, не имеющих прав root, App Profile может управлять поведением ядра и системы модулей по отношению к этим приложениям. Например, он может определять, следует ли обращать внимание на модификации, возникающие в результате работы модулей. На основе этой конфигурации ядро и система модулей могут принимать решения, например, выполнять операции, аналогичные "скрытию".
|
||||||
|
|
||||||
|
## Корневой профиль
|
||||||
|
|
||||||
|
### UID, GID и группы
|
||||||
|
|
||||||
|
В системах Linux существуют два понятия: пользователи и группы. Каждый пользователь имеет идентификатор пользователя (UID), а пользователь может принадлежать к нескольким группам, каждая из которых имеет свой идентификатор группы (GID). Эти идентификаторы используются для идентификации пользователей в системе и определяют, к каким системным ресурсам они могут получить доступ.
|
||||||
|
|
||||||
|
Пользователи с UID, равным 0, называются корневыми пользователями, а группы с GID, равным 0, - корневыми группами. Группа пользователей root, как правило, обладает самыми высокими системными привилегиями.
|
||||||
|
|
||||||
|
В случае системы Android каждое приложение является отдельным пользователем (исключая сценарии с общим UID) с уникальным UID. Например, `0` представляет пользователя root, `1000` - `system`, `2000` - ADB shell, а UID в диапазоне от 10000 до 19999 - обычные приложения.
|
||||||
|
|
||||||
|
:::info
|
||||||
|
Здесь упомянутый UID не совпадает с концепцией нескольких пользователей или рабочих профилей в системе Android. На самом деле рабочие профили реализуются путем разделения диапазона UID. Например, 10000-19999 представляет собой основного пользователя, а 110000-119999 - рабочий профиль. Каждое обычное приложение среди них имеет свой уникальный UID.
|
||||||
|
:::
|
||||||
|
|
||||||
|
Каждое приложение может иметь несколько групп, причем GID представляет собой основную группу, которая обычно совпадает с UID. Другие группы называются дополнительными. Определенные разрешения контролируются через группы, например, разрешения на доступ к сети или доступ к Bluetooth.
|
||||||
|
|
||||||
|
Например, если мы выполним команду `id` в оболочке ADB, то результат может выглядеть следующим образом:
|
||||||
|
|
||||||
|
```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
|
||||||
|
```
|
||||||
|
|
||||||
|
Здесь UID равен `2000`, а GID (идентификатор основной группы) также равен `2000`. Кроме того, он входит в несколько дополнительных групп, таких как `inet` (указывает на возможность создания сокетов `AF_INET` и `AF_INET6`) и `sdcard_rw` (указывает на права чтения/записи на SD-карту).
|
||||||
|
|
||||||
|
Корневой профиль KernelSU позволяет настраивать UID, GID и группы для корневого процесса после выполнения команды `su`. Например, в корневом профиле корневого приложения можно установить его UID на `2000`, что означает, что при использовании `su` фактические разрешения приложения будут находиться на уровне оболочки ADB. Группа `inet` может быть удалена, что не позволит команде `su` получить доступ к сети.
|
||||||
|
|
||||||
|
:::tip Примечание
|
||||||
|
Профиль приложений контролирует только разрешения корневого процесса после использования `su`; он не контролирует разрешения самого приложения. Если приложение запросило разрешение на доступ к сети, оно может получить доступ к сети даже без использования `su`. Удаление группы `inet` из `su` только предотвращает доступ `su` к сети.
|
||||||
|
:::
|
||||||
|
|
||||||
|
Корневой профиль реализуется в ядре и не зависит от добровольного поведения root-приложений, в отличие от переключения пользователей или групп через `su`, предоставление прав `su` полностью зависит от пользователя, а не от разработчика.
|
||||||
|
|
||||||
|
### Привилегии
|
||||||
|
|
||||||
|
Привилегии - это механизм разделения привилегий в Linux.
|
||||||
|
|
||||||
|
В традиционных реализациях UNIX для проверки прав доступа выделяются две категории процессов: привилегированные процессы (эффективный идентификатор пользователя равен 0 и называется суперпользователем или root) и непривилегированные процессы (эффективный UID которых не равен нулю). Привилегированные процессы обходят все проверки прав ядра, в то время как непривилегированные процессы подвергаются полной проверке прав на основе учетных данных процесса (обычно: эффективный UID, эффективный GID и список дополнительных групп).
|
||||||
|
|
||||||
|
Начиная с версии Linux 2.2, в Linux привилегии, традиционно ассоциируемые с суперпользователем, разделены на отдельные единицы, называемые возможностями, которые могут быть независимо включены и выключены.
|
||||||
|
|
||||||
|
Каждая способность представляет собой одну или несколько привилегий. Например, `CAP_DAC_READ_SEARCH` представляет собой возможность обхода проверок прав на чтение файлов, а также прав на чтение и выполнение каталогов. Если пользователь с эффективным UID `0` (пользователь root) не имеет возможности `CAP_DAC_READ_SEARCH` или более высоких возможностей, это означает, что, хотя он и является пользователем root, он не может читать файлы по своему усмотрению.
|
||||||
|
|
||||||
|
Корневой профиль KernelSU позволяет настраивать возможности корневого процесса после выполнения `su`, тем самым добиваясь частичного предоставления "прав root". В отличие от вышеупомянутых UID и GID, некоторые root-приложения после использования `su` требуют UID, равный `0`. В таких случаях ограничение возможностей данного root-пользователя с UID `0` может ограничить их разрешенные операции.
|
||||||
|
|
||||||
|
:::tip Настоятельная рекомендация
|
||||||
|
В документе привелегий Linux [официальной документации](https://man7.org/linux/man-pages/man7/capabilities.7.html) дается подробное объяснение возможностей, представленных каждой привелегией. Если вы собираетесь настраивать привелегии, настоятельно рекомендуется сначала прочитать этот документ.
|
||||||
|
:::
|
||||||
|
|
||||||
|
### SELinux
|
||||||
|
|
||||||
|
SELinux - это мощный механизм обязательного контроля доступа (MAC). Он работает по принципу **запрет по умолчанию**: любое действие, не разрешенное в явном виде, запрещается.
|
||||||
|
|
||||||
|
SELinux может работать в двух глобальных режимах:
|
||||||
|
|
||||||
|
1. Разрешительный режим: События запрета регистрируются, но не выполняются.
|
||||||
|
2. Принудительный режим: События запрета регистрируются и выполняются.
|
||||||
|
|
||||||
|
:::warning Предупреждение
|
||||||
|
Современные системы Android в значительной степени опираются на SELinux для обеспечения общей безопасности системы. Настоятельно не рекомендуется использовать пользовательские системы, работающие в "разрешительном режиме", поскольку это не дает существенных преимуществ перед полностью открытой системой.
|
||||||
|
:::
|
||||||
|
|
||||||
|
Объяснение полной концепции SELinux является сложным и выходит за рамки данного документа. Рекомендуется сначала разобраться в его работе с помощью следующих ресурсов:
|
||||||
|
|
||||||
|
1. [Wikipedia](https://en.wikipedia.org/wiki/Security-Enhanced_Linux)
|
||||||
|
2. [Red Hat: Что такое SELinux?](https://www.redhat.com/en/topics/linux/what-is-selinux)
|
||||||
|
3. [ArchLinux: SELinux](https://wiki.archlinux.org/title/SELinux)
|
||||||
|
|
||||||
|
Корневой профиль KernelSU позволяет настраивать SELinux-контекст корневого процесса после выполнения команды `su`. Для этого контекста могут быть заданы специальные правила управления доступом, позволяющие осуществлять тонкий контроль над правами root.
|
||||||
|
|
||||||
|
В типичных сценариях, когда приложение выполняет команду `su`, оно переключает процесс на домен SELinux с **неограниченным доступом**, например `u:r:su:s0`. С помощью профиля Root Profile этот домен может быть переключен на пользовательский домен, например `u:r:app1:s0`, и для него может быть определен ряд правил:
|
||||||
|
|
||||||
|
```sh
|
||||||
|
type app1
|
||||||
|
enforce app1
|
||||||
|
typeattribute app1 mlstrustedsubject
|
||||||
|
allow app1 * * *
|
||||||
|
```
|
||||||
|
|
||||||
|
Обратите внимание, что правило `allow app1 * * *` используется только в демонстрационных целях. На практике это правило не должно широко использоваться, поскольку оно мало чем отличается от разрешительного режима.
|
||||||
|
|
||||||
|
### Эскалация
|
||||||
|
|
||||||
|
При неправильной настройке корневого профиля может возникнуть сценарий эскалации: ограничения, накладываемые корневым профилем, могут непреднамеренно не сработать.
|
||||||
|
|
||||||
|
Например, если предоставить права root пользователю ADB shell (что является обычным случаем), а затем предоставить права root обычному приложению, но настроить его профиль root с UID 2000 (это UID пользователя ADB shell), то приложение может получить полный доступ root, выполнив команду `su` дважды:
|
||||||
|
|
||||||
|
1. При первом выполнении команды `su` будет применен профиль App Profile и произойдет переход на UID `2000` (adb shell) вместо `0` (root).
|
||||||
|
2. При втором выполнении команды `su`, поскольку UID равен `2000`, а в конфигурации вы предоставили доступ root к UID `2000` (adb shell), приложение получит полные привилегии root.
|
||||||
|
|
||||||
|
:::warning Примечание
|
||||||
|
Такое поведение вполне ожидаемо и не является ошибкой. Поэтому мы рекомендуем следующее:
|
||||||
|
|
||||||
|
Если вам действительно необходимо предоставить права root в ADB (например, как разработчику), не рекомендуется изменять UID на `2000` при настройке корневого профиля. Лучше использовать `1000` (система).
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Некорневой профиль
|
||||||
|
|
||||||
|
### Размонтирование модулей
|
||||||
|
|
||||||
|
KernelSU предоставляет бессистемный механизм модификации системных разделов, реализуемый через монтирование overlayfs. Однако некоторые приложения могут быть чувствительны к такому поведению. Поэтому мы можем выгрузить модули, смонтированные в этих приложениях, установив опцию "размонтирование модулей".
|
||||||
|
|
||||||
|
Кроме того, в интерфейсе настроек менеджера KernelSU имеется переключатель "размонтирование модулей по умолчанию". По умолчанию этот переключатель **включен**, что означает, что KernelSU или некоторые модули будут выгружать модули для данного приложения, если не будут применены дополнительные настройки. Если вам не нравится эта настройка или если она влияет на определенные приложения, у вас есть следующие возможности:
|
||||||
|
|
||||||
|
1. Оставить переключатель "размонтирование модулей по умолчанию" и индивидуально отключить опцию "размонтирование модулей" в профиле приложений для приложений, требующих загрузки модулей (действует как "белый список").
|
||||||
|
2. Отключить переключатель "размонтирование модулей по умолчанию" и индивидуально включить опцию "размонтирование модулей" в App Profile для приложений, требующих выгрузки модулей (действует как "черный список").
|
||||||
|
|
||||||
|
:::info
|
||||||
|
В устройствах, использующих ядро версии 5.10 и выше, выгрузку модулей выполняет само ядро. Однако для устройств с ядром версии ниже 5.10 этот переключатель является лишь опцией конфигурации, и KernelSU сам по себе не предпринимает никаких действий. Некоторые модули, например, Zygisksu, могут использовать этот переключатель для определения необходимости выгрузки модулей.
|
||||||
|
:::
|
||||||
26
website/docs/ru_RU/guide/difference-with-magisk.md
Normal file
26
website/docs/ru_RU/guide/difference-with-magisk.md
Normal file
@@ -0,0 +1,26 @@
|
|||||||
|
# Различия с Magisk
|
||||||
|
|
||||||
|
Несмотря на большое количество сходств между модулями KernelSU и модулями Magisk, неизбежно возникают и различия, обусловленные совершенно разными механизмами их реализации. Если вы хотите, чтобы ваш модуль работал как на Magisk, так и на KernelSU, вы должны понимать эти различия.
|
||||||
|
|
||||||
|
## Сходства
|
||||||
|
|
||||||
|
- Формат файлов модулей: оба используют формат zip для организации модулей, и формат модулей практически одинаков
|
||||||
|
- Каталог установки модулей: оба расположены в `/data/adb/modules`.
|
||||||
|
- Бессистемность: оба поддерживают модификацию /system бессистемным способом через модули
|
||||||
|
- post-fs-data.sh: время выполнения и семантика полностью совпадают
|
||||||
|
- service.sh: время выполнения и семантика полностью совпадают
|
||||||
|
- system.prop: полностью совпадает
|
||||||
|
- sepolicy.rule: полностью совпадает
|
||||||
|
- BusyBox: скрипты запускаются в BusyBox с включенным "автономным режимом" в обоих случаях
|
||||||
|
|
||||||
|
## Различия
|
||||||
|
|
||||||
|
Прежде чем разбираться в различиях, необходимо знать, как отличить, в каком режиме работает ваш модуль - KernelSU или Magisk. Для этого можно использовать переменную окружения `KSU` во всех местах, где можно запустить скрипты модуля (`customize.sh`, `post-fs-data.sh`, `service.sh`). В KernelSU эта переменная окружения будет установлена в значение `true`.
|
||||||
|
|
||||||
|
Вот некоторые отличия:
|
||||||
|
|
||||||
|
- Модули KernelSU не могут быть установлены в режиме Recovery.
|
||||||
|
- Модули KernelSU не имеют встроенной поддержки Zygisk (но вы можете использовать модули Zygisk через [ZygiskOnKernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU).
|
||||||
|
- Метод замены или удаления файлов в модулях KernelSU полностью отличается от Magisk. KernelSU не поддерживает метод `.replace`. Вместо этого необходимо создать одноименный файл с помощью команды `mknod filename c 0 0` для удаления соответствующего файла.
|
||||||
|
- Каталоги для BusyBox отличаются. Встроенный BusyBox в KernelSU находится в каталоге `/data/adb/ksu/bin/busybox`, а в Magisk - в каталоге `/data/adb/magisk/busybox`. **Обратите внимание, что это внутреннее поведение KernelSU и в будущем оно может измениться!**
|
||||||
|
- KernelSU не поддерживает файлы `.replace`; однако KernelSU поддерживает переменные `REMOVE` и `REPLACE` для удаления или замены файлов и папок.
|
||||||
67
website/docs/ru_RU/guide/faq.md
Normal file
67
website/docs/ru_RU/guide/faq.md
Normal file
@@ -0,0 +1,67 @@
|
|||||||
|
# FAQ
|
||||||
|
|
||||||
|
## Поддерживает ли KernelSU мое устройство?
|
||||||
|
|
||||||
|
Во-первых, ваше устройство должно быть способно разблокировать загрузчик. Если не может, значит, устройство не поддерживается.
|
||||||
|
|
||||||
|
Затем установите на устройство приложение KernelSU manager App и откройте его, если оно покажет `Unsupported`, то ваше устройство не поддерживается из коробки, но вы можете собрать исходный код ядра и интегрировать KernelSU, чтобы заставить его работать, или использовать [неофициально-поддерживаемые-устройства](unofficially-support-devices).
|
||||||
|
|
||||||
|
## Нужно ли для KernelSU разблокировать загрузчик?
|
||||||
|
|
||||||
|
Безусловно, да.
|
||||||
|
|
||||||
|
## Поддерживает ли KernelSU модули?
|
||||||
|
|
||||||
|
Да, но это ранняя версия, она может быть глючной. Пожалуйста, подождите, пока она станет стабильной :)
|
||||||
|
|
||||||
|
## Поддерживает ли KernelSU Xposed?
|
||||||
|
|
||||||
|
Да, [Dreamland](https://github.com/canyie/Dreamland) и [TaiChi](https://taichi.cool) работают. Что касается LSPosed, то его можно заставить работать с помощью [Zygisk на KernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU)
|
||||||
|
|
||||||
|
## Поддерживает ли KernelSU Zygisk?
|
||||||
|
|
||||||
|
KernelSU не имеет встроенной поддержки Zygisk, но вы можете использовать [Zygisk на KernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU).
|
||||||
|
|
||||||
|
## Совместим ли KernelSU с Magisk?
|
||||||
|
|
||||||
|
Система модулей KernelSU конфликтует с магическим монтированием Magisk, если в KernelSU включен какой-либо модуль, то весь Magisk не будет работать.
|
||||||
|
|
||||||
|
Но если вы используете только `su` из KernelSU, то он будет хорошо работать с Magisk: KernelSU модифицирует `kernel`, а Magisk - `ramdisk`, они могут работать вместе.
|
||||||
|
|
||||||
|
## Заменит ли KernelSU Magisk?
|
||||||
|
|
||||||
|
Мы так не считаем, и это не является нашей целью. Magisk достаточно хорош для решения проблемы root в пользовательском пространстве и будет жить долго. Цель KernelSU - предоставить пользователям интерфейс ядра, а не заменить Magisk.
|
||||||
|
|
||||||
|
## Может ли KernelSU поддерживать устройства, не относящиеся к GKI?
|
||||||
|
|
||||||
|
Это возможно. Но для этого необходимо скачать исходный текст ядра, подключить KernelSU к дереву исходных текстов и скомпилировать ядро самостоятельно.
|
||||||
|
|
||||||
|
## Может ли KernelSU поддерживать устройства под управлением Android 12?
|
||||||
|
|
||||||
|
На совместимость KernelSU влияет ядро устройства, и версия Android здесь ни при чем. Единственное ограничение - устройства, запускаемые с Android 12, должны иметь ядро 5.10+ (устройства GKI). Итак:
|
||||||
|
|
||||||
|
1. Устройства, выпущенные под управлением Android 12, должны поддерживаться.
|
||||||
|
2. Устройства со старым ядром (некоторые устройства с Android 12 также имеют старое ядро) совместимы (Вы должны собрать ядро самостоятельно).
|
||||||
|
|
||||||
|
## Может ли KernelSU поддерживать старое ядро?
|
||||||
|
|
||||||
|
Это возможно, KernelSU бэкпортирован на ядро 4.14, для более старых ядер, вам нужно сделать бэкпорт вручную, и PR приветствуются!
|
||||||
|
|
||||||
|
## Как интегрировать KernelSU в старое ядро?
|
||||||
|
|
||||||
|
Пожалуйста, обратитесь к [руководству](how-to-integrate-for-non-gki)
|
||||||
|
|
||||||
|
## Почему моя версия Android - 13, а ядро показывает "android12-5.10"?
|
||||||
|
|
||||||
|
Версия ядра не имеет никакого отношения к версии Android, если вам нужно прошить ядро, всегда используйте версию ядра, версия Android не так важна.
|
||||||
|
|
||||||
|
## Есть ли в KernelSU пространство имен --mount-master/global mount?
|
||||||
|
|
||||||
|
Сейчас нет (возможно, в будущем), но есть много способов переключиться на глобальное пространство имен монтирования вручную, например:
|
||||||
|
|
||||||
|
1. `nsenter -t 1 -m sh` для получения оболочки в глобальном пространстве имен монтирования.
|
||||||
|
2. Добавить `nsenter --mount=/proc/1/ns/mnt` к команде, которую вы хотите выполнить, тогда команда будет выполнена в глобальном пространстве имен монтирования. KernelSU также [использует этот способ](https://github.com/tiann/KernelSU/blob/77056a710073d7a5f7ee38f9e77c9fd0b3256576/manager/app/src/main/java/me/weishu/kernelsu/ui/util/KsuCli.kt#L115)
|
||||||
|
|
||||||
|
## Я GKI1.0, могу ли я использовать это?
|
||||||
|
|
||||||
|
GKI1 полностью отличается от GKI2, вы должны скомпилировать ядро самостоятельно.
|
||||||
7
website/docs/ru_RU/guide/hidden-features.md
Normal file
7
website/docs/ru_RU/guide/hidden-features.md
Normal file
@@ -0,0 +1,7 @@
|
|||||||
|
# Скрытые возможности
|
||||||
|
|
||||||
|
## .ksurc
|
||||||
|
|
||||||
|
По умолчанию `/system/bin/sh` загружает `/system/etc/mkshrc`.
|
||||||
|
|
||||||
|
Вы можете заставить su загружать пользовательский rc-файл, создав файл `/data/adb/ksu/.ksurc`.
|
||||||
65
website/docs/ru_RU/guide/how-to-build.md
Normal file
65
website/docs/ru_RU/guide/how-to-build.md
Normal file
@@ -0,0 +1,65 @@
|
|||||||
|
# Как собрать KernelSU?
|
||||||
|
|
||||||
|
Прежде всего, необходимо ознакомиться с официальной документацией Android по сборке ядра:
|
||||||
|
|
||||||
|
1. [Сборка ядер](https://source.android.com/docs/setup/build/building-kernels)
|
||||||
|
2. [Сборки релизов GKI](https://source.android.com/docs/core/architecture/kernel/gki-release-builds)
|
||||||
|
|
||||||
|
::: warning
|
||||||
|
Эта страница предназначена для устройств GKI, если вы используете старое ядро, пожалуйста, обратитесь к [Как интегрировать KernelSU для не GKI ядер?](how-to-integrate-for-non-gki).
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Сборка ядра
|
||||||
|
|
||||||
|
### Синхронизация исходного кода ядра
|
||||||
|
|
||||||
|
```sh
|
||||||
|
repo init -u https://android.googlesource.com/kernel/manifest
|
||||||
|
mv <kernel_manifest.xml> .repo/manifests
|
||||||
|
repo init -m manifest.xml
|
||||||
|
repo sync
|
||||||
|
```
|
||||||
|
|
||||||
|
Файл `<kernel_manifest.xml>` - это файл манифеста, который может однозначно определять сборку, с его помощью можно выполнить пересборку. Файл манифеста следует загрузить с сайта [Сборки релизов Google GKI](https://source.android.com/docs/core/architecture/kernel/gki-release-builds)
|
||||||
|
|
||||||
|
### Построение
|
||||||
|
|
||||||
|
Пожалуйста, сначала ознакомьтесь с [официальной документацией](https://source.android.com/docs/setup/build/building-kernels).
|
||||||
|
|
||||||
|
Например, нам необходимо собрать образ ядра aarch64:
|
||||||
|
|
||||||
|
```sh
|
||||||
|
LTO=thin BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
|
||||||
|
```
|
||||||
|
|
||||||
|
Не забудьте добавить флаг `LTO=thin`, иначе сборка может завершиться неудачей, если память вашего компьютера меньше 24 Гб.
|
||||||
|
|
||||||
|
Начиная с Android 13, сборка ядра осуществляется с помощью `bazel`:
|
||||||
|
|
||||||
|
```sh
|
||||||
|
tools/bazel build --config=fast //common:kernel_aarch64_dist
|
||||||
|
```
|
||||||
|
|
||||||
|
## Сборка ядра с помощью KernelSU
|
||||||
|
|
||||||
|
Если вы успешно собрали ядро, то собрать KernelSU очень просто, выберите любой запуск в корневом каталоге исходного кода ядра:
|
||||||
|
|
||||||
|
- Последний тэг(стабильный)
|
||||||
|
|
||||||
|
```sh
|
||||||
|
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -
|
||||||
|
```
|
||||||
|
|
||||||
|
- Основная ветвь(разработка)
|
||||||
|
|
||||||
|
```sh
|
||||||
|
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s main
|
||||||
|
```
|
||||||
|
|
||||||
|
- Выбранный тэг(Например, версия v0.5.2)
|
||||||
|
|
||||||
|
```sh
|
||||||
|
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s v0.5.2
|
||||||
|
```
|
||||||
|
|
||||||
|
А затем пересоберите ядро и получите образ ядра с KernelSU!
|
||||||
251
website/docs/ru_RU/guide/how-to-integrate-for-non-gki.md
Normal file
251
website/docs/ru_RU/guide/how-to-integrate-for-non-gki.md
Normal file
@@ -0,0 +1,251 @@
|
|||||||
|
# Как интегрировать KernelSU для не GKI ядер?
|
||||||
|
|
||||||
|
KernelSU может быть интегрирован в ядра, отличные от GKI, и был перенесен на версии 4.14 и ниже.
|
||||||
|
|
||||||
|
В связи с фрагментацией ядер, отличных от GKI, у нас нет единого способа их сборки, поэтому мы не можем предоставить загрузочные образы, отличные от GKI. Однако вы можете собрать ядро самостоятельно с помощью интегрированной программы KernelSU.
|
||||||
|
|
||||||
|
Во-первых, вы должны уметь собирать загрузочное ядро из исходных текстов ядра. Если ядро не является открытым, то запустить KernelSU для вашего устройства будет затруднительно.
|
||||||
|
|
||||||
|
Если вы можете собрать загрузочное ядро, то существует два способа интеграции KernelSU в исходный код ядра:
|
||||||
|
|
||||||
|
1. Автоматически с помощью `kprobe`
|
||||||
|
2. Вручную
|
||||||
|
|
||||||
|
## Интеграция с kprobe
|
||||||
|
|
||||||
|
KernelSU использует kprobe для выполнения хуков ядра, если *kprobe* хорошо работает в вашем ядре, то рекомендуется использовать именно этот способ.
|
||||||
|
|
||||||
|
Сначала добавьте KernelSU в дерево исходных текстов ядра:
|
||||||
|
|
||||||
|
```sh
|
||||||
|
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -
|
||||||
|
```
|
||||||
|
|
||||||
|
Затем необходимо проверить, включена ли функция *kprobe* в конфигурации ядра, если нет, то добавьте в нее эти настройки:
|
||||||
|
|
||||||
|
```
|
||||||
|
CONFIG_KPROBES=y
|
||||||
|
CONFIG_HAVE_KPROBES=y
|
||||||
|
CONFIG_KPROBE_EVENTS=y
|
||||||
|
```
|
||||||
|
|
||||||
|
И снова соберите ядро, KernelSU должен работать нормально.
|
||||||
|
|
||||||
|
Если вы обнаружите, что KPROBES по-прежнему не активирован, попробуйте включить `CONFIG_MODULES`. (Если это все равно не даст результата, используйте `make menuconfig` для поиска других зависимостей KPROBES).
|
||||||
|
|
||||||
|
Если же при интеграции KernelSU возникает зацикливание загрузки, то, возможно, в вашем ядре *kprobe неисправен*, следует исправить ошибку kprobe или воспользоваться вторым способом.
|
||||||
|
|
||||||
|
:::tip Как проверить, не сломан ли kprobe?
|
||||||
|
|
||||||
|
закомментируйте `ksu_enable_sucompat()` и `ksu_enable_ksud()` в файле `KernelSU/kernel/ksu.c`, если устройство загружается нормально, то может быть нарушена работа kprobe.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Ручная модификация исходного кода ядра
|
||||||
|
|
||||||
|
Если kprobe не работает в вашем ядре (возможно, это ошибка апстрима или ядра ниже 4.8), то можно попробовать следующий способ:
|
||||||
|
|
||||||
|
Сначала добавьте Kernel SU в дерево исходного кода вашего ядра:
|
||||||
|
|
||||||
|
- Последний тэг(стабильный)
|
||||||
|
|
||||||
|
```sh
|
||||||
|
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -
|
||||||
|
```
|
||||||
|
|
||||||
|
- Основная ветвь(разработка)
|
||||||
|
|
||||||
|
```sh
|
||||||
|
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s main
|
||||||
|
```
|
||||||
|
|
||||||
|
- Выбранный тэг(Например, версия v0.5.2)
|
||||||
|
|
||||||
|
```sh
|
||||||
|
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s v0.5.2
|
||||||
|
```
|
||||||
|
|
||||||
|
Затем добавьте вызовы KernelSU в исходный код ядра, вот патч, на который можно сослаться:
|
||||||
|
|
||||||
|
```diff
|
||||||
|
diff --git a/fs/exec.c b/fs/exec.c
|
||||||
|
index ac59664eaecf..bdd585e1d2cc 100644
|
||||||
|
--- a/fs/exec.c
|
||||||
|
+++ b/fs/exec.c
|
||||||
|
@@ -1890,11 +1890,14 @@ static int __do_execve_file(int fd, struct filename *filename,
|
||||||
|
return retval;
|
||||||
|
}
|
||||||
|
|
||||||
|
+extern bool ksu_execveat_hook __read_mostly;
|
||||||
|
+extern int ksu_handle_execveat(int *fd, struct filename **filename_ptr, void *argv,
|
||||||
|
+ void *envp, int *flags);
|
||||||
|
+extern int ksu_handle_execveat_sucompat(int *fd, struct filename **filename_ptr,
|
||||||
|
+ void *argv, void *envp, int *flags);
|
||||||
|
static int do_execveat_common(int fd, struct filename *filename,
|
||||||
|
struct user_arg_ptr argv,
|
||||||
|
struct user_arg_ptr envp,
|
||||||
|
int flags)
|
||||||
|
{
|
||||||
|
+ if (unlikely(ksu_execveat_hook))
|
||||||
|
+ ksu_handle_execveat(&fd, &filename, &argv, &envp, &flags);
|
||||||
|
+ else
|
||||||
|
+ ksu_handle_execveat_sucompat(&fd, &filename, &argv, &envp, &flags);
|
||||||
|
return __do_execve_file(fd, filename, argv, envp, flags, NULL);
|
||||||
|
}
|
||||||
|
|
||||||
|
diff --git a/fs/open.c b/fs/open.c
|
||||||
|
index 05036d819197..965b84d486b8 100644
|
||||||
|
--- a/fs/open.c
|
||||||
|
+++ b/fs/open.c
|
||||||
|
@@ -348,6 +348,8 @@ SYSCALL_DEFINE4(fallocate, int, fd, int, mode, loff_t, offset, loff_t, len)
|
||||||
|
return ksys_fallocate(fd, mode, offset, len);
|
||||||
|
}
|
||||||
|
|
||||||
|
+extern int ksu_handle_faccessat(int *dfd, const char __user **filename_user, int *mode,
|
||||||
|
+ int *flags);
|
||||||
|
/*
|
||||||
|
* access() needs to use the real uid/gid, not the effective uid/gid.
|
||||||
|
* We do this by temporarily clearing all FS-related capabilities and
|
||||||
|
@@ -355,6 +357,7 @@ SYSCALL_DEFINE4(fallocate, int, fd, int, mode, loff_t, offset, loff_t, len)
|
||||||
|
*/
|
||||||
|
long do_faccessat(int dfd, const char __user *filename, int mode)
|
||||||
|
{
|
||||||
|
+ ksu_handle_faccessat(&dfd, &filename, &mode, NULL);
|
||||||
|
const struct cred *old_cred;
|
||||||
|
struct cred *override_cred;
|
||||||
|
struct path path;
|
||||||
|
diff --git a/fs/read_write.c b/fs/read_write.c
|
||||||
|
index 650fc7e0f3a6..55be193913b6 100644
|
||||||
|
--- a/fs/read_write.c
|
||||||
|
+++ b/fs/read_write.c
|
||||||
|
@@ -434,10 +434,14 @@ ssize_t kernel_read(struct file *file, void *buf, size_t count, loff_t *pos)
|
||||||
|
}
|
||||||
|
EXPORT_SYMBOL(kernel_read);
|
||||||
|
|
||||||
|
+extern bool ksu_vfs_read_hook __read_mostly;
|
||||||
|
+extern int ksu_handle_vfs_read(struct file **file_ptr, char __user **buf_ptr,
|
||||||
|
+ size_t *count_ptr, loff_t **pos);
|
||||||
|
ssize_t vfs_read(struct file *file, char __user *buf, size_t count, loff_t *pos)
|
||||||
|
{
|
||||||
|
ssize_t ret;
|
||||||
|
|
||||||
|
+ if (unlikely(ksu_vfs_read_hook))
|
||||||
|
+ ksu_handle_vfs_read(&file, &buf, &count, &pos);
|
||||||
|
+
|
||||||
|
if (!(file->f_mode & FMODE_READ))
|
||||||
|
return -EBADF;
|
||||||
|
if (!(file->f_mode & FMODE_CAN_READ))
|
||||||
|
diff --git a/fs/stat.c b/fs/stat.c
|
||||||
|
index 376543199b5a..82adcef03ecc 100644
|
||||||
|
--- a/fs/stat.c
|
||||||
|
+++ b/fs/stat.c
|
||||||
|
@@ -148,6 +148,8 @@ int vfs_statx_fd(unsigned int fd, struct kstat *stat,
|
||||||
|
}
|
||||||
|
EXPORT_SYMBOL(vfs_statx_fd);
|
||||||
|
|
||||||
|
+extern int ksu_handle_stat(int *dfd, const char __user **filename_user, int *flags);
|
||||||
|
+
|
||||||
|
/**
|
||||||
|
* vfs_statx - Get basic and extra attributes by filename
|
||||||
|
* @dfd: A file descriptor representing the base dir for a relative filename
|
||||||
|
@@ -170,6 +172,7 @@ int vfs_statx(int dfd, const char __user *filename, int flags,
|
||||||
|
int error = -EINVAL;
|
||||||
|
unsigned int lookup_flags = LOOKUP_FOLLOW | LOOKUP_AUTOMOUNT;
|
||||||
|
|
||||||
|
+ ksu_handle_stat(&dfd, &filename, &flags);
|
||||||
|
if ((flags & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT |
|
||||||
|
AT_EMPTY_PATH | KSTAT_QUERY_FLAGS)) != 0)
|
||||||
|
return -EINVAL;
|
||||||
|
```
|
||||||
|
|
||||||
|
В исходных кодах ядра можно найти эти четыре функции:
|
||||||
|
|
||||||
|
1. do_faccessat, обычно в `fs/open.c`.
|
||||||
|
2. do_execveat_common, обычно в `fs/exec.c`.
|
||||||
|
3. vfs_read, обычно в `fs/read_write.c`.
|
||||||
|
4. vfs_statx, обычно в `fs/stat.c`.
|
||||||
|
|
||||||
|
Если в вашем ядре нет `vfs_statx`, используйте вместо него `vfs_fstatat`:
|
||||||
|
|
||||||
|
```diff
|
||||||
|
diff --git a/fs/stat.c b/fs/stat.c
|
||||||
|
index 068fdbcc9e26..5348b7bb9db2 100644
|
||||||
|
--- a/fs/stat.c
|
||||||
|
+++ b/fs/stat.c
|
||||||
|
@@ -87,6 +87,8 @@ int vfs_fstat(unsigned int fd, struct kstat *stat)
|
||||||
|
}
|
||||||
|
EXPORT_SYMBOL(vfs_fstat);
|
||||||
|
|
||||||
|
+extern int ksu_handle_stat(int *dfd, const char __user **filename_user, int *flags);
|
||||||
|
+
|
||||||
|
int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat,
|
||||||
|
int flag)
|
||||||
|
{
|
||||||
|
@@ -94,6 +96,8 @@ int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat,
|
||||||
|
int error = -EINVAL;
|
||||||
|
unsigned int lookup_flags = 0;
|
||||||
|
|
||||||
|
+ ksu_handle_stat(&dfd, &filename, &flag);
|
||||||
|
+
|
||||||
|
if ((flag & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT |
|
||||||
|
AT_EMPTY_PATH)) != 0)
|
||||||
|
goto out;
|
||||||
|
```
|
||||||
|
|
||||||
|
Для ядер младше 4.17, если вы не можете найти `do_faccessat`, просто перейдите к определению системного вызова `faccessat` и поместите вызов туда:
|
||||||
|
|
||||||
|
```diff
|
||||||
|
diff --git a/fs/open.c b/fs/open.c
|
||||||
|
index 2ff887661237..e758d7db7663 100644
|
||||||
|
--- a/fs/open.c
|
||||||
|
+++ b/fs/open.c
|
||||||
|
@@ -355,6 +355,9 @@ SYSCALL_DEFINE4(fallocate, int, fd, int, mode, loff_t, offset, loff_t, len)
|
||||||
|
return error;
|
||||||
|
}
|
||||||
|
|
||||||
|
+extern int ksu_handle_faccessat(int *dfd, const char __user **filename_user, int *mode,
|
||||||
|
+ int *flags);
|
||||||
|
+
|
||||||
|
/*
|
||||||
|
* access() needs to use the real uid/gid, not the effective uid/gid.
|
||||||
|
* We do this by temporarily clearing all FS-related capabilities and
|
||||||
|
@@ -370,6 +373,8 @@ SYSCALL_DEFINE3(faccessat, int, dfd, const char __user *, filename, int, mode)
|
||||||
|
int res;
|
||||||
|
unsigned int lookup_flags = LOOKUP_FOLLOW;
|
||||||
|
|
||||||
|
+ ksu_handle_faccessat(&dfd, &filename, &mode, NULL);
|
||||||
|
+
|
||||||
|
if (mode & ~S_IRWXO) /* where's F_OK, X_OK, W_OK, R_OK? */
|
||||||
|
return -EINVAL;
|
||||||
|
```
|
||||||
|
|
||||||
|
Чтобы включить встроенный в KernelSU безопасный режим, необходимо также изменить `input_handle_event` в файле `drivers/input/input.c`:
|
||||||
|
|
||||||
|
:::tip
|
||||||
|
Настоятельно рекомендуется включить эту функцию, она очень помогает предотвратить циклическую загрузку!
|
||||||
|
:::
|
||||||
|
|
||||||
|
```diff
|
||||||
|
diff --git a/drivers/input/input.c b/drivers/input/input.c
|
||||||
|
index 45306f9ef247..815091ebfca4 100755
|
||||||
|
--- a/drivers/input/input.c
|
||||||
|
+++ b/drivers/input/input.c
|
||||||
|
@@ -367,10 +367,13 @@ static int input_get_disposition(struct input_dev *dev,
|
||||||
|
return disposition;
|
||||||
|
}
|
||||||
|
|
||||||
|
+extern bool ksu_input_hook __read_mostly;
|
||||||
|
+extern int ksu_handle_input_handle_event(unsigned int *type, unsigned int *code, int *value);
|
||||||
|
+
|
||||||
|
static void input_handle_event(struct input_dev *dev,
|
||||||
|
unsigned int type, unsigned int code, int value)
|
||||||
|
{
|
||||||
|
int disposition = input_get_disposition(dev, type, code, &value);
|
||||||
|
+
|
||||||
|
+ if (unlikely(ksu_input_hook))
|
||||||
|
+ ksu_handle_input_handle_event(&type, &code, &value);
|
||||||
|
|
||||||
|
if (disposition != INPUT_IGNORE_EVENT && type != EV_SYN)
|
||||||
|
add_input_randomness(type, code, value);
|
||||||
|
```
|
||||||
|
|
||||||
|
Наконец, снова соберите ядро, KernelSU должен работать хорошо.
|
||||||
169
website/docs/ru_RU/guide/installation.md
Normal file
169
website/docs/ru_RU/guide/installation.md
Normal file
@@ -0,0 +1,169 @@
|
|||||||
|
# Установка
|
||||||
|
|
||||||
|
## Проверьте, поддерживается ли ваше устройство
|
||||||
|
|
||||||
|
Скачайте приложение менеджера KernelSU с сайта [GitHub Releases](https://github.com/tiann/KernelSU/releases) или [Coolapk market](https://www.coolapk.com/apk/me.weishu.kernelsu) и установите его на устройство:
|
||||||
|
|
||||||
|
- Если приложение показывает `Unsupported`, это означает, что **Вы должны скомпилировать ядро самостоятельно**, KernelSU не будет и никогда не предоставит Вам загрузочный образ для прошивки.
|
||||||
|
- Если приложение показывает `Не установлено`, значит, ваши устройства официально поддерживаются KernelSU.
|
||||||
|
|
||||||
|
:::info
|
||||||
|
Для устройств, показывающих `Unsupported`, здесь находится [Unofficially-support-devices](unofficially-support-devices.md), вы можете скомпилировать ядро самостоятельно.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Резервное копирование стокового файла boot.img
|
||||||
|
|
||||||
|
Перед прошивкой необходимо создать резервную копию файла boot.img. Если возникнет ошибка загрузки, вы всегда сможете восстановить систему, перепрошив ее на заводскую загрузку с помощью fastboot.
|
||||||
|
|
||||||
|
::: warning
|
||||||
|
Прошивка может привести к потере данных, поэтому обязательно выполните этот шаг перед переходом к следующему шагу!!! При необходимости можно также создать резервную копию всех данных на телефоне.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Необходимые знания
|
||||||
|
|
||||||
|
### ADB и fastboot
|
||||||
|
|
||||||
|
По умолчанию в этом руководстве вы будете использовать инструменты ADB и fastboot, поэтому, если вы их не знаете, рекомендуем сначала воспользоваться поисковой системой, чтобы узнать о них.
|
||||||
|
|
||||||
|
### KMI
|
||||||
|
|
||||||
|
Kernel Module Interface (KMI), версии ядра с одинаковым KMI **совместимы** Это то, что в GKI означает "общий"; наоборот, если KMI отличается, то эти ядра несовместимы друг с другом, и прошивка образа ядра с другим KMI, чем у вашего устройства, может привести к bootloop.
|
||||||
|
|
||||||
|
В частности, для устройств GKI формат версии ядра должен быть следующим:
|
||||||
|
|
||||||
|
```txt
|
||||||
|
KernelRelease :=
|
||||||
|
Version.PatchLevel.SubLevel-AndroidRelease-KmiGeneration-suffix
|
||||||
|
w .x .y -zzz -k -something
|
||||||
|
```
|
||||||
|
|
||||||
|
`w.x-zz-k` - версия KMI. Например, если версия ядра устройства `5.10.101-android12-9-g30979850fc20`, то его KMI - `5.10-android12-9`; теоретически оно может нормально загружаться с другими ядрами KMI.
|
||||||
|
|
||||||
|
::: tip
|
||||||
|
Обратите внимание, что SubLevel в версии ядра не является частью KMI! Это означает, что `5.10.101-android12-9-g30979850fc20` имеет тот же KMI, что и `5.10.137-android12-9-g30979850fc20`!
|
||||||
|
:::
|
||||||
|
|
||||||
|
### Версия ядра и версия Android
|
||||||
|
|
||||||
|
Обратите внимание: **Версия ядра и версия Android - это не обязательно одно и то же!**
|
||||||
|
|
||||||
|
Если вы обнаружили, что версия ядра `android12-5.10.101`, а версия системы Android - Android 13 или другая, не удивляйтесь, поскольку номер версии системы Android не обязательно совпадает с номером версии ядра Linux; Номер версии ядра Linux обычно соответствует версии системы Android, поставляемой с **устройством при его поставке**. При последующем обновлении системы Android версия ядра, как правило, не меняется. При необходимости прошивки **укажите версию ядра!!!**.
|
||||||
|
|
||||||
|
## Введение
|
||||||
|
|
||||||
|
Существует несколько способов установки KernelSU, каждый из которых подходит для разных сценариев, поэтому выбирайте их по своему усмотрению.
|
||||||
|
|
||||||
|
1. Установка с помощью пользовательского Recovery (например, TWRP)
|
||||||
|
2. Установка с помощью приложения для прошивки ядра, например, Franco Kernel Manager
|
||||||
|
3. Установка с помощью fastboot с использованием boot.img, предоставленного KernelSU
|
||||||
|
4. Восстановить boot.img вручную и установить его
|
||||||
|
|
||||||
|
## Установка с помощью пользовательского Recovery
|
||||||
|
|
||||||
|
Необходимые условия: На устройстве должен быть установлен пользовательский Recovery, например TWRP; если его нет или доступен только официальный Recovery, воспользуйтесь другим способом.
|
||||||
|
|
||||||
|
Шаг:
|
||||||
|
|
||||||
|
1. С [Release page](https://github.com/tiann/KernelSU/releases) KernelSU загрузите zip-пакет, начинающийся с AnyKernel3, который соответствует версии вашего телефона; например, версия ядра телефона - `android12-5.10. 66`, то следует скачать файл `AnyKernel3-android12-5.10.66_yyy-MM.zip` (где `yyyy` - год, а `MM` - месяц).
|
||||||
|
2. Перезагрузите телефон в TWRP.
|
||||||
|
3. С помощью adb поместите AnyKernel3-*.zip в /sdcard телефона и выберите установку в графическом интерфейсе TWRP; или вы можете напрямую `adb sideload AnyKernel-*.zip` для установки.
|
||||||
|
|
||||||
|
PS. Данный способ подходит для любой установки (не ограничиваясь начальной установкой или последующими обновлениями), если вы используете TWRP.
|
||||||
|
|
||||||
|
## Установка с помощью Kernel Flasher
|
||||||
|
|
||||||
|
Необходимые условия: Ваше устройство должно быть рутованным. Например, вы установили Magisk, чтобы получить root, или установили старую версию KernelSU и должны обновить ее до другой версии; если ваше устройство не укоренено, попробуйте другие методы.
|
||||||
|
|
||||||
|
Шаг:
|
||||||
|
|
||||||
|
1. Загрузите zip-архив AnyKernel3; инструкции по загрузке см. в разделе *Установка с помощью пользовательского Recovery*.
|
||||||
|
2. Откройте приложение для прошивки ядра и используйте предоставленный AnyKernel3 zip для прошивки.
|
||||||
|
|
||||||
|
Если вы раньше не использовали приложение для прошивки ядра, то наиболее популярными являются следующие.
|
||||||
|
|
||||||
|
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. Этот способ более удобен при обновлении KernelSU и может быть выполнен без компьютера (сначала сделайте резервную копию!). .
|
||||||
|
|
||||||
|
## Установка с помощью boot.img, предоставленного KernelSU
|
||||||
|
|
||||||
|
Этот способ не требует наличия TWRP и root-прав на телефоне; он подходит для первой установки KernelSU.
|
||||||
|
|
||||||
|
### Найти подходящий boot.img
|
||||||
|
|
||||||
|
KernelSU предоставляет общий boot.img для устройств GKI, и его необходимо прошить в загрузочный раздел устройства.
|
||||||
|
|
||||||
|
Вы можете загрузить boot.img с [GitHub Release](https://github.com/tiann/KernelSU/releases), обратите внимание, что вы должны использовать правильную версию boot.img. Например, если на устройстве установлено ядро `android12-5.10.101`, то необходимо загрузить `android-5.10.101_yyy-MM.boot-<format>.img`. , необходимо загрузить `android-5.10.101_yyy-MM.boot-<format>.img`.(Соблюдайте соответствие KMI!).
|
||||||
|
|
||||||
|
Где `<format>` означает формат сжатия ядра в официальном boot.img, проверьте формат сжатия ядра в оригинальном boot.img, вы должны использовать правильный формат, например, `lz4`, `gz`; если вы используете неправильный формат сжатия, вы можете столкнуться с bootloop.
|
||||||
|
|
||||||
|
::: info
|
||||||
|
1. Вы можете использовать magiskboot для получения формата сжатия исходной загрузки; конечно, вы также можете спросить других, более опытных ребят с той же моделью, что и ваше устройство. Кроме того, формат сжатия ядра обычно не меняется, поэтому, если вы успешно загрузились с определенным форматом сжатия, вы можете попробовать этот формат позже.
|
||||||
|
2. Устройства Xiaomi обычно используют `gz` или **без сжатия**.
|
||||||
|
3. Для устройств Pixel следуйте приведенным ниже инструкциям.
|
||||||
|
:::
|
||||||
|
|
||||||
|
### прошить boot.img на устройство
|
||||||
|
|
||||||
|
Используйте `adb` для подключения устройства, затем выполните `adb reboot bootloader` для входа в режим fastboot, после чего используйте эту команду для прошивки KernelSU:
|
||||||
|
|
||||||
|
```sh
|
||||||
|
fastboot flash boot boot.img
|
||||||
|
```
|
||||||
|
|
||||||
|
::: info
|
||||||
|
Если устройство поддерживает `fastboot boot`, можно сначала использовать `fastboot boot boot.img`, чтобы попытаться использовать boot.img для загрузки системы. Если произойдет что-то непредвиденное, перезагрузите его снова для загрузки.
|
||||||
|
:::
|
||||||
|
|
||||||
|
### перезагрузка
|
||||||
|
|
||||||
|
После завершения прошивки необходимо перезагрузить устройство:
|
||||||
|
|
||||||
|
```sh
|
||||||
|
fastboot reboot
|
||||||
|
```
|
||||||
|
|
||||||
|
## Исправить boot.img вручную
|
||||||
|
|
||||||
|
Для некоторых устройств формат boot.img не так распространен, например, не `lz4`, `gz` или несжатый; наиболее типичным является Pixel, его boot.img имеет формат `lz4_legacy` со сжатием, ramdisk может быть `gz`, также может быть `lz4_legacy` со сжатием; в это время, если напрямую прошить boot.img, предоставляемый KernelSU, телефон может не загрузиться; в это время можно вручную исправить boot.img для достижения цели.
|
||||||
|
|
||||||
|
Как правило, существует два способа исправления:
|
||||||
|
|
||||||
|
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)
|
||||||
|
|
||||||
|
Среди них Android-Image-Kitchen подходит для работы на ПК, а magiskboot нуждается в сотрудничестве мобильного телефона.
|
||||||
|
|
||||||
|
### Подготовка
|
||||||
|
|
||||||
|
1. Получите стоковый boot.img вашего телефона; его можно получить у производителя устройства, возможно, вам понадобится [payload-dumper-go](https://github.com/ssut/payload-dumper-go)
|
||||||
|
2. Загрузите zip-файл AnyKernel3, предоставленный KernelSU, который соответствует версии KMI вашего устройства (можно обратиться к разделу *Установка с помощью пользовательского Recovery*).
|
||||||
|
3. Распакуйте пакет AnyKernel3 и получите файл `Image`, который является файлом ядра KernelSU.
|
||||||
|
|
||||||
|
### Использование Android-Image-Kitchen
|
||||||
|
|
||||||
|
1. Загрузите программу Android-Image-Kitchen на свой компьютер.
|
||||||
|
2. Поместите файл boot.img в корневую папку Android-Image-Kitchen.
|
||||||
|
3. Выполните команду `./unpackimg.sh boot.img` в корневом каталоге Android-Image-Kitchen, в результате чего boot.img распакуется и появятся некоторые файлы.
|
||||||
|
4. Замените `boot.img-kernel` в каталоге `split_img` тем `образом`, который вы извлекли из AnyKernel3 (обратите внимание на изменение названия на boot.img-kernel).
|
||||||
|
5. Выполните команду `./repackimg.sh` в корневом каталоге 在 Android-Image-Kitchen; Вы получите файл с именем `image-new.img`; Прошейте этот boot.img с помощью fastboot (см. предыдущий раздел).
|
||||||
|
|
||||||
|
### Использование magiskboot
|
||||||
|
|
||||||
|
1. Загрузите последнюю версию Magisk с [Release Page](https://github.com/topjohnwu/Magisk/releases).
|
||||||
|
2. Переименуйте Magisk-*.apk в Magisk-vesion.zip и разархивируйте его.
|
||||||
|
3. Закачайте `Magisk-v25.2/lib/arm64-v8a/libmagiskboot.so` на устройство с помощью adb: `adb push Magisk-v25.2/lib/arm64-v8a/libmagiskboot.so /data/local/tmp/magiskboot`.
|
||||||
|
4. Установите на устройство стоковый boot.img и образ в AnyKernel3.
|
||||||
|
5. Войдите в оболочку adb и перейдите в каталог `/data/local/tmp/`, затем `chmod +x magiskboot`.
|
||||||
|
6. Войдите в adb shell и cd директории `/data/local/tmp/`, выполните команду `./magiskboot unpack boot.img` для распаковки `boot.img`, вы получите файл `kernel`, это и есть ваше стоковое ядро.
|
||||||
|
7. Замените `kernel` на `Image`: `mv -f Image kernel`.
|
||||||
|
8. Выполните команду `./magiskboot repack boot.img`, чтобы перепаковать boot img, и получите файл `new-boot.img`, прошейте его на устройство с помощью fastboot.
|
||||||
|
|
||||||
|
## Другие методы
|
||||||
|
|
||||||
|
На самом деле все эти способы установки имеют только одну основную идею - **заменить исходное ядро на ядро, предоставляемое KernelSU**; если это возможно, то установка возможна; например, возможны следующие способы.
|
||||||
|
|
||||||
|
1. Сначала установить Magisk, получить права root через Magisk, а затем с помощью kernel flasher прошить AnyKernel zip из KernelSU.
|
||||||
|
2. Использовать какой-либо инструментарий для прошивки на ПК, чтобы прошить ядро, предоставленное KernelSU.
|
||||||
255
website/docs/ru_RU/guide/module.md
Normal file
255
website/docs/ru_RU/guide/module.md
Normal file
@@ -0,0 +1,255 @@
|
|||||||
|
# Модульные справочники
|
||||||
|
|
||||||
|
KernelSU предоставляет механизм модулей, позволяющий добиться эффекта модификации системного каталога при сохранении целостности системного раздела. Этот механизм принято называть "бессистемным".
|
||||||
|
|
||||||
|
Модульный механизм KernelSU практически аналогичен механизму Magisk. Если вы знакомы с разработкой модулей Magisk, то разработка модулей KernelSU очень похожа. Представление модулей ниже можно пропустить, достаточно прочитать [различия-с-magisk] (difference-with-magisk.md).
|
||||||
|
|
||||||
|
## Busybox
|
||||||
|
|
||||||
|
В комплект поставки KernelSU входит полнофункциональный бинарный файл BusyBox (включая полную поддержку SELinux). Исполняемый файл находится по адресу `/data/adb/ksu/bin/busybox`. BusyBox от KernelSU поддерживает переключаемый во время работы "ASH Standalone Shell Mode". Этот автономный режим означает, что при запуске в оболочке `ash` BusyBox каждая команда будет напрямую использовать апплет внутри BusyBox, независимо от того, что задано в качестве `PATH`. Например, такие команды, как `ls`, `rm`, `chmod` будут **НЕ** использовать то, что находится в `PATH` (в случае Android по умолчанию это будут `/system/bin/ls`, `/system/bin/rm` и `/system/bin/chmod` соответственно), а вместо этого будут напрямую вызывать внутренние апплеты BusyBox. Это гарантирует, что скрипты всегда будут выполняться в предсказуемом окружении и всегда будут иметь полный набор команд, независимо от того, на какой версии Android они выполняются. Чтобы заставить команду _не_ использовать BusyBox, необходимо вызвать исполняемый файл с полными путями.
|
||||||
|
|
||||||
|
Каждый сценарий оболочки, запущенный в контексте KernelSU, будет выполняться в оболочке BusyBox `ash` с включенным автономным режимом. Для сторонних разработчиков это касается всех загрузочных скриптов и скриптов установки модулей.
|
||||||
|
|
||||||
|
Для тех, кто хочет использовать эту возможность "Автономного режима" вне KernelSU, есть два способа включить ее:
|
||||||
|
|
||||||
|
1. Установите переменной окружения `ASH_STANDALONE` значение `1`<br>Пример: `ASH_STANDALONE=1 /data/adb/ksu/bin/busybox sh <script>`
|
||||||
|
2. Переключитесь с помощью параметров командной строки:<br>`/data/adb/ksu/bin/busybox sh -o standalone <script>`
|
||||||
|
|
||||||
|
Чтобы убедиться, что все последующие запуски оболочки `sh` также выполняются в автономном режиме, предпочтительным методом является вариант 1 (и это то, что KernelSU и менеджер KernelSU используют внутри), поскольку переменные окружения наследуются вплоть до дочерних процессов.
|
||||||
|
|
||||||
|
::: tip отличие от Magisk
|
||||||
|
|
||||||
|
BusyBox в KernelSU теперь использует бинарный файл, скомпилированный непосредственно из проекта Magisk. **Поэтому вам не нужно беспокоиться о проблемах совместимости между скриптами BusyBox в Magisk и KernelSU, поскольку они абсолютно одинаковы!
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Модули KernelSU
|
||||||
|
|
||||||
|
Модуль KernelSU - это папка, размещенная в каталоге `/data/adb/modules` и имеющая следующую структуру:
|
||||||
|
|
||||||
|
```txt
|
||||||
|
/data/adb/modules
|
||||||
|
├── .
|
||||||
|
├── .
|
||||||
|
|
|
||||||
|
├── $MODID <--- Папка имеет имя с идентификатором модуля
|
||||||
|
│ │
|
||||||
|
│ │ *** Идентификация модуля ***
|
||||||
|
│ │
|
||||||
|
│ ├── module.prop <--- В этом файле хранятся метаданные модуля
|
||||||
|
│ │
|
||||||
|
│ │ *** Основное содержимое ***
|
||||||
|
│ │
|
||||||
|
│ ├── system <--- Эта папка будет смонтирована, если skip_mount не существует
|
||||||
|
│ │ ├── ...
|
||||||
|
│ │ ├── ...
|
||||||
|
│ │ └── ...
|
||||||
|
│ │
|
||||||
|
│ │ *** Флаги состояния ***
|
||||||
|
│ │
|
||||||
|
│ ├── skip_mount <--- Если он существует, то KernelSU НЕ будет монтировать вашу системную папку
|
||||||
|
│ ├── disable <--- Если модуль существует, то он будет отключен
|
||||||
|
│ ├── remove <--- Если модуль существует, то при следующей перезагрузке он будет удален
|
||||||
|
│ │
|
||||||
|
│ │ *** Необязательные файлы ***
|
||||||
|
│ │
|
||||||
|
│ ├── post-fs-data.sh <--- Этот скрипт будет выполняться в post-fs-data
|
||||||
|
│ ├── service.sh <--- Этот скрипт будет выполняться в сервисе late_start
|
||||||
|
| ├── uninstall.sh <--- Этот скрипт будет выполнен, когда KernelSU удалит ваш модуль
|
||||||
|
│ ├── system.prop <--- Свойства из этого файла будут загружены в качестве системных свойств программой resetprop
|
||||||
|
│ ├── sepolicy.rule <--- Дополнительные пользовательские правила sepolicy
|
||||||
|
│ │
|
||||||
|
│ │ *** Автоматически генерируется, НЕЛЬЗЯ создавать или изменять вручную ***
|
||||||
|
│ │
|
||||||
|
│ ├── vendor <--- Символьная ссылка на $MODID/system/vendor
|
||||||
|
│ ├── product <--- Символьная ссылка на $MODID/system/product
|
||||||
|
│ ├── system_ext <--- Симлинк на $MODID/system/system_ext
|
||||||
|
│ │
|
||||||
|
│ │ *** Допускается использование любых дополнительных файлов/папок ***
|
||||||
|
│ │
|
||||||
|
│ ├── ...
|
||||||
|
│ └── ...
|
||||||
|
|
|
||||||
|
├── another_module
|
||||||
|
│ ├── .
|
||||||
|
│ └── .
|
||||||
|
├── .
|
||||||
|
├── .
|
||||||
|
```
|
||||||
|
|
||||||
|
::: tip различия с Magisk
|
||||||
|
KernelSU не имеет встроенной поддержки Zygisk, поэтому в модуле нет содержимого, связанного с Zygisk. Однако для поддержки модулей Zygisk можно использовать [ZygiskOnKernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU). В этом случае содержимое модуля Zygisk идентично содержимому, поддерживаемому Magisk.
|
||||||
|
:::
|
||||||
|
|
||||||
|
### module.prop
|
||||||
|
|
||||||
|
module.prop - это конфигурационный файл модуля. В KernelSU, если модуль не содержит этого файла, он не будет распознан как модуль. Формат этого файла следующий:
|
||||||
|
|
||||||
|
```txt
|
||||||
|
id=<string>
|
||||||
|
name=<string>
|
||||||
|
version=<string>
|
||||||
|
versionCode=<int>
|
||||||
|
author=<string>
|
||||||
|
description=<string>
|
||||||
|
```
|
||||||
|
|
||||||
|
- `id` должно соответствовать данному регулярному выражению: `^[a-zA-Z][a-zA-Z0-9._-]+$`<br>
|
||||||
|
экс: ✓ `a_module`, ✓ `a.module`, ✓ `module-101`, ✗ `a module`, ✗ `1_module`, ✗ `-a-module`<br>
|
||||||
|
Это **уникальный идентификатор** вашего модуля. Не следует изменять его после публикации.
|
||||||
|
- `versionCode` должен быть **целым**. Это используется для сравнения версий
|
||||||
|
- Другими, не упомянутыми выше, могут быть любые **однострочные** строки.
|
||||||
|
- Обязательно используйте тип перевода строки `UNIX (LF)`, а не `Windows (CR+LF)` или `Macintosh (CR)`.
|
||||||
|
|
||||||
|
### Сценарии командной оболочки
|
||||||
|
|
||||||
|
Чтобы понять разницу между `post-fs-data.sh` и `Service.sh`, прочитайте раздел [Boot Scripts](#boot-scripts). Для большинства разработчиков модулей `service.sh` должно быть достаточно, если вам нужно просто запустить загрузочный скрипт.
|
||||||
|
|
||||||
|
Во всех скриптах вашего модуля используйте `MODDIR=${0%/*}` для получения пути к базовому каталогу вашего модуля; **НЕ** кодируйте жестко путь к вашему модулю в скриптах.
|
||||||
|
|
||||||
|
::: tip различия с Magisk
|
||||||
|
С помощью переменной окружения KSU можно определить, выполняется ли сценарий в KernelSU или в Magisk. Если скрипт выполняется в KernelSU, то это значение будет равно true.
|
||||||
|
:::
|
||||||
|
|
||||||
|
### каталог `system`
|
||||||
|
|
||||||
|
После загрузки системы содержимое этого каталога будет наложено поверх раздела /system с помощью overlayfs. Это означает, что:
|
||||||
|
|
||||||
|
1. Файлы с теми же именами, что и в соответствующем каталоге в системе, будут перезаписаны файлами в этом каталоге.
|
||||||
|
2. Папки с теми же именами, что и в соответствующем каталоге в системе, будут объединены с папками в этом каталоге.
|
||||||
|
|
||||||
|
Если вы хотите удалить файл или папку в исходном каталоге системы, необходимо создать файл с тем же именем, что и файл/папка, в каталоге модуля с помощью команды `mknod filename c 0 0`. Таким образом, система overlayfs автоматически "забелит" этот файл, как если бы он был удален (раздел /system при этом фактически не изменится).
|
||||||
|
|
||||||
|
Вы также можете объявить в `customize.sh` переменную с именем `REMOVE`, содержащую список каталогов для выполнения операций удаления, и KernelSU автоматически выполнит команду `mknod <TARGET> c 0 0` в соответствующих каталогах модуля. Например:
|
||||||
|
|
||||||
|
```sh
|
||||||
|
REMOVE="
|
||||||
|
/system/app/YouTube
|
||||||
|
/system/app/Bloatware
|
||||||
|
"
|
||||||
|
```
|
||||||
|
|
||||||
|
В приведенном выше списке будут выполнены команды `mknod $MODPATH/system/app/YouTuBe c 0 0` и `mknod $MODPATH/system/app/Bloatware c 0 0`; при этом `/system/app/YouTube` и `/system/app/Bloatware` будут удалены после вступления модуля в силу.
|
||||||
|
|
||||||
|
Если вы хотите заменить каталог в системе, то необходимо создать каталог с тем же путем в каталоге модуля, а затем установить для этого каталога атрибут `setfattr -n trusted.overlay.opaque -v y <TARGET>`. Таким образом, система overlayfs автоматически заменит соответствующий каталог в системе (без изменения раздела /system).
|
||||||
|
|
||||||
|
Вы можете объявить в файле `customize.sh` переменную с именем `REPLACE`, содержащую список заменяемых каталогов, и KernelSU автоматически выполнит соответствующие операции в каталоге вашего модуля. Например:
|
||||||
|
|
||||||
|
REPLACE="
|
||||||
|
/system/app/YouTube
|
||||||
|
/system/app/Bloatware
|
||||||
|
"
|
||||||
|
|
||||||
|
В этом списке будут автоматически созданы каталоги `$MODPATH/system/app/YouTube` и `$MODPATH/system/app/Bloatware`, а затем выполнены команды `setfattr -n trusted.overlay.opaque -v y $MODPATH/system/app/YouTube` и `setfattr -n trusted.overlay.opaque -v y $MODPATH/system/app/Bloatware`. После вступления модуля в силу каталоги `/system/app/YouTube` и `/system/app/Bloatware` будут заменены на пустые.
|
||||||
|
|
||||||
|
::: tip различия с Magisk
|
||||||
|
|
||||||
|
В KernelSU бессистемный механизм реализован через overlayfs ядра, а в Magisk в настоящее время используется магическое монтирование (bind mount). Эти два метода реализации имеют существенные различия, но конечная цель у них одна: модификация файлов /system без физического изменения раздела /system.
|
||||||
|
:::
|
||||||
|
|
||||||
|
Если вы заинтересованы в использовании overlayfs, рекомендуется прочитать [документацию по overlayfs](https://docs.kernel.org/filesystems/overlayfs.html) ядра Linux.
|
||||||
|
|
||||||
|
### system.prop
|
||||||
|
|
||||||
|
Этот файл имеет тот же формат, что и `build.prop`. Каждая строка состоит из `[key]=[value]`.
|
||||||
|
|
||||||
|
### sepolicy.rule
|
||||||
|
|
||||||
|
Если для вашего модуля требуются дополнительные патчи sepolicy, добавьте эти правила в данный файл. Каждая строка в этом файле будет рассматриваться как утверждение политики.
|
||||||
|
|
||||||
|
## Установщик модулей
|
||||||
|
|
||||||
|
Инсталлятор модуля KernelSU - это модуль KernelSU, упакованный в zip-файл, который может быть прошит в APP-менеджере KernelSU. Простейший установщик модуля KernelSU - это просто модуль KernelSU, упакованный в zip-файл.
|
||||||
|
|
||||||
|
```txt
|
||||||
|
module.zip
|
||||||
|
│
|
||||||
|
├── customize.sh <--- (Необязательно, более подробно позже)
|
||||||
|
│ Этот скрипт будет использоваться в update-binary
|
||||||
|
├── ...
|
||||||
|
├── ... /* Остальные файлы модуля */
|
||||||
|
│
|
||||||
|
```
|
||||||
|
|
||||||
|
:::warning
|
||||||
|
Модуль KernelSU НЕ поддерживается для установки в пользовательское Recovery!!!
|
||||||
|
:::
|
||||||
|
|
||||||
|
### Персонализация
|
||||||
|
|
||||||
|
Если вам необходимо настроить процесс установки модуля, то в качестве опции вы можете создать в программе установки скрипт с именем `customize.sh`. Этот скрипт будет _источником_ (не исполняться!) сценария установщика модуля после извлечения всех файлов и применения стандартных разрешений и secontext. Это очень удобно, если ваш модуль требует дополнительной настройки в зависимости от ABI устройства, или вам необходимо установить специальные разрешения/секонтекст для некоторых файлов модуля.
|
||||||
|
|
||||||
|
Если вы хотите полностью контролировать и настраивать процесс установки, объявите `SKIPUNZIP=1` в файле `customize.sh`, чтобы пропустить все шаги установки по умолчанию. При этом ваш `customize.sh` будет сам отвечать за установку.
|
||||||
|
|
||||||
|
Сценарий `customize.sh` запускается в оболочке BusyBox `ash` KernelSU с включенным "Автономным режимом". Доступны следующие переменные и функции:
|
||||||
|
|
||||||
|
#### Переменные
|
||||||
|
|
||||||
|
- `KSU` (bool): переменная, отмечающая, что скрипт выполняется в окружении KernelSU, причем значение этой переменной всегда будет true. Ее можно использовать для различения KernelSU и Magisk.
|
||||||
|
- `KSU_VER` (string): строка версии текущего установленного KernelSU (например, `v0.4.0`)
|
||||||
|
- `KSU_VER_CODE` (int): код версии текущего установленного KernelSU в пользовательском пространстве (например, `10672`)
|
||||||
|
- `KSU_KERNEL_VER_CODE` (int): код версии текущей установленной KernelSU в пространстве ядра (например, `10672`)
|
||||||
|
- `BOOTMODE` (bool): в KernelSU всегда должно быть `true`.
|
||||||
|
- `MODPATH` (path): путь, по которому должны быть установлены файлы ваших модулей
|
||||||
|
- `TMPDIR` (path): место, где вы можете временно хранить файлы
|
||||||
|
- `ZIPFILE` (path): установочный zip-архив вашего модуля
|
||||||
|
- `ARCH` (string): архитектура процессора устройства. Значение: `arm`, `arm64`, `x86` или `x64`.
|
||||||
|
- `IS64BIT` (bool): `true`, если `$ARCH` имеет значение `arm64` или `x64`.
|
||||||
|
- `API` (int): уровень API (версия Android) устройства (например, `23` для Android 6.0)
|
||||||
|
|
||||||
|
::: warning
|
||||||
|
В KernelSU MAGISK_VER_CODE всегда равен 25200, а MAGISK_VER всегда равен v25.2. Пожалуйста, не используйте эти две переменные для определения того, запущен ли он на KernelSU или нет.
|
||||||
|
:::
|
||||||
|
|
||||||
|
#### Функции
|
||||||
|
|
||||||
|
```txt
|
||||||
|
ui_print <msg>
|
||||||
|
вывести <msg> на консоль
|
||||||
|
Избегайте использования 'echo', так как он не будет отображаться в консоли пользовательского recovery
|
||||||
|
|
||||||
|
abort <msg>
|
||||||
|
вывести сообщение об ошибке <msg> на консоль и завершить установку
|
||||||
|
Избегайте использования команды 'exit', так как в этом случае будут пропущены шаги очистки завершения установки
|
||||||
|
|
||||||
|
set_perm <target> <owner> <group> <permission> [context]
|
||||||
|
если [context] не задан, то по умолчанию используется "u:object_r:system_file:s0".
|
||||||
|
Эта функция является сокращением для следующих команд:
|
||||||
|
chown owner.group target
|
||||||
|
chmod permission target
|
||||||
|
chcon context target
|
||||||
|
|
||||||
|
set_perm_recursive <directory> <owner> <group> <dirpermission> <filepermission> [context]
|
||||||
|
если [context] не задан, то по умолчанию используется "u:object_r:system_file:s0".
|
||||||
|
для всех файлов в <directory> будет вызвана команда:
|
||||||
|
set_perm file owner group filepermission context
|
||||||
|
для всех каталогов в <directory> (включая себя самого), он вызовет:
|
||||||
|
set_perm dir owner group dirpermission context
|
||||||
|
```
|
||||||
|
|
||||||
|
## Загрузочные сценарии {#boot-scripts}
|
||||||
|
|
||||||
|
В KernelSU скрипты делятся на два типа в зависимости от режима их работы: режим post-fs-data и режим late_start service:
|
||||||
|
|
||||||
|
- режим post-fs-data
|
||||||
|
- Эта стадия является БЛОКИРУЮЩЕЙ. Процесс загрузки приостанавливается до завершения выполнения или по истечении 10 секунд.
|
||||||
|
- Сценарии запускаются до того, как будут смонтированы какие-либо модули. Это позволяет разработчику модулей динамически настраивать свои модули до того, как они будут смонтированы.
|
||||||
|
- Этот этап происходит до запуска Zygote, что практически означает, что все в Android
|
||||||
|
- **ПРЕДУПРЕЖДЕНИЕ:** использование `setprop` приведет к блокировке процесса загрузки! Вместо этого используйте `resetprop -n <prop_name> <prop_value>`.
|
||||||
|
- Запускайте скрипты в этом режиме только в случае необходимости.
|
||||||
|
- режим обслуживания late_start
|
||||||
|
- Эта стадия является НЕБЛОКИРУЮЩЕЙ. Ваш скрипт выполняется параллельно с остальным процессом загрузки.
|
||||||
|
- **Это рекомендуемый этап для запуска большинства скриптов.**
|
||||||
|
|
||||||
|
В KernelSU скрипты запуска делятся на два типа по месту их хранения: общие скрипты и скрипты модулей:
|
||||||
|
|
||||||
|
- Общие скрипты
|
||||||
|
- Размещаются в файлах `/data/adb/post-fs-data.d` или `/data/adb/service.d`.
|
||||||
|
- Выполняется только в том случае, если скрипт установлен как исполняемый (`chmod +x script.sh`)
|
||||||
|
- Скрипты в `post-fs-data.d` выполняются в режиме post-fs-data, а скрипты в `service.d` - в режиме late_start service.
|
||||||
|
- Модули не должны **НЕ** добавлять общие скрипты при установке
|
||||||
|
- Скрипты модуля
|
||||||
|
- Размещаются в отдельной папке модуля
|
||||||
|
- Выполняются только в том случае, если модуль включен
|
||||||
|
- `post-fs-data.sh` запускается в режиме post-fs-data, а `service.sh` - в режиме late_start service.
|
||||||
|
|
||||||
|
Все загрузочные скрипты будут выполняться в оболочке BusyBox `ash` от KernelSU с включенным "Автономным режимом".
|
||||||
50
website/docs/ru_RU/guide/rescue-from-bootloop.md
Normal file
50
website/docs/ru_RU/guide/rescue-from-bootloop.md
Normal file
@@ -0,0 +1,50 @@
|
|||||||
|
# Выход из циклической загрузки
|
||||||
|
|
||||||
|
При прошивке устройства могут возникать ситуации, когда устройство становится "окирпиченным". Теоретически, если использовать fastboot только для прошивки загрузочного раздела или установить неподходящие модули, из-за которых устройство не загружается, то это можно восстановить соответствующими операциями. В данном документе описаны некоторые экстренные методы восстановления работоспособности "окирпиченного" устройства.
|
||||||
|
|
||||||
|
## Кирпич путем перепрошивки загрузочного раздела
|
||||||
|
|
||||||
|
В KernelSU при прошивке загрузочного раздела могут возникнуть следующие ситуации:
|
||||||
|
|
||||||
|
1. Загрузочный образ прошивается в неправильном формате. Например, если формат загрузки телефона - `gz`, а вы прошили образ в формате `lz4`, то телефон не сможет загрузиться.
|
||||||
|
2. Для корректной загрузки телефона необходимо отключить проверку AVB (обычно для этого требуется стереть все данные на телефоне).
|
||||||
|
3. Ядро содержит ошибки или не подходит для прошивки телефона.
|
||||||
|
|
||||||
|
Независимо от ситуации, восстановить работоспособность можно путем **прошивки стокового загрузочного образа**. Поэтому в начале руководства по установке мы настоятельно рекомендуем создать резервную копию стокового загрузочного образа перед прошивкой. Если у вас нет резервной копии, вы можете получить оригинальную заводскую загрузку от других пользователей с таким же устройством, как у вас, или из официальной прошивки.
|
||||||
|
|
||||||
|
## Окирпичивание из-за модулей
|
||||||
|
|
||||||
|
Установка модулей может быть более распространенной причиной окирпичивания устройства, но мы должны серьезно предупредить вас: **Не устанавливайте модули из неизвестных источников**! Поскольку модули обладают правами root, они могут нанести непоправимый ущерб вашему устройству!
|
||||||
|
|
||||||
|
### Нормальные модули
|
||||||
|
|
||||||
|
Если вы прошили модуль, безопасность которого доказана, но он приводит к невозможности загрузки устройства, то такая ситуация легко восстанавливается в KernelSU без каких-либо проблем. KernelSU имеет встроенные механизмы для спасения устройства, в том числе следующие:
|
||||||
|
|
||||||
|
1. Обновление AB
|
||||||
|
2. Восстановление при нажатии клавиши уменьшения громкости
|
||||||
|
|
||||||
|
#### AB-обновление
|
||||||
|
|
||||||
|
Механизм обновления модулей в KernelSU основан на механизме AB-обновления, используемом в OTA-обновлениях системы Android. При установке нового модуля или обновлении существующего он не будет напрямую изменять текущий файл модуля. Вместо этого все модули будут встроены в другой образ обновления. После перезагрузки системы она попытается начать использовать этот образ обновления. Если система Android успешно загрузится, то модули будут действительно обновлены.
|
||||||
|
|
||||||
|
Поэтому самым простым и наиболее часто используемым методом спасения устройства является **принудительная перезагрузка**. Если после прошивки модуля не удается запустить систему, можно нажать и удерживать кнопку питания более 10 секунд, после чего система автоматически перезагрузится; после перезагрузки произойдет откат к состоянию до обновления модуля, а ранее обновленные модули будут автоматически отключены.
|
||||||
|
|
||||||
|
#### Спасение, с зажатой клавишей уменьшения громкости.
|
||||||
|
|
||||||
|
Если обновление AB не помогло решить проблему, можно попробовать использовать **Безопасный режим**. В безопасном режиме все модули отключены.
|
||||||
|
|
||||||
|
Войти в безопасный режим можно двумя способами:
|
||||||
|
|
||||||
|
1. Встроенный безопасный режим некоторых систем; некоторые системы имеют встроенный безопасный режим, доступ к которому осуществляется долгим нажатием кнопки уменьшения громкости, в то время как другие (например, MIUI) могут включить безопасный режим в Recovery. При входе в безопасный режим системы KernelSU также переходит в безопасный режим и автоматически отключает модули.
|
||||||
|
2. Встроенный безопасный режим KernelSU; метод работы заключается в том, что после первого экрана загрузки необходимо **непрерывно нажать клавишу уменьшения громкости более трех раз**. Обратите внимание, что именно нажать-отпустить, нажать-отпустить, нажать-отпустить, а не нажать и удерживать.
|
||||||
|
|
||||||
|
После входа в безопасный режим все модули на странице модулей менеджера KernelSU Manager отключаются, но можно выполнить операцию "деинсталляция" для удаления модулей, которые могут вызывать проблемы.
|
||||||
|
|
||||||
|
Встроенный безопасный режим реализован в ядре, поэтому вероятность пропуска ключевых событий из-за перехвата исключена. Однако для ядер, отличных от ГКИ, может потребоваться ручная интеграция кода, и за рекомендациями можно обратиться к официальной документации.
|
||||||
|
|
||||||
|
### Вредоносные модули
|
||||||
|
|
||||||
|
Если описанные выше способы не помогли спасти устройство, то высока вероятность того, что установленный модуль имеет вредоносные операции или повредил устройство иным способом. В этом случае есть только два варианта:
|
||||||
|
|
||||||
|
1. Стереть данные и прошить официальную систему.
|
||||||
|
2. Обратиться в сервисную службу.
|
||||||
30
website/docs/ru_RU/guide/unofficially-support-devices.md
Normal file
30
website/docs/ru_RU/guide/unofficially-support-devices.md
Normal file
@@ -0,0 +1,30 @@
|
|||||||
|
# Неофициально поддерживаемые устройства
|
||||||
|
|
||||||
|
::: warning
|
||||||
|
На этой странице представлены ядра для устройств, не поддерживающих ГКИ и поддерживающих KernelSU, которые поддерживаются другими разработчиками.
|
||||||
|
:::
|
||||||
|
|
||||||
|
::: warning
|
||||||
|
Эта страница предназначена только для поиска исходного кода, соответствующего вашему устройству, и **НЕ** означает, что исходный код был проверен _разработчиками KernelSU_. Вы должны использовать его на свой страх и риск.
|
||||||
|
:::
|
||||||
|
|
||||||
|
<script setup>
|
||||||
|
import data from '../repos.json'
|
||||||
|
</script>
|
||||||
|
|
||||||
|
<table>
|
||||||
|
<thead>
|
||||||
|
<tr>
|
||||||
|
<th>Сопровождающий</th>
|
||||||
|
<th>Репозиторий</th>
|
||||||
|
<th>Поддерживаемое устройство</th>
|
||||||
|
</tr>
|
||||||
|
</thead>
|
||||||
|
<tbody>
|
||||||
|
<tr v-for="repo in data" :key="repo.devices">
|
||||||
|
<td><a :href="repo.maintainer_link" target="_blank" rel="noreferrer">{{ repo.maintainer }}</a></td>
|
||||||
|
<td><a :href="repo.kernel_link" target="_blank" rel="noreferrer">{{ repo.kernel_name }}</a></td>
|
||||||
|
<td>{{ repo.devices }}</td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
21
website/docs/ru_RU/guide/what-is-kernelsu.md
Normal file
21
website/docs/ru_RU/guide/what-is-kernelsu.md
Normal file
@@ -0,0 +1,21 @@
|
|||||||
|
# Что такое KernelSU?
|
||||||
|
|
||||||
|
KernelSU - это root-решение для устройств Android GKI, работающее в режиме ядра и предоставляющее root-права пользовательским приложениям непосредственно в пространстве ядра.
|
||||||
|
|
||||||
|
## Особенности
|
||||||
|
|
||||||
|
Основной особенностью KernelSU является то, что он **основан на ядре**. KernelSU работает в режиме ядра, поэтому он может предоставить интерфейс ядра, которого раньше не было. Например, мы можем добавить аппаратную точку останова любому процессу в режиме ядра; мы можем получить доступ к физической памяти любого процесса без чьего-либо ведома; мы можем перехватить любой syscall в пространстве ядра; и т.д.
|
||||||
|
|
||||||
|
Кроме того, KernelSU предоставляет систему модулей через overlayfs, что позволяет загружать в систему пользовательские плагины. Также предусмотрен механизм модификации файлов в разделе `/system`.
|
||||||
|
|
||||||
|
## Как использовать
|
||||||
|
|
||||||
|
Пожалуйста, обратитесь к: [Установка](installation)
|
||||||
|
|
||||||
|
## Как собрать
|
||||||
|
|
||||||
|
[Как собрать](how-to-build)
|
||||||
|
|
||||||
|
## Обсуждение
|
||||||
|
|
||||||
|
- Telegram: [@KernelSU](https://t.me/KernelSU)
|
||||||
29
website/docs/ru_RU/index.md
Normal file
29
website/docs/ru_RU/index.md
Normal file
@@ -0,0 +1,29 @@
|
|||||||
|
---
|
||||||
|
layout: home
|
||||||
|
title: Основанное на ядре root-решение для Android
|
||||||
|
|
||||||
|
hero:
|
||||||
|
name: KernelSU
|
||||||
|
text: Основанное на ядре root-решение для Android
|
||||||
|
tagline: ""
|
||||||
|
image:
|
||||||
|
src: /logo.png
|
||||||
|
alt: KernelSU
|
||||||
|
actions:
|
||||||
|
- theme: brand
|
||||||
|
text: Начало работы
|
||||||
|
link: /ru_RU/guide/what-is-kernelsu
|
||||||
|
- theme: alt
|
||||||
|
text: Посмотр на GitHub
|
||||||
|
link: https://github.com/tiann/KernelSU
|
||||||
|
|
||||||
|
features:
|
||||||
|
- title: Основанный на ядре
|
||||||
|
details: KernelSU работает в режиме ядра Linux, он имеет больше контроля над пользовательскими приложениями.
|
||||||
|
- title: Контроль доступа по белому списку
|
||||||
|
details: Только приложение, которому предоставлено разрешение root, может получить доступ к `su`, другие приложения не могут воспринимать su.
|
||||||
|
- title: Ограниченные root-права
|
||||||
|
details: KernelSU позволяет вам настраивать uid, gid, группы, возможности и правила SELinux для su. Заприте root-власть в клетке.
|
||||||
|
- title: Модульность и открытый исходный код
|
||||||
|
details: KernelSU поддерживает модификацию /system бессистемно с помощью overlayfs и имеет открытый исходный код под лицензией GPL-3.
|
||||||
|
|
||||||
Reference in New Issue
Block a user