Repo cloned
This commit is contained in:
commit
11ea8025b0
214 changed files with 33943 additions and 0 deletions
56
docs/BG/faq_bg.md
Normal file
56
docs/BG/faq_bg.md
Normal file
|
|
@ -0,0 +1,56 @@
|
|||
# ЧЗВ
|
||||
|
||||
|
||||
## Какво е APatch?
|
||||
|
||||
APatch е root решение, подобно на Magisk или KernelSU, което обединява най-доброто от двете.
|
||||
Комбинира удобния и лесен метод за инсталиране на Magisk чрез boot.img с мощните възможности за пачване на ядрото на KernelSU.
|
||||
|
||||
## Каква е разликата между APatch и Magisk?
|
||||
|
||||
Magisk модифицира init системата с пач в ramdisk-а на boot image-а, докато APatch пачва директно ядрото.
|
||||
|
||||
|
||||
## APatch срещу KernelSU
|
||||
|
||||
KernelSU изисква изходния код на ядрото на устройството, който не винаги се предоставя от производителя. APatch работи само със стандартния boot.img.
|
||||
|
||||
|
||||
## APatch срещу Magisk, KernelSU
|
||||
|
||||
APatch позволява по избор да не се модифицира SELinux, което означава, че нишката на приложението може да бъде root-ната, без да е необходимо libsu и IPC.
|
||||
|
||||
Kernel Patch Module е включен.
|
||||
|
||||
|
||||
## Какво е Kernel Patch Module?
|
||||
|
||||
Някой код се изпълнява в Kernel Space, подобно на Loadable Kernel Modules (LKM).
|
||||
|
||||
Освен това, KPM позволява inline-hook и syscall-table-hook в kernel space.
|
||||
|
||||
За повече информация виж Как да напишем KPM
|
||||
|
||||
## Връзка между APatch и KernelPatch
|
||||
|
||||
APatch зависи от KernelPatch, наследява всичките му възможности и е разширен.
|
||||
|
||||
Можеш да инсталираш само KernelPatch, но това няма да ти позволи да използваш Magisk модули.
|
||||
|
||||
Научи повече за KernelPatch
|
||||
|
||||
## Какво е SuperKey?
|
||||
|
||||
KernelPatch добавя нов системен повик (syscall), който предоставя всички възможности на приложенията и програмите в потребителското пространство. Този syscall се нарича SuperCall.
|
||||
Когато приложение/програма се опита да извика SuperCall, трябва да предостави идентификационен ключ, наречен SuperKey.
|
||||
SuperCall може да бъде извикан успешно само ако SuperKey е правилен. Ако не е, извикващият остава незасегнат.
|
||||
|
||||
## А какво става със SELinux?
|
||||
|
||||
KernelPatch не модифицира SELinux контекста и го заобикаля чрез hook.
|
||||
Това позволява root достъп до нишка на Android в контекста на самото приложение, без да е необходимо да се използва libsu за стартиране на нов процес и IPC.
|
||||
Това е много удобно.
|
||||
|
||||
Освен това, APatch използва директно magiskpolicy за допълнителна поддръжка на SELinux.
|
||||
|
||||
|
||||
38
docs/ar/faq_ar.md
Normal file
38
docs/ar/faq_ar.md
Normal file
|
|
@ -0,0 +1,38 @@
|
|||
# الأسئلة الشائعة (FAQ)
|
||||
|
||||
## ما هو أباتش؟
|
||||
أباتش هو حل روت شبيه بـ ماجيسك أو كيرنل إس يو، يجمع بين أفضل ما في كليهما.
|
||||
يستخدم طريقة التثبيت السهلة الخاصة بـ ماجيسك من خلال `boot.img`، مع قدرات تعديل النواة القوية التي يوفرها كيرنل إس يو.
|
||||
|
||||
## ما الفرق بين أباتش وماجيسك؟
|
||||
- ماجيسك يقوم بتعديل نظام init عبر تعديل في ramdisk الخاص بملف boot image، بينما أباتش يقوم بتعديل النواة مباشرة.
|
||||
|
||||
## أباتش مقابل كيرنل إس يو
|
||||
- كيرنل إس يو يحتاج إلى الكود المصدري للنواة الخاصة بجهازك، والذي لا توفره الشركات دائمًا.
|
||||
أما أباتش فيعمل فقط باستخدام ملف `boot.img` الأصلي.
|
||||
|
||||
## أباتش مقابل ماجيسك وكيرنل إس يو
|
||||
- يسمح لك أباتش بعدم تعديل SELinux اختياريًا، مما يعني أن خيوط التطبيق (APP thread) يمكن أن تحصل على صلاحيات الروت، دون الحاجة إلى libsu أو IPC.
|
||||
- **وحدة تعديل النواة (Kernel Patch Module)** متوفرة.
|
||||
|
||||
## ما هي وحدة تعديل النواة (Kernel Patch Module)؟
|
||||
بعض الشيفرات تعمل ضمن مساحة النواة، مشابهة لـ LKM (وحدات نواة قابلة للتحميل).
|
||||
بالإضافة إلى ذلك، توفر KPM القدرة على تنفيذ inline-hook و syscall-table-hook ضمن مساحة النواة.
|
||||
|
||||
لمزيد من المعلومات، راجع [كيفية كتابة KPM](https://github.com/bmax121/KernelPatch/blob/main/doc/module.md)
|
||||
|
||||
## العلاقة بين أباتش وKernelPatch
|
||||
يعتمد أباتش على KernelPatch، ويرث جميع قدراته، وتم توسيعه ليشمل ميزات إضافية.
|
||||
يمكنك تثبيت KernelPatch فقط، لكنك لن تستطيع استخدام وحدات ماجيسك معه.
|
||||
|
||||
[تعرف أكثر على KernelPatch](https://github.com/bmax121/KernelPatch)
|
||||
|
||||
## ما هو SuperKey؟
|
||||
يضيف KernelPatch نداء نظامي (syscall) جديد يمنح كافة الصلاحيات للتطبيقات والبرامج في مساحة المستخدم (userspace)، وهذا النداء يسمى **SuperCall**.
|
||||
عندما يحاول تطبيق أو برنامج استدعاء **SuperCall**، يجب أن يقدم بيانات اعتماد وصول تُعرف باسم **SuperKey**.
|
||||
يتم تنفيذ **SuperCall** بنجاح فقط إذا كانت **SuperKey** صحيحة، وإن لم تكن كذلك فلن يتأثر المستدعي.
|
||||
|
||||
## ماذا عن SELinux؟
|
||||
- لا يقوم KernelPatch بتعديل سياق SELinux، بل يتجاوزه من خلال hook.
|
||||
هذا يسمح بعمل روت لخيط (thread) داخل التطبيق دون الحاجة لاستخدام libsu لبدء عملية جديدة ثم إجراء IPC، مما يجعله مريحًا جدًا.
|
||||
- بالإضافة إلى ذلك، يستخدم أباتش أداة magiskpolicy مباشرة لتوفير دعم إضافي لـ SELinux.
|
||||
49
docs/az/faq_az.md
Normal file
49
docs/az/faq_az.md
Normal file
|
|
@ -0,0 +1,49 @@
|
|||
# TSS
|
||||
|
||||
|
||||
## APatch nədir?
|
||||
APatch, hər ikisinin ən yaxşısını birləşdirən Magisk və ya KernelSU-ya bənzər kök həllidir.
|
||||
O, Magisk-in `boot.img` vasitəsilə rahat və asan quraşdırma metodunu KernelSU-nun güclü nüvə yamaqlamaq qabiliyyətləri ilə birləşdirir.
|
||||
|
||||
|
||||
## APatch və Magisk arasındakı fərq nədir?
|
||||
- Magisk başlanğıc sistemini nüvə imajınızın ramdiskindəki yamaq ilə dəyişdirir, APatch isə nüvəni birbaşa yamaqlayır.
|
||||
|
||||
|
||||
## APatch vs KernelSU
|
||||
- KernelSU cihazınızın nüvəsi üçün həmişə OEM tərəfindən təmin edilməyən mənbə kodunu tələb edir. APAtch yalnız sizin stok `boot.img` ilə işləyir.
|
||||
|
||||
|
||||
## APatch vs Magisk, KernelSU
|
||||
- APatch istəyə bağlı olaraq SELinux-u dəyişdirməməyə imkan verir, bu o deməkdir ki, Android proqramı köklənə bilər, libsu və IPC zəruri deyil.
|
||||
- **Nüvə Yamaq Modulu** təmin edilmişdir.
|
||||
|
||||
|
||||
## Nüvə Yamaq Modulu nədir?
|
||||
Bəzi kodlar Yüklənəbilən Nüvə Modulları (LKM) kimi Nüvə Məkanında işləyir.
|
||||
|
||||
Əlavə olaraq, KPM nüvə məkanında daxili-çəngəl, sistem-zəngi-cədvəli-çəngəlləri etmək imkanı verir.
|
||||
|
||||
Ətraflı məlumat üçün [KPM necə yazılır](https://github.com/bmax121/KernelPatch/blob/main/doc/module.md) bölməsinə baxın.
|
||||
|
||||
|
||||
## APatch və NüvəYamağı arasındakı əlaqə
|
||||
|
||||
APatch NüvəYamağından asılıdır, onun bütün imkanlarını miras alır və genişləndirilib.
|
||||
|
||||
Siz yalnızca NüvəYamağı quraşdıra bilərsiniz, lakin bu, Magisk modullarından istifadə etməyə imkan verməyəcək və superistifadəçi idarəçiliyindən istifadə etmək üçün AndroidYamağını quraşdırmalı və sonra onu silməlisiniz.
|
||||
|
||||
[NüvəYamağı haqqında ətraflı öyrənin](https://github.com/bmax121/KernelPatch)
|
||||
|
||||
|
||||
## SuperAçar nədir?
|
||||
NüvəYamağı istifadəçi məkanındakı tətbiq və proqramlara bütün imkanları təmin etmək üçün yeni sistem zəngi (syscall) əlavə edir, bu sistem zəngi **SuperZəng** adlanır.
|
||||
Tətbiq/proqram **SuperZəngi** işə salmağa çalışdıqda, o, **SuperAçar** kimi tanınan giriş etimadnaməsini təmin etməlidir.
|
||||
**SuperZəng** yalnız **SuperAçar** düzgün olduqda uğurla işə salına bilər və bu deyilsə, zəng edən şəxs təsirsiz qalacaq.
|
||||
|
||||
|
||||
## SELinux bəs?
|
||||
- NüvəYamağı SELinux kontekstini dəyişdirmir və çəngəl vasitəsilə SELinux-dan yan keçir.
|
||||
Bu, yeni prosesə başlamaq və sonra IPC yerinə yetirmək üçün libsu-dan istifadə etmədən proqram kontekstində Android mövzusunu kökləməyə imkan verir.
|
||||
Bu çox rahatdır.
|
||||
- Bundan əlavə, APatch əlavə SELinux dəstəyi təmin etmək üçün birbaşa magiskpolicy-dən istifadə edir.
|
||||
351
docs/cn/ap_module.md
Normal file
351
docs/cn/ap_module.md
Normal file
|
|
@ -0,0 +1,351 @@
|
|||
# 模块(APM)开发指南 {#introduction}
|
||||
|
||||
APatch 提供了一个模块机制（ AndroidPatch Module），它可以在保持系统分区完整性的同时达到修改系统分区的效果；这种机制通常被称之为 systemless。
|
||||
|
||||
APatch 的模块实现是从 [KernelSU](https://github.com/tiann/KernelSU) 模块复制并修改而来，感谢 KernelSU。
|
||||
具体修改的代码对应位置：
|
||||
KernelSU: [https://github.com/tiann/KernelSU/tree/main/userspace/ksud](https://github.com/tiann/KernelSU/tree/main/userspace/ksud)
|
||||
APatch: [https://github.com/bmax121/APatch/tree/main/apd](https://github.com/bmax121/APatch/tree/main/apd)
|
||||
|
||||
以下的文档内容也是从 KernelSU 的文档复制并修改而来，其中大部分的内容是一致。需要注意的主要有以下几个地方
|
||||
|
||||
1. 文件位置
|
||||
2. 环境变量
|
||||
3. SELinux 支持，APatch 直接使用了 magiskpolicy
|
||||
|
||||
APatch 的模块运作机制与 Magisk 几乎是一样的，如果你熟悉 Magisk 模块的开发，那么开发 APatch 的模块大同小异，你可以跳过下面有关模块的介绍，只需要了解 [APatch 模块与 Magisk 模块的异同](difference-with-magisk.md)。
|
||||
|
||||
<!-- ## 模块界面
|
||||
|
||||
APatch 的模块支持显示界面并与用户交互，请参阅 [WebUI 文档](module-webui.md)。 -->
|
||||
|
||||
## Busybox
|
||||
|
||||
APatch 提供了一个功能完备的 BusyBox 二进制文件（包括完整的SELinux支持）。可执行文件位于 `/data/adb/ap/bin/busybox`。
|
||||
APatch 的 BusyBox 支持运行时可切换的 "ASH Standalone Shell Mode"。
|
||||
这种独立模式意味着在运行 BusyBox 的 ash shell 时，每个命令都会直接使用 BusyBox 中内置的应用程序，而不管 PATH 设置为什么。
|
||||
例如，`ls`、`rm`、`chmod` 等命令将不会使用 PATH 中设置的命令（在Android的情况下，默认情况下分别为 `/system/bin/ls`、`/system/bin/rm` 和 `/system/bin/chmod`），而是直接调用 BusyBox 内置的应用程序。
|
||||
这确保了脚本始终在可预测的环境中运行，并始终具有完整的命令套件，无论它运行在哪个Android版本上。
|
||||
要强制一个命令不使用BusyBox，你必须使用完整路径调用可执行文件。
|
||||
|
||||
在 APatch 上下文中运行的每个 shell 脚本都将在 BusyBox 的 ash shell 中以独立模式运行。对于第三方开发者相关的内容，包括所有启动脚本和模块安装脚本。
|
||||
|
||||
对于想要在 APatch 之外使用这个“独立模式”功能的用户，有两种启用方法:
|
||||
|
||||
1. 设置环境变量 `ASH_STANDALONE` 为 `1`。例如：`ASH_STANDALONE=1 /data/adb/ap/bin/busybox sh <script>`
|
||||
2. 使用命令行选项切换：`/data/adb/ap/bin/busybox sh -o standalone <script>`
|
||||
|
||||
为了确保所有后续的 `sh` shell 都在独立模式下执行，第一种是首选方法（这也是 APatch 和 APatch 管理器内部使用的方法），因为环境变量会被继承到子进程中。
|
||||
|
||||
::: tip 与 KernelSU 的差异
|
||||
|
||||
busybox 的位置由 /data/adb/ksu/bin/busybox 改到了 /data/adb/ap/bin/busybox
|
||||
:::
|
||||
|
||||
::: tip 与 Magisk 的差异
|
||||
|
||||
APatch 的 BusyBox 现在是直接使用 Magisk 项目编译的二进制文件，**感谢 Magisk！**
|
||||
因此，你完全不用担心 BusyBox 脚本与在 Magisk 和 APatch 之间的兼容问题，因为他们是完全一样的！
|
||||
:::
|
||||
|
||||
## APatch 模块 {#APatch-modules}
|
||||
|
||||
APatch 模块就是一个放置在 `/data/adb/modules` 内且满足如下结构的文件夹：
|
||||
|
||||
```txt
|
||||
/data/adb/modules
|
||||
├── .
|
||||
├── .
|
||||
|
|
||||
├── $MODID <--- 模块的文件夹名称与模块 ID 相同
|
||||
│ │
|
||||
│ │ *** 模块配置文件 ***
|
||||
│ │
|
||||
│ ├── module.prop <--- 此文件保存模块相关的一些配置，如模块 ID、版本等
|
||||
│ │
|
||||
│ │ *** 模块内容 ***
|
||||
│ │
|
||||
│ ├── system <--- 这个文件夹通常会被挂载到系统
|
||||
│ │ ├── ...
|
||||
│ │ ├── ...
|
||||
│ │ └── ...
|
||||
│ │
|
||||
│ │ *** 标记文件 ***
|
||||
│ │
|
||||
│ ├── skip_mount <--- 如果这个文件存在，那么模块的 `/system` 将不会被挂载
|
||||
│ ├── disable <--- 如果这个文件存在，那么模块会被禁用
|
||||
│ ├── remove <--- 如果这个文件存在，下次重启的时候模块会被移除
|
||||
│ │
|
||||
│ │ *** 可选文件 ***
|
||||
│ │
|
||||
│ ├── post-fs-data.sh <--- 这个脚本将会在 post-fs-data 模式下运行
|
||||
│ ├── post-mount.sh <--- 这个脚本将会在 post-mount 模式下运行
|
||||
│ ├── service.sh <--- 这个脚本将会在 late_start 服务模式下运行
|
||||
│ ├── boot-completed.sh <--- 这个脚本将会在 Android 系统启动完毕后以服务模式运行
|
||||
| ├── uninstall.sh <--- 这个脚本将会在模块被卸载时运行
|
||||
| ├── action.sh <--- 这个脚本将会在管理器模块中点击 Action 时运行
|
||||
│ ├── system.prop <--- 这个文件中指定的属性将会在系统启动时通过 resetprop 更改
|
||||
│ ├── sepolicy.rule <--- 这个文件中的 SELinux 策略将会在系统启动时加载
|
||||
│ │
|
||||
│ │ *** 自动生成的目录，不要手动创建或者修改！ ***
|
||||
│ │
|
||||
│ ├── vendor <--- A symlink to $MODID/system/vendor
|
||||
│ ├── product <--- A symlink to $MODID/system/product
|
||||
│ ├── system_ext <--- A symlink to $MODID/system/system_ext
|
||||
│ │
|
||||
│ │ *** Any additional files / folders are allowed ***
|
||||
│ │
|
||||
│ ├── ...
|
||||
│ └── ...
|
||||
|
|
||||
├── another_module
|
||||
│ ├── .
|
||||
│ └── .
|
||||
├── .
|
||||
├── .
|
||||
```
|
||||
|
||||
::: tip 与 Magisk 的差异
|
||||
APatch 没有内置的针对 Zygisk 的支持，因此模块中没有 Zygisk 相关的内容
|
||||
<!-- ，但你可以通过 [ZygiskNext](https://github.com/Dr-TSNG/ZygiskNext) 来支持 Zygisk 模块，此时 Zygisk 模块的内容与 Magisk 所支持的 Zygisk 是完全相同的。 -->
|
||||
:::
|
||||
|
||||
### module.prop
|
||||
|
||||
module.prop 是一个模块的配置文件，在 APatch 中如果模块中不包含此文件，那么它将不被认为是一个模块；此文件的格式如下：
|
||||
|
||||
```txt
|
||||
id=<string>
|
||||
name=<string>
|
||||
version=<string>
|
||||
versionCode=<int>
|
||||
author=<string>
|
||||
description=<string>
|
||||
```
|
||||
|
||||
- id 必须与这个正则表达式匹配：`^[a-zA-Z][a-zA-Z0-9._-]+$` 例如：✓ `a_module`，✓ `a.module`，✓ `module-101`，✗ `a module`，✗ `1_module`，✗ `-a-module`。这是您的模块的唯一标识符，发布后不应更改。
|
||||
- versionCode 必须是一个整数，用于比较版本。
|
||||
- 其他未在上面提到的内容可以是任何单行字符串。
|
||||
- 请确保使用 UNIX（LF）换行类型，而不是Windows（CR + LF）或 Macintosh（CR）。
|
||||
|
||||
### Shell 脚本 {#shell-scripts}
|
||||
|
||||
请阅读 [启动脚本](#boot-scripts) 一节，以了解 `post-fs-data.sh`, `post-mount.sh`, `service.sh` 和 `boot-completed.sh` 之间的区别。对于大多数模块开发者来说，如果您只需要运行一个启动脚本，`service.sh` 应该已经足够了。
|
||||
|
||||
在您的模块的所有脚本中，请使用 `MODDIR=${0%/*}`来获取您的模块的基本目录路径；请勿在脚本中硬编码您的模块路径。
|
||||
|
||||
:::tip 与 Magisk, KernelSU 的差异
|
||||
你可以通过环境变量 `APATCH` 来判断脚本是否运行在 APatch 中，如果运行在 APatch，这个值会被设置为 `true`。
|
||||
:::
|
||||
|
||||
### `system` 目录 {#system-directories}
|
||||
|
||||
这个目录的内容会在系统启动后，以 `overlayfs` 的方式叠加在系统的 `/system` 分区之上，这意味着：
|
||||
|
||||
1. 系统中对应目录的同名文件会被此目录的文件覆盖。
|
||||
2. 系统中对应目录的同名文件夹会与此目录的文件夹合并。
|
||||
|
||||
如果你想删掉系统原来目录某个文件或者文件夹，你需要在模块目录通过 `mknod filename c 0 0` 来创建一个 `filename` 的同名文件；这样 overlayfs 系统会自动 whiteout 等效删除此文件（`/system` 分区并没有被更改）。
|
||||
|
||||
你也可以在 `customize.sh` 中声明一个名为 `REMOVE` 并且包含一系列目录的变量来执行删除操作，APatch 会自动为你在模块对应目录执行 `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` 并且包含一系列目录的变量来执行替换操作，APatch 会自动为你在模块对应目录执行相关操作。例如：
|
||||
|
||||
```sh
|
||||
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 的差异
|
||||
|
||||
APatch 的 systemless 机制是通过内核的 overlayfs 实现的，而 Magisk 当前则是通过 magic mount (bind mount)，二者实现方式有着巨大的差异，但最终的目标实际上是一致的：不修改物理的 `/system` 分区但实现修改 `/system` 文件。
|
||||
:::
|
||||
|
||||
如果你对 overlayfs 感兴趣，建议阅读 Linux Kernel 关于 [overlayfs 的文档](https://docs.kernel.org/filesystems/overlayfs.html)
|
||||
|
||||
### system.prop
|
||||
|
||||
这个文件的格式与 `build.prop` 完全相同：每一行都是 `[key]=[value]` 的形式。
|
||||
|
||||
### sepolicy.rule
|
||||
|
||||
如果您的模块需要一些额外的 SELinux 策略补丁，请将这些规则添加到此文件中。这个文件中的每一行都将被视为一个策略语句。
|
||||
|
||||
## 模块安装包 {#module-installer}
|
||||
|
||||
APatch 的模块安装包就是一个可以通过 APatch 管理器 APP 刷入的 zip 文件，此 zip 文件的格式如下：
|
||||
|
||||
```txt
|
||||
module.zip
|
||||
│
|
||||
├── customize.sh <--- (Optional, more details later)
|
||||
│ This script will be sourced by update-binary
|
||||
├── ...
|
||||
├── ... /* 其他模块文件 */
|
||||
│
|
||||
```
|
||||
|
||||
:::warning
|
||||
APatch 模块不支持在 Recovery 中安装！！
|
||||
:::
|
||||
|
||||
### 定制安装过程 {#customizing-installation}
|
||||
|
||||
如果你想控制模块的安装过程，可以在模块的目录下创建一个名为 `customize.sh` 的文件，这个脚本将会在模块被解压后**导入**到当前 shell 中，如果你的模块需要根据设备的 API 版本或者设备构架做一些额外的操作，那这个脚本将非常有用。
|
||||
|
||||
如果你想完全控制脚本的安装过程，你可以在 `customize.sh` 中声明 `SKIPUNZIP=1` 来跳过所有的默认安装步骤；此时，你需要自行处理所有安装过程（如解压模块，设置权限等）
|
||||
|
||||
`customize.sh` 脚本以“独立模式”运行在 APatch 的 BusyBox `ash` shell 中。你可以使用如下变量和函数：
|
||||
|
||||
#### 变量 {#variables}
|
||||
|
||||
- `KERNELPATCH` (bool): 标记此脚本运行在 APatch 环境下，此变量的值将永远为 `true`
|
||||
- `KERNEL_VERSION` (hex): 从 KernelPatch 继承，内核版本号 (如： `50a01` 是指 5.10.1)
|
||||
- `KERNELPATCH_VERSION` (hex): 从 KernelPatch 继承，KernelPatch 版本号 (如： `a05` 是指 0.10.5)
|
||||
- `SUPERKEY` (string): 从 KernelPatch 继承，用于调用 kpatch 或者 supercall
|
||||
|
||||
- `APATCH` (bool): 标记此脚本运行在 APatch 环境下，此变量的值将永远为 `true`
|
||||
- `APATCH_VER_CODE` (int): APatch 当前的版本号 (如. `10672`)
|
||||
- `APATCH_VER` (string): APatch 当前的版本名 (如. `10672`)
|
||||
|
||||
- `BOOTMODE` (bool): 此变量在 APatch 中永远为 `true`
|
||||
- `MODPATH` (path): 当前模块的安装目录
|
||||
- `TMPDIR` (path): 可以存放临时文件的目录
|
||||
- `ZIPFILE` (path): 当前模块的安装包文件
|
||||
- `ARCH` (string): 设备的 CPU 构架，只有 `arm64`
|
||||
- `IS64BIT` (bool): 是否是 64 位设备
|
||||
- `API` (int): 当前设备的 Android API 版本 (如：Android 6.0 上为 `23`)
|
||||
|
||||
::: warning
|
||||
`MAGISK_VER_CODE` 在 APatch 为 `27000`，`MAGISK_VER` 则为 `27.0`
|
||||
:::
|
||||
|
||||
#### 函数 {#functions}
|
||||
|
||||
```txt
|
||||
ui_print <msg>
|
||||
print <msg> to console
|
||||
Avoid using 'echo' as it will not display in custom recovery's console
|
||||
|
||||
abort <msg>
|
||||
print error message <msg> to console and terminate the installation
|
||||
Avoid using 'exit' as it will skip the termination cleanup steps
|
||||
|
||||
set_perm <target> <owner> <group> <permission> [context]
|
||||
if [context] is not set, the default is "u:object_r:system_file:s0"
|
||||
this function is a shorthand for the following commands:
|
||||
chown owner.group target
|
||||
chmod permission target
|
||||
chcon context target
|
||||
|
||||
set_perm_recursive <directory> <owner> <group> <dirpermission> <filepermission> [context]
|
||||
if [context] is not set, the default is "u:object_r:system_file:s0"
|
||||
for all files in <directory>, it will call:
|
||||
set_perm file owner group filepermission context
|
||||
for all directories in <directory> (including itself), it will call:
|
||||
set_perm dir owner group dirpermission context
|
||||
```
|
||||
|
||||
## 启动脚本 {#boot-scripts}
|
||||
|
||||
在 APatch 中，根据脚本运行模式的不同分为两种：post-fs-data 模式和 late_start 服务模式。
|
||||
|
||||
- post-fs-data 模式
|
||||
- 这个阶段是阻塞的。在执行完成之前或者 10 秒钟之后，启动过程会暂停。
|
||||
- 脚本在任何模块被挂载之前运行。这使得模块开发者可以在模块被挂载之前动态地调整它们的模块。
|
||||
- 这个阶段发生在 Zygote 启动之前。
|
||||
- 使用 setprop 会导致启动过程死锁！请使用 `resetprop -n <prop_name> <prop_value>` 代替。
|
||||
- **只有在必要时才在此模式下运行脚本**。
|
||||
|
||||
- late_start 服务模式
|
||||
- 这个阶段是非阻塞的。你的脚本会与其余的启动过程**并行**运行。
|
||||
- **大多数脚本都建议在这种模式下运行**。
|
||||
|
||||
在 APatch 中，启动脚本根据存放位置的不同还分为两种：通用脚本和模块脚本。
|
||||
|
||||
- 通用脚本
|
||||
- 放置在 `/data/adb/post-fs-data.d`, `/data/adb/post-mount.d`, `/data/adb/service.d` 或 `/data/adb/boot-completed.d` 中。
|
||||
- 只有在脚本被设置为可执行（`chmod +x script.sh`）时才会被执行。
|
||||
- 在 `post-fs-data.d` 中的脚本以 post-fs-data 模式运行，在 `service.d` 中的脚本以 late_start 服务模式运行。
|
||||
- 模块**不应**在安装过程中添加通用脚本。
|
||||
|
||||
- 模块脚本
|
||||
- 放置在模块自己的文件夹中。
|
||||
- 只有当模块被启用时才会执行。
|
||||
- `post-fs-data.sh` 以 post-fs-data 模式运行，`post-mount.sh` 以 post-mount 模式运行，而 `service.sh` 则以 late_start 服务模式运行，`boot-completed` 在 Android 系统启动完毕后以服务模式运行。
|
||||
|
||||
所有启动脚本都将在 APatch 的 BusyBox ash shell 中运行，并启用“独立模式”。
|
||||
|
||||
|
||||
### 启动脚本的流程解疑 {#Boot-scripts-process-explanation}
|
||||
以下是 Android 的相关启动流程（部分省略），其中包括了 Apatch 的操作（带前导星号），应该能帮助你更好地理解这些启动脚本的用途：
|
||||
|
||||
```txt
|
||||
0. BootLoader (nothing on sceen)
|
||||
load patched boot.img
|
||||
...
|
||||
|
||||
1. kernel init (oem logo on screen)
|
||||
mount /dev, /dev/pts, /proc, /sys, etc.
|
||||
property-init -> read default props
|
||||
read init.rc
|
||||
...
|
||||
early-init -> init -> late_init
|
||||
early-fs
|
||||
start vold
|
||||
fs
|
||||
mount /vendor, /system, /persist, etc.
|
||||
post-fs-data
|
||||
*safe mode check
|
||||
*execute general scripts in post-fs-data.d/
|
||||
*load sepolicy.rule -> magiskpolicy
|
||||
*mount tmpfs, devpts
|
||||
*execute module scripts post-fs-data.sh
|
||||
**(Zygisk)./bin/zygisk-ptrace64 monitor
|
||||
*(pre)load system.prop (same as `resetprop -n`)
|
||||
*remount modules /system
|
||||
*execute general scripts in post-mount.d/
|
||||
*execute module scripts post-mount.sh
|
||||
zygote-start
|
||||
load_all_props_action
|
||||
*execute resetprop (actual set props for resetprop with -n option)
|
||||
... -> boot
|
||||
class_start core
|
||||
start-service logd, console, vold, etc.
|
||||
class_start main
|
||||
start-service adb, netd, zygote, etc.
|
||||
|
||||
2. kernel2user init (rom animation on screen, start by service bootanim)
|
||||
*execute general scripts in service.d/
|
||||
*execute module scripts service.sh
|
||||
*set props for resetprop without -p option
|
||||
**(Zygisk) hook zygote (start zygiskd)
|
||||
**(Zygisk) mount zygisksu/module.prop
|
||||
start system apps (autostart)
|
||||
...
|
||||
boot complete (broadcast ACTION_LOCKED_BOOT_COMPLETED event)
|
||||
*execute general scripts in boot-completed.d/
|
||||
*execute module scripts boot-completed.sh
|
||||
|
||||
3. User operable (lock screen)
|
||||
input password to decrypt /data/data
|
||||
*actual set props for resetprop with -p option
|
||||
start user apps (autostart)
|
||||
```
|
||||
|
||||
如果你对 Android 的 init 语言感兴趣，推荐阅读[文档](https://android.googlesource.com/platform/system/core/+/master/init/README.md)
|
||||
47
docs/cn/faq_cn.md
Normal file
47
docs/cn/faq_cn.md
Normal file
|
|
@ -0,0 +1,47 @@
|
|||
# 常见问题解答
|
||||
|
||||
## 什么是APatch？
|
||||
|
||||
APatch是一种类似于Magisk或KernelSU的root解决方案，但APatch提供更多功能。
|
||||
APatch分别结合了Magisk方便易用的通过`boot.img`安装的方法，和KernelSU强大的内核修补能力。
|
||||
|
||||
## APatch与Magisk的区别？
|
||||
|
||||
- Magisk对启动映像中的ramdisk进行补丁，以修改init系统。而APatch则直接修补Linux内核。
|
||||
|
||||
## APatch与KernelSU的区别？
|
||||
|
||||
- KernelSU需要您设备的内核的源代码，而OEM并不总是提供该源码。而APatch仅需要您的设备原本的`boot.img`。
|
||||
|
||||
## APatch与Magisk、KernelSU的区别？
|
||||
|
||||
- APatch可选择不修改SELinux，这意味着Android应用程序线程可以被root，无需libsu和IPC。
|
||||
- APatch提供**Kernel Patch Module（KP模块）**。
|
||||
|
||||
## 什么是Kernel Patch Module（KP模块）？
|
||||
|
||||
一些代码在内核空间运行，类似于Loadable Kernel Modules（LKM）。
|
||||
|
||||
此外，KPM提供在内核空间进行内联hook、系统调用表hook的能力。
|
||||
|
||||
更多相关信息，请参阅[如何编写KPM](https://github.com/bmax121/KernelPatch/blob/main/doc/module.md)
|
||||
|
||||
## APatch与KernelPatch的关系
|
||||
|
||||
APatch依赖于KernelPatch，继承了其所有功能并进行了扩展。
|
||||
|
||||
您可以仅安装KernelPatch，但如此将不允许您使用Magisk模块。
|
||||
要使用超级用户管理，您需要安装AndroidPatch，然后卸载KernelPatch。
|
||||
|
||||
[了解更多关于KernelPatch的信息](https://github.com/bmax121/KernelPatch)
|
||||
|
||||
## 什么是SuperKey（超级密钥）？
|
||||
|
||||
KernelPatch 添加了一个新的系统调用（syscall），为应用程序和用户空间中的程序提供所有功能，此系统调用称为SuperCall。
|
||||
当应用程序/程序尝试调用SuperCall时，它需要提供访问凭据，称为SuperKey。
|
||||
只有当SuperKey正确时，才能成功调用 SuperCall。否则，调用方将不受影响。
|
||||
|
||||
## 关于SELinux如何处理？
|
||||
|
||||
- KernelPatch不修改SELinux上下文，而是通过hook绕过SELinux。 这允许您在应用程序上下文中root Android线程，无需使用libsu启动新进程，然后执行IPC。这非常方便。
|
||||
- 此外，APatch直接利用magiskpolicy提供额外的SELinux支持。
|
||||
48
docs/cn_tw/faq_cn_tw.md
Normal file
48
docs/cn_tw/faq_cn_tw.md
Normal file
|
|
@ -0,0 +1,48 @@
|
|||
# 〈常見問題集〉
|
||||
|
||||
|
||||
## 什麼是 APatch？
|
||||
APatch 為一套汲取 Magisk、KernelSU 優勢於一身的 Root 解決方案。
|
||||
不僅保留 Magisk 自身便捷、修補 `boot.img` 即用的特性，也有 KernelSU 強大的核心修補功能。
|
||||
|
||||
|
||||
## APatch 與 Magisk 的差別為何？
|
||||
- Magisk 會先調用 boot 修補鏡像的 ramdisk，再修改 init 系統；APatch 則經由修補鏡像，直接修改核心本身。
|
||||
|
||||
|
||||
## APatch vs KernelSU
|
||||
- KernelSU 依託 OEM 廠商提供的裝置核心原始碼，但並非每間廠商都會提供；而 APatch 只需修補原廠 `boot.img`。
|
||||
|
||||
|
||||
## APatch vs Magisk、KernelSU
|
||||
- APatch 可選擇不修改 SELinux，但仍讓應用程式執行緒調用 Root 權限。過程不需要 libsu 以及 IPC。
|
||||
- 支援**核心修補模組**。
|
||||
|
||||
|
||||
## 什麼是核心修補模組？
|
||||
**核心修補模組**為一套執行在核心空間的程式片段——類似於裝載式核心模組（LKM）——。
|
||||
|
||||
包括 inline-hook、syscall-table-hook，核心修補模組也能做到。
|
||||
|
||||
更多詳情，請參閱[〈如何編寫核心修補模組？〉](https://github.com/bmax121/KernelPatch/blob/main/doc/module.md)（英語）。
|
||||
|
||||
|
||||
## APatch 和 KernelPatch 的關係
|
||||
|
||||
APatch 基於 KernelPatch。繼承 KernelPatch 特性的基礎之上，新增更多功能。
|
||||
|
||||
你也能選擇只安裝 KernelPatch，但這樣就沒辦法使用 Magisk 模組，且包括管理超級使用者權限在內的功能，你都必須解除安裝 KernelPatch 後再安裝 AndroidPatch。
|
||||
|
||||
[深入了解 KernelPatch](https://github.com/bmax121/KernelPatch)
|
||||
|
||||
|
||||
## 什麼是超級密鑰？
|
||||
**超級密鑰**為 KernelPatch 上的系統呼叫（syscall）服務，旨在讓使用者空間內的程式也能套用修補變更；也稱作**超級呼叫**。當程式請求**超級呼叫**，需提供一份稱作**超級密鑰**的存取憑證。
|
||||
**超級呼叫**僅在**超級密鑰**正確無虞之下生效，反之則失效。
|
||||
|
||||
|
||||
## 那 SELinux 怎麼辦？
|
||||
- KernelPatch 不修改 SELinux 內容，而是使用 Hook 忽略 SELinux 層；
|
||||
換句話說，應用程式內的 Android 執行緒可直接調用 Root 權限，而不用經過讓 libsu 新增運算排程、安排 IPC 等步驟。
|
||||
可謂事半功倍。
|
||||
- 此外，由於 APatch 使用了 magiskpolicy，使你能有額外的 SELinux 支援。
|
||||
49
docs/de/faq_de.md
Normal file
49
docs/de/faq_de.md
Normal file
|
|
@ -0,0 +1,49 @@
|
|||
# Häufig gestellte Fragen
|
||||
|
||||
|
||||
## Was ist APatch?
|
||||
APatch ist eine Root-Lösung, ähnlich wie Magisk oder KernelSU, welche das Beste beider vereint.
|
||||
Es kombiniert Magisks bequeme und leichte Installationsmethode über `boot.img` mit KernelSUs starken Kernel-Korrektur-Fähigkeiten.
|
||||
|
||||
|
||||
## Was ist der Unterschied zwischen APatch und Magisk?
|
||||
- Magisk modifiziert das Init-System mit einer Korrektur in Ihrem boot image ramdisk, während APatch den Kernel direkt korrigiert.
|
||||
|
||||
|
||||
## APatch gegen KernelSU
|
||||
- KernelSU benötigt den Quellcode für dein Geräte-Kernel, welcher nicht immer von der OEM gegeben wird. APatch funktioniert allein mit Ihrem Standard-`boot.img`.
|
||||
|
||||
|
||||
## APatch gegen Magisk, KernelSU
|
||||
- APatch erlaubt Ihnen, optional, nicht SELinux zu modifizieren, was bedeutet, dass ein App-Kontext gerootet werden kann, sodass libsu und IPC nicht benötigt werden.
|
||||
- **Kernel Korrektur Modul** gegeben.
|
||||
|
||||
|
||||
## Was ist ein Kernel Korrigtur Modul?
|
||||
Etwas Code läuft im Kernelbereich, ähnlich zu Ladbaren Kernel-Modulen (LKM).
|
||||
|
||||
Dazu stellt KPM die Fähigkeit bereit, "inline-hook", "syscall-table-hook" im Kernelbereich zu machen.
|
||||
|
||||
Für mehr Informationen, siehe [Wie schreibt man ein KPM](https://github.com/bmax121/KernelPatch/blob/main/doc/module.md)
|
||||
|
||||
|
||||
## Beziehung zwischen APatch und KernelPatch
|
||||
|
||||
APatch benötigt KernelPatch, übernimmt all seine Fähigkeiten und wurde erweitert.
|
||||
|
||||
Sie können nur KernelPatch installieren, aber dies wird Ihnen nicht erlauben, Magisk-Module zu nutzen.
|
||||
|
||||
[Lerne mehr über KernelPatch](https://github.com/bmax121/KernelPatch)
|
||||
|
||||
|
||||
## Was ist SuperKey?
|
||||
KernelPatch fügt einen neuen System-Abruf (syscall) hinzu, um alle Möglichkeiten, Apps und anderen Programmen im Benutzerbereich, bereitzustellen, dieser System-Abruf ist bekannt als **SuperCall**.
|
||||
Wenn eine App / ein Programm versucht, **SuperCall** abzurufen, muss es ein Berechtigungsnachweis vorlegen, bekannt als **SuperKey**.
|
||||
**SuperCall** kann nur erfolgreich abgerufen werden, wenn der **SuperKey** korrekt ist und wenn nicht, dann bleibt der Rufer unbetroffen.
|
||||
|
||||
|
||||
## Was ist mit SELinux?
|
||||
- KernelPatch bearbeitet den SELinux-Kontext nicht und umgeht den SELinux über einen Haken.
|
||||
Dies erlaubt Ihnen, einen Android-Kontext in dem App-Kontext, ohne dem Gebrauch, libsu zu nutzen, um einen neuen Prozess zu starten und darauf IPC auszuführen, zu rooten.
|
||||
Dies ist bequem.
|
||||
- Dazu verwendet APatch direkt das Magiskkonzept, um weitere SELinux-Unterstützung bereitzustellen.
|
||||
49
docs/en/faq.md
Normal file
49
docs/en/faq.md
Normal file
|
|
@ -0,0 +1,49 @@
|
|||
# FAQ
|
||||
|
||||
|
||||
## What is APatch?
|
||||
APatch is a root solution similar to Magisk or KernelSU that unites the best of both.
|
||||
It combines Magisk's convenient and easy install method through `boot.img` with KernelSU's powerful kernel patching abilities.
|
||||
|
||||
|
||||
## What's the difference between APatch and Magisk?
|
||||
- Magisk modifies the init system with a patch in your boot image's ramdisk, while APatch patches the kernel directly.
|
||||
|
||||
|
||||
## APatch vs KernelSU
|
||||
- KernelSU requires the source code for your device's kernel which is not always provided by the OEM. APatch works with just your stock `boot.img`.
|
||||
|
||||
|
||||
## APatch vs Magisk, KernelSU
|
||||
- APatch allows you to optionally not modify SELinux, this means that the APP thread can be rooted, libsu and IPC are not necessary.
|
||||
- **Kernel Patch Module** provided.
|
||||
|
||||
|
||||
## What is Kernel Patch Module?
|
||||
Some code runs in Kernel Space, similar to Loadable Kernel Modules (LKM).
|
||||
|
||||
Additionally, KPM provides the ability to do inline-hook, syscall-table-hook in kernel space.
|
||||
|
||||
For more information, see [How to write a KPM](https://github.com/bmax121/KernelPatch/blob/main/doc/module.md)
|
||||
|
||||
|
||||
## Relationship between APatch and KernelPatch
|
||||
|
||||
APatch depends on KernelPatch, inherits all its capabilities, and has been expanded.
|
||||
|
||||
You can install KernelPatch only, but this will not allow you to use Magisk modules
|
||||
|
||||
[Learn more about KernelPatch](https://github.com/bmax121/KernelPatch)
|
||||
|
||||
|
||||
## What is SuperKey?
|
||||
KernelPatch adds a new system call (syscall) to provide all capabilities to apps and programs in userspace, this syscall is referred to as **SuperCall**.
|
||||
When an app/program tries to invoke **SuperCall**, it needs to provide an access credential, known as the **SuperKey**.
|
||||
**SuperCall** can only be successfully invoked if the **SuperKey** is correct and if it's not the caller will remain unaffected.
|
||||
|
||||
|
||||
## How about SELinux?
|
||||
- KernelPatch doesn't modify the SELinux context and bypasses SELinux via a hook.
|
||||
This allows you to root an Android thread within the app context without the need to use libsu to start a new process and then perform IPC.
|
||||
This is very convenient.
|
||||
- In addition, APatch directly utilizes magiskpolicy to provide additional SELinux support.
|
||||
45
docs/es/faq_es.md
Normal file
45
docs/es/faq_es.md
Normal file
|
|
@ -0,0 +1,45 @@
|
|||
# Preguntas frecuentes
|
||||
|
||||
## ¿Qué es APatch?
|
||||
APatch es una solución de root similar a Magisk o KernelSU que une lo mejor de ambos.
|
||||
Combina el método de instalación conveniente y fácil de Magisk a través de un patche en `boot.img` y las potentes capacidades de KernelSU para parchear el kernel.
|
||||
|
||||
|
||||
## Diferencias entre APatch y Magisk
|
||||
- Magisk modifica el sistema de init (el sistema que inicializa todos los subsistemas del dispositivo) con un parche en la ramdisk de tu imagen `boot.img`, mientras que APatch parchea el kernel directamente.
|
||||
|
||||
|
||||
## Diferencias entre APatch y KernelSU
|
||||
- KernelSU requiere el código fuente del kernel del dispositivo, que no siempre es brindado por el fabricante del mismo. APatch solo requiere la imagen `boot.img`
|
||||
|
||||
|
||||
## Diferencias entre APatch y ambas soluciones de root
|
||||
- APatch permite opcionalmente no modificar el contexto de SELinux. También da acceso root a las apps en su propio contexto, lo cual significa que no hay necesidad de usar libsu ni IPC.
|
||||
- Se añaden los **KPM** (Kernel Patch Modules), explicados abajo
|
||||
|
||||
|
||||
## ¿Qué es un Kernel Patch Module (KPM, Módulo de Parche del Kernel)?
|
||||
Permite implementar código personalizado que corra en kernelspace, es decir, en el mismo entorno que el kernel. Funciona similar a los módulos de kernel (los LKM, Loadable Kernel Modules) que se cargan con insmod/rmmod/modprobe/etc.
|
||||
|
||||
Además, KPM permite hacer inline-hooks ("engancharse" a una función en el mismo lugar de memoria, he de ahí el "inline") y syscall-table-hook (modificar la tabla de syscalls)
|
||||
|
||||
Para más información, lee [Como escribir un KPM](https://github.com/bmax121/KernelPatch/blob/main/doc/module.md) (en Inglés)
|
||||
|
||||
|
||||
## Relación entre APatch y KernelPatch
|
||||
APatch depende de KernelPatch, hereda todas sus capacidades y las expande.
|
||||
|
||||
Puedes instalar solo KernelPatch, pero esto no va a permitir que uses módulos de Magisk, y para poder administrar el acceso root vas a tener que instalar AndroidPatch y desinstalarlo.
|
||||
|
||||
[Aprende más de KernelPatch](https://github.com/bmax121/KernelPatch) (en Inglés)
|
||||
|
||||
|
||||
## ¿Qué es SuperKey?
|
||||
KernelPatch agrega una nueva syscall (llamada al sistema) para dar todas las capacidades a apps y programas en userspace (el espacio del usuario fuera del kernel), y esta syscall se llama **SuperCall**.
|
||||
Cuando una app o programa intenta llamar **SuperCall**, necesita proveer una credencial de acceso llamada **SuperKey**.
|
||||
**SuperCall** solo se puede llamar si se provee una **SuperKey** correcta, caso contrario la app/programa que lo llame quedará intacta.
|
||||
|
||||
|
||||
## ¿Y qué pasa con SELinux?
|
||||
- KernelPatch no modifica el contexto de SELinux y simplemente se lo salta a través de un hook, lo cual permite que des acceso root a un hilo de Android dentro del contexto de la aplicación sin necesidad de usar libsu para iniciar un nuevo proceso y luego comunicarte con él a través de IPC (Inter-Process Communication)
|
||||
- Además, APatch usa magiskpolicy directamente para obtener mayor soporte de SELinux. Solo esto va a ser detectado como Magisk, y cualquiera que lo desee puede intentar evitar esto ya que el problema ya está bastante claro.
|
||||
48
docs/fr/faq_fr.md
Normal file
48
docs/fr/faq_fr.md
Normal file
|
|
@ -0,0 +1,48 @@
|
|||
## Foire aux questions (FAQ)
|
||||
|
||||
## Qu'est-ce qu'APatch ?
|
||||
|
||||
APatch est une méthode de root, similaire à Magisk ou KernelSU, offrant encore plus de fonctionnalités.
|
||||
|
||||
## Quelle est la différence entre APatch et Magisk ?
|
||||
|
||||
- Magisk modifie init, tandis qu'APatch patche le noyau Linux.
|
||||
|
||||
## Quelle est la différence entre APatch et KernelSU ?
|
||||
|
||||
- KernelSU nécessite le code source. APatch n'a besoin que du fichier boot.img.
|
||||
|
||||
## Quelle est la différence entre APatch, Magisk et KernelSU ?
|
||||
|
||||
- Optionnellement, ne modifie pas SELinux. Root dans le contexte d'application Android, libsu et d'IPC non nécessaires
|
||||
- Fournit **Kernel Patch Module**
|
||||
|
||||
## Qu'est-ce que Kernel Patch Module ?
|
||||
|
||||
Certains codes s'exécutent dans l'espace du noyau, à l'instar des modules noyau chargeables (LKM, Loadable Kernel Modules).
|
||||
|
||||
De plus, KPM offre la possibilité d'effectuer des inline-hook, syscall-table-hook dans l'espace noyau.
|
||||
|
||||
[Comment écrire un module KPM](https://github.com/bmax121/KernelPatch/blob/main/doc/fr/module.md)
|
||||
|
||||
## Relation entre APatch et KernelPatch
|
||||
|
||||
APatch dépend de KernelPatch, héritant de toutes ses fonctionnalités, et l'étendant.
|
||||
|
||||
Vous pouvez installer KernelPatch seul, mais cela ne vous permettra pas d'utiliser de module Magisk.
|
||||
Pour utiliser la gestion super utilisateur, vous devez installer AndroidPatch puis le désinstaller.
|
||||
|
||||
[En savoir plus sur KernelPatch](https://github.com/bmax121/KernelPatch)
|
||||
|
||||
## Qu'est-ce que la clé (SuperKey) ?
|
||||
|
||||
KernelPatch fournit toutes les fonctionnalités à l'espace utilisateur en effectuant un appel système appelé **SuperCall**.
|
||||
L'appel du SuperCall nécessite le passage d'un type d'informations d'identification appelé **SuperKey**.
|
||||
Un SuperCall ne peut être effectué avec succès que si la clé est correcte. Si la clé est incorrecte, l'appelant ne sera pas affecté.
|
||||
|
||||
## Qu'en est-il de SELinux ?
|
||||
|
||||
- KernelPatch ne modifie pas le contexte SELinux et contourne SELinux via des hooks.
|
||||
Cela vous permet de rooter un processus Android dans le contexte de applicatif, sans avoir à démarrer un nouveau processus avec libsu et ensuite exécuter l'IPC.
|
||||
- De plus, APatch fournit un support SELinux supplémentaire directement via magiskpolicy.
|
||||
Cependant, seul ce dernier sera détecté en tant que Magisk. Toute personne intéressée peut essayer de le contourner, le problème est déjà très clair.
|
||||
44
docs/id/faq.md
Normal file
44
docs/id/faq.md
Normal file
|
|
@ -0,0 +1,44 @@
|
|||
# FAQ
|
||||
|
||||
## Apa itu APatch?
|
||||
APatch adalah solusi root yang mirip dengan Magisk atau KernelSU yang menyatukan yang terbaik dari keduanya.
|
||||
Ia menggabungkan metode instalasi Magisk yang mudah dan praktis melalui `boot.img` dengan kemampuan patching kernel KernelSU yang hebat.
|
||||
|
||||
## Apa perbedaan antara APatch dan Magisk?
|
||||
|
||||
- Magisk memodifikasi sistem init dengan patch di ramdisk boot image Anda, sementara APatch menambal kernel secara langsung.
|
||||
|
||||
## APatch vs KernelSU
|
||||
- KernelSU memerlukan kode sumber untuk kernel perangkat Anda yang tidak selalu disediakan oleh OEM. APatch hanya berfungsi dengan `boot.img` bawaan Anda.
|
||||
|
||||
## APatch vs Magisk, KernelSU
|
||||
- APatch memungkinkan Anda untuk secara opsional tidak memodifikasi SELinux, ini berarti bahwa utas APP dapat di-root, libsu dan IPC tidak diperlukan.
|
||||
|
||||
- **Modul Patch Kernel** disediakan.
|
||||
|
||||
## Apa itu Modul Patch Kernel? Beberapa kode berjalan di Kernel Space, mirip dengan Loadable Kernel Modules (LKM).
|
||||
|
||||
Selain itu, KPM menyediakan kemampuan untuk melakukan inline-hook, syscall-table-hook di kernel space.
|
||||
|
||||
Untuk informasi selengkapnya, lihat [Cara menulis KPM](https://github.com/bmax121/KernelPatch/blob/main/doc/module.md)
|
||||
|
||||
## Hubungan antara APatch dan KernelPatch
|
||||
|
||||
APatch bergantung pada KernelPatch, mewarisi semua kemampuannya, dan telah diperluas.
|
||||
|
||||
Anda hanya dapat menginstal KernelPatch, tetapi ini tidak akan memungkinkan Anda untuk menggunakan modul Magisk
|
||||
|
||||
[Pelajari selengkapnya tentang KernelPatch](https://github.com/bmax121/KernelPatch)
|
||||
|
||||
## Apa itu SuperKey?
|
||||
KernelPatch menambahkan panggilan sistem baru (syscall) untuk menyediakan semua kemampuan bagi aplikasi dan program di userspace, syscall ini disebut sebagai **SuperCall**. Saat aplikasi/program mencoba memanggil **SuperCall**, aplikasi/program tersebut perlu menyediakan kredensial akses, yang dikenal sebagai **SuperKey**.
|
||||
**SuperCall** hanya dapat dipanggil dengan sukses jika **SuperKey** benar dan jika tidak, pemanggil tidak akan terpengaruh.
|
||||
|
||||
## Bagaimana dengan SELinux?
|
||||
- KernelPatch tidak mengubah konteks SELinux dan melewati SELinux melalui hook.
|
||||
|
||||
Ini memungkinkan Anda untuk melakukan root pada thread Android dalam konteks aplikasi tanpa perlu menggunakan libsu untuk memulai proses baru dan kemudian melakukan IPC.
|
||||
|
||||
Ini sangat praktis.
|
||||
|
||||
- Selain itu, APatch secara langsung menggunakan magiskpolicy untuk menyediakan dukungan SELinux tambahan.
|
||||
50
docs/it/faq_it.md
Normal file
50
docs/it/faq_it.md
Normal file
|
|
@ -0,0 +1,50 @@
|
|||
# Domande frequenti
|
||||
|
||||
## Cos'è APatch
|
||||
|
||||
APatch è una soluzione per il root simile a Magisk o KernelSU, ma offre funzionalità aggiuntive.
|
||||
|
||||
## APatch vs Magisk
|
||||
|
||||
- Magisk modifica l'init, mentre APatch patcha il kernel Linux.
|
||||
|
||||
## APatch vs KernelSU
|
||||
|
||||
- KernelSU richiede il codice sorgente del kernel, mentre per APatch è sufficiente solo il file boot.img.
|
||||
|
||||
## APatch vs Magisk, KerenlSU
|
||||
|
||||
- Opzionalmente, non modifica SELinux.
|
||||
- Consente di ottenere i permessi di root nel contesto dell'app Android, senza la necessità di libsu e IPC.
|
||||
- Possibilità di utilizzare **Kernel Patch Module**
|
||||
|
||||
## Cos'è un Kernel Patch Module
|
||||
|
||||
È del codice eseguito nello spazio del Kernel, simile ai Loadable Kernel Modules (LKM).
|
||||
|
||||
Inoltre, KPM fornisce la possibilità di effettuare inline-hook e syscall-table-hook nello spazio del kernel.
|
||||
|
||||
[Come scrivere un KPM](https://github.com/bmax121/KernelPatch/blob/main/doc/module.md)
|
||||
|
||||
## Relazione tra APatch e KernelPatch
|
||||
|
||||
APatch dipende da KernelPatch, eredita tutte le sue capacità ed è stato ampliato.
|
||||
|
||||
Puoi installare solo KernelPatch, ma ciò non consentirà l'uso dei moduli Magisk.
|
||||
Per gestire i permessi di root, è necessario installare AndroidPatch e successivamente disinstallarlo.
|
||||
|
||||
[Scopri di più su KernelPatch](https://github.com/bmax121/KernelPatch)
|
||||
|
||||
## Cos'è la SuperKey
|
||||
|
||||
KernelPatch aggancia le chiamate di sistema per fornire tutte le capacità allo spazio utente, e questa chiamata di sistema è chiamata **SuperCall**.
|
||||
Invocare SuperCall richiede il passaggio di una credenziale, nota come **SuperKey**.
|
||||
SuperCall può essere invocato con successo solo quando la SuperKey è corretta; se la SuperKey è errata, chi effettua la chiamata rimane inalterato.
|
||||
|
||||
## Riguardo a SELinux
|
||||
|
||||
- KernelPatch non modifica il contesto SELinux e bypassa SELinux tramite hook,
|
||||
consentendo di ottenere i privilegi di root in un thread Android all'interno del contesto dell'app senza la necessità di utilizzare libsu per avviare un nuovo processo e quindi eseguire IPC.
|
||||
Questo è molto conveniente.
|
||||
- Inoltre, APatch utilizza direttamente magiskpolicy per fornire ulteriore supporto SELinux.
|
||||
Tuttavia, solo questo sarà rilevato come Magisk. Chiunque sia interessato può cercare di bypassarlo; il problema è già abbastanza chiaro.
|
||||
49
docs/kr/faq_kr.md
Normal file
49
docs/kr/faq_kr.md
Normal file
|
|
@ -0,0 +1,49 @@
|
|||
# FAQ
|
||||
|
||||
|
||||
## APatch가 뭔가요?
|
||||
APatch는 Magisk와 KernelSU와 유사한 루팅툴로, 두 가지의 장점을 결합하였습니다.
|
||||
`boot.img`을 통해 설치하는 Magisk의 편리하고 간편한 방법과 강력한 커널 패치 기능을 제공하는 KernelSU를 결합하였습니다.
|
||||
|
||||
|
||||
## APatch와 Magisk의 차이점은 무엇인가요?
|
||||
- Magisk는 부트 이미지의 램디스크에 패치를 적용하여 초기 시스템을 수정하는 반면, APatch는 커널을 직접 패치합니다.
|
||||
|
||||
|
||||
## APatch vs KernelSU
|
||||
- KernelSU는 기기의 커널 소스 코드가 필요하지만 OEM에서 항상 제공하지는 않습니다. 반면, APatch는 단지 여러분의 기본 `boot.img`만으로 작동합니다.
|
||||
|
||||
|
||||
## APatch vs Magisk, KernelSU
|
||||
- APatch는 선택적으로 SELinux를 수정하지 않을 수 있어, APP 스레드를 루팅할 수 있으며, libsu와 IPC가 필요하지 않습니다.
|
||||
- **커널 패치 모듈**을 제공합니다..
|
||||
|
||||
|
||||
## 커널 패치 모듈이 뭔가요?
|
||||
커널 패치 모듈은 Loadable Kernel Modules (LKM)과 유사하게 커널 공간에서 실행되는 코드입니다.
|
||||
|
||||
또한, KPM은 커널에서 인라인 훅과 시스템 콜 테이블 훅을 수행할 수 있습니다.
|
||||
|
||||
자세한 정보는 [KPM 작성 방법](https://github.com/bmax121/KernelPatch/blob/main/doc/module.md)에서 확인하세요.
|
||||
|
||||
|
||||
## APatch와 KernelPatch의 관계
|
||||
|
||||
APatch는 KernelPatch에 의존하며, 모든 기능을 상속받고 확장되었습니다.
|
||||
|
||||
KernelPatch만 설치할 수도 있지만, 이 경우 Magisk 모듈을 사용할 수 없습니다.
|
||||
|
||||
[KernelPatch에 대해 더 알아보기](https://github.com/bmax121/KernelPatch)
|
||||
|
||||
|
||||
## SuperKey가 뭔가요?
|
||||
KernelPatch는 사용자 공간의 앱 및 프로그램에 모든 기능을 제공하는 새로운 시스템 콜 (syscall)을 추가하며, 이것을 **SuperCall**이라고 합니다.
|
||||
앱이나 프로그램이 **SuperCall**를 호출하려고 할 때, 접근 자격증명인 **SuperKey**를 제공해야 합니다.
|
||||
**SuperCall**은 **SuperKey**가 정확하고 호출자에게 영향을 미치지 않을 경우에만 성공적으로 수행됩니다.
|
||||
|
||||
|
||||
## SELinux는 어떻게 다루나요?
|
||||
- KernelPatch는 SELinux 컨텍스트를 수정하지 않고 SELinux를 우회하는 훅을 사용합니다.
|
||||
이를 통해 앱 컨텍스트 내에서 안드로이드 스레드를 루팅할 수 있으며, 새 프로세스를 시작하고 IPC를 수행하기 위해 libsu를 사용할 필요가 없습니다.
|
||||
이 방법은 매우 편리합니다.
|
||||
- 또한, APatch는 추가적인 SELinux 지원을 제공하기 위해 직접 magiskpolicy를 활용합니다.
|
||||
43
docs/pt_br/faq_pt_br.md
Normal file
43
docs/pt_br/faq_pt_br.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
# Perguntas frequentes
|
||||
|
||||
## O que é APatch?
|
||||
|
||||
APatch é uma solução root semelhante ao Magisk ou KernelSU que une o melhor de ambos. Ele combina o método de instalação fácil e conveniente do Magisk por meio do `boot.img` com as poderosas habilidades de patch de kernel do KernelSU.
|
||||
|
||||
## Qual é a diferença entre APatch e Magisk?
|
||||
|
||||
- Magisk modifica o sistema init com um patch no ramdisk da sua imagem de inicialização, enquanto o APatch corrige o kernel diretamente.
|
||||
|
||||
## APatch vs KernelSU
|
||||
|
||||
- KernelSU requer o código-fonte do kernel de seu dispositivo, que nem sempre é fornecido pelo OEM. APatch funciona apenas com seu `boot.img` stock.
|
||||
|
||||
## APatch vs Magisk e KernelSU
|
||||
|
||||
- APatch permite opcionalmente não modificar o SELinux, isso significa que o thread do app pode ser rooteado, libsu e IPC não são necessários.
|
||||
- **Módulo KernelPatch** fornecido.
|
||||
|
||||
## O que é Módulo KernelPatch?
|
||||
|
||||
Alguns códigos são executados no Kernel Space, semelhante ao Loadable Kernel Modules (LKM).
|
||||
|
||||
Além disso, o KPM fornece a capacidade de executar inline-hook e syscall-table-hook no Kernel Space.
|
||||
|
||||
Para mais informações, veja [como escrever um KPM](https://github.com/bmax121/KernelPatch/blob/main/doc/module.md).
|
||||
|
||||
## Relacionamento entre APatch e KernelPatch
|
||||
|
||||
APatch depende do KernelPatch. Ele herda todas as suas capacidades e foi expandido.
|
||||
|
||||
Você pode instalar apenas o KernelPatch, mas isso não permitirá o uso de módulos Magisk.
|
||||
|
||||
[Saiba mais sobre o KernelPatch](https://github.com/bmax121/KernelPatch).
|
||||
|
||||
## O que é SuperKey?
|
||||
|
||||
KernelPatch conecta chamadas do sistema para fornecer todos os recursos ao espaço do usuário, e essa chamada do sistema é chamada de **SuperCall**. Invocar o SuperCall requer a passagem de uma credencial, conhecida como **SuperKey**. SuperCall só pode ser invocado com sucesso quando a SuperKey estiver correta. Se a SuperKey estiver incorreta, o chamador não será afetado.
|
||||
|
||||
## E o SELinux?
|
||||
|
||||
- KernelPatch não modifica o contexto do SELinux e ignora o SELinux via hook. Isso permite que você faça root em um thread do Android dentro do contexto do app sem a necessidade de usar libsu para iniciar um novo processo e então executar o IPC.
|
||||
- Além disso, o APatch utiliza diretamente o magiskpolicy para fornecer suporte adicional ao SELinux.
|
||||
0
docs/ru/.gitkeep
Normal file
0
docs/ru/.gitkeep
Normal file
48
docs/ru/faq_ru.md
Normal file
48
docs/ru/faq_ru.md
Normal file
|
|
@ -0,0 +1,48 @@
|
|||
# Часто задаваемые вопросы
|
||||
|
||||
|
||||
## Что такое APatch?
|
||||
APatch - это root решение, похожее на Magisk или KernelSU, которое объединяет лучшее из обоих.
|
||||
Оно сочетает удобный и простой метод установки Magisk через `boot.img` с мощными возможностями исправления ядра KernelSU.
|
||||
|
||||
## В чем разница между APatch и Magisk?
|
||||
- Magisk изменяет систему инициализации с помощью патча на RAM-диске вашего загрузочного образа, в то время как APatch вносит изменения непосредственно в ядро.
|
||||
|
||||
|
||||
## APatch против KernelSU
|
||||
- Для KernelSU требуется исходный код ядра вашего устройства, который не всегда предоставляется OEM-производителем. APatch работает напрямую с вашим исходным `boot.img`.
|
||||
|
||||
|
||||
## APatch против Magisk, KernelSU
|
||||
- APatch позволяет вам при желании не изменять SELinux. Это означает, что поток приложения может быть рутирован, в libsu и IPC нет необходимости.
|
||||
- **Kernel Patch Module** предоставляется.
|
||||
|
||||
|
||||
## Что такое Kernel Patch Module?
|
||||
Некоторый код выполняется в пространстве ядра, аналогично загружаемым модулям ядра (Loadable Kernel Modules, LKM).
|
||||
|
||||
Кроме того, KPM предоставляет возможность выполнять inline-hook, syscall-table-hook в пространстве ядра.
|
||||
|
||||
Для получения дополнительной информации смотрите [Как написать KPM](https://github.com/bmax121/KernelPatch/blob/main/doc/module.md)
|
||||
|
||||
|
||||
## Связь между APatch и KernelPatch
|
||||
|
||||
APatch основан на KernelPatch, унаследовал все его возможности и был расширен.
|
||||
|
||||
Вы можете установить только KernelPatch, но это не позволит вам использовать модули Magisk, а чтобы использовать управление суперпользователем, вам необходимо установить AndroidPatch, а затем удалить его.
|
||||
|
||||
[Узнать больше о KernelPatch](https://github.com/bmax121/KernelPatch)
|
||||
|
||||
|
||||
## Что такое SuperKey?
|
||||
KernelPatch добавляет новый системный вызов (syscall) для предоставления всех возможностей приложениям и программам в пользовательском пространстве. Этот системный вызов называется **SuperCall**.
|
||||
Когда приложение/программа пытается вызвать **SuperCall**, ему необходимо предоставить учетные данные для доступа, называемые **SuperKey**.
|
||||
**SuperCall** может быть успешно вызван только в том случае, если **SuperKey** правильный, а в противном случае вызывающий объект останется незатронутым.
|
||||
|
||||
|
||||
## Что насчет SELinux?
|
||||
- KernelPatch не изменяет контекст SELinux и обходит SELinux с помощью перехвата.
|
||||
Это позволяет вам рутировать поток Android в контексте приложения без необходимости использовать libsu для запуска нового процесса и последующего выполнения IPC.
|
||||
Это очень удобно.
|
||||
- Кроме того, APatch напрямую использует magiskpolicy для обеспечения дополнительной поддержки SELinux.
|
||||
46
docs/tr/faq_tr.md
Normal file
46
docs/tr/faq_tr.md
Normal file
|
|
@ -0,0 +1,46 @@
|
|||
# SSS
|
||||
|
||||
## APatch nedir?
|
||||
|
||||
APatch, Magisk veya KernelSU benzeri ve her ikisinin de en iyi yönlerini birleştiren bir root çözümdür. Magisk'in `boot.img` aracılığıyla kullanışlı ve kolay kurulum yöntemini ve KernelSU'nun güçlü kernel yamalama yeteneklerini birleştirir.
|
||||
|
||||
## APatch ve Magisk arasındaki fark nedir?
|
||||
|
||||
- Magisk başlangıç sistemini kernel'in ramdisk'indeki bir yama ile değiştirirken; APatch kernel'i doğrudan yamalar.
|
||||
|
||||
## APatch vs KernelSU
|
||||
|
||||
- KernelSU, cihazınızın kernel'i için her zaman OEM tarafından sağlanmayan kaynak kodunu gerektirir. APatch yalnızca stok `boot.img` dosyanızla çalışır.
|
||||
|
||||
## APatch vs Magisk, KernelSU
|
||||
|
||||
- İsteğe bağlı olarak SELinux'u değiştirmez. Bu şu anlama gelir; android uygulama parçacığının root'lanması için libsu ve IPC'ye gerek yoktur.
|
||||
- **Kernel Patch (Yama) Modülü** sağlanır.
|
||||
|
||||
## Kernel Patch (Yama) Modülü nedir?
|
||||
|
||||
Bazı kodlar, Yüklenebilir Kernel Modüllerinde (LKM) olduğu gibi Kernel Seviyesinde çalışır.
|
||||
|
||||
Ek olarak KPM, kernel sviyesinde satır içi kanca, sistem çağrısı-tablo kancası yapma yeteneği sağlar.
|
||||
|
||||
Daha fazla bilgi için bkz [KPM nasıl yazılır?](https://github.com/bmax121/KernelPatch/blob/main/doc/module.md)
|
||||
|
||||
## APatch and KernelPatch arasındaki ilişki
|
||||
|
||||
APatch, KernelPatch'e dayalıdır; onun tüm yeteneklerini devralır ve onu daha da geliştirmiştir.
|
||||
|
||||
Yalnızca KernelPatch'i kurabilirsiniz ancak bu magisk modüllerini kullanmanıza izin vermez,
|
||||
Superuser yönetimini kullanmak için de AndroidPatch'i yüklemeniz ve ardından kaldırmanız gerekir.
|
||||
|
||||
[KernelPatch hakkında daha fazlasını öğrenin](https://github.com/bmax121/KernelPatch)
|
||||
|
||||
## Süper Anahtar nedir?
|
||||
|
||||
KernelPatch, tüm yetenekleri kullanıcı alanına (userspace) sağlamak için sistem çağrılarını (syscall) kancalar ve bu sistem çağrısına **SuperCall** denir.
|
||||
Bir uygulama/program SuperCall'ı çağırmayı denediğinde, **Süper Anahtar** olarak bilinen bir kimlik bilgisinin iletilmesini gerektirir.
|
||||
SuperCall yalnızca Süper Anahtar doğru olduğunda başarılı bir şekilde çağrılabilir; Süper Anahtar hatalıysa çağıran bundan etkilenmez.
|
||||
|
||||
## Peki ya SELinux?
|
||||
|
||||
- KernelPatch, SELinux içeriğini değiştirmez ve SELinux'u kanca yoluyla atlamaz. Bu, yeni bir işlem başlatmak ve ardından IPC gerçekleştirmek için libsu kullanmanıza gerek kalmadan, uygulama bağlamında bir Android iş parçacığını rootlamanıza olanak tanır. Bu çok kullanışlıdır.
|
||||
- Ayrıca APatch, ek SELinux desteği sağlamak için doğrudan magiskpolicy'yi kullanır.
|
||||
48
docs/uk/faq_uk.md
Normal file
48
docs/uk/faq_uk.md
Normal file
|
|
@ -0,0 +1,48 @@
|
|||
# Поширені запитання
|
||||
|
||||
|
||||
## Що таке APatch?
|
||||
APatch - це root рішення, схоже на Magisk або KernelSU, яке поєднує найкраще з обох.
|
||||
Воно поєднує зручний і простий метод установки Magisk через boot.img з потужними можливостями виправлення ядра KernelSU.
|
||||
|
||||
## У чому різниця між APatch та Magisk?
|
||||
- Magisk змінює систему ініціалізації за допомогою патча на RAM диску вашого завантажувального образу, в той час як APatch вносить зміни безпосередньо в ядро.
|
||||
|
||||
|
||||
## APatch проти KernelSU
|
||||
- Для KernelSU потрібен вихідний код ядра вашого пристрою, який не завжди надається OEM-виробником. APatch працює безпосередньо з вашим вихідним `boot.img`.
|
||||
|
||||
|
||||
## APatch проти Magisk, KernelSU
|
||||
- APatch дозволяє вам за бажання не змінювати SELinux. Це означає, що потік програми може бути рутований, в libsu і IPC немає необхідності.
|
||||
- **Kernel Patch Module** надається.
|
||||
|
||||
|
||||
## Що таке Kernel Patch Module?
|
||||
Деякий код виконується у просторі ядра, аналогічно модулям ядра (Loadable Kernel Modules, LKM).
|
||||
|
||||
Крім того, KPM надає можливість виконувати inline-hook, syscall-table-hook у просторі ядра.
|
||||
|
||||
Для отримання додаткової інформації дивіться [Як написати KPM](https://github.com/bmax121/KernelPatch/blob/main/doc/module.md)
|
||||
|
||||
|
||||
## Зв'язок між APatch та KernelPatch
|
||||
|
||||
APatch заснований на KernelPatch, успадкував усі його можливості та був розширений.
|
||||
|
||||
Ви можете встановити тільки KernelPatch, але це не дозволить вам використовувати модулі Magisk, а щоб використовувати керування суперкористувачем, вам необхідно встановити AndroidPatch, а потім видалити його.
|
||||
|
||||
[Дізнатись більше про KernelPatch](https://github.com/bmax121/KernelPatch)
|
||||
|
||||
|
||||
## Що таке SuperKey?
|
||||
KernelPatch додає новий системний дзвінок (syscall) для надання всіх можливостей додаткам і програмам в просторі користувача. Цей системний виклик називається **SuperCall**.
|
||||
Коли програма намагається викликати **SuperCall**, їй необхідно надати облікові дані для доступу, які називають **SuperKey**.
|
||||
**SuperCall** може бути успішно викликаний тільки в тому випадку, якщо **SuperKey** правильний, а в іншому випадку об'єкт, що викликає, не змінюється.
|
||||
|
||||
|
||||
## Як щодо SELinux?
|
||||
- KernelPatch не змінює контекст SELinux та обходить SELinux за допомогою перехоплення.
|
||||
Це дозволяє вам рутувати потік Android у контексті програми без необхідності використовувати libsu для запуску нового процесу та подальшого виконання IPC.
|
||||
Це дуже зручно.
|
||||
- Крім того, APatch безпосередньо використовує magiskpolicy для забезпечення додаткової підтримки SELinux.
|
||||
Loading…
Add table
Add a link
Reference in a new issue