mirror of
https://github.com/DevLARLEY/spotify-oggmp4-dl.git
synced 2026-04-26 22:05:55 +03:00
[GH-ISSUE #6] Question regarding API #5
Labels
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/spotify-oggmp4-dl#5
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @oSumAtrIX on GitHub (Jul 16, 2025).
Original GitHub issue: https://github.com/DevLARLEY/spotify-oggmp4-dl/issues/6
Hi, this is a question regarding the code, specifically https://github.com/DevLARLEY/spotify-oggmp4-dl/blob/main/spotify.py#L554.
Is it known what this string of bytes is or where it comes from? What is the playplay API and where did you get the byte string?
@SuisChan commented on GitHub (Jul 16, 2025):
This string of bytes is essentially a hash or fingerprint of a unique public-private key pair used by the app. It is unique per os/arch/each build of the app, and is hardcoded directly inside the app [native].
The server uses this token to identify the specific key pair and encrypts a key using the matching private key. The app's decryption procedures(obfuscated) is tightly bound to the same key pair implied by the token, so you cannot simply swap tokens between app ver/builds, since corresponding decryption routines and keys will not match.
This design allows the server to ban or revoke access for a particular build/ver/arch without impacting others, providing fine control.
@oSumAtrIX commented on GitHub (Jul 16, 2025):
In my experiments, I swapped the token, and the app played streams just fine. This contradicts with what you said, can you clarify?
@SuisChan commented on GitHub (Jul 16, 2025):
Huh? One thing I'm sure of: it didn't work before.
What versions did you use? I'm interested to check if it really works differently now
@oSumAtrIX commented on GitHub (Jul 16, 2025):
The current Spotify version from PlayStore. Here's my situation:
I am currently creating iOS access tokens. However I noticed playplay requests return 403, assuming calls from Android differ from iOS. Replacing all headers to match that of iOS Spotify had no effect, only the body did. Here's the question:
Does Spotify backend match the token in the playplay body the to the version the access token was generated for?
@SuisChan commented on GitHub (Jul 16, 2025):
I just tried it, tried real tokens, as well as garbage, it plays a few seconds (up to 10), and then stops/repeats/skips, so it plays the heads-fa file, then nothing. Win/1.2.66/1.2.67
Idk, it can be. Since the client-token is included in each request, and it is derived from the request in which there is information about the client device. Using in a request the ios client-token had no effect at all?
@oSumAtrIX commented on GitHub (Jul 16, 2025):
If you just swap the token to one of iOS, android requests to playplay return 403. Keep in mind, Spotify dynamically blocks. For example if I https proxy the issue disappears. This is because of a tls fingerprint they do. If I use burp suite with a tls fingerprint spoof, the issue appears again, so whatever's going on, it's dynamic
@SuisChan commented on GitHub (Jul 16, 2025):
I also thought about it (tls fingerprint), but then everything would break much earlier, therefore I consider it a problem partly. What about trying different account? Cause they can just flag an account or something else
@oSumAtrIX commented on GitHub (Jul 16, 2025):
It's definitely A/B but the fingerprinting on TLS was seen couple months ago on my end
@oSumAtrIX commented on GitHub (Jul 16, 2025):
Different accounts yield different results