PlayPlay endpoint reversing - Working Discussion

[Velka-DEV]

Hi everyone, I'm opening this thread for those who would like to participate in the reversing of the new Spotify endpoint playplay.

The points to clarify are as follows:

• What is the sent token ?
• @SuisChan: "Token is hardcoded, and not hard to find. Each version, even architecture, has its own uniq token"
• What does the key received correspond to?
• How is it obfuscated? (How to deobfuscate mainly)
• What is the cache_id and is it mandatory?
• The cache_id field is not mandotary, we still need to confirm what is it. (Prob. downloaded songs or cached ones)

All these data are sent in the playplay proto (See the playplay branch).

NOTE: No of these data is mandatory ! When sniffing HTTP request from client, i noticed that some songs only send GET request so no data at all.

Actually, I could find several hash and obfuscation functions in the decompiled sources of the mobile application but without finding a direct link with playplay.

Any help will be welcome. Thanks to all who will participate.

[SuisChan]

CacheID? Or do you mean token, the requests I've seen only have a token, but not a CacheID. Can you give an example ?

[SuisChan]

Okay, but a little later

[KateYogurt]

I don't know the token, but I sent the request with random token anyway, and it returned 502.
So is setting a token a must or just optional?

[iscle]

@KateYogurt check out the playplay branch in my profile, that one has the request working

[KateYogurt]

@KateYogurt check out the playplay branch in my profile, that one has the request working

Thank you! I am checking now. But it seems that the token is fixed?

[iscle]

The token has been extracted by reverse engineering a spotify compiled binary. It looks like it is paired with the decryption algorithm, also extracted but not reverse engineered yet. The version code is also paired to the decryption algorithm.

[sashahilton00]

@iscle in the interests of avoiding stepping on any toes, it might be a good idea to replace a chunk of the file ID/decryption keys above with ... - I think we're probably kosher with documenting the reverse engineering given that it's for educational/interoperability purposes, not sure if the resulting keys are integral to that.

[iscle]

I had to delete the comment since the keys still showed up on the edit history. Thanks for the tip!

[devgianlu]

@devgianlu please do not link to my code. I have open legal concerns with Spotify, so doing that is not helping.

Sorry, done.

[justfoolingaround]

Any updates on this?

Has this already been done or has it encountered a roadblock?

(Nevermind, I got notified about the DMCA takedown after a deobfuscation algorithm was created.)

[ghost]

since the above user contacted me privately, I would like to add some context to this comment:

https://github.com/librespot-org/librespot-java/discussions/421/comments/1812935#discussioncomment-1813151

no one to my knowledge has reversed the PlayPlay code, at least not publicly. @SuisChan was close, but they only captured a binary blob rather than implementing or reversing a solution. to anyone reading this page, I would recommend to use the old Shannon code, or to pursue a Widevine solution. Any questions feel free to contact me privately.

[ghost]

yes, it may "work", but that doesn't change the fact of anything I said in my original comment. its still relying in a binary blob dump, rather than a fully open source solution.

[SuisChan]

Well, if you can do it better than others, then go for it.

[iscle]

Also as I already mentioned, just decrypting the Widevine would be a better approach, one I have done several times with other websites.

Can you decrypt widevine with an open-source solution?

[SuisChan]

@SuisChan and I already have done better, by implementing the Shannon code, which is a fully open source solution, granted not using HTTP. Also as I already mentioned, just decrypting the Widevine would be a better approach, one I have done several times with other websites.

The TCP part has not been used in official applications for a long time (with some exceptions) and will probably be removed in the future as unnecessary. Although everything is working now, it does not mean that it will continue to be so.

About widevine, I definitely agree with you that this is a good, convenient and easily implemented option, but with a view as an open source project, this option is not very suitable due to the dependence in a private key, which will be immediately revoked by Google if it gets into the public space.

[ghost]

thats why you design an API in such a way that the private key is kept private, as I have done:

https://godocs.io/2a.pages.dev/mech/widevine#New_Module

and provide instruction to user where they can download a private key, or how to dump their own key. or you could even run a Widevine proxy, which some users are already doing, which keeps the private key private as well

[baltitenger]

Did anyone get further with this? @SuisChan do you perhaps still have the extracted code / could share what methods and tools you used to find it?

[jpochyla]

I was wondering if it'd be possible to use the same approach as the official Web Playback SDK (login through API key, WS communication), but handle the DRM playback through official means, like the FairPlay support in AVPlayer on Apple, some libwidevine on Linux, etc. What do you think?

[jpochyla]

Unfortunately WV and FP support only up to 256kbit streams in Spotify, doesn't seem like worth the work.

[3052]

OK according to this:

https://github.com/mIwr/SwiftySpot/blob/94a57db83e7fb4635fa9e64508ee62dcbd4a45be/Example/RhythmRider/Controller/PlaybackController.swift#L499

the obfuscatedKey appears to just be used as is. and the decryption seems to be normal AES-128-CTR:

https://github.com/p0rterB/YAD/blob/cbaa733f5bf569822bf62f88ead4f0d6435b7e04/Sources/YAD.swift#L15

has anyone tried this yet? seems too good to be true.

[SuisChan]

There's nothing new, just my old code wrapped in the Swift language

[3052]

yeah I see, sorry for the noise

[SuisChan]

It's okay, at least you're trying 👌

[baltitenger]

@SuisChan by the way, was this extracted from liborbit-jni-spotify.so of the android app?

[SuisChan]

Extracted and lifted, but there is a better way than this, maybe I'll write about it someday

[baltitenger]

@3052 I think in that code the aes part is just the file decryption, the important bit would be the unwrapKey function, seemingly implemented in c++ (decompiled) which might get taken down just like the previous guy's code.

[devgianlu]

@3052 This is correct, the decryption key is returned by the current shannon approach. For playplay they took that key and "obfuscated" it with an hardcoded key present in the client itself. Last guy that published the decompiled code was taken down, if, perhaps, the "obfuscation" scheme turns out to be a standard chiper and I think I'd be less of a problem, but maybe it's the hardcoded key that angers them.

[justfoolingaround]

It likely is some sort of standard cipher. The extracted C++ code simply takes the obfuscated_key and the file_id (as far as I can tell). Additionally there's a table that it uses internally that is supposedly associated with the "token" part sent to Spotify (token is likely an IV that derives that table?). So we're assuming a suite that takes at least 2 inputs other than the obfuscated key.

I think the said hardcoded key isn't quite the problem. The problem may be some sort of relation between that key and the internal table.

[baltitenger]

I think it's more likely that this is an asymmetric encryption scheme and what you're calling the internal table is the private key, the token sent to spotify is the public key. Also, as far as I can tell, the file id is only used near the end of the processData function, so I think it could be split so that the main decryption function only depends on the private key and the encrypted key returned by spotify.

[DevLARLEY]

Is this what you have to do decrypt the file?:

• Get the obfuscated_key from the request.
• De-obfuscate it using the program by SuisChan
• Decrypt it with AES-128 CTR, by using the de-obfuscated key as the IV and the file_id as the key

My problem is that the file_id isn't 16 bytes long (I'm guessing the safeFile.id is the file_id in bytes)

[DevLARLEY]

Already requested song keys aren't requested again, instead the endpoint GET https://gew4-spclient.spotify.com/playplay/v1/playable/<file_id> is queried without a request body or response.

[SuisChan]

fail to decrypt.\nCan anyone reproduce this?

This is true, unfortunately. The decryptor is not perfect, it can decrypt many keys, but some of them will fail

I have a workaround and it works with all tracks that I've tested so far and never had any problems with decryption

but that's a topic for another time, I don't plan to publish it yet because Spotify will still try to shutdown the repo like last time

Maybe the right time for release will be when lossless appears on the platform? 🤔

[DevLARLEY]

@3052 I'm gonna need a copy!

[justfoolingaround]

@DevLARLEY Hey, I just wanted to let you know that the reason that mpv or ffmpeg fails to play is probably due to the extra header Spotify adds. Try skipping 167 bytes from the start!

See: https://github.com/justfoolingaround/spotivents/blob/master/spotivents/streamer.py#L112

Also good luck on this! And if you do find a solution please notify me as well!

[DevLARLEY]

Thanks, @justfoolingaround!
All of my current spotify downloading knowledge can be found here: https://github.com/DevLARLEY/spotify-oggmp4-dl

[3052]

I found another decompilation here:

https://github.com/es3n1n/re-unplayplay/blob/master/src/lib/reversals/decrypt_key.cpp