1. Введение
1.1 О чём статья?
Всем снова, здрасте. Я думаю, каждый разработчик хоть раз сталкивался с ситуацией, когда запросы, собранные с браузера через DevTools, не пробивались никаким образом, просто невозможно автоматизировать этот запрос в силу сильной защиты. Это может быть связано с чем угодно, факторов целое множество, начиная от банальной сверки User-Agent, до чего-то покрупней, как защита у Cloudflare. В таких случаях мобильное API приложения становится самым настоящим спасением. С моей точки зрения, при работе с бигтехами, которые чуть ли не монополисты в своей сфере/стране, стоит начинать всегда с их приложения, а не с сайта, ибо мобильное API всегда будет в тысячи раз легче.
1.2 Почему мобильное API легче?
Это объясняется как минимум чуть ли не абсолютно разной архитектурой. Запросы в браузере зачастую зависят от кучи динамических параметров, которые сложно автоматизировать, так как они зависят от контекста. Примером может быть какой-нибудь кусочек на JavaScript, который генерирует CSRF-токены, nonce или еще что похуже, и не стоит забывать, что язык этот обфусцируется на раз два, что еще делает нам проблем. В то время как у мобильных приложений структура запросов более простая - это самые обыкновенные прямые запросы, которые не зависят от JS-а. Связано это с тем, что разработчики контролируют практически полностью ваше устройство, знают они примерно всё про ваш в техническом плане, а если тыкнуть еще и на всякие разрешения, то будут знать всё и про вас (на днях была уязвимость в IOS, которая позволяла файлики ваши красть из облака, даже без ваших согласий, просто в фоне).
Так же в браузере в разы легче анализировать поведение человека: скорость ввода, клики, движение мыши. На телефоне сделать это крайне затруднительно, ибо я думаю, все знают про популярную проблему на сайтах при присутствии на них hover'ов, они отвечают за то, чтоб кнопочка загоралась когда на неё наводились курсором, а с мобильного, так оно работать не будет.
В то время как в мобильных приложениях такие проверки происходят крайне редко. Не могу сказать точно, с чем это связано, но предположу, что разработчики просто больше доверяют пользователям с телефонов, нежели с браузеров, ибо среда разработки при мобильных приложениях более контролируемая.
1.3 Devtools - панацея?
Думаю, каждый хоть раз сталкивался с ним, даже не в рамках запросов, а просто. Devtools - замечательный и мощный инструмент, буквально развязывает руки при работе с браузером, он универсален, с этим поспорить нельзя. Даёт доступ и к запросам, к работе с консолью, и куче другого. Но, есть одно "но", его нет как такого в мобильных приложениях, с этим ничего не поделать. По этому нельзя говорить, что Devtools - является панацеей. И что делать? Как тогда собирать запросы с мобильных приложений, если они нам так нужны?
1.4 ADB или MiTM? С чём его есть в рамках сниффа траффика?
И так, Devtools у нас не работает с мобильными приложениями. Здесь есть всего лишь два подхода, с моей точки зрения, а именно, подключать по ADB или же проводить MiTM-атаку над самим собой же. ADB (Android Debug Bridge) — это крайне мощный инструмент для работы с Android-ами. С его помощью мы можем подключаться к устройству, перехватывать трафик, управлять приложениями и множество других возможностей. Для работы с ADB нужно, чтобы устройство было подключено к компьютеру по проводу или же просто подключить и ПК и телефон к одной сети. Достаточно легок он в использовании, тому кто хоть раз кликался и разбирался в этом, там нет кучи команд и т.д., не придется убиваться. Выглядит это все дело в простом исполнении как терминал с командами.
Но есть и свои минусы: нужно физически подключать устройство и настраивать сертификаты, потому что иначе это бессмыслица, ведь все нормальные проекты используют HTTPS, ну и конечно, ADB не будет работать с IOS-устройствами.
MiTM (Man-in-the-Middle) — это метод перехвата трафика между устройством и сервером. По сути, это атака, которую в реалиях используют, чтоб воровать кукисы, пароли и всё что угодно, думаю каждый хоть раз видел сообщение на форуме о продаже фишлетов, так вот, они все зачастую работают на основе MITM, но нам не нужны ни чьи пароли, нам нужно достать запросы, мы будем должны проводить атаку над самим собой, локально. Суть заключается в том, чтобы подменить сертификат сервера на свой собственный, что позволяет легко перехватывать нужные нам запросы. Без сторонних инструментов организовать MiTM над самим же собой, гораздо легче, нежели париться с ADB. В Burp'e можно настроить proxy-сервер, после чего уже в нашем мобильнике, выставить прокси, настроить сертификат, и лететь в бой.
1.5 HTTP Toolkit - панацея в сниффинге с мобильных устройств.
Все эти методы, как ADB-подключение и MiTM-атака, действительно круты, но их воспроизведение забвенными путями — это самый настоящий кошмар. Зачем нам усложнять всё и лишний раз ковыряться в настройках, когда уже существуют решения, которые автоматизируют всё это самостоятельно? Именно здесь на сцену выходит наша панацея, HTTP Toolkit.
Это наше спасение, который делает весь процесс перехвата запросов в мобильных приложениях до нажатия пару кнопок в самом приложении. Он сам всё настраивает: подключается к телефону через ADB, настраивает локальный MiTM для перехвата трафика и даже ставит сертификаты, чтобы можно было перехватывать HTTPS-трафик.
Мы рассмотрим с вами по итогу два варианта, снифф с Android-устройств, и как делается это на IOS-устройствах, разбирать целиком на IOS мы не будем, ибо это всё сведется к повторению того, что было, и не будет нести смысла. За подопытную крыску возьмем немецкий сервис ebay-kleinzaigen, у которого невыносимо сильная защита и фрод (я не преувеличиваю, у меня банально даже не получается зарегистрировать аккаунт руками). Я не думаю по итогу, что у меня получится написать проверку на то, зарегистрирована ли почта в сервисе или нет, требуется это "брутерам", которые гоняют почты, проверяют на регистрацию, а после продают аккаунты, а цена за 1 аккаунт, достаточно неплоха, иль мне так кажется лишь.
2. Снифф в самой красе
2.1 Какие запросы в Devtools? Какая защита там у нашего сервиса?
Проверка на то зарегистрирована ли почта в сервисе достаточно обыкновенная, нам стоит просто попробовать залогиниться, и он нам скажет, что не так, исходов куча, но нас интересует вариант, когда почта зарегистрирована. Вот так выглядит грустное письмо, а представьте брутеров с гигабитными текстовиками mail
ass, которые все надо проверить и крайне быстро.
Открывая Devtools, я сразу же вижу кошмар под названием "datadome", который точно уж никого из ботов не пропустит)
Сбор абсолютного всего, всё что можно, и всё что нельзя уже собрали, cервис мощный, крайне мощный. Цена за его решение стоит от 160 рублей за 1000 штук, кажется не дорого, а если у нас огромные объемы, то уже становится более напряжней, ведь тогда мы играем в некую русскую рулетку, ведь кто может точно знать насколько хороша база, которую я буду гонять? Никто и не знает, в этом есть маленькая проблемка. Выходит, что на сайте, нам предлагают решать datadome, очень грустно и страшно. Но мы пойдем другим путем, ведь все читали, что я писал до этого?)
2.2 Снифф с андроида. Настройка, разбор. Писанина и код.
Пора уже переходить к самому желаемому в этой статье. Понять всё же, как это делается. Как я говорил ранее мы будем работать с HTTP Toolkit в связке с эмулятором Android-a, в качестве эмулятора я могу посоветовать именно Nox, ибо эмулятор Bluestacks на отрез отказывается работать в комбинации с нашим тулкитом. Для начала скачиваем наше приложение, с которого будем снифать. Сделать это можете как угодно, хоть с Google Play, хоть берите APK с какого-нибудь сайта и устанавливайте его. Тут свобода действий. Я предпочитаю качать APK с сайтов, хоть это и не безопасно, так как не люблю морочиться с Гугл аккаунтом, этим Гугл плеем, не привыкший я к нему. Теперь когда мы установили нужное нам приложение
Пора начинать скакать к нашему HTTP Toolkit, запускаем его и нам нужно выбрать этот метод.
Эта панацея сделает всё сама как я и говорил ранее, чтоб убедиться в работоспособности, проверьте эмулятор, должна запуститься "дочка" toolkit-а, которая нам покажет и скажет, что всё класс, перехватывай сколько угодно.
Теперь можно приступать, все наши запросы, которые происходят можно увидеть полностью здесь.
И бамц, наблюдаем проблему и уже начинаем видеть различия, в мобильном приложении, он нам просто заявляет, что не, у тебя пароль неверный или почта, гадай сам.
Это тоже не очень прикольно, но при этом дает нам прямые док-ва, что API-разные полностью, ведь функция одна и та же, но обрабатываются они по другому. Тогда стоит попробовать другие методы, к примеру попробовать зарегистрироваться. При регистрации ему так же плевать на всё вокруг, он не обращает внимания на почту, говорит, что отправил письмо для подтверждения, хотя аккаунт зарегистрирован, а в ответе так же возвращает
Изначально для меня это было достаточно неплохой зацепкой, ведь он возвращает нам userID, по которому можно найти пользователя и посмотреть когда был зарегистрирован, и в случае если он был бы зарегистрирован сегодня, тогда мы могли бы сделать вывод, что аккаунт пустышка, и никто его не купит, а если дата регистрации старенькая, то это зеленый свет, который даёт нам знать, что на эту почту стоит положить глаз.
Но кто сказал, что всем будет хорошо? Я решил, что надо проверить такую теорию, по этому было решено накатать скриптик, который будет псевдо-регистрировать нам аккаунты, но для нас будет интересом какой userId возвращается, то ли это вообще о чем я подумал парой предложениями ранее? Ибо один раз отправив письмо на почту из разряда "29348923dyu8iquhgiudowed@gmxfhsadlof.de", я получил userID, который был зарегистрирован еще пару лет назад, меня это смутило.
Значение x-acf-sensor-data заберите самостоятельно из HTTP Toolkit, оно лежит там, в дальнейшем это можно автоматизировать с помощью этого чуда, который автоматически генерит это значение нам. Все остальные параметры оставляем как есть.
По итогу работы скрипта получилось так, что каждая рандомная почта, уже имеет какой либо аккаунт, что с 101% вероятностью - одна из насмешек разработчиков над такими как мы) Это грустно, ведь других маршрутов для работы у нас не осталось. Я вполне ожидал такого исхода, как и говорил ранее, сервис крепко забит гвоздиком с молоточком, защита пока такова, что разрушить мне её не под силу, и я был бы рад услышать ваши мысли и возможные решения по этому сервису.
3. Выводы. Итоговое сравнение мобильного-API и браузерного.
Заключение на самом деле, немного даже прискорбное, ведь у меня не получилось реализовать желаемое, но при этом изначальная цель статьи была все же рассказать о мобильном-API, к которому стоит приглянуться нежели к обыкновенному. Это можно увидеть на примере, ведь при работе в браузере у нас вылез ненавистный "datadome", который готов убить любого и каждого, кто попробует автоматизировать сайт, находящийся под его защитой. В то время как в мобильном приложении все полностью приятно, за исключением "akamai", но на него есть открытое и стабильное решение, которое легко ставится на тачке параллельно с другими желаемыми скриптами. Отсутствие JS'a развязывает руки, ведь нет кучи динамических параметров и прочего неприятного дерьма, и все защиты выстраиваются зачастую сугубо от нашего устройства). Прошу заметить, что некоторые приложения все же замечают эти действия и блокируют доступ, в таком случае я делал ручками в связке с Burp и ФИЗИЧЕСКИМ телефоном, тогда приложения прекращали жаловаться на это и пропускали меня. Надеюсь, что материал был полезен, хоть и не получилось ничего сделать по итогу)
Полезные ссылки
Эмулятор - https://www.bignox.com/
HTTP Toolkit, заходить не с RU IP - https://httptoolkit.com/
Генератор x-acf-sensor-data - https://github.com/xvertile/akamai-bmp-generator
Краткое введение в ADB - https://habr.com/ru/articles/751092/
(c) chiefchain
1.1 О чём статья?
Всем снова, здрасте. Я думаю, каждый разработчик хоть раз сталкивался с ситуацией, когда запросы, собранные с браузера через DevTools, не пробивались никаким образом, просто невозможно автоматизировать этот запрос в силу сильной защиты. Это может быть связано с чем угодно, факторов целое множество, начиная от банальной сверки User-Agent, до чего-то покрупней, как защита у Cloudflare. В таких случаях мобильное API приложения становится самым настоящим спасением. С моей точки зрения, при работе с бигтехами, которые чуть ли не монополисты в своей сфере/стране, стоит начинать всегда с их приложения, а не с сайта, ибо мобильное API всегда будет в тысячи раз легче.
1.2 Почему мобильное API легче?
Это объясняется как минимум чуть ли не абсолютно разной архитектурой. Запросы в браузере зачастую зависят от кучи динамических параметров, которые сложно автоматизировать, так как они зависят от контекста. Примером может быть какой-нибудь кусочек на JavaScript, который генерирует CSRF-токены, nonce или еще что похуже, и не стоит забывать, что язык этот обфусцируется на раз два, что еще делает нам проблем. В то время как у мобильных приложений структура запросов более простая - это самые обыкновенные прямые запросы, которые не зависят от JS-а. Связано это с тем, что разработчики контролируют практически полностью ваше устройство, знают они примерно всё про ваш в техническом плане, а если тыкнуть еще и на всякие разрешения, то будут знать всё и про вас (на днях была уязвимость в IOS, которая позволяла файлики ваши красть из облака, даже без ваших согласий, просто в фоне).
Так же в браузере в разы легче анализировать поведение человека: скорость ввода, клики, движение мыши. На телефоне сделать это крайне затруднительно, ибо я думаю, все знают про популярную проблему на сайтах при присутствии на них hover'ов, они отвечают за то, чтоб кнопочка загоралась когда на неё наводились курсором, а с мобильного, так оно работать не будет.
В то время как в мобильных приложениях такие проверки происходят крайне редко. Не могу сказать точно, с чем это связано, но предположу, что разработчики просто больше доверяют пользователям с телефонов, нежели с браузеров, ибо среда разработки при мобильных приложениях более контролируемая.
1.3 Devtools - панацея?
Думаю, каждый хоть раз сталкивался с ним, даже не в рамках запросов, а просто. Devtools - замечательный и мощный инструмент, буквально развязывает руки при работе с браузером, он универсален, с этим поспорить нельзя. Даёт доступ и к запросам, к работе с консолью, и куче другого. Но, есть одно "но", его нет как такого в мобильных приложениях, с этим ничего не поделать. По этому нельзя говорить, что Devtools - является панацеей. И что делать? Как тогда собирать запросы с мобильных приложений, если они нам так нужны?
1.4 ADB или MiTM? С чём его есть в рамках сниффа траффика?
И так, Devtools у нас не работает с мобильными приложениями. Здесь есть всего лишь два подхода, с моей точки зрения, а именно, подключать по ADB или же проводить MiTM-атаку над самим собой же. ADB (Android Debug Bridge) — это крайне мощный инструмент для работы с Android-ами. С его помощью мы можем подключаться к устройству, перехватывать трафик, управлять приложениями и множество других возможностей. Для работы с ADB нужно, чтобы устройство было подключено к компьютеру по проводу или же просто подключить и ПК и телефон к одной сети. Достаточно легок он в использовании, тому кто хоть раз кликался и разбирался в этом, там нет кучи команд и т.д., не придется убиваться. Выглядит это все дело в простом исполнении как терминал с командами.
Но есть и свои минусы: нужно физически подключать устройство и настраивать сертификаты, потому что иначе это бессмыслица, ведь все нормальные проекты используют HTTPS, ну и конечно, ADB не будет работать с IOS-устройствами.
MiTM (Man-in-the-Middle) — это метод перехвата трафика между устройством и сервером. По сути, это атака, которую в реалиях используют, чтоб воровать кукисы, пароли и всё что угодно, думаю каждый хоть раз видел сообщение на форуме о продаже фишлетов, так вот, они все зачастую работают на основе MITM, но нам не нужны ни чьи пароли, нам нужно достать запросы, мы будем должны проводить атаку над самим собой, локально. Суть заключается в том, чтобы подменить сертификат сервера на свой собственный, что позволяет легко перехватывать нужные нам запросы. Без сторонних инструментов организовать MiTM над самим же собой, гораздо легче, нежели париться с ADB. В Burp'e можно настроить proxy-сервер, после чего уже в нашем мобильнике, выставить прокси, настроить сертификат, и лететь в бой.
1.5 HTTP Toolkit - панацея в сниффинге с мобильных устройств.
Все эти методы, как ADB-подключение и MiTM-атака, действительно круты, но их воспроизведение забвенными путями — это самый настоящий кошмар. Зачем нам усложнять всё и лишний раз ковыряться в настройках, когда уже существуют решения, которые автоматизируют всё это самостоятельно? Именно здесь на сцену выходит наша панацея, HTTP Toolkit.
Это наше спасение, который делает весь процесс перехвата запросов в мобильных приложениях до нажатия пару кнопок в самом приложении. Он сам всё настраивает: подключается к телефону через ADB, настраивает локальный MiTM для перехвата трафика и даже ставит сертификаты, чтобы можно было перехватывать HTTPS-трафик.
Мы рассмотрим с вами по итогу два варианта, снифф с Android-устройств, и как делается это на IOS-устройствах, разбирать целиком на IOS мы не будем, ибо это всё сведется к повторению того, что было, и не будет нести смысла. За подопытную крыску возьмем немецкий сервис ebay-kleinzaigen, у которого невыносимо сильная защита и фрод (я не преувеличиваю, у меня банально даже не получается зарегистрировать аккаунт руками). Я не думаю по итогу, что у меня получится написать проверку на то, зарегистрирована ли почта в сервисе или нет, требуется это "брутерам", которые гоняют почты, проверяют на регистрацию, а после продают аккаунты, а цена за 1 аккаунт, достаточно неплоха, иль мне так кажется лишь.
2. Снифф в самой красе
2.1 Какие запросы в Devtools? Какая защита там у нашего сервиса?
Проверка на то зарегистрирована ли почта в сервисе достаточно обыкновенная, нам стоит просто попробовать залогиниться, и он нам скажет, что не так, исходов куча, но нас интересует вариант, когда почта зарегистрирована. Вот так выглядит грустное письмо, а представьте брутеров с гигабитными текстовиками mail
ass, которые все надо проверить и крайне быстро.Открывая Devtools, я сразу же вижу кошмар под названием "datadome", который точно уж никого из ботов не пропустит)
Сбор абсолютного всего, всё что можно, и всё что нельзя уже собрали, cервис мощный, крайне мощный. Цена за его решение стоит от 160 рублей за 1000 штук, кажется не дорого, а если у нас огромные объемы, то уже становится более напряжней, ведь тогда мы играем в некую русскую рулетку, ведь кто может точно знать насколько хороша база, которую я буду гонять? Никто и не знает, в этом есть маленькая проблемка. Выходит, что на сайте, нам предлагают решать datadome, очень грустно и страшно. Но мы пойдем другим путем, ведь все читали, что я писал до этого?)
2.2 Снифф с андроида. Настройка, разбор. Писанина и код.
Пора уже переходить к самому желаемому в этой статье. Понять всё же, как это делается. Как я говорил ранее мы будем работать с HTTP Toolkit в связке с эмулятором Android-a, в качестве эмулятора я могу посоветовать именно Nox, ибо эмулятор Bluestacks на отрез отказывается работать в комбинации с нашим тулкитом. Для начала скачиваем наше приложение, с которого будем снифать. Сделать это можете как угодно, хоть с Google Play, хоть берите APK с какого-нибудь сайта и устанавливайте его. Тут свобода действий. Я предпочитаю качать APK с сайтов, хоть это и не безопасно, так как не люблю морочиться с Гугл аккаунтом, этим Гугл плеем, не привыкший я к нему. Теперь когда мы установили нужное нам приложение
Пора начинать скакать к нашему HTTP Toolkit, запускаем его и нам нужно выбрать этот метод.
Эта панацея сделает всё сама как я и говорил ранее, чтоб убедиться в работоспособности, проверьте эмулятор, должна запуститься "дочка" toolkit-а, которая нам покажет и скажет, что всё класс, перехватывай сколько угодно.
Теперь можно приступать, все наши запросы, которые происходят можно увидеть полностью здесь.
И бамц, наблюдаем проблему и уже начинаем видеть различия, в мобильном приложении, он нам просто заявляет, что не, у тебя пароль неверный или почта, гадай сам.
Это тоже не очень прикольно, но при этом дает нам прямые док-ва, что API-разные полностью, ведь функция одна и та же, но обрабатываются они по другому. Тогда стоит попробовать другие методы, к примеру попробовать зарегистрироваться. При регистрации ему так же плевать на всё вокруг, он не обращает внимания на почту, говорит, что отправил письмо для подтверждения, хотя аккаунт зарегистрирован, а в ответе так же возвращает
Изначально для меня это было достаточно неплохой зацепкой, ведь он возвращает нам userID, по которому можно найти пользователя и посмотреть когда был зарегистрирован, и в случае если он был бы зарегистрирован сегодня, тогда мы могли бы сделать вывод, что аккаунт пустышка, и никто его не купит, а если дата регистрации старенькая, то это зеленый свет, который даёт нам знать, что на эту почту стоит положить глаз.
Но кто сказал, что всем будет хорошо? Я решил, что надо проверить такую теорию, по этому было решено накатать скриптик, который будет псевдо-регистрировать нам аккаунты, но для нас будет интересом какой userId возвращается, то ли это вообще о чем я подумал парой предложениями ранее? Ибо один раз отправив письмо на почту из разряда "29348923dyu8iquhgiudowed@gmxfhsadlof.de", я получил userID, который был зарегистрирован еще пару лет назад, меня это смутило.
Code:
import requests
from faker import Faker
fake = Faker()
headers = {
"Accept-Encoding": "gzip",
"Authorization": "Basic YW5kcm9pZDpUYVI2MHBFdHRZ",
"Connection": "Keep-Alive",
"Content-Length": "250",
"Content-Type": "application/json; charset=utf-8",
"Host": "api.kleinanzeigen.de",
"User-Agent": "Kleinanzeigen/100.26.0 (Android 7.1.2; samsung SM-G955N)",
"x-acf-sensor-data": "",
"X-EBAYK-APP": "a9b512a6-1e9d-48a9-aea8-6b77f59240f31733909713801",
"X-EBAYK-GROUPS": "BAND-7832-Category-Alerts_B|BAND-8364_B|BAND-8483_composeSlider_A|BLN-19260-cis-login_B|BLN-24652_category_alert_B|BLN-25729_Likes_in_Feed_B|backend_ab_bln01021_B|backend_ab_bln13364_B|backend_ab_bln418_B|backend_ab_bln_abc_B|backend_ab_bln_abc2_B",
"X-EBAYK-USERID-TOKEN": "",
"X-EBAYK-WENKSE-SESSION-ID": "2d6b7511ae814b91b0fc36ecf262a80f",
"X-ECG-USER-AGENT": "ebayk-android-app-100.26.0",
"X-ECG-USER-VERSION": "100.26.0"
}
for _ in range(5):
email = fake.email()
contact_name = fake.name().replace(" ", "_")
data = {
"email": email,
"password": "sadgsdafgpoJA89gh8u72134!",
"contactName": contact_name,
"passwordConfirmation": "sadgsdafgpoJA89gh8u72134!",
"marketingOptIn": False,
"accountType": "COMMERCIAL"
}
response = requests.post("https://api.kleinanzeigen.de/api/account/registration", headers=headers, json=data)
print(f"{email}\n{response.text}")Значение x-acf-sensor-data заберите самостоятельно из HTTP Toolkit, оно лежит там, в дальнейшем это можно автоматизировать с помощью этого чуда, который автоматически генерит это значение нам. Все остальные параметры оставляем как есть.
По итогу работы скрипта получилось так, что каждая рандомная почта, уже имеет какой либо аккаунт, что с 101% вероятностью - одна из насмешек разработчиков над такими как мы) Это грустно, ведь других маршрутов для работы у нас не осталось. Я вполне ожидал такого исхода, как и говорил ранее, сервис крепко забит гвоздиком с молоточком, защита пока такова, что разрушить мне её не под силу, и я был бы рад услышать ваши мысли и возможные решения по этому сервису.
3. Выводы. Итоговое сравнение мобильного-API и браузерного.
Заключение на самом деле, немного даже прискорбное, ведь у меня не получилось реализовать желаемое, но при этом изначальная цель статьи была все же рассказать о мобильном-API, к которому стоит приглянуться нежели к обыкновенному. Это можно увидеть на примере, ведь при работе в браузере у нас вылез ненавистный "datadome", который готов убить любого и каждого, кто попробует автоматизировать сайт, находящийся под его защитой. В то время как в мобильном приложении все полностью приятно, за исключением "akamai", но на него есть открытое и стабильное решение, которое легко ставится на тачке параллельно с другими желаемыми скриптами. Отсутствие JS'a развязывает руки, ведь нет кучи динамических параметров и прочего неприятного дерьма, и все защиты выстраиваются зачастую сугубо от нашего устройства). Прошу заметить, что некоторые приложения все же замечают эти действия и блокируют доступ, в таком случае я делал ручками в связке с Burp и ФИЗИЧЕСКИМ телефоном, тогда приложения прекращали жаловаться на это и пропускали меня. Надеюсь, что материал был полезен, хоть и не получилось ничего сделать по итогу)
Полезные ссылки
Эмулятор - https://www.bignox.com/
HTTP Toolkit, заходить не с RU IP - https://httptoolkit.com/
Генератор x-acf-sensor-data - https://github.com/xvertile/akamai-bmp-generator
Краткое введение в ADB - https://habr.com/ru/articles/751092/
(c) chiefchain
