Логические капчи ломаются не силой, а разбором дерева условий и триггеров

Логические капчи ломаются не силой, а разбором дерева условий и триггеров

Логическая капча почти всегда сводится к проверке последовательности: клик, задержка, движение, текст в поле, переход между экранами. Внутри это не «магия антибота», а набор веток, где каждое действие переводит сессию в следующий state. Если рендерить страницу как черный ящик, ошибки будут случайными; если снять события и сетевые запросы — появляется предсказуемая схема.

Базовый обход строится вокруг трех вещей:
— фиксируем DOM, XHR/fetch и изменения скрытых полей;
— строим карту переходов: какой input, какой timeout, какой ответ сервера;
— воспроизводим действия в том же порядке, но без лишних событий, которые ломают тайминг.

Чаще всего ломается не сам ответ, а контекст. Капча может проверять фокус окна, порядок keydown/keyup, наличие pointermove, а также консистентность токенов между фронтом и бэком. Поэтому скрипт должен быть не «быстрым», а стабильным: одинаковые интервалы, одинаковая последовательность, один и тот же набор заголовков и cookie. Здесь выигрывает не агрессивная эмуляция, а аккуратная симуляция браузерной логики.

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