ID:
ROOT_MAGISK_PROPERTYКатегория: Root и состояние системы Статус в RKNHardering 2.10.0: Активная проверка Роль в вердикте: Средняя
Эта страница описывает фактическую реализацию RKNHardering 2.10.0. Здесь отдельно указано, что можно сделать без root, что требует root, а также где способ только уменьшает один сигнал, но не скрывает VPN целиком.
Проверяются init.svc.magisk_daemon, init.svc.magisk_pfs и persist.magisk.hide. Любое непустое значение создаёт magisk_prop и high-confidence review.
Одна из трёх property существует и непуста в property view процесса.
Сильный Magisk-артефакт, особенно на старых/совместимых конфигурациях. Современная версия может не использовать все эти имена, поэтому clean не исключает Magisk.
Как строка влияет на отчёт: Строка не даёт самостоятельный окончательный вердикт, но выставляет needsReview=true и добавляет доказательство средней уверенности.
OEM или сторонний модуль теоретически может создать одноимённую property. resetprop может скрыть её только в части контекстов и оставить mount/path признаки.
Важно оценивать эту строку вместе с соседними сигналами. Один чистый API не перекрывает Java Binder, libc, raw netlink/syscall, procfs/sysfs, локальные сокеты и серверные признаки одновременно.
Если root не нужен, надёжное исправление — вернуть устройство к штатному состоянию официальным способом: удалить root через его менеджер либо прошить заводские boot/init_boot и системные разделы именно от установленной сборки. Разблокированный загрузчик, кастомное ядро и оставшиеся каталоги могут продолжить выдавать модификацию даже после удаления менеджера. Перед восстановлением сделайте резервную копию; повторная блокировка загрузчика на изменённой прошивке способна привести к потере данных или неработоспособности устройства.
С root можно лишь уменьшать наблюдаемую поверхность, а не доказать отсутствие root. Ограничьте выдачу su минимальным числом приложений, не давайте её RKNHardering, отключите ненужные модули и не переводите SELinux в permissive. App Profile/DenyList и mount-изоляция проверяются на конкретной прошивке. SUSFS и сходные решения относятся к экспериментальным: они требуют совместимого ядра и могут сами добавлять следы. Для эталонного теста всё равно нужен отдельный стоковый телефон. Если property появилась из legacy-модуля, обновите или удалите его через официальный manager. Не используйте случайный hide-script, который массово переписывает init.svc.*.
adb shell getprop init.svc.magisk_daemon
adb shell getprop init.svc.magisk_pfs
adb shell getprop persist.magisk.hide
Сравните с detail после force-stop/relaunch.
После любого изменения сделайте force-stop RKNHardering и VPN-клиента, запустите их заново и повторите полный scan. Для Zygisk/Xposed/kernel-модулей обычно нужна перезагрузка. Сравнивайте не только эту строку, но и соседние сигналы: частичный hook часто создаёт несогласованность между API.
Сама проба выполняется с обычными правами приложения и не запрашивает root. ADB-команды ниже служат только для ориентира: adb shell работает под другим UID и может видеть больше или меньше, чем процесс приложения. Решающий тест — повторный запуск самой проверки после force-stop.
Подмена init service property может нарушить управление сервисом и усложнить диагностику. Изменение boot scripts может вызвать bootloop.
Удалите созданное resetprop-правило или legacy-модуль, затем перезагрузитесь. Для полного unroot следуйте официальной инструкции Magisk.
Средняя. Проверено по kMagiskProps; Kotlin назначает high confidence review.
Статус стороннего решения не переносится автоматически на это устройство. Заявление разработчика модуля — это исходная гипотеза; подтверждением служит повторяемый результат RKNHardering на конкретной версии Android, прошивки и ядра.
native_signs_probe.cpp — нативная реализация проб.NativeSignsChecker.kt — основной native/legacy verdict.NativeSignalId.kt — полный реестр ID.NativeSignalCatalog.kt — категория, slug и mapping строк.Связанные сигналы: root-property, root-management, root-suspicious-mount.