Аренда WhatsApp API у неофициального провайдера
Далекий 2017 год. Мы делаем сервис онлайн-записи SLONBOOK для салонов красоты. Историю создания сервиса я подробно описал в этой статье. Фишкой нашего сервиса, которая выгодно отличала нас от конкурентов, была тесная интеграция с WhatsApp. Это позволяло с одной стороны существенно экономить на SMS, а с другой было генератором повторных продаж для салона. Эти два момента делали SLONBOOK привлекательным по сравнению с конкурентами. Начали экспериментировать с WhatsApp.
Вначале у нас не было своей реализации и поэтому мы арендовали шлюз WhatsApp API у стороннего сервиса. У нас пошли первые продажи, и первые проблемы. Оказалось, что при использовании неофициального канала есть риск словить бан и потерять номер. Для салона красоты потерять номер WhatsApp, это все равно что для Интернет-магазина потерять сайт (домен). Клиенты салона общаются с администратором в основном по WhatsApp, при этом мало кто звонит или приходит без предварительной записи. Вначале всегда будет чат с администратором по WhatsApp. И вот этот номер банят. Естественным образом салон выставлял претензию на наш сервис: "- мол, подключились к вашему сервису и потеряли номер." Пошел негатив. Начали разбираться в проблеме. Пытались достучаться до нашего неофициального провайдера. Безуспешно.
Официального WhatsApp Business API в 2017 году еще не существовало, но нам нужна была интеграция. Это было нашим ключевым преимуществом и было новшеством для рынка, особенно в нашей нише.
Реализация собственного WhatsApp API через веб-обертку
Начали искать решение на своем уровне. Была поставлена задача не допустить бана номера клиента. Второстепенные задачи снизить себестоимость WhatsApp API и повысить стабильность работы.
На Github нашли исходники либы, которая реализовывала WhatsApp API через парсинг веб-версии клиента воцап. Затратили порядка 4 месяцев и выпустили на базе этого решения свою реализацию с минимальным набором функций для нашей CRM.
Начали подключать клиентов, и снова начались баны несмотря на то, что мы предпринимали целый ряд мер. Для каждого номера был отдельный IP-адрес, сообщения отправляли с рамдомными задержками, не более двух сообщений в минуту, персональное обращение по имени. Всё тщетно. Баны продолжались. Шел негатив. Продажи встали. Надо было найти кардинальное решение.
Взлом WhatsApp на уровне сокет-соединения
Решение было найдено. Один из нас как-то предложил взломать протокол и работать с сервером WhatsApp напрямую через socket, как это делает нативный веб-клиент. Задача на первый взгляд нам показалась фантастической и невыполнимой. Но нет ничего невозможного! Была поставлена задача взломать зашифрованный протокол WhatsApp. Цель отловить сигналы о скорой блокировке номера. Задачу эту мы успешно решили. Однако потребовалось нам на это 2+ года.
Следует отметить, что прежде чем изобретать свой велосипед мы порылись на Github. Нашли там либу, которая реализовывала взаимодействие с сервером воцап именно по сокету. Однако наш номер словил бан раньше, чем мы успели отправить первое сообщение.
По этой причине мы решили делать свой велосипед. Когда работаешь с воцап на уровне протокола, то надо быть очень аккуратным. Если упустить какую-либо мелочь, то можно быстро спалиться. Пришлось долго и кропотливо изучать трафик, анализировать, сегментировать. Далее пришлось также долго имитировать работу клиента таким образом, чтобы сервер воцап думал, что он работает со своим нативным веб-клиентом.
Протокол WhatsApp версионируется. Каждая версия имеет отличия от предыдущей. При выходе новой версии мы запускам автоматические проверки, которые выдают нам изменения протокола, и мы оперативно их отражаем в своей имплементации.
Надо сказать, что протокол WhatsApp надежно защищен от подобно рода взломов. После взлома протокола на уровне шифровальщика требуется дополнительно полностью повторить работу нативного веб-клиента. WhatsApp защитил свой протокол на двух уровнях: на уровне шифра, и на уровне контента. На втором уровне защиты, на уровне контента, очень много особенностей. Важно полностью повторить контент, который выдает нативный клиент. И тут разработчики воцап заложили немало пасхалочек. Например, нативный веб-клиент рамдомно в течение суток вычисляет хеш-сумму всех отправленных сообщений и отправляет хеш на сервер. На сервере, по-видимому, выполняется сверка. Если хеш не отправить, или если ошибиться со значением хеша, то бан гарантирован. И таких ловушек в протоколе накидано на каждом шагу. Вот поэтому нам и потребовалось 2+ года, чтобы добиться устойчивой работы на уровне протокола сначала взломать уровень шифровальщика, далее полностью повторить уровень контента до мельчайших деталей.
Здесь следует отметить, что существует два канала работы с воцап на уровне протокола: канал веб-клиента и канал мобильного приложения воцап.
Канал веб-клиента используется для связи веб-клиента с мобильным приложением через сервер WhatsApp. Канал мобильного приложения работает с сервером WhatsApp напрямую. В этой статье я подразумеваю взлом именно канала веб-клиента, в то время как взлом канала мобильного клиента на порядок более сложная задача. По этой причине наша имплементация WhatsApp API требует наличия телефонной трубки, на которой установлено мобильное приложение воцап. Без физического телефона наш API работать не будет.
Жёлтая карточка
При работе с сервером воцап на уровне протокола у нас появилась возможность отлавливать сигналы приближающегося бана номера. Мы умеем отлавливать предупреждения о скором бане и тем самым уберегаем номер клиента. Если раньше WhatsApp мог забанить номер одномоментно, внезапно и без предупреждения, то сейчас мы считываем из трафика управляющие сигналы и заранее приостанавливаем активность номера, чтобы сохранить его. Спустя 12 часов мы снова активируем номер. Раньше WhatsApp выдавал нам сразу Красную карточку без предупреждения. Сейчас мы научились получать из протокола Жёлтую карточку. Можно, конечно, игнорировать первую, вторую и третью Жёлтые карточки, однако на кону номер и бизнес клиента.
Благодаря такому подходу нам удалось добиться того, что номера наших клиентов перестали попадать в бан вовсе. Время показало, что на протяжении более 12 мес наши клиенты не потеряли ни одного номера. Разумеется, речь идет не о спамерах, а о нормальной работе пользователя в режиме онлайн-записи в салон красоты. Если очень хочется потерять номер, то достаточно отправить 1000+ сообщений и игнорировать предупреждения нашего шлюза.
На защиту номера от бана влияет множество факторов. Возраст номера, соотношение количества отправленных и полученных сообщений в сутки, количество отправленных жалоб на ваш номер, контент сообщений. Чем дольше номер зарегистрирован в воцап, чем активнее клиенты общаются с вами, тем лучше защищен номер от блокировки и тем большее количество сообщений в сутки номер может отправить. На официальном сайте Facebook опубликована таблица, которая наглядно показывает, как возрастает пропускная способность канала в зависимости от показателя качества номера. Примерно такие же правила мы реализовали на уровне нашего API.
Бонусы
Работа на уровне протокола имеет свои преимущества по сравнению с работой на уровне веб-обертки. Нам удалось решить вопросы безопасности, скорости, стабильности и функциональности.
Безопасность на первом месте. Важно защитить номер от бана. Об этом выше.
Скорость. Например, для чат-ботов актуальным является вопрос скорости ответа клиенту. При общении человека с ботом важно не терять фокус внимания. Если бот будет отвечать с задержкой более 5 секунд, то фокус внимания переключиться, работа с ботом прекратится. Если чат-бот ведет одновременно 10 диалогов, то скорость обработки сообщений должна быть порядка 10 сообщений в секунду.
Стабильность. Протокол WhatsApp версионируется. Это означает, что мы заранее узнаем о новых версиях протокола и своевременно адаптируем наше API под новую версию протокола.
Функциональность. На уровне протокола имеется возможность поддержать любую функцию, которая есть в WhatsApp. Поэтому потенциальные возможности API безграничны.
Рождение Сверхзелёной
Итак, решение своих задач внутри нашей CRM позволило нам создать очень качественное WhatsApp API. Во главу угла была поставлена задача защиты номера от бана. И эту задачу мы решили. Заодно решили целый ряд вспомогательных технических задач. Держать такую птичку взаперти было бы преступлением, и в начале 2020 года мы опубликовали наш проект GREEN-API.
Что дальше?
Особенностью всех существующих реализаций взлома WhatsApp является обязательное наличие телефонного аппарата. Воцап устроен таким образом, что вся переписка хранится в телефоне и всё взаимодействие выполняется через телефонный аппарат. Поэтому любая имплементация неофициального WhatsApp API требует обязательного наличия телефонного аппарата. Это в свою очередь имеет свои неудобства приходится приобретать телефон и дополнительно следить, чтобы он был всегда заряжен, подключен к Интернет. Если телефон, например, уснет, то отправка и получение сообщений прекратится. Нужен сотрудник, который будет следить за работоспособностью трубки. Это очень неудобно.
По этой причине мы параллельно разработали WhatsApp API, который работает без трубки. Мы пошли по пути использования эмулятора Android и добились того, что воцап думает, что работает с обычным телефоном. По сути это иная имплементация задачи взлома воцап на уровне реверс-инжиниринга Android-приложения. Но об этом уже в следующий раз.
