ПРОТОКОЛ АНАЛИЗА ПРИЛОЖЕНИЯ "BURGER KING" ОТ РАЗРАБОТЧИКА "LOYALTY PLANT" ("ФАБРИКА ЛОЯЛЬНОСТИ") ОСНОВНЫЕ ПОЛОЖЕНИЯ: ======================================================================================================== 1. Приложение разработано для мобильных платформ: Android, Windows Phone, iOS 2. Приложение разработано на основе фреймворка Xamarin, который реализует поддержку .NET-приложений в мобильной среде 3. Приложение, кроме того, состоит в целом из двух важных частей: * .NET-ассембли, написаный, скорее всего, на C#. (Весь код, включая структуру классов, а так же декомпилированные листинги методов, можно получить с использованием .NET Reflector) * Ассембли содержит основной функционал программы, логику работы с аппаратным обеспечением, логику для генерирования уникального идентфикатора устройства * Ассембли содержит основную логику для работы с REST-сервисом LoyaltyPlant на основе XML-запросов * Ассембли содержит вызовы подпрограмм для обеспечения шифрования передаваемых данных: * Используется следующая схема: КЛИЕНТ->СЕРВЕР: [ XML-запрос] -> [ AES-шифрование (Java-бэкенд) ] -> [ Base64-кодирование ] СЕРВЕР->КЛИЕНТ: [ Base64-декодирование ] -> [ Дешифровка AES (Java-бэкенд) ] -> [ XML-ответ ] * Java-бэкенд (весь существенный код, кроме биндингов к Android-среде, прошёл процедуру обфускации путём искажения реальных имён классов и их членов, а так же локальных переменных. Получить исходные коды можно через связку утилит: dex2jar -> jd-gui): * Состоит из биндингов из Xamarin (.NET) среды к среде Android (в данном конкретном случае рассматривается только реализация для Android) * Содержит в себе набор обфусцированных классов библиотеки BouncyCastle для обеспечения поддержки AES-шифрования * Содержит в себе класс (с именем a.class), цель которого обеспечить связь между .NET-частью и Java-бэкендом через вызовы JNI со стороны .NET-части. Связь выражается в виде вызовов подпрограмм для шифрования/дешифрования * Содержит класс "a.class", который в своём статическом блоке инициализации единожды генерирует постоянный 16-байтовый ключ для AES-шифрования. Кроме того, класс имеет подпрограммы вызова шифрующих/дешифрующих подпрограмм. * Содержит в себе класс com.google.utils.Util, который, в свою очередь, содержит подпрограмму для генерации уникального идентификатора пользователя на основе данных о его модели. Содержит строковые константы с предупреждением о возможном нарушении статьи 272 УК РФ, а так же вызовы хеш-функции CRC32 4. Некоторые сведения об используемой "защите": * Криптографическая схема в стандартных обозначениях: AES/CBC/PCKS7Padding (алгоритм: симметричный шифр AES (aka Rijndael), режим: блочный, выравнивание блоков: PCKS7) * Хеш-функция: CRC32 * Функция обратимого кодирования малым алфавитом: Base64 * Схема передачи данных: КЛИЕНТ->СЕРВЕР: [ XML-запрос] -> [ AES-шифрование (Java-бэкенд) ] -> [ Base64-кодирование ] СЕРВЕР->КЛИЕНТ: [ Base64-декодирование ] -> [ Дешифровка AES (Java-бэкенд) ] -> [ XML-ответ ] ЦЕЛЬ: ======================================================================================================== Разработать приложение, которое будет имитировать ввод промо-кода на физическом устройстве с целью получения бонусных баллов с минимумом затрат ОБФУСЦИРОВАННЫЕ НАЗВАНИЯ КЛАССОВ Java-БЭКЕНДА И ИХ ПРЕДНАЗНАЧЕНИЕ: ======================================================================================================== * a - Main (можно назвать главным классом в крипографической схеме. Генерирует ключ шифрования, обеспечивает связь с .NET-частью в плане вызова шифрующих/дешифрующих подпрограмм) * d - BlockCipher (BouncyCastle) * l - CBCBlockCipher (BouncyCastle) * t.class, r.class - кодирование BASE64 * k.class - Реализация AES (BouncyCastle) * n.class - PaddedBufferedBlockCipher (BouncyCastle) ПРОТОКОЛ ЛЕГАЛЬНОЙ СЕССИИ ПЕРЕДАЧИ ДАННЫХ МЕЖДУ КЛИЕНТОМ И СЕРВЕРОМ: ======================================================================================================== Общие положения: * Передача данных ведётся по протоколу HTTP версии 1.1 * Используется метод POST * URL, к которому идут запросы, постоянен и имеет вид: http://54.247.166.174/IPLPhoneServer/PhoneServerSec.do * Тело запроса и ответа на запрос зашифровано известной схемой, приведённой выше * Тело каждого запроса, если исключить шифрование и кодирование, это обращение к REST-сервису на основе XML-формата. В каждом запросе упоминается: * Версия протокола * Уникальный идентификатор клиента (устройства) * Запросы от клиента имеют следующие заголовки: POST /IPLPhoneServer/PhoneServerSec.do HTTP/1.1 Accept: application/json, application/xml, text/json, text/x-json, text/javascript, text/xml User-Agent: RestSharp 104.1.0.0 Content-Type: application/octet-stream Content-Length: длина-передаваемых-данных Host: 54.247.166.174 (айпи сервера, постоянен) Accept-Encoding: gzip, deflate (клиент принимает в качестве ответа от сервера сжатый ZLib/Deflate поток данных) * Ответы сервера на запросы имеют следующие заголовки: HTTP/1.1 200 OK Server: nginx/1.4.7 Date: временная-метка-в-формате-GMT Content-Length: длина-пакета-данных Connection: keep-alive Set-Cookie: JSESSIONID=A7F19DE146D0C1DA921CF279643A0A5A; Path=/IPLPhoneServer/; HttpOnly Content-Encoding: gzip ======================================================================================================== Краткая схема запросов клиента: 1. Запрос на регистрацию 2. Запрос на данные интернационализации (Loyalty Plant - межнациональная компания, так-то) 3. Запрос на получение информации о партнёре (в нашем случае это Burger King) 4. Запрос на загрузку данных синхронизации 5. Подробный журнал запуска 6. Подробный журнал, в том числе содержащий информацию о модели физического устройства 7. Подробный журнал, содержащий данные метрики BlackBox (какие кнопки когда и где нажаты, какие окна открывались/закрывались и т. п.) 8. Запрос на проверку введённого промо-кода ПОДРОБНЫЙ РАЗБОР СЕССИИ ПЕРЕДАЧИ ДАННЫХ: ======================================================================================================== * Знаком [!] помечены СУЩЕСТВЕННЫЕ для выполнения ЦЕЛИ вещи 0. [!] Запрос на регистрацию клиента (первая установка) 1. [!] Ответ на пакет о первой регистрации 2. Запрос на получение данных интернационализации (язык, переводы и пр.) 3. Ответ на запрос данных интернационализации (готовые кнопки меню) 4. Запрос на получение информации о партнёре 5. Ответ на запрос информации о партнёре, возвращает кучу данных о бургер-кинге, включая описание, какая валюта используется, телефон тех. поддержки и т. п. 6. [!] Запрос на синхронизацию [!] 7. Ответ на запрос о синхронизации. Беглый анализ показывает, что в ответе содержатся следующие данные: * Текущее время на сервере в формате временной метки POSIX-TIME * Количество бонусных очков * Список филиалов Burger King в городе, включая их точные GPS-координаты * Список купонов * Шаблон пригласительного смс-сообщения Заголовок: 8. [!] Запрос на синхронизацию меню 9. Ответ на запрос синхронизации меню Содержит: * Текущее время сервера * Список элементов меню, включая купоны * Список категорий 10. [!] Клиент отправляет подробный журнал запуска Требуется полностью имитировать его формирование и отправку в целях поддержания максимального сходства с легальным приложением 11. Ответ на высланный лог, подтверждение со стороны сервера 12. [!] Очередной посыл лога, содержит важную информацию о модели устройства: 13. Ответ сервера на высланный лог 14. Клиент посылает запрос типа "log" (журнал) с данными от системы метрики BlackBox: 15. Ответ сервера на присланный лог 16. Очередные данные о метрике. [!] СУЩЕСТВЕННО: в метрике содержатся данные о том, что открыто окно ввода промо-кода (требуется имитировать и это в целях 100% схожести) Код запроса: 17. Ответ сервера на принятый лог (такой же, как и в пунктах №15, №13, №11) 18. [!] Запрос к серверу: пользователь ввёл промо-код 19. [!] Ответ от сервера о статусе принятия промо-кода (это, собственно, цель имитации, дальнейшие действия, скорее всего, будут несущественны) ======================================================================================================== Дата последнего изменения: 07.09.14 0:30 МСК