Сводка проблем¶

Скачайте этот скрипт user-home/modules/script/enhanced_automation_wechat.yaml и поместите его в каталог ~/modules/script на устройстве.

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

Эта ситуация может возникать на Android 16, но не исключено её появление и на более старых версиях. Прежде всего убедитесь, что вы используете последнюю версию сервера. Если ошибка сохраняется, проверьте, не используете ли вы KernelSU в качестве Root-решения. Сбой возникает из-за того, что старая версия ksu повреждает системный образ SELinux policy; попробуйте использовать последнюю версию ksu. Если сбой не исчезает, переключитесь на Magisk или запустите с пониженными привилегиями shell.

Возможно, некоторые приложения используют app-zygote для обнаружения Frida. Попробуйте настроить enhanced-stealth-mode=true в удалённом рабочем столе, чтобы обойти эту проблему (побочный эффект — невозможность использовать функции spawn в Frida). В 10.x по умолчанию эта настройка не требуется, поскольку используемая версия frida-server по умолчанию уже обходит данную проблему. (Однако если вы вручную переключились на версию 17.5.2, возможно, потребуется выполнить эту настройку.) Если проблема всё же остаётся, отключите все модули Magisk и перезагрузите устройство.

Не нужно спрашивать, насколько совершенна функция захвата пакетов: FIRERPA уже всё настроил и выполнил все необходимые шаги для захвата пакетов. Если другие программы для захвата пакетов ничего не перехватывают, FIRERPA обязательно сможет; если FIRERPA не может перехватить, то и ни одна программа с аналогичной логикой не сможет. Не беспокойтесь о проблемах с доверием к сертификатам: при захвате пакетов FIRERPA автоматически установит системный корневой сертификат для приложения, без вашего участия. Что касается понижения QUIC: startmitm автоматически отключает протокол UDP, и в обычной ситуации, когда приложение не может использовать UDP, оно автоматически переходит на TCP, не используя QUIC. Всё это не требует ручного вмешательства.

Возможные причины: 1) в самом приложении есть механизм проверки сертификатов или certificate pinning; 2) неправильно выполнены предварительные или последующие действия. Как определить, есть ли в приложении проверка сертификатов: включите глобальный захват пакетов и откройте браузер или другие приложения, чтобы проверить, перехватываются ли пакеты нормально. Проверьте несколько сетевых приложений: если одни приложения перехватываются, а другие нет, то, скорее всего, те, что не перехватываются, используют частный протокол или проверку сертификатов. Обычно в логах startmitm при этом появляется Client TLS handshake failed и подобное, но это не главное. Если подтверждено наличие проверки сертификатов, для продолжения захвата необходимо динамически обойти эту проверку с помощью реверс-инжиниринга или других методов. Что касается неправильной предварительной/последующей обработки: обычно некоторые пользователи не отключают системный брандмауэр, из-за чего порт прокси не доступен для телефона и ничего не происходит. Другой случай: приложение установило необходимые сетевые соединения до запуска захвата, поэтому после его запуска трафик продолжает идти через уже установленные соединения, минуя прокси. После запуска startmitm нужно вручную полностью завершить приложение (принудительно остановить) и затем снова открыть его.

Сначала проверьте, отключён ли брандмауэр. Затем посмотрите, выводит ли скрипт захвата логи при посещении веб-сайтов в мобильном браузере. Если появляется ошибка вида No route to host, и она соответствует действиям браузера (то есть при каждом посещении скрипт выводит эту ошибку), возможная причина в следующем: телефон поддерживает доступ по IPv6, и DNS по умолчанию также использует IPv6, но компьютер, на котором запущен скрипт, не имеет включённого IPv6 или не поддерживает его, из-за чего возникает No route to host. Если ваш провайдер поддерживает IPv6, включите IPv6 в настройках сети на компьютере; либо в командной строке скрипта попробуйте указать --proxy-dns 114.114.114.114 и проверьте, восстановилась ли работа. Если оба способа не помогли, обратитесь в поддержку.

Эта проблема аналогична предыдущей. Сначала проверьте, могут ли другие приложения нормально перехватываться, чтобы исключить проблему с сервисом. Если проксирование работает нормально, то, вероятно, устройство поддерживает IPv6, а на машине, где запущен startmitm, нет действующего IPv6-адреса. Если в вашей сети есть доступный публичный IPv6, назначьте его компьютеру; либо полностью отключите IPv6 на маршрутизаторе.

Если вы можете нормально захватывать пакеты нужных приложений, не обращайте внимания на этот вывод: это могут быть логи от механизмов проверки сертификатов других приложений в системе или сторонних SDK внутри приложения.

APK для автозапуска зависит от настроек разных систем и может не запускаться автоматически вместе с системой. Если после включения устройства доступ невозможен, нажмите кнопку «Запуск вручную» в приложении, подождите одну минуту и повторите попытку доступа. Если запустить всё равно не удаётся, попробуйте установить сервис вручную или через модуль.

Убедитесь, что вы выполнили все настройки из раздела Подготовка окружения, затем попробуйте несколько раз перезагрузить устройство (примерно 3 раза).