Блог проекта

Обновление в работе RuCaptcha по решению ReCaptcha V3

Скоро будет ровно 2 года, как мы добавили на наш сервис возможность обхода ReCaptcha V3 и всё это время алгоритмы обхода несколько менялись. Сейчас мы снова немного изменили алгоритм работы и хотим об этом рассказать вам.

Кратко:
1) Работает хорошо
2) Платите только за сработавшие токены
3) Работает хорошо, но не сразу, нужно прислать 500-2000 капч, прежде чем начнёте получать стабильно хороший результат.
4) Нужно обязательно слать reportgood\reportbad - уведомления.

Подробнее:
Для начала напомним, что ReCaptcha V3 это вовсе не капча, как это иногда представлятся, а вероятностная оценка человечности пользователя, основывающаяся на IP, истории пользователя в интернете и поведении пользователя на сайте. ReCaptcha V3 не может отделить однозначно человека от робота, а лишь показывает вероятность того кем является пользователь, причём с достаточно большой погрешностью.  Одна из особенностей ReCaptcaha V3 -  один и тот же браузер, работающий с одним и тем же набором cookie с одного и того же IP в один момент времени может получить совершенно разную оценку от ReCaptcha V3 для разных страниц одного сайта. А для разных сайтов почти всегда оценка будет разной. К сожалению, за эти 2 года мы так и не нашли способа достоверно оценить какой score получит тот или иной компьютер для определённого сайта. В последнее время мы использовали вероятностную модель "если ответ этого компьютера подошёл к пяти сайтам и не подошёл к шестому, то скорее всего к седьмому он всё же подойдёт", но теперь решили отказаться от неё, т.к. к некоторым сайтам она была совершенно неприменима. Но при этом, если ответ от конкретного компьютера подошёл к определённому сайту, то почти всегда ещё 5-50 его ответов по аналогичному заданию подойдут.

Что мы сделали:
Мы ввели AllowList и BlockList компьютеров работников для каждого нашего клиента. Изначально ваши капчи выдаются случайным компьютерам наших работников, а когда вы присылаете reportgood или reportbad, то мы вносим компьютер, который дал ответ на эту капчу  в соответсвующий лист. Как только наберётся 50 компьютеров онлайн в вашем AllowList то каждая вторая капча будет уходить компьютеру из этого листа, а когда в AllowList накопится 500 компьютеров онлайн, то все ваши задачи будут выдаваться только компьютерам из AllowList. При этом, если капча не разгадана мы возвращаем списанные за неё средства (так было всегда) и если вы прислали reportbad то мы возвращаем за неё средства (так было всегда, но с некоторыми ограничениями)

Что нужно сделать вам:
Если вы ещё не шлёте reportgood и reportbad уведомления - вы должны начать это делать. Без этого вы будете получать мало хороших токенов и не будете получать возврат за неработающие токены.

Система оплаты:
Списание: Как обычно, списание с баланса за капчу происходит каждый раз, при загрузке капчи. Списывается 0.16 рубля.
Возврат: Если токен не подошёл и вы прислали reportbad
Возврат: Если по какой-то причине мы не решили капчу и она получила статус ERROR_CAPTCHA_UNSOLVABLE

Это эффективно? Покажите кейсы!
У нас есть клиенты, которые шлют V3 с сайта, где V3 установлена некорректно и recaptcha даже половину реальных пользователей считает ботами. Лишь 4,5% наших компьютеров дают рабочие токены для этого сайта. Когда заказчик начинает слать капчи то сначала он получает лишь эти 4,5% корректных ответов. Примерно через 1500 присланных капч у него корректных ответов уже 40% и ещё через 10000 капч корректных ответов 70-80%.
При этом есть заказчики которые изначально получают 90% корректных токенов, через 100 капч - 95% корректных и через 1000 - 99% корректных токенов.

Я шлю задачи по V3 от двух сайтов, можно мне для них раздельные листы?
К сожалению, в текущей реализации у Вас может быть только один лист. Но вы можете завести ещё один аккаунт и перевести часть баланса на второй аккаунт. И задачи с разными сайтами слать с разных аккаунтов.

Почему бы не сделать Allow\Block-листы по каждому домену для всех заказчиков?
Тогда один заказчик по ошибке, начав добавлять всех работников в Allow или Block лист испортит работу остальным заказчикам.

При загрузке задачи ещё нужно указывать score?
Да. Задачи со score = 0.1-0.3 у нас обрабатываются по одному алгоритму, где мы можем дать гарантированный результат, а задачи со score = 0.4  и выше - по другому. Разницы между score = 0.4 и 0.9 у нас сейчас нет, а вот между 0.3 и 0.4 - есть. Поэтому продолжайте слать.

Почему данные хранятся лишь 2 дня?
Это обусловлено особенностью архитектуры хранения данных. Возможно мы перейдём на более подходящее хранилище данных и тогда сможем увеличить период хранения данных.

Что случится если я всех работников занесу в BlockList?
Пока никто не смог занести в него даже 10% работников. Если Вы туда занесёте всех, скорее всего на вашей стороне есть какая-то ошибка и вы на всё подряд шлёте reportbad.

У меня есть вопрос:
Если у вас есть ещё вопросы, их лучше всего задавать публично в этой ветке форума: https://captchaforum.com/threads/recaptcha-v3-obhod-avtomatizatsiya-beta.12/, либо пишите нам в  поддержку.

Обновление по рекапче на google.com

Обновление информации по поводу ReCaptcha на google.com

Данная статья является продолжением вчерашней статьи.

Две проблемы:
Сегодня мы заметили не самые лучше результаты по качеству решений рекапчи на google.com, есть две беды
1) Большой процент нераспознанных капч. К сожалению, если работник отказался от решения капчи или у из-за плохой прокси капча у него не прогрузилась полностью, то решена она уже не будет - мы не передадим её другому работнику, т.к. при повторной загрузке она даст 100% невалидный токен.
2) Низкий процент валидныйх токенов (40-60%)

Решение:
С первой проблемой мы пока ничего не можем поделать, но мы полностью возвращаем средства за неразгаданные капчи.
А вот со второй проблемой мы сегодня много воевали и пришли к некоторым выводам:
1) Прокси можно не слать,  но с ними процент корректных токенов выше
2) Куки нужно использовать, но не брать куки нашего работника, а присылать нам куки Вашего парсера, что бы работник решал капчу с ними.

Если слать прокси и куки, то процент валидных токенов поднимается до 100%!
Итак, что нужно дополнительно слать к тому, что было вчера:

1) cookies
 Присылайте капчу с параметром
"cookies" Cтрока. Двоеточие отделяет название куки от содержимого, точка с запятой - разделяет куки.
Пример:
cookies=ANID:AHWqTUkiE1lX;NID:204=SbYHJRGMb4wtUG2

2) Proxy
"proxy" Строка. Формат: логин:пароль@123.123.123.123:3128
"proxytype" Строка. Тип вашего прокси-сервера: HTTP, HTTPS, SOCKS4, SOCKS5.
Пример:
proxy=login:pass@123.123.123.123:3128
proxytype=HTTP

Важно отметить:
1) Как получить куки от google.com, если я взаимодействую с иным сайтом и парсер не заходил на google.com до момента получения капчи?
Допустим, вы парсите выдачу по домену www.google.sm и у вас нет кук от google.com. Просто перед тем как начать парсить, зайдите на https://google.com и сохраните полученные куки. В момент, когда получите капчу - пришлите нам эти куки.
2) Если у Вас не сработал токен или мы не решили капчу, то нельзя пытаться решить капчу на этой же странице. Вы должны вернуться в поиск и снова получить капчу из поиска. Попытки пройти капчу  на той же странице 100% не закончатся успехом, а IP-адреса будут заблокированы в google

Прямой эфир!
Кстати, вы можете следить за новостями по этой проблеме в "прямом эфире" на форуме:
https://captchaforum.com/threads/google-search-obnovlenie-ot-18-maya-2020.683/#post-1521

ReCaptcha на поиске google.com/sorry/index

UPD 29 мая 2020. Рекомендуем слать прокси и куки, подробнее в следующей статье.

Главное:
Решение капчи на поиске google.com работает, но вы должны отправлять дополнительный параметр - "data-s", взятый из переменной "data-s" на странице с капчей. Более подробно ниже.

Что случилось:
Начиная с 18 мая на странице //google.com/sorry/index рекапча стала не всегда приниматься с первого раза. Изначально проблема была не очень заметна и случаи непринятия токена списывались на случайность, но постепенно процент таких случаев рос и к субботе-воскресенью достиг практически 100% запросов.
К сожалению, по началу мы списали это на ошибки в работе самого google.com, т.к. даже при ручном прохождении через браузер он иногда повторно отдавал капчу и не стали особо разбираться с ситуацией (возможно в тот момент действительно были проблемы со стороны google, сейчас такой ситуации уже не происходит)
К 25 маю мы осознали всю глубину проблемы, когда остановились практически все сервисы парсинга позиций\сбора семантики и другие взаимодействующие с поиском на google.com.

Как теперь правильно слать капчу с google.com/sorry/index:
1. Вам нужно со страницы /google.com/sorry/index взять параметр, находящийся в переменной "data-s" и прислать его нам в параметре "data-s". Значение data-s каждый раз новое.
2. Вы ни в коем случае не должны отрабатывать JS подгружающие саму капчу на странице google.com/sorry/index. Если у вас прогрузится капча на странице, а потом Вы пришлёте нам данные от этой капчи, то токен полученный нами работать не будет. С одним data-s капча может быть загружена только один раз.

Что мы ещё знаем о новой капче:
1. Google реализовал недокументированный функционал. В документации к ReCaptcha V2 никакой data-s нет.
2. Data-s всегда уникальный и ReCaptcha контролирует что бы одна один data-s открывался только один раз. Поэтому если Вы открыли страницу с капчей и у вас она прогрузилась, то мы уже не сможем никаким образом дать рабочий токен для обхода капчи на этой странице. Вы должны брать HTML код страницы, брать оттуда значение data-s и присылать нам.
3. Помимо Data-s ReCaptcha реализовала ещё несколько хитрых приёмов - они контролируют целостность данных на странице с капчей. Анализ именно этого момента у нас отнял больше всего времени (т.к. нам пришлось по новой изобретать как выводить рекапчу работнику), но вам об этом не нужно беспокоиться, это всё делается с нашей стороны.
4. Proxy, UserAgent и Coockie пользователя не влияют на прохождение. Решаться рекапча может с IP из Филиппин, с UserAgentom Mozilla FireFox и куками работника, а токен Вы используете со своего IP, со своим UserAgent и своими куками.
Однако, если Вы пришлёте нам свою прокси и свой UserAgent мы будем их использовать. Как это сделать  - описано в API

Благодарности:
A-Parser. Подтолкнули нас в сторону правильного решения и помогли с тестированим. Кстати, по нашему мнению A-Parser является самым мощным парсером поисковых систем и всего остального что нужно для SEO, а в последние годы A-Parser научился парсить что угодно, вы можете даже спарсить даже Amazon, ведь у A-Parser есть серверная версия, которая действительно поддерживает неограниченное количество потоков (ограничено лишь производительностью вашего сервера), а результаты парсинга может складывать сразу в SQL-базу.
Топвизор. За то, что заставили нас поверить в наличие проблемы. Кстати, именно через Топвизор мы следим за позициями нашего сайта в поиске.

UPD
UPD: Что-то не очень хорошие результаты у нас получаются. Продолжаем исследование. Если хотите следить за последними изменениями, то заходите на эту тему: https://captchaforum.com/threads/google-search-obnovlenie-ot-18-maya-2020.683/

Обход hCaptcha с RuCaptcha API

Недавно Cloudflare добавили поддержку hCaptcha на странице проверки ботов и это вызвало заметный рост интереса к hCaptcha. Хотим немного рассказать об этой капче, а также напомнить, что ее можно решать с помощью нашего API.