Все хуки Frida срабатывают. Почему рабочих эндпоинтов всё равно ноль

На трёх платформах я нашёл все нативные звенья цепочки: точку входа регистрации устройства, слой, где security SDK перехватывает запрос, нативный interceptor, переписывающий исходящий пакет, а также методы, которые JNI динамически регистрирует в рантайме через RegisterNatives. Скрипт Frida подключён, логи идут потоком, каждый хук стабильно срабатывает. Но когда я открыл каталог команд и посчитал вызываемые нативные эндпоинты этих трёх платформ, результат оказался простым: ноль.

В этом же проекте у другой платформы их было 11. Все проверены в реальных условиях, перенесены в код и работают как полноценные команды.

Дело не в технике хуков. Все хуки срабатывают, схема связей аккуратно собрана. Разница — в пороге, о существовании которого многие даже не задумываются. Между фактом срабатывания хука и действительно пригодной возможностью лежит уровень доказательств. О том, как задать этот порог, почему отметка «пока не готово» обходится дешевле недоделанного эндпоинта и где в этом процессе полезна модель, и пойдёт речь.

Сработавший хук ещё не делает возможность рабочей

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

Но каталог команд не интересует, что вы «внутри». Для него важнее другое: способна ли команда при нормальном входе стабильно вернуть непустой, корректно структурированный payload, который можно передать дальше по цепочке. Между этими состояниями — большая дистанция.

Обычно всё ломается так: хуки срабатывают, цепочка целиком понятна, в логах видно, как уходит запрос регистрации устройства, как security SDK вычисляет своё значение, как нативный interceptor добавляет заголовок подписи. На вид всё правильно. Но на реальном устройстве регистрация возвращает нулевой device ID либо эндпоинт деталей приходит с пустым телом. Цепочка открыта, данных нет.

Что есть в этот момент? Набор пробников, которые умеют наблюдать внутреннее поведение конкретной версии приложения. Но вызываемого эндпоинта у вас ещё нет. Выдать первое за второе — значит заложить мину для всех, кто будет работать после вас.

Почему на одной платформе 11 команд, а на трёх — 0

Достаточно поставить эти платформы рядом, и нужный порог становится очевиден.

Эти 11 команд на контрольной платформе — не просто «более удачные хуки». Прежде чем стать полноценными Python-командами, каждая прошла четыре порога доказательств из следующего раздела и принесла с собой структурированные результаты валидации.

Три другие платформы тоже не были заброшены. Разобраны слой перехвата security SDK, нативный interceptor запросов и набор методов, которые JNI регистрирует динамически; хуки Frida остаются на месте. Но пока не проходит проверка реального состояния установки, пока регистрация устройства не выдаёт ненулевую идентичность, всё, что следует дальше, остаётся пустым. Поэтому число нативных команд честно остаётся равным 0, а реально доступен совершенно отдельный путь через Web или браузерный транспорт.

Если смотреть на общую ведомость, в этой пачке мобильных возможностей всего 32: из них 23 действительно дошли до реализации, а оставшиеся 9 застряли в статусе «ждём реальный профиль устройства». Ни одна из них не попала в каталог раньше времени. Число 9 — не показатель провала, а показатель дисциплины: это точный объём того, что «цепочку поняли, но доказательств пока недостаточно».

Четыре порога доказательств

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

Первый: реальное состояние установки. Запрос должен исходить от ненулевой идентичности установки, которую признаёт upstream. Срабатывание хука в эмуляторе или на сломанном профиле не считается. Если регистрация устройства возвращает нулевой ID, этот барьер не пройден; после этого полнота цепочки уже ничего не меняет — на выходе будет пусто. Именно здесь одновременно застряли все три платформы.

Второй: непустой ответ. Открытый маршрут ещё не означает наличие данных. Запрос ушёл, статус — 200, тело — пустое. Такой «успешный пустой ответ» опаснее ошибки: он проходит проверки, которые смотрят лишь на отсутствие исключения. Для прохождения порога нужны структурированные, полные и непустые данные, которые можно сразу передать дальше.

Третий: полная классификация ошибок. Зрелая возможность при сбое должна объяснять причину, а не выбрасывать общую ошибку. Нет страницы, не выполнен вход, рантайм не готов, ответ пустой — это совершенно разные сценарии, и для них нужны различимые коды ошибок, а не одна общая категория. Команда, способная сказать только «не получилось», не готова к каталогу: вызывающая сторона не поймёт, нужно ли повторить запрос, пройти аутентификацию или пропустить операцию.

Четвёртый: замкнутый повторяемый тест. Один удачный запуск — не возможность. Один и тот же вход и один и тот же сценарий должны стабильно отрабатываться, а успешный результат нужно зафиксировать в сохранённых структурированных данных валидации. Если один раз всё сработало, а в следующий пришла пустота, значит вы пока не контролируете цепочку: вы лишь однажды случайно попали в подходящее состояние рантайма.

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

Как разбирать взрывные логи Frida по уровням моделей

Для проверки этих четырёх порогов исходным материалом служит трасса Frida — и она быстро разрастается. Подключите несколько десятков методов, прогоните одну полную цепочку, и получите от десятков до сотен тысяч строк. Большая их часть — шум от polyfills, heartbeat-событий и посторонних бизнес-модулей.

Если выгрузить весь этот массив в одну модель с вопросом «почему хук не получил данные», получится обобщённая догадка. Чем больше контекст, тем выше вероятность, что модель склеит два несвязанных фрагмента вызовов. Правильнее дробить трассу и передавать сегменты моделям разных уровней в зависимости от задачи.

Это учебниковый случай, когда уровни нужно комбинировать, а не просто «выбрать самую сильную модель для всего». Четыре задачи требуют от модели совершенно разных способностей:

Особенно важен этап разметки. Это механическая работа: в десятках тысяч строк нужно отделить шум и оставить классы регистрации устройства, криптографии и сети. Объём слишком велик для ручной обработки. Задачи вида «простое суждение с очень высокой частотой» — естественная территория дешёвого уровня; запускать их на reasoning-модели — прямое расточительство. Когда лог сжат до нескольких сотен размеченных строк, его можно отдать reasoning-уровню для решения вопроса «на каком пороге мы застряли» — и тогда сходятся и стоимость, и точность.

Не верьте на слово — один раз прогоните оба варианта:

1. Вырежьте сегмент трассы одной цепочки — от нескольких тысяч до десятков тысяч строк.

2. Сначала размечайте его частями через claude-sonnet-5: отбрасывайте шум, оставляйте классы регистрации устройства, криптографии и сети.

3. Передайте размеченное резюме в claude-opus-5 и попросите вывести «на каком из четырёх порогов сейчас застряла цепочка и какие строки это подтверждают».

4. Для контроля загрузите ту же сырую трассу целиком в одну модель и задайте тот же вопрос.

5. Смотрите на одно: выдаёт ли модель общую догадку или указывает конкретный порог и конкретные строки. В этом и будет критерий выбора.

Хук — это привязанный к версии пробник, а не signer

Почему хуки для этих трёх платформ сохранены, но принципиально не добавлены в каталог команд? Потому что хук — это пробник, а не signer. По своей природе это разные вещи.

Хук привязан к конкретной сборке приложения — например, к версии 32.x. Символы, смещения и раскладка методов, от которых он зависит, принадлежат именно этой версии. Upstream выпускает обновление, всё сдвигается — и хук сразу перестаёт работать. Это по определению недолговечный, версионно-зависимый инструмент. Он отвечает на вопрос наблюдения: «что эта версия прямо сейчас делает внутри?» Именно для этого нужна инструментация: в документации Frida Interceptor описан как средство наблюдения и переписывания вызовов в рантайме. Он позволяет увидеть, как вызывается функция и какие у неё аргументы, но сам по себе не является готовым решением, которое «вычисляет подпись по входным данным».

Signer, который попадает в каталог эндпоинтов, устроен наоборот: он должен быть стабильным, повторяемым, автономным и пригодным для CI. Его задача — «дай мне вход, и я вычислю правильную подпись»; это уже вопрос переиспользуемой возможности. Даже если хук позволяет отчётливо увидеть каркас алгоритма подписи, это лишь этап algorithm-fingerprinting. До самостоятельного signer всё ещё остаётся полный процесс очистки и дифференциальной верификации.

Этим же объясняется порядок в лестнице очистки: сначала возможность должна стремиться к прямому соединению на чистом Python, затем при необходимости переходить к запуску минимального фрагмента подписи в локальном Node/V8 и лишь в крайнем случае соглашаться на пассивный браузерный bridge. Хука на этой лестнице пока вообще нет. Он находится до неё, в зоне «исследование», а не «реализация». Регистрировать зависящий от версии пробник наблюдения как signer — значит повесить вывеску «реализация» на недостроенный фрагмент «исследования».

Как архивировать исследовательский актив, чтобы он не протух

Не добавлять хук в каталог эндпоинтов — не значит выбрасывать его. На его создание уже ушли реальные усилия, в нём содержатся знания о цепочке, образцы и результаты валидации. Удалить это — чистый убыток. Важно правильно его архивировать, иначе через два месяца даже вы сами не поймёте, насколько далеко продвинулись.

Исследовательский актив по приложению должен фиксировать как минимум четыре вещи:

• Тип транспорта. Работает ли цепочка на нативном протоколе, через локальную подпись Node/V8 или пассивный браузерный bridge. От этого зависит, насколько далеко её можно будет очистить позже.

• Уровень доказательств. Сколько из четырёх порогов пройдено. Это может быть «цепочка найдена», «получено ненулевое состояние установки, но ответ пустой» или «ответ непустой, но результат не повторяется». Эта запись точно покажет следующему исследователю, что отделяет работу от пригодного результата.

• Версия / сборка приложения. Версия, к которой привязан хук. Без неё после очередного обновления upstream невозможно понять: вы ошиблись в реализации или изменили сборку.

• Краткое описание образца. Как выглядели вход и выход конкретного прогона; хранить нужно обезличенную копию. Это самый быстрый ориентир для возвращения к исследованию.

Если зафиксировать эти четыре пункта, цепочка с 0 командами останется активом, который можно развивать, а не кучей устаревших логов. Заодно это предотвращает два худших сценария: удалить хук и сделать вид, что исследования не было, или насильно внести его в каталог и притвориться, что он пригоден к использованию. Второй вариант особенно дорог. Эндпоинт, который «выглядит вызываемым, но на деле возвращает пустоту», переносит издержки на каждого последующего пользователя каталога: он строит интеграцию, пишет повторы, один раз сталкивается с пустыми данными и в итоге перестаёт доверять всему каталогу. Честный пробел с пометкой «исследовательский актив, 0 команд» стоит лишь одной строки в README — и только вам.

Пустая оболочка обходится дороже, чем пробел, и здесь это видно особенно ясно.

Один ключ убирает трение при разборе логов

Вернёмся к разделению логов из четвёртого раздела: длинный контекст для чтения всей трассы, дешёвый уровень для массовой разметки, reasoning-уровень для классификации, средний reasoning-уровень для атрибуции. Четыре уровня от нескольких поставщиков, четыре SDK, четыре схемы аутентификации, четыре формата ошибок. Когда нужно классифицировать логи Frida через четыре клиента, большинство быстро прикидывает затраты, решает, что оно того не стоит, и в итоге мучает сотни тысяч строк трассы одной моделью — либо сжигая деньги, либо не справляясь с объёмом.

AIReiter убирает это трение: один ключ, один OpenAI-совместимый интерфейс, все четыре уровня за ним, а переключение происходит заменой поля model в теле запроса.

# Разметка лога: дешёвый уровень, тысячи вызовов с высокой параллельностью
curl https://aireiter.com/api/v1/chat/completions \
  -H "Authorization: Bearer $AIREITER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-5",
    "messages": [{"role": "user", "content": "<one chunk of trace + labeling instruction>"}]
  }'

# Классификация порога: переключитесь на reasoning-уровень, остальное без изменений
#   "model": "claude-opus-5"
# Чтение всей цепочки вызовов: уровень длинного контекста
#   "model": "kimi-k3"
# Атрибуция различий в ответе:
#   "model": "gpt-5.6-sol"

Если вы уже используете OpenAI SDK, укажите для base_url значение https://aireiter.com/api/v1 — больше ничего менять не нужно. В Anthropic SDK используйте POST /api/v1/messages с тем же ключом.

У этой задачи неравномерная структура затрат, и скидка приходится как раз на её тяжёлую часть. Трасса одной цепочки занимает от десятков до сотен тысяч строк, разметка выполняется по чанкам, и на одну платформу приходится от сотен до тысяч вызовов claude-sonnet-5. Это основная часть стоимости. Вызовы с длинным контекстом, читающие всю трассу, занимают несколько сотен тысяч токенов на вход — ещё одна крупная статья. Классификация и атрибуция требуют мало вызовов, но у них выше цена единицы. Скидка 30% на Claude попадает точно в разметку и классификацию порогов — две самые затратные части. GPT за полцены покрывает уровень атрибуции. Чтение длинного контекста выполняет Kimi K3, доступный по тому же ключу.

• Получить API-ключ

• Попробовать без регистрации: передайте сегмент трассы в claude-sonnet-5 для разметки, затем попросите claude-opus-5 классифицировать его и проверьте, сможет ли он сразу указать порог, на котором застряла цепочка, прежде чем подключать всё к своему процессу.

Итог

В реверс-инжиниринге приложений сработавший хук даёт возможность наблюдения: «я вижу, что эта версия делает внутри». Каталогу эндпоинтов нужна возможность вызова: «дай мне вход, и я стабильно верну непустые корректные данные». Между ними лежат четыре порога доказательств: реальное состояние установки, непустой ответ, классификация ошибок и повторяемый тест.

Три платформы полностью разобраны, все хуки срабатывают, а число команд всё равно 0 — это не провал, а дисциплина. Реальное состояние установки не проходит проверку, поэтому вы честно останавливаетесь на 0, архивируете хук как исследовательский актив и продолжаете работу, когда появится профиль устройства.

Роль модели в этом процессе вполне конкретна. Она помогает разделять, размечать, классифицировать и атрибутировать сотни тысяч строк трассы, сокращая поиск ответа на вопрос «где застряла цепочка» с целого дня чтения логов до нескольких минут. Но окончательное решение «пройден ли порог» — так же, как решение «верна ли гипотеза» при дифференциальном тестировании, — в итоге принимает не модель. Его определяют заданные вами четыре критерия и доказательства, которые воспроизводятся при повторных запусках. О том, как встроить модель на правильное место во всём процессе реверс-инжиниринга, рассказывает обзор из четырёх этапов.