Описание API Max (неофициальное)

Important

Данный репозиторий является неофициальным и реализован на основе анализа сетевого трафика и предположений.

Про проблему 7‑го байта см. в конце.

---

Общая информация

API клиентской части Max.

У Max существует два API:

• WSS (WebSocket) - для web‑версии
• TLS - для приложений

Базовая логика у них во многом одинаковая, поэтому выбор между ними остаётся за вами.

---

Web API

Наиболее простой API с понятной структурой и самым лёгким способом анализа.

Как анализировать

Анализ можно проводить прямо в браузере с помощью панели разработчика:

1. Зайти на сайт: https://web.max.ru

2. Открыть консоль разработчика:

   • Ctrl + Shift + J, либо
   • ПКМ → Проверить

3. Перейти во вкладку Network.

4. (Опционально) В фильтрах сверху выбрать Socket.

5. Перезагрузить страницу.

6. Найти и открыть WebSocket‑подключение:

   • если выполнен пункт 4 - оно будет первым и единственным.

7. Перейти во вкладку Messages.

На этом всё - далее остаётся анализировать смысл пакетов, порядок их отправки и структуру.

Отдельно описывать формат пакетов, на мой взгляд, не имеет смысла - он достаточно очевиден.

---

App API

Здесь начинается самое интересное. В отличие от Web‑версии, в приложении нет простого пути анализа, а структура пакетов заметно усложнена.

Далее описание ориентировано на Windows‑версию.

---

Как анализировать

1. Скачать Windows‑версию приложения:

   • https://download.max.ru/#desktop

2. Установить приложение.

   • Я использовал виртуальную машину, но это не принципиально.

3. Подготовить инструмент для анализа трафика.

   • В данном описании используется mitmproxy.

---

Установка mitmproxy

1. Скачать Windows‑версию:

   • https://www.mitmproxy.org

2. Установить приложение.

3. Запустить mitmweb (веб‑интерфейс - более удобен).

---

Установка сертификата

Файл сертификата:

C:\Users\%User%\.mitmproxy\mitmproxy-ca-cert.cer

Параметры установки:

• Устанавливать для: Локального компьютера
• Хранилище: Доверенные корневые центры сертификации

---

Настройка mitmproxy

В интерфейсе mitmproxy:

1. Перейти во вкладку Capture.

2. Включить Local Applications.

3. Выбрать max.exe.

4. Перейти во вкладку Flow List.

5. Очистить список:

   • File → Clear All

6. (Опционально) Перезапустить Max.

Готово.

---

Советы по анализу

В mitmproxy, после выбора соединения, в правом верхнем углу можно выбрать режим View.

Наиболее полезные режимы:

• Hex Dump
• Hex Stream

Для анализа Hex Stream удобно использовать сервис:

• https://hexed.it - отличный инструмент для работы с бинарными данными.

---

Структура TLS‑пакетов

Заголовок

Размер заголовка: 10 байт.

Разбор по байтам

Байты	Описание
1	Версия протокола (за всё время анализа не менялась)
2	cmd - тип команды
3..4	seq - номер пакета (начинается с 1, ответ приходит с тем же seq)
5..6	opcode - тип пакета
7	Неизвестное поле
8..10	Длина payload в байтах
11..	Payload

---

Payload

• Обычно кодируется в формате MsgPack.
• Если значение 7‑го байта ≠ 0, то в начале payload присутствуют 2 дополнительных неизвестных байта.

---

Значения cmd

Note

Актуально и для WebSocket

Значение	Описание
0	Запрос
1	Ответ
3	Ошибка

---

Список opcode

(w) - предположение на основе web‑версии

Opcode	Описание
1	Статус клиента (период отправки - 1 секунда)
5	События - действия клиента (w)
6	Информация о клиенте
11	Отправка номера телефона (аутентификация)
12	Проверка кода из SMS
13	Вход по токену (повторный вход)
19	Синхронизировать по токену (w)
26	Секции по ID (w)
27	Эмодзи (w)
28	Эмодзи по ID (w)
32	Контакт по ID (w)
35	Последнее время онлайн контакта по ID (w)
36	Список заблокированных контактов (w)
48	Информация о чате по ID (w)
49	История чата по ID (w)
50	Действие с каналом (например, отметить прочитанным) (w)
64	Отправить сообщения (w)
75	Подписка на чат (клиент просматривает чат) (w)
79	Истории (w)
83	Получить видео по ID (w)
96	Сессии клиента (входы, устройства и т.п.) (w)
130	Событие, связанное с чатом (от сервера) (w)
177	??? (w)
178	Добавить реакцию на сообщение (w)
180	Реакции на сообщениях (w)
272	Папки (w)
288	Запрос QR-кода для входа (w)
288	Статус QR-кода по trackId (w)
291	Вход по trackId после сканирования QR-кода (w)
292	Запрос от сервера: показать баннер

---

Проблема 7‑го байта

Пару матов про 7‑й байт.

Желание сделать API у меня было давно, но я так его и не реализовал. Основная причина - 7‑й байт заголовка.

Суть проблемы

Если значение 7‑го байта не равно нулю, то:

• в начале payload появляются 2 неизвестных байта;
• payload перестаёт адекватно декодироваться как MsgPack.

Я не имею ни малейшего понятия, что это за байт и в чём его смысл.

Я сломал голову, пытаясь его проанализировать, но безуспешно.

Пробовал использовать нейросети для анализа пакетов - но они слишком тупые для таких задач.

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

На данный момент у меня есть лишь два предположения:

1. Это некий вид сжатия.
2. Это некое шифрование.

Скорее всего, оба предположения неверны, потому что:

• в случае сжатия:

  • 7‑й байт встречается даже в маленьких пакетах, где сжатие бессмысленно,
  • а в больших пакетах его может не быть;

• в случае шифрования:

  • пакет всё ещё частично читаем,
  • и частично декодируется как MsgPack.

Выглядит это так, будто payload просто побит.