Migrate to CDN

[sashahilton00]

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.

[devgianlu]

It is not necessary to download the head file, you can still get the total size from the Content-Range present in every response. This file is very useful to start the playback immediately as it's not encrypted, but still not mandatory.

[roderickvd]

Additionally, it's not of any use to do a HTTP HEAD request on that head-files-url because its Content-Range is of its own body (128 kB) and not of the full file.

[devgianlu]

@sashahilton00 The encryption method is actually the same, I've dumped everything into a file and it plays fine. I must have done something wrong with the player.