The desktop and mobile clients are increasingly using the CDN to download audio. We should migrate to this to avoid issues in future and speed up load times. Some initial reverse engineering of it has been done, dumping chat logs with findings below. There are still some things that need to be worked out, such as audio chunk decryption via CDN, as it appears to use different decryption when compared to the chunks delivered by mercury according to @devgianlu.
So, here’s what it appears to be doing:
Request metadata for track via mercury: hm://metadata/4/track/d0495a9853af45f1a9643d5d1f942d4a?country=GB&product=premium
this produces the following response (in hex):
0A10D049 ... 01026869
the file key (for the cdn, for this particular track) is: e6db8ca5795084258db731f5219ed9303f4b5035
which is located in the dump above
a request is then sent to https://spclient.wg.spotify.com/storage-resolve/files/audio/interactive/e6db8ca5795084258db731f5219ed9303f4b5035?product=0&partner=vodafone-uk, critically, with an authorization header, which includes an auth token from the keymaster endpoint
the response is protobuf, and contains a (time limited) link to the audio file, such as http://audio-fa.spotify.com/audio/e6db8ca5795084258db731f5219ed9303f4b5035?1552598178_MSB6bZHGC31kosuRxiJ8TICK5ua0TA6VEhM0k83AByg= which can be downloaded in chunks by specifying the range header. No auth token necessary.
In order to determine the total size of the file, the client first requests the file header, at the following url: http://heads-fa.spotify.com/head/e6db8ca5795084258db731f5219ed9303f4b5035, again, unauthenticated
Thus, the flow is as follows: (keymaster) -> Mercury metadata request -> Spotify file header url -> download audio file
EDB6... is the id of the first audio file in the protobuf response
if you carry out further work on reverse engineering the CDN, please note the progress in this issue.
The desktop and mobile clients are increasingly using the CDN to download audio. We should migrate to this to avoid issues in future and speed up load times. Some initial reverse engineering of it has been done, dumping chat logs with findings below. There are still some things that need to be worked out, such as audio chunk decryption via CDN, as it appears to use different decryption when compared to the chunks delivered by mercury according to @devgianlu.
if you carry out further work on reverse engineering the CDN, please note the progress in this issue.