KSuRoot

⚠️ Внимание: у устройств Blue Factory довольно строгая политика планирования, при повышении привилегий дочерние процессы легко уничтожаются системой. Сначала включите «Остановить ограничение дочерних процессов» в «Параметрах разработчика», а затем выполняйте повышение привилегий — так вероятность успеха выше.

Инструмент повышения привилегий KernelSU в один клик на основе уязвимости ядра CVE-2026-43499 (GhostLock).

Эта ветка основана на KSuRoot и полностью синхронизирована с обновлениями основной линии Root-My-Galaxy v0.2.6, а поверх этого добавлены сборка полезной нагрузки, встроенные полезные нагрузки производителя и целый набор UI в стиле жидкого стекла.

Mod by hmascs · версия 4.1.2 · Apache-2.0 Репозиторий: https://github.com/hmascs/KSuRoot

---

Что изменилось в 4.1.2

Новое в этом раунде (4.1.2): чтение смещения метки vr.ko из образа

vr.ko помечает task, приходящие от app, и это смещение бывает двух видов — 0x04 / 0x06, причём оно запекается в полезную нагрузку на этапе компиляции и патчу не поддаётся. Что ещё хуже — на одном и том же устройстве две копии vr.ko имеют каждая своё значение (в vendor_boot у Y300 Pro+ их две, при этом srcversion полностью совпадает) — при выборе неверного варианта проявляется «байты очищены не там, метка не стёрта, дочерний процесс по-прежнему убивается», а в логах всё выглядит нормально.

Теперь схема Blue Factory потребует от вас предоставить vendor_boot.img: приложение читает из той копии lib/modules/vr.ko, которая фактически загружается, настоящее смещение данного устройства и затем перезаписывает полезную нагрузку. Четыре встроенные/самостоятельно собранные библиотеки (libbaseline_6_1 / libbaseline_6_12 / libbs / libionstack) жёстко привязаны каждая к своему профилю, и при ошибочном выборе вас сразу остановит шлюз нулевых попаданий, а не выдаст продукт, скопированный как есть.

Кроме того, добавлен «Импорт полного пакета прошивки»: просто выберите скачанный вами OTA zip или fastboot tgz, и он сам извлечёт boot и vendor_boot — не нужно сначала распаковывать и не нужно извлекать вручную.

⚠️ Полный пакет нужно целиком скопировать в кэш приложения, чтобы можно было читать произвольно (центральный каталог ZIP находится в конце пакета, а uri из SAF не преобразуется в File). При нехватке места он сразу откажет, а после извлечения немедленно удалит кэш.

4.1.2 = 4.1.0 + 19 коммитов. Эти коммиты изначально остановились в ветке fix/baseline-routing, теперь они влиты в main. Уже выпущенный установочный пакет 4.1.0 их не содержит — каждый пункт ниже был исправлен только после этого.

Исправленные тихие сбои

#	Дефект	Последствие
1	VR_TAG_A_OFF для 6.1 заполнен как 0x06 (по факту должно быть 0x04)	На устройствах Blue Factory с 6.1 метка не стирается ни на один байт, а самопроверка сообщает об успехе. Проявляется как «после успешного повышения привилегий дочерний процесс немедленно убивается», и причину не видно
2	Для定位 таблицы смещений kallsyms использовалась отрицательная модульная арифметика (прямой перенос семантики Python)	Полный отказ на ядрах 6.4+, базовый адрес берётся из фрагмента ASCII-текста
3	Критерий таблицы смещений учитывал только «монотонность первых трёх элементов»	Практически нулевая различимость (внутри таблицы любое место монотонно); заменено на проверку формы таблицы
4	BASELINE_6_12.imageBase заполнен целевым базовым адресом	Все точки конструирования в форме абсолютных адресов пропущены (39 мест → 9 мест)
5	При несовпадении символов только обнулялся продукт, а gate оставался Proceed	blocked=false и продукт 0 B, UI не показывает блокирующее окно
6	fallback у FopsSlot так и не был задействован	Если таблица не найдена — сразу отказ, откат к резервному символу невозможен

Дополнение функциональности

• 6.12 действительно заработал: ashmem в 6.12 стал реализацией на Rust, имена символов полностью mangled → изменено на чтение во время выполнения из слота fops у miscdevice (TARGET_ASHMEM_FOPS_UNSYMBOLED)
• 6.1 / 6.12 доступны как в универсальной, так и в схеме Blue Factory (четыре комбинации по 16 / 16 / 13 / 13 профилей), список см. в архиве 07-文档/6.1-6.12-双方案清单.md
• Смещение метки vr.ko измерено поштучно на реальных устройствах: 6.1 = 0x04, 6.6 / 6.12 = 0x06 (в vr.ko из прошивок производителя на трёх реальных устройствах)
• Рецепты сборки полезной нагрузки в репозитории (载荷构建/): ранее в репозитории было 15 мест, ссылающихся на несуществующий каталог

★ Обнаружено на реальном устройстве: на 6.1 ни одно из 26 смещений не было изменено, и пакет всё равно собирался

Результат запуска сборки на X100 Pro (6.1.145):

偏移解析: 28 / 28 项
需要改写: 26 项 · 校验通过: 0 项
该动态库未引用 26 项偏移

Это не «нечего менять», а «эти две вещи не из одного набора». Корневая причина — две независимые дороги разошлись:

Что выбираем	По чему выбираем	На 6.1.145 выбралось
Базовая библиотека	Семейство структур (F6_1)	libbaseline_6_1.so (старое значение из baseline-6.1-tokay/target.h)
Профиль	Трёхуровневая маршрутизация (строка ядра)	up-6-1-145-… (старое значение из offsets.h GhostLock)

Способ патчинга — «взять старое значение из профиля и искать литерал в .so». Два набора старых значений не пересекаются вообще, поэтому ни один из 26 пунктов не совпал, и результат равен побитовой копии базовой библиотеки.

Почему исходный жёсткий шлюз не сработал: критерий hasFailures — это changed && !ok && !absent —— absent явно исключён. То обоснование («в старой версии .so может не быть соответствующего пути кода») верно для отдельных ключей, но неверно для «все ключи absent».

Два способа исправления:

1. Библиотека и профиль принудительно из одного источника: самосборное семейство базовых библиотек (libbaseline_6_1.so / libbaseline_6_12.so) должно идти со своим профилем (baseline-6-1-tokay / baseline-6-12-honor), а профили up-* из апстрима применимы только к той .so из апстрима. Добавлен BaselineLibraries.profileIdForLibrary().
2. Жёсткий шлюз на ноль попаданий: если ни одна спецификация смещения не попала на сайт, упаковка останавливается (спецификация базового адреса не учитывается — она часто меняется, даже если ничего не совпало, и замаскировала бы «ни одно смещение не изменено»). Для этого в SpecOutcome добавлено поле kind.

Регрессионные тесты в BaselineLibraryPairingTest (4 штуки), один из которых напрямую утверждает, что два набора старых значений не пересекаются —— превращая «почему обязательно нужно сопоставление» в исполняемый факт.

Динамические библиотеки: тот класс проблем, когда после импорта «нажал — и ничего»

#	Дефект	Последствие
1	«Сборка полезной нагрузки → использование как полезной нагрузки» использует продукт в памяти; после перезапуска процесса outputLibrary равен null, а старый код делал ?: return	Ничего не произойдёт: ни Toast, ни ошибки, кнопка не меняется — пользователь видит «нажал — и ничего»
2	Ключ кэша PayloadStaging — «одно имя + одна длина»	Пользовательская полезная нагрузка в приватном каталоге всегда называется payload.so; при замене на нагрузку с точно таким же числом байт произойдёт молчаливое переиспользование предыдущей
3	Ключ кэша shizukuStage — только длина	Та же яма снова на пути Shizuku
4	Можно хранить только одну пользовательскую полезную нагрузку	Импорт второй перезаписывает первую без предупреждения
5	Все файлы в приватном каталоге приложения	Пользователь не видит их в файловом менеджере и не может сам сделать резервную копию/разобрать

Хранилище динамических библиотек: Download/动态库/<机型>/<文件名>.so