Мобильный трафик уже давно закрепился в арбитраже, фарминге аккаунтов, веб-парсинге и PWA-продвижении как самый лакомый кусок пирога. Причина до банального проста — разница в доверии антифрод-систем к десктопным и мобильным пользователям.

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

Привет! Я Александр, пишу для антидетект-браузера Aurorium и по совместительству являюсь специалистом в вопросах автоматизации и парсинга. В этом материале мы рассмотрим разницу между мобильными профилями, которые предлагают большинство антидетект-браузеров и профилями на базе ARM? По традиции сварите чашечку кофе или заварите чай, соорудите пару бутербродов — мы начинаем!

Так исторически сложилось, что защитные алгоритмы площадок чаще триггерятся при проверках десктопных пользователей, потому что могут. Могут проверить с пристрастием графические отпечатки (Canvas-фингерпринт), покопаться в сетевых заголовках и покрутить носом при виде серверных IP-адресов (кто-то до сих пор использует серверные прокси для серьезных задач?). 

Мобильный трафик на контрасте дает более высокий траст благодаря трем факторам:

• Защита IP через CGNAT

• Доступ к In-App конверсиям

• Специфика мобильного следа

CGNAT (Carrier-Grade NAT или NAT операторского класса) — это технология, которая позволяет мобильным операторам подключать множество устройств к интернету через один общий публичный IP-адрес, экономя IPv4-адреса. Без этой технологии мобильный интернет для телефонов и планшетов просто не смог бы работать из-за нехватки свободных IP-адресов. 

Запустить же массовый мультиаккаунтинг под мобильный трафик с обычного ноутбука или сервера сложнее, чем под десктопный. Но прежде чем понять почему, давайте разберем три варианта, при помощи которых возможно этот самый мультиаккаунтинг реализовать (не берем в расчет нишевые схемы, а ориентируемся на массовый спрос):

• Мобильные профили в антидетект-браузерах — создание мобильных профилей, работающих исключительно внутри мобильных браузеров (Safari или Chrome), подходят для работы с веб-сайтами.

• Мобильные эмуляторы — создание виртуальной ОС Android на базе процессора ПК для запуска мобильных приложений.

• Облачные ARM-смартфоны — работа с нативной операционной системой на удаленном ARM-железе (доступна для Android).

ARM-система (облачный смартфон на ARM-железе) — это инфраструктурное решение, использующее реальные мобильные процессоры архитектуры ARM на удаленных серверах. Она запускает полноценную мобильную операционную систему в облаке, предоставляя каждому аккаунту уникальное окружение. 

Каждый из этих подходов работает на своем уровне системы и подходит под конкретные задачи. Причем использовать, к примеру, облачный телефон для фарминга ФБ-профиля технически можно, но по факту такое решение избыточно и приведет к перерасходу бюджета. А вот организовать полноценную работу с Instagram с мобильного профиля уже не получится по техническим причинам (мобильное приложение просто невозможно будет открыть через этот профиль, у вас получится лишь запустить браузерную версию сайта). В общем, вопросов много, давайте разбираться. 

Что такое мобильные профили, эмуляторы и облачные ARM-смартфоны?

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

Профили на базе антика под мобильный браузер

Мобильный профиль в антидетект-браузере — это конфигурация десктопного браузера (как правило на базе Chromium), настроенная таким образом, чтобы сайты принимали ее за мобильное устройство. 

Как уже написали выше — это не полноценная эмуляция мобильного устройства, а мимикрия десктопного браузера под мобильный (вы, кстати, увидите это, когда откроете его, он будет похож на экран смартфона).

Если заглянуть под капот, то при создании такого профиля браузер отдает серверу мобильные идентификаторы, в частности:

• User-Agent: Строка, имитирующая браузер мобильного устройства (Mobile Safari или Chrome под Android).

• Client Hints (Sec-CH-UA): Заголовки, указывающие на использование мобильной платформы.

• События Viewport и Touch Events: Эмуляция разрешения экрана смартфона, плотности пикселей и сенсорных событий касания вместо кликов мыши.

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

Мы уже опубликовали статью про то, что такое отпечатки браузера и как они работают, можете ознакомиться с ней в нашем блоге.

То есть, когда сайт попросит ваш «мобильный браузер» пройти простую проверку и отрисовать Canvas и WebGL фингерпринты, они будут отрисованы железом устройства, на котором запущен клиент антидетект-браузера. Естественно отпечаток, полученный от десктопной видеокарты, вроде Nvidia или AMD, будет отличаться от того, что выдают  мобильные чипы. 

Таким образом, если ничего не предпринимать, базово мы получаем такую картину — заявлен iPhone 15 Pro, а имеем отпечаток сильно напоминающий Nvidia RTX 4060 (которую даже в мыслях сложно совместить с Айфоном). И подобных нюансов достаточно, чтобы убить «мобильный браузер» на старте.

Антидетект-браузер решает этот вопрос путем внедрения подмены на уровне кода Chromium: он подменяет названия видеокарты, добавляет уникальный микро-«шум» в результат рендеринга, что позволяет проходить проверки. 

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

Главное ограничение: Мобильный профиль работает только внутри браузера. Запустить через него мобильное приложение (.apk или .ipa) физически невозможно.

Мобильные эмуляторы — виртуальный Android на процессорах x86

Популярные среди мобильных геймеров программы обладают интересным побочным эффектом, оказывается, на эмуляторах можно не только играть в условные Clash of Clans или Free Fire, но и заниматься вопросами автоматизации и мультиаккаунтинга (такое вот неожиданное применение лекарства от сердечно-сосудистых болезней, если вы понимаете, о чем я). Или нельзя? 

Мобильный эмулятор (яркие представители — это BlueStacks, NoxPlayer, LDPlayer, Android Studio AVD) — это программа, создающая полноценную виртуальную машину с операционной системой Android внутри Windows или Linux.

Эмулятор работает по следующему принципу: он подгружает образ Android и позволяет устанавливать любые APK-файлы из Google Play или сторонних источников. В отличие от мобильного профиля в антидетект-браузере, здесь вы получаете доступ к In-App экосистеме и работаете уже внутри самих приложений, а не в браузере. 

Проблема, которую нужно было решить разработчикам эмуляторов, заключалась в том, что подавляющее большинство ПК работают на процессорах архитектуры x86_64 (Intel, AMD), в то время как смартфонам необходима архитектура ARM (ARM64 / aarch64). В качестве решения используют трансляторы инструкций (Intel Houdini или Google libndk_translation).

Трансляторы инструкций — это программы длябинарной трансляции «на лету». Они переводят код ARM-процессоров в команды для архитектуры x86. Это нужно, чтобы запускать мобильные приложения для Android с ARM-кодом на компьютерах или планшетах с процессорами Intel и AMD.

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

1. Бинарные трансляторы ARM → x86: Эмулятор не является инструментом автоматизации, и ему нечего скрывать, поэтому наличие системных библиотек libhoudini.so или libndk_translation.so указывает на то, что запущен эмулятор.

2. Системные свойства (build.prop): Приложения умеют считывать параметры системы и находят дефолтные строки виртуальных машин: ro.kernel.qemu=1, ro.product.model=sdk_gphone, упоминания драйверов, отсутствующие IMEI и данные SIM-карты. Все это никак не маскируется и доступно даже с минимальными усилиями.

3. Виртуальный графический стек (GPU): Вместо реальных мобильных видеочипов приложение видит программные рендереры вроде SwiftShader, Bluestacks Graphics Engine или OpenGL ES over Direct3D.

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

5. Аппаратная аттестация (Play Integrity API): Google умеет запрашивать проверку целостности устройства через криптографический чип TEE (Trusted Execution Environment). Эмулятор не может пройти проверку MEETS_DEVICE_INTEGRITY, так как у него просто нет аппаратных ключей, сертифицированных Google.

Криптографический чип TEE — это изолированная и защищенная область на аппаратном уровне внутри основного процессора устройства. Она гарантирует конфиденциальность и целостность данных даже в том случае, если основная операционная система заражена вирусом или взломана.

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

Самое опасное для мультиаккаунтинга — когда антифрод видит эмулятор, но визуально дает вам работать.

Обнаружение эмулятора выливается в четыре практические проблемы:

1. Теневые баны (аккаунт не получает охваты и любые действия бесполезны).

2. Отложенные сносы на этапе списания средств (потеря аккаунтов после внесения денежных средств на счет).

3. Бесполезный слив бюджета на расходники (бессмысленные траты на прокси и аренду сервера).

4. Бесконечные проверки (циклические капчи).

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

• Нулевая стоимость: Аренда облачного ARM-смартфона (о котором мы еще поговорим далее) обходится в среднем в $5–$15 в месяц за один телефон. Сетка из 100 облачных аккаунтов — это $500–$1500 в месяц. Эмулятор работает на вашем устройстве бесплатно (на сэкономленные средства можно арендовать сервер и расходники).

• Глубокий доступ к системе и гибкая автоматизация: Эмулятор, в отличие от облачных телефонов или тем более мобильных профилей открывает на самом деле широкие возможности, если накатить на него Root-права. Правда, рядовой пользователь (не технарь) вряд ли сможет реализовать подобное, технически процесс входа сложнее.

Вот как примерно выглядит работа с эмулятором, уверенного в себе специалиста:

Согласитесь, слегка сложновато?

Ну и нельзя не напомнить про прожорливость эмуляторов. Они сильно нагружают железо и запустить на одном, даже мощном устройстве 5 виртуалок (а логика такая одна виртуалка — один профиль) будет серьезным испытанием для железа. И это мы еще не углубились в вопросы связывания аккаунтов по отпечаткам устройства, так что вопросов больше, чем ответов.

Эмулятор — это инструмент для тех, кто имеет глубокие технические знания и готов тратить свое время в угоду экономии.

Облачные ARM-смартфоны — Дейенерис Таргариен во Вселенной Мультиаккаунтинга

Вот мы и подошли к наиболее предпочтительному (и технически совершенному) варианту работы с несколькими аккаунтами под мобильный трафик — облачные ARM-смартфоны. 

Параллель с Дейенерис тут проведена не случайно, ведь как у матери драконов в жилах течет настоящая валирийская кровь, так и в основе облачных смартфонов лежат подлинные мобильные процессоры. Они являются мобильными устройствами по праву своего рождения. 

ARM-устройства — это относительно новое, но быстро набирающее популярность направление в мультиаккаунтинге. По сути, это удалённая аренда мобильного устройства. 

Где-то в дата-центрах стоят серверные стойки с ARM-платами, на которых запущены изолированные экземпляры Android. Пользователь подключается к этому устройству со своего ПК или ноутбука и видит интерфейс обычного телефона.

Но отличий от реального устройства нет не только снаружи, но и внутри. Следам виртуализации здесь попросту неоткуда взяться. Повторимся — вы работаете с реальным устройством.

Есть еще один вариант — ферма из реальных смартфонов (когда вы берете несколько реальных устройств с реальными SIM-картами).

Но очевидно, что такую ферму сложнее масштабировать, она на старте обойдется дороже, хотя, если посчитать, сколько денег будет уходить на обслуживание каждой SIM-карты, в долгосрочной перспективе шансов выйти в ноль по сравнению с облачным решением тоже немного.

У облачных сервисов тарификация поминутная (либо доступны пакеты минут), что выгоднее ежемесячной SIM-карты, если вам нужно заходить на аккаунты на 10 минут в день, вы платите только за фактическое время работы.

Ну и юзабилити — ваша облачная ферма по сравнению с фермой реальных смартфонов в более выигрышном положении, особенно если использовать синхронизаторы. Запускаете 10 облачных телефонов, включаете синхронизатор и он дублирует все ваши действия, которые вы выполняете на главном профиле. Можно так сделать на мобильной ферме? Отвечать не обязательно.

Кому нужны облачные телефоны? Далеко копать не нужно, открываем любой мануал по работе с тем же TikTok и видим, что он подразумевает работу именно с мобильными устройствами.

Естественно, будут и минусы, не может все быть так гладко.

Самый главный минус, который отталкивает пользователей от облачной ARM-инфраструктуры в пользу мобильных профилей в антидетект-браузерах — цена. Да, себестоимость ARM-устройства выше, чем мобильного профиля.

Давайте посчитаем: если для работы с Facebook вам, к примеру, нужно 500 профилей, антидетект-браузер обойдётся в $150–$200/мес. А 500 облачных телефонов даже по минимальной ставке потянут на несколько тысяч долларов (учтите важную особенность, за возможность запуска нескольких устройств одновременно придется платить больше).

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

Для наглядности собрали в единую таблицу, что видит антифрод при въедливой проверке:

Работа с iOS — хорошая мина при плохой игре или наоборот?

С Android все понятно — это простая и понятная система, по сравнению с iOS. Давайте на примере видеоигр сравним три подхода (десктопный, мобильный под Android и мобильный под iOS).

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

• десктопная эмуляция — уверенный новичок

• мобильная эмуляция под Android — продвинутый уровень

• мобильная эмуляция под iOS — хардкор

И даже несмотря на статус наиболее сложного способа в мультиаккаунтинге,  запрос на эмуляцию iOS — остается одним из самых востребованных в этой нише. Почему? Ответ лежит на поверхности — деньги и живучесть аккаунтов. 

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

Для антифрод-систем iOS тоже не просто слова, а своего рода «+ балл к карме» пользователя. Аккаунты на iOS получают повышенный траст на старте, проще вяжут платежные карты и реже попадают на ручные проверки, капчи, теневые баны чем аккаунты на Android.

При всем уважении к владельцам Android (у меня самого Samsung), в этой нише мяч на стороне iOS.

Но чем более лакомый кусок, тем сложнее его заполучить.

Почему эмуляторов iOS для Windows не существует?

Как думаете, какие запросы, связанные с iOS в топе поисковой выдачи? Все что связано с эмуляцией на ПК.

Но к разочарованию ищущих — полноценных эмуляторов iOS для Windows не существует.

Операционная система iOS привязана к защищенной аппаратной архитектуре Apple. Код iOS закрыт, к тому же Apple запрещает использование своей ОС на стороннем оборудовании. Все программы для Windows, называющие себя «эмуляторами iPhone» (iPadian и аналоги), являются обычными визуальными оболочками, и даже не пытаются сыграть в игру, под названием эмуляция. Мало того, что они не в состоянии запустить ни один файл формата .ipa, открыть мобильное приложение под iOS тоже не удастся.

Собственно даже о робких попытках в направлении мультиаккаунтинга на iOS с помощью десктопа не может идти и речи, сразу переходим дальше. 

Мобильные iOS-профили в антидетектах: возможности и лимиты

Если полноценно запустить iOS на компьютере невозможно, как же организуется работа с трафиком под iPhone? 

Самый доступный и наиболее распространенный путь — мобильные iOS-профили в антидетект-браузерах. Но есть нюансы и для некоторых ниш эти нюансы могут быть критичными.

Вот как работает мобильный профиль на iOS.  Пользователь создает в антике профиль с пресетом Safari на iOS. Антидетект берет свой десктопный браузер и начинает мимикрировать под мобильное устройство Apple:

• Модифицирует User-Agent под iOS (Mozilla/5.0 (iPhone; CPU iPhone OS 18_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.5 Mobile/15E148 Safari/604.1).

• Эмулирует разрешение экрана iPhone и плотность пикселей.

• Переписывает переменные вроде navigator.vendor на "Apple Computer, Inc." и выключает десктопные методы.

Окно браузера становится узким, верстка на требуемом ресурсе сменяется на мобильную, и создается ощущение, что вы действительно зашли с iPhone.

Нужно учесть такой момент — весь мобильный веб на iPhone по требованию Apple обязан работать исключительно на движке WebKit (и JS-движке JavaScriptCore). Важно понимать, с каким именно движком работает конкретный антидетект-браузер. Если это Chromium (а большинство антиков работают именно с ним), и дальнейшая мимикрия под мобильный браузер iOS строится на нем, вот что мы получим:

Визуально все будет выглядеть прилично и практически неотличимо от оригинала, но внутри будет работать Chromium, и нормальный антифрод сможет распознать это:

1. Рендеринг Canvas и шрифтов: Наиболее очевидный способ проверки, так как алгоритмы сглаживания текста, субпиксельный рендеринг и обработка графических инструкций в WebKit и Chromium отличаются. Антифрод это знает и в состоянии распознать

2. Форматирование ошибок JS (Error.stack): Если направить скрипту заведомо ошибочный код, движок V8 (Chromium) и JavaScriptCore (WebKit) выдадут текст и структуру стека ошибок по-разному. Chromium не умеет форматировать ошибки так, как это делает Safari.

3. Поддержка специфичных API: У WebKit есть уникальные функции и свойства, которых нет в Chromium либо они работают по другой логике.

И это мы еще не говорим о других проблемах мобильных и десктопных сборок (о них мы говорили выше, в разделе про мобильные профили на Android).

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

Когда антидетект-браузер умеет работать с WebKit (как именно это делается вопрос другой) ситуация несколько меняется. Проблема с рендерингом Canvas и шрифтов, как и обработкой ошибок становится неактуальной, но никуда не девается разница в сборках.

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

Xcode Simulator vs Облачные iPhone: решения для работы с нативными приложениями

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

• Xcode Simulator (официальный инструмент от Apple для разработчиков)

• Облачные смартфоны 

Xcode Simulator — это специальная программа от Apple. Она запускает виртуальные версии iPhone, iPad, Mac, Apple Watch и Apple TV на экране Mac. Нужна она для того, чтобы проверять работу приложений без покупки реальных гаджетов.

Запущенный на Macbook симулятор действительно выглядит как iPhone. Но для целей мультиаккаунтинга он не подойдет, и вот почему:

Симулятор позволяет запустить только те приложения, чей исходный код у вас есть (напоминаем, он создан для разработчиков, которым требуется протестировать приложения), то есть это своего рода песочница, а не полноценный эмулятор. Разбирать его архитектуру дальше не имеет никакого смысла.

Реально работающий вариант в случае с iPhone — облачный телефон, схема работы примерно такая же, как мы описывали выше про Android, но исполнение отличается. Облачные фермы — это реальные устройства на стенде, а не серверные стойки с ARM-платами.

К сожалению, для iOS это единственный рабочий способ запустить приложение в автоматизированном режиме и масштабировать это на несколько профилей.

Главные сложности и «боли» работы с облачными iPhone:

1. Космическая цена: Аренда облачного iPhone — еще более дорогой инструмент на рынке, даже по сравнению с Android. Из-за стоимости оборудования Apple и сложности его обслуживания цена за один телефон колеблется от $20 до $50+ в месяц (или же продается по более высокой поминутной ставке).

2. Сложность автоматизации: В отличие от Android, автоматизация действий (клики, свипы, ввод текста) на iOS реализуется через тестовые фреймворки Apple (XCUITest / WebDriverAgent). А это требует от специалиста более глубоких навыков написания скриптов.

3. Дефицит инфраструктуры: Облачных ферм на базе iOS в разы меньше, чем на Android, мы буквально на сегодняшний момент знаем только о двух сервисах, предлагающих удаленный доступ к айфонам из своей фермы.

Получается, что и в этом вопросе iPhone отличается от Android большей дороговизной и эксклюзивностью. Но есть ощущение, что это уже не плюс, а минус.

Ниже собрали в таблицу все отличия методов и их узкие места.

Заключение

В работе с мобильными профилями не может быть универсальной «серебряной пули» — выбор всегда будет упираться в ваш бюджет, тип трафика и ROI.

Чтобы не переплачивать за красивую галочку (использование iPhone), руководствуйтесь простыми правилами:

• Мобильные профили в антидетект-браузере — подойдут для 80% задач (арбитраж Facebook/Google/Яндекс, фарминг браузерных аккаунтов, крипто-дропы через браузер, E-commerce). Это самый быстрый, легко масштабируемый и относительно дешевый способ получить высокий траст, не выходя за пределы браузера, но находясь де-юре в мобильном сегменте.

• Облачные ARM-смартфоны — используются там, где критически важно именно присутствие внутри мобильного приложения (TikTok App, мобильный фарминг, игры, бонус-хантинг).

• Облачные iPhone (iOS) — используются только под самый дорогой трафик, эксклюзивные iOS-приложения и VIP-офферы. Оправдан в нишах, где высокий чек и окупаемость перекрывают цену аренды и сложную автоматизацию.

Не пытайтесь использовать заведомо избыточные и дорогостоящие решения там, где они не нужны.