Как запустить Xposed-модули без рут-прав с помощью NPatch

Когда нужно поковырять чужое Android-приложение, снять SSL pinning или включить скрытую отладку, обычно сразу тянутся за Magisk или KernelSU. Но рутовать рабочий телефон ради одной утилиты неудобно. Банковские клиенты начинают ругаться, Play Integrity сыпется, а на корпоративных девайсах рут и вовсе запрещен политиками безопасности.

Долгое время эту проблему решал проект LSPatch. Он брал готовый APK, вшивал внутрь рантайм LSPosed и нужные хуки, после чего приложение работало с Xposed-модулями без системных привилегий. Когда оригинальный LSPatch перестал активно обновляться, на смену пришел форк под названием NPatch (Neo LSPatch).

Что делает этот инструмент

Проект берет обычный APK-файл и пересобирает его. Внутрь архива внедряются DEX-файлы загрузчика и нативные библиотеки (.so), отвечающие за перехват вызовов ART (Android Runtime). Когда пропатченное приложение запускается, первым делом стартует этот встроенный слой. Он инициализирует среду выполнения Xposed API прямо внутри изолированного процесса приложения.

Для остальной системы вы запускаете обычную пользовательскую программу. Ей не нужны права суперпользователя, она не трогает системный раздел /system и не пытается подменять zygote. Все модификации и хуки замыкаются исключительно внутри песочницы конкретного пакета.

Поддерживаются версии начиная с Android 9 и вплоть до актуальных релизов Android, совместимых с кодовой базой ветки JingMatrix/LSPosed.

Как устроен процесс патчинга

Под капотом NPatch опирается на наработки нескольких открытых проектов:

• LSPosed отвечает за реализацию вызовов Xposed API и перехват методов в рантайме ART.
• Xpatch дал базовую концепцию инъекции кода внутрь APK без системного вмешательства.
• Apkzlib используется для разборки, модификации zip-архива и последующей быстрой упаковки пакета без полной декомпиляции в smali.

В отличие от классической связки apktool + jarsigner, где декомпиляция объемных проектов с обфускацией часто падает с ошибками, такой подход работает быстрее и надежнее. Ресурсы и манифест корректируются напрямую, после чего внедряется загрузчик.

Способы использования

Работать с инструментом можно двумя путями: на компьютере через терминал или прямо на телефоне.

Вариант 1. Консольный запуск через jar

Если вы автоматизируете сборку тестовых билдов на CI или анализируете софт на рабочей станции, удобнее взять готовый jar-файл из релизов:

# Базовый синтаксис запуска утилиты
java -jar npatch.jar [аргументы]

Утилита принимает на вход исходный APK и модули, которые нужно встроить. На выходе получается готовый модифицированный пакет, который остается только подписать тестовым ключом и поставить через adb install.

Вариант 2. Менеджер на устройстве

Для повседневных задач проще скачать manager.apk из раздела релизов на GitHub.

1. Устанавливаете менеджер на Android-девайс.
2. Выбираете установленное приложение или локальный APK-файл.
3. Указываете Xposed-модули, которые должны загружаться при старте.
4. Менеджер собирает новый установочный пакет и предлагает удалить оригинал перед инсталляцией модификации.

Так как подпись приложения неизбежно меняется при пересборке, обновить оригинальную программу поверх не выйдет. Ее придется удалить, потеряв локальные данные, если они не были синхронизированы.

Для чего это пригодится на практике

Я регулярно использую подобные патчеры в реверс-инжиниринге и тестировании мобильных клиентов.

• Обход SSL Pinning для перехвата трафика. Заворачивать трафик в Burp Suite или mitmproxy намного проще, когда можно вшить модуль вроде TrustMeAlready или JustTrustMe прямо в APK. Не нужно прокидывать сертификаты в системное хранилище через Magisk.
• Инструментирование и сбор логов. Если нужно посмотреть, какие аргументы улетают в закрытые методы сторонней SDK, пишется крошечный Xposed-хук, внедряется в билд и логирует стек вызовов в logcat.
• Тестирование модулей на чистых девайсах. Разработчикам модулей полезно проверять, как их код ведет себя в изоляции без системного LSPosed.

Подводные камни и ограничения

У рутлесс-подхода есть естественные границы, о которых стоит знать заранее:

• Системные модули работать не будут. Если хук рассчитан на изменение поведения SystemUI, шторки уведомлений или сервисов Android, NPatch здесь бессилен. Он живет строго внутри пользовательского процесса.
• Некоторые приложения с жестким античитом или продвинутой самозащитой (проверка целостности подписи, контроль наличия посторонних .so файлов) обнаружат вмешательство и закроются при старте.
• Документация в репозитории пока лаконичная. Большая часть деталей обсуждается в Telegram-чате проекта, а свежие сборки нередко приходится вытаскивать прямо из артефактов GitHub Actions.

Стоит ли пробовать

Если вам периодически требуется залезть под капот стороннего Android-приложения или быстро протестировать гипотезу без перепрошивки устройства, положите npatch.jar себе в тулбокс. Проект держит кодовую базу LSPatch в актуальном состоянии и спокойно справляется с пересборкой приложений под свежие версии Android.