Zapret Wiki

Недавно обновлено

время чтения ~9 мин.

.md

🦎 ReSukiSU — форк SukiSU для root-доступа на Android

О чём заметка

ReSukiSU — это решение для получения root-прав на Android через ядро (kernel-based root). Заметка объясняет, что это за проект, откуда он взялся, чем отличается от KernelSU/SukiSU/Magisk, какие у него возможности (KPM, SUSFS, метамодули) и на каких устройствах он работает. Это обзорная (теоретическая) заметка; пошаговую установку под конкретное устройство ищите в официальной документации проекта.

TL;DR

  • ReSukiSU — форк проекта SukiSU-Ultra, который сам является форком KernelSU. Слоган проекта — «Make SukiSU Great Again!». Заявленная цель форка: больше стабильности и более простая сборка ядра.
  • Это root на уровне ядра: суперпользователь встроен в само ядро Linux, а не подгружается в загрузчике, как у Magisk. Из-за этого его сложнее обнаружить, но нужно совместимое ядро.
  • Ключевые фишки семейства: KPM (запуск кода прямо в ядре), встроенный SUSFS (скрытие root от приложений), система метамодулей (systemless-модификации), совместимость с несколькими менеджерами (KernelSU, RKSU, MKSU, SukiSU).
  • Официально поддерживаются GKI 2.0 устройства (ядро Linux 5.10+). Старые ядра (от 3.4) тоже работают, но ядро придётся собирать вручную. Архитектуры: arm64-v8a, armeabi-v7a, x86_64.
  • Лицензия: код ядра — GPL-2.0-only, остальное — GPL-3.0-or-later.

Что такое «root через ядро» и при чём тут KernelSU

Root (суперпользователь) на Android — это права, позволяющие приложениям делать то, что обычно запрещено: менять системные файлы, блокировать рекламу на уровне системы, удалять предустановленные приложения, тонко настраивать сеть и т.д.

Есть два принципиально разных подхода, как получить эти права:

  • Magisk и подобные — патчат загрузочный образ (boot.img) и подгружают суперпользователя поверх системы на этапе загрузки (userspace). Гибко, ставится почти на всё, но и обнаруживается относительно легко.
  • KernelSU (проект автора weishu) — встраивает суперпользователя в само ядро Linux. Отсюда название: Kernel-assisted SuperUser. Права выдаёт ядро, а не пользовательский процесс.

Проще говоря: Magisk — это «надстройка сверху», которую система в принципе может заметить; KernelSU — это «встроено в фундамент», ниже уровня, на котором обычно работают проверки. Взамен KernelSU требователен к ядру: нужно либо совместимое заводское ядро (GKI — Generic Kernel Image, единое ядро Google для многих устройств), либо ядро, собранное вручную.

ReSukiSU относится к семейству KernelSU: это тоже root через ядро.

KernelSU/ReSukiSU против Magisk: чем отличается и когда что выбрать

Частый вопрос — «что лучше, ReSukiSU или Magisk?». Правильный ответ: зависит от задачи и устройства, универсального «лучше» нет. Ниже — честное сравнение по подходам (ReSukiSU здесь представляет всё семейство KernelSU, Magisk — классический userspace-root).

КритерийKernelSU / ReSukiSU (root через ядро)Magisk (root поверх системы)
Где живёт rootв ядре Linux (ниже уровня приложений)в userspace, подгружается при загрузке
Скрытность от провероксложнее обнаружить; есть встроенный SUSFSобнаруживается относительно легче; скрытие — через отдельные модули
Требованиянужно совместимое ядро (GKI 2.0) или ручная сборкаставится почти на любое устройство
Простота установкисложнее: зависит от ядра, KMI, способа (LKM/AnyKernel3)обычно проще: патч boot.img и всё
Экосистема модулейсвоя, моложе и меньшеогромная, зрелая, много готовых модулей
Работа в ядреKPM — код прямо в kernel spaceнет (только userspace-модули)
Надёжность на кастомных ROMLKM часто не встаёт на самосборные ядра (см. ниже)как правило, работает стабильнее

В чём KernelSU/ReSukiSU объективно сильнее

  • Скрытность. Раз права выдаёт само ядро, а не процесс поверх системы, обнаружить root приложениям-проверяльщикам труднее. Плюс встроенный SUSFS для сокрытия. Это главный практический плюс для банков/платежей/игр — хотя 100%-й гарантии обхода конкретной проверки нет ни у кого, это «гонка вооружений».
  • KPM. Возможность запускать код прямо в ядре — то, чего у Magisk нет в принципе.
  • Гранулярный контроль. App Profile — точечная выдача root по приложениям с правилами SELinux/capabilities.

В чём Magisk удобнее

  • Ставится почти на всё. Magisk патчит boot.img и не требует GKI-совместимого ядра, поэтому подходит и старым, и «нестандартным» устройствам.
  • Проще и предсказуемее. Меньше зависимостей от версии ядра и KMI.
  • Зрелая экосистема модулей. За годы накопилось много готовых модулей и решений.
  • Стабильнее на кастомных прошивках. Это ключевой момент ⤵.

На кастомных ROM (LineageOS и т.п.) KernelSU-LKM часто не работает

Простой способ установки KernelSU/ReSukiSU — LKM (готовый бинарный модуль, встраиваемый в init_boot). Такой модуль собран под стоковое ядро Google и грузится только в совместимое ядро. Кастомные прошивки собирают ядро из исходников сами, и generic-LKM в него не встаёт из-за несовпадения vermagic/KMI. Для LineageOS это задокументировано: 🔗 KernelSU issue #2685 (июль 2025) — LineageOS обрезает поле androidXX-N в строке версии ядра, и менеджер не может определить KMI. Симптом: образ прошит, телефон загрузился, но менеджер показывает «Not Installed», а демон ksud падает с SECCOMP. Разбор и диагностика — в заметке про установку. Надёжный путь на кастомном ROM — ядро с уже вкомпилированным KernelSU (не LKM; в идеале собранное из исходников той же ROM), либо, если такого под вашу модель нет, Magisk оказывается практичнее — он патчит рамдиск и от vermagic не зависит.

Вывод: если устройство на GKI 2.0 и важна скрытность/KPM — KernelSU/ReSukiSU выигрывает. Если у вас кастомный ROM без готового интегрированного ядра, старое/non-GKI устройство или нужна максимальная простота — Magisk чаще практичнее. Это не «одно лучше другого вообще», а выбор под конкретный кейс.

Цепочка форков: KernelSU → SukiSU-Ultra → ReSukiSU

Чтобы не путаться в похожих названиях, вот происхождение проекта:

ПроектКтоРоль в цепочке
KernelSUweishu (tiann)Первоисточник — сама идея root через ядро
SukiSU-UltraShirkNekoФорк KernelSU: добавил KPM и ряд изменений
ReSukiSUReSukiSUФорк SukiSU-Ultra: упор на стабильность и простую сборку

По описанию самого проекта, ReSukiSU — это «более стабильный форк SukiSU»: те же возможности семейства SukiSU/KernelSU, но с правками ради надёжности и упрощённой сборки ядра. Насколько «стабильнее» на практике — это заявление авторов форка, а не измеренный факт, поэтому проверяйте на своём устройстве.

Возможности

KPM — Kernel Patch Module (модули, работающие в ядре)

KPM — визитная карточка семейства SukiSU. Это механизм, позволяющий запускать код прямо в пространстве ядра (kernel space), по аналогии с загружаемыми модулями ядра (LKM — Loadable Kernel Modules). KPM даёт возможность делать inline-hook и hook таблицы системных вызовов (syscall-table-hook) изнутри ядра.

Проще говоря: обычные root-модули работают в пользовательском пространстве (как приложения с расширенными правами). KPM позволяет внедрять произвольный код на самый глубокий уровень — в ядро. Это мощнее, но и опаснее: ошибка в коде уровня ядра роняет всё устройство, а не одно приложение.

SUSFS — скрытие root от приложений

SUSFS (SU Spoofing File System) — это набор патчей ядра для сокрытия факта root от приложений, которые его проверяют (банки, платёжные сервисы, игры с защитой от читов, Google Play Integrity). ReSukiSU включает встроенное управление SUSFS прямо в менеджере.

Важные ограничения именно этой реализации:

Ограничения SUSFS в ReSukiSU

В этом проекте SUSFS поддерживает бэкпорт с ядра 4.3+. Основной режим hook — Tracepoint Syscall Redirect — работает только на ядрах GKI 2.0 (5.10+) с архитектурой arm64-v8a или x86_64. На других ядрах используются альтернативные режимы hook (Manual Hook — ядра 3.4–6.18; SUSFS Inline Hook — ядра 4.3+). Скрытие root — постоянная «гонка вооружений» с системами проверки, поэтому 100%-й гарантии обхода конкретной проверки нет.

Система метамодулей

Модификации системы в ReSukiSU делаются systemless — то есть без изменения самих системных разделов, поверх них накладывается «слой» изменений. За монтирование модулей теперь отвечает отдельный метамодуль (metamodule): ядро- core больше не занимается монтированием само, а делегирует это установленному метамодулю.

Проще говоря: «systemless» значит, что системный раздел физически не трогается — модуль лишь подменяет то, что видит система, поэтому изменения легко откатить и они переживают обновления. А вынос монтирования в отдельный метамодуль — это архитектурное решение SukiSU/ReSukiSU: движок, который «накладывает» модули, стал сменным компонентом, а не частью ядра.

Совместимость с несколькими менеджерами

Менеджер — это приложение (APK), через которое вы управляете root-правами: выдаёте/забираете доступ у приложений, ставите модули, настраиваете SUSFS. Ядро ReSukiSU по умолчанию совместимо в роли ядра с менеджерами KernelSU, RKSU, MKSU и SukiSU — то есть можно управлять им из привычного менеджера семейства.

App Profile — права по приложениям

Как и в KernelSU, есть App Profile — точечный контроль, какому приложению давать root, а какому нет, вплоть до отдельных правил (SELinux-контекст, capabilities). Это снижает риск: root-доступ получают только те приложения, которым вы его явно разрешили.

Поддерживаемые устройства и ядра

Требования

  • Android / ядро: официально — GKI 2.0 (ядро Linux 5.10+). Старые ядра начиная с 3.4 тоже поддерживаются, но такое ядро придётся собирать вручную (готового образа не будет).
  • Архитектуры: arm64-v8a, armeabi-v7a, x86_64.
  • Проект отдельно позиционирует поддержку non-GKI ядер — то есть старых устройств, под которые нет единого образа Google.

Как это устанавливается

Пошаговая установка вынесена в отдельную заметку: Установка ReSukiSU — LKM, AnyKernel3 и ручной патч boot.img. Там разобран весь порядок по официальной документации (по состоянию на июль 2026): где взять менеджер, три способа прошивки и запасной ручной патч через magiskboot.

Коротко, чтобы понимать масштаб:

  • Менеджер (APK) на июль 2026 ещё в разработке и не публикуется в GitHub Releases — сборку берут из CI (nightly.link или GitHub Actions), только из ветки main.
  • Способ 1 — LKM-установка (ядра ≥ 5.10): менеджер сам патчит boot/init_boot/vendor_boot, вы прошиваете результат. Самый простой путь.
  • Способ 2 — AnyKernel3 (GKI и non-GKI): встроенная установка из менеджера, но требует уже полученного root.
  • Запасной путь — ручной патч boot.img через magiskboot (на устройстве или на ПК), когда автопатч не срабатывает.

Осторожно с прошивкой ядра

Прошивка несовместимого образа — частая причина «кирпича» (устройство не загружается). Ставьте образ только под точную модель и версию вашего устройства и заранее сохраните резервную копию заводских boot.img / init_boot.img. Root снимает часть защит устройства и может влиять на гарантию и работу банковских/платёжных приложений. Полные шаги и предостережения — в заметке про установку.

Лицензия и сообщество

  • Ядро (/kernel) — GPL-2.0-only.
  • Остальное (менеджер на Kotlin, userspace-инструменты, скрипты) — GPL-3.0-or-later.
  • Иконки-арт (аниме-персонажи) — Creative Commons BY-NC-SA 4.0 с дополнительными согласованиями авторов.
  • Исходники и документация открыты; переводы менеджера ведутся через Crowdin, обсуждение — в Telegram-канале проекта.

📚 См. также

🤖 Эти статьи открыты — можно обучать на них ИИ

При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: исходник этой заметки · весь репозиторий.

Вид графа

Обратные ссылки