Каждый год (если вы не являетесь одним из пользователей Apple Music) фанаты музыки получают собственный Spotify Wrapped или обзор их музыкальных предпочтений в течение уходящего года. Это забавный способ исследовать наиболее прослушиваемых исполнителей и композиции. И, если мне не изменяет память, каждый год вплоть до текущего Spotify Wrapped был доступен в браузере. А затем я посетил сайт Spotify в этом году.
Что ж, облом. Но мне интересно, есть ли какие-либо особые технические требования к устройству пользователя, не позволяющие отобразить Spotify Wrapped в браузере? И для интереса предположим, что это не просто схема для популяризации мобильных версий Spotify.
В роли этакого Шерлока Холмса, я решил составить список моих самых верных союзников в этом деле:
Я надеялся, что Spotify не пиннингует сертификаты, поскольку это сорвало бы все планы. И, внимание, спойлер — они этого не делают. Но, как оказалось, я был слишком наивен, рассчитывая получить все ответы в пару кликов. После настройки Fiddler сертификата на iOS 15, я смог перехватить ровно ноль HTTPS-трафика. Это немного сбило меня с толку: я подумал, что Spotify реализовало пиннинг сертификатов, пока я собирался с мыслями и начал что-то делать. Что-то в Fiddler работало не очень хорошо с iOS, несмотря на все настройки параметров доверия, поэтому я переключился на mitmproxy на WSL.
После небольшой настройки я был готов к работе и, как обычно, проверял трафик:
Первое, что бросилось мне в глаза, это запрос к CDN, вытягивающий что-то вроде
К счастью, из временных меток UNIX включенных в
Хорошо, давайте копать дальше. Я перезапускал приложение несколько раз, потому что некоторые запросы казались кэшированными, и поэтому я не ожидал ничего увидеть при запуске истории. А потом я увидел это:
Бинго! Это запрос к:
К этому запросу прикреплена куча заголовков, что здорово, но самым важным является авторизация, которая является лишь токеном на предъявителя, который вы можете получить из локального трафика Spotify, в том числе и в десктопной версии клиента. Выполнение запроса GET к конечной точке вернуло кое-что интересно — тип контента
Мне не хотелось писать код и я решил использовать протокол для декодирования данных. Если вы работаете на Debian (или внутри Ubuntu в WSL), вы можете выполнить команду:
После установки я могу загрузить двоичные данные через
И, наконец, расшифровать необработанное сообщение:
В итоге получая структурированный Spotify Wrapped:
Как оказалось, за кулисами Spotify Wrapped очень мало видеоматериалов. Большинство режимов закодировано в ProtoBuf. При наличии желания, вы можете пойти дальше и воссоздать собственный Spotify Wrapped.
Учитывая, что закулисье Spotify Wrapped — это всего лишь структурированные данные, остается загадкой, почему Spotify убрал возможность просматривать музыкальные итоги года в браузере. Тем не менее, похоже, что содержимого в полезной нагрузке ProtoBuf (включая предварительный просмотр аудио MP3 со скоростью 96 Кбит/с) достаточно для создания кастомных обзоров в любой среде.
Что ж, облом. Но мне интересно, есть ли какие-либо особые технические требования к устройству пользователя, не позволяющие отобразить Spotify Wrapped в браузере? И для интереса предположим, что это не просто схема для популяризации мобильных версий Spotify.
В роли этакого Шерлока Холмса, я решил составить список моих самых верных союзников в этом деле:
- iPhone с установленным приложением Spotify;
- Fiddler для Windows и mitmproxy для macOS;
- Самозаверенный сертификат для расшифровки локального HTTPS-трафика;
- Обеденный перерыв.
Я надеялся, что Spotify не пиннингует сертификаты, поскольку это сорвало бы все планы. И, внимание, спойлер — они этого не делают. Но, как оказалось, я был слишком наивен, рассчитывая получить все ответы в пару кликов. После настройки Fiddler сертификата на iOS 15, я смог перехватить ровно ноль HTTPS-трафика. Это немного сбило меня с толку: я подумал, что Spotify реализовало пиннинг сертификатов, пока я собирался с мыслями и начал что-то делать. Что-то в Fiddler работало не очень хорошо с iOS, несмотря на все настройки параметров доверия, поэтому я переключился на mitmproxy на WSL.
После небольшой настройки я был готов к работе и, как обычно, проверял трафик:
Первое, что бросилось мне в глаза, это запрос к CDN, вытягивающий что-то вроде
video/MP2T — мог ли я так быстро найти золотую жилу? URL запроса: https://video-akpcw-cdn-spotify-com.akamaized.net/segments/v1/origins/{FIRST_ID}/sources/{SOME_ID}/encodings/{ANOTHER_ID}/profiles/17/4.ts?token=SOME_TOKEN&token_ak=st=UNIX_TIMESTAMP_1~exp=UNIX_TIMESTAMP_2~acl=*/encodings/{SOME_ID}/*~hmac=HMAC_SIGNATURE
К счастью, из временных меток UNIX включенных в
token_ak, который, к слову, является токеном Akamai, следует, что этот токен долгоживущий (я могу использовать его как минимум 7 дней). Я вставил URL в curl и увидел, что .ts файл оказался на диске. Здорово! Однако, открыв его, я не обнаружил ничего интересного:Хорошо, давайте копать дальше. Я перезапускал приложение несколько раз, потому что некоторые запросы казались кэшированными, и поэтому я не ожидал ничего увидеть при запуске истории. А потом я увидел это:
Бинго! Это запрос к:
https://spclient.wg.spotify.com/campaigns-service/v1/campaigns/wrapped/consumer
К этому запросу прикреплена куча заголовков, что здорово, но самым важным является авторизация, которая является лишь токеном на предъявителя, который вы можете получить из локального трафика Spotify, в том числе и в десктопной версии клиента. Выполнение запроса GET к конечной точке вернуло кое-что интересно — тип контента
application/protobuf. Мне не доводилось работать с ProtoBufs с тех пор, как я изучал внутренности камеры Nest, так что это была отличная возможность заново ознакомиться со всеми инструментами.Мне не хотелось писать код и я решил использовать протокол для декодирования данных. Если вы работаете на Debian (или внутри Ubuntu в WSL), вы можете выполнить команду:
sudo apt-get install protobuf-compiler
После установки я могу загрузить двоичные данные через
curl:curl --location --request GET 'https://spclient.wg.spotify.com/campaigns-service/v1/campaigns/wrapped/consumer' --header 'Authorization: YOUR_BEARER_TOKEN' --output data.proto
И, наконец, расшифровать необработанное сообщение:
protoc --decode_raw < data.proto
В итоге получая структурированный Spotify Wrapped:
Как оказалось, за кулисами Spotify Wrapped очень мало видеоматериалов. Большинство режимов закодировано в ProtoBuf. При наличии желания, вы можете пойти дальше и воссоздать собственный Spotify Wrapped.
Заключение
Учитывая, что закулисье Spotify Wrapped — это всего лишь структурированные данные, остается загадкой, почему Spotify убрал возможность просматривать музыкальные итоги года в браузере. Тем не менее, похоже, что содержимого в полезной нагрузке ProtoBuf (включая предварительный просмотр аудио MP3 со скоростью 96 Кбит/с) достаточно для создания кастомных обзоров в любой среде.