[HN Gopher] SpotifyKeyDumper - Dump song decryption keys from th...
___________________________________________________________________
SpotifyKeyDumper - Dump song decryption keys from the Windows
Spotify client
Author : ffpip
Score : 187 points
Date : 2020-11-07 18:30 UTC (4 hours ago)
(HTM) web link (gitlab.com)
(TXT) w3m dump (gitlab.com)
| speedgoose wrote:
| Does Spotify use the same AES key for all songs?
|
| Deezer is doing weird stuff in comparison. A friend told me that
| each song has every third block of 2048 bytes encrypted using
| blowfish. The key is derived from the hex md5 of the song ID, xor
| the same hex md5 but with a Ceasar cipher shift of 16, xor a
| hard-coded secret. The initialization vector is 0,1,2,3,4,5,6,7.
| mimimi31 wrote:
| Deezer's encryption has been reverse engineered a few years ago
| and given rise to lots of scripts for ripping music from the
| platform. Interestingly it's even possible to download and
| decrypt lossless files like that without having the
| subscription you'd normally need to access the higher quality
| audio.
| drannex wrote:
| Even more interesting on Deezer - Deezer Has a New Message
| for App Pirates -- 'We're Not Going to Stop You'
| https://www.digitalmusicnews.com/2020/10/26/deezer-pirate-
| ap...
| jrz53 wrote:
| Looks like they pretty much care after all: https://fuwafuw
| a.moe/transparency/git.fuwafuwa.moe/001.2020-...
| lucgommans wrote:
| Grooveshark's was a beauty as well: xor 0x25
|
| Wrote a blog post about it back in the day, for those
| wondering how to break (super easy) encryption:
| https://lgms.nl/blog-1-plain
| bootloop wrote:
| Most likely its a single key per song.
| Etheryte wrote:
| A classic example of stacking algorithms in a way that provides
| no additional benefit whatsoever. In many cases, stacking
| encryption algorithms actually weakens the resulting security.
| smhmd wrote:
| > In many cases, stacking encryption algorithms actually
| weakens the resulting security.
|
| Could you, please, explain how?
| n3k5 wrote:
| Imagine you have a couple of algorithms that scramble a
| solved Rubik's cube into a configuration that takes at
| least 20 twists to unscramble [0]. From there, any attempt
| to make it 'even more scrambled' would be pointless -- and
| actually likely make solving the resulting puzzle easier.
|
| Now imagine there's a programmer who wants to make the
| ultimate cube scrambler despite not knowing any of the
| above. Their brilliant idea is to take the aforementioned
| algorithms and chain them together. (Result: snafu.)
|
| In essence, the moral of the story is that one shouldn't
| try stacking encryption algorithms without first acquiring
| a pretty good understanding of how they all work.
|
| [0] https://www.popsci.com/science/article/2010-08/gods-
| number-r...
| soared wrote:
| If I'm following this logic correctly - running a few
| more algorithms on something before trying to decrypt
| will make it easier rather than harder to decrypt?
|
| Is the ceiling for "max encryption" that low, or is just
| that one algorithm combined with another has a local
| maximum?
| MauranKilom wrote:
| Very basic example: ROT13 is a form of encryption. Applying
| ROT13 twice gives you plaintext.
|
| It's of course not that trivial with better encryption
| algorithms. But before stacking encryption algorithms, try
| to first answer what you are trying to achieve (that
| application of a single algorithm does not).
| hatsunearu wrote:
| what the fuck
| gruez wrote:
| What happens after you dump the key? Is there a corresponding
| tool to download and decrypt the tracks?
| clashmeifyoucan wrote:
| I think you need to intercept the network request then decrypt
| it using the key.1 Can be automated I guess, not sure if
| someone has done that yet however.
|
| [1]: https://gitlab.com/fuck-
| capitalism/spotifykeydumper/-/releas...
| bootloop wrote:
| I would imaging the cached files work too.
| m00dy wrote:
| the key is for AES cipher which is a block cipher. So, I think
| the tracks should already be in filesystem.
| tbrockman wrote:
| Not quite as user-friendly with regards to exposing the keys, but
| if you're interested in learning Rust you can check out the
| reverse-engineered protocol and access already decrypted audio
| streams using librespot: https://github.com/librespot-
| org/librespot
| [deleted]
| steve_mcdougall wrote:
| heejin stans unite
| ianlevesque wrote:
| Who cares at this point? You can buy DRM-free tracks from iTunes
| and multiple other providers now. It's not 1999 anymore.
| gitweb wrote:
| Big difference between paying for a song or album vs
| downloading unlimited DRM-free music for a small subscription
| fee.
| [deleted]
| roboyoshi wrote:
| spotify has exclusive content and I'm especially angry they
| make certain podcasts exclusive to their platform. itunes and
| bandcamp are good though when you want drm-free music.
| sdfhbdf wrote:
| Interesting project although the drawback seems to be that the
| maintenance is pretty high since it uses the hardcoded memory
| addresses to dump the key for each Spotify version. I understand
| it requires from the maintainer after each update, which are
| frequent since Spotify has a well-developed Continuos Delivery
| [0], to reverse engineer the memory address and commit it to this
| repo.
|
| [0]: https://www.youtube.com/watch?v=5Ycb7jlZGkU
| hyperdimension wrote:
| If _three tests_ from youtube-dl got the RIAA angry, I can 't
| imagine this will be up for long.
|
| EDIT: didn't notice it was gitlab rather than github. I'm still
| rather interested.
| hedora wrote:
| I don't think the RIAA can touch this.
|
| After all, fuck-capitalism added this prominent disclaimer:
|
| > _This program was created for educational purposes. It is not
| intended to be used otherwise_
|
| /sarcasm
|
| Pro-tip: Intent matters to the courts. Intent is really hard to
| show, since the prosecution has to prove the internal state of
| your mind when you did the thing.
|
| Focus on plausible deniability when you do this sort of thing.
| I, for one, still own a Cowon iAudio, and can't wait to format
| shift my legitimate subscription to it so I can use my high-end
| wired headphones.
| stu2b50 wrote:
| I don't think gitlab* vs github matters. All public sites in
| the US and allies need to have a mechanism for DMCA removals,
| or they lose their safe haven status (which allows them to not
| be legally liable for what their users do with respect to
| copyright). Losing safe haven status is a death sentence.
|
| * by this I mean gitlab's own instance of gitlab. Of course,
| you can host your own, and then its up to you how you respond.
| martini333 wrote:
| But this was "created for educational purposes"
| stu2b50 wrote:
| DMCAs are a shoot first, talk later kind of deal. Or rather
| take it down first, file counterclaims, and see if the
| other party responds, then put it back up they don't.
| vmception wrote:
| Just clone it and move on
|
| DMCA take downs don't delete stuff stored client side on your
| computer, I fail to see what all this discussion is even
| about
|
| If it looks hot, just clone it and forget about it
| andrepew wrote:
| IANAL but doesn't the DMCA takedown system only apply to
| distribution of content itself? No RIAA member has the
| ownership rights to this software. It probably is illegal but
| I believe another legal mechanism other than a takedown
| notice is required.
|
| Someone correct me if I'm wrong. This is a layman's
| understanding.
| stu2b50 wrote:
| There's also a provision in the DMCA law about
| "circumventing copyright law"
|
| https://www.law.cornell.edu/uscode/text/17/1201
|
| Which you could argue this falls into.
| andrepew wrote:
| Yes the DMCA prohibits circumvention but I'm asking if a
| takedown notice is the correct legal remedy for such
| violations? I thought notices were just for content
| distribution.
___________________________________________________________________
(page generated 2020-11-07 23:00 UTC)