Reverse Engineering the Soundcloud API | Hacker News Reader

Reverse Engineering the Soundcloud API

pythontips.com

116 pointspmoriarty25 comments

The only reason I continued to read was this:

> We will create a Python script which will allow us to download even those songs which are not enabled for downloading.

and then he goes on downloading the 128kbit/s web-player mp3... that was very disappointing.

It's like saying "How to download music from Spotify," where I'd expect you to use libspotify or the web API before reading the article, but suddenly I find myself reading about how I can record Spotify music with the "voice memo" app of my phone and a lot of time.

What's the difference between this and the info publicly available at https://developers.soundcloud.com/docs/api?

On a related note, the soundcloud API is horrible. Their solution to rate limiting is to require a client_id and then stop giving them out. So those few client_ids out there get abused by everyone (since they are simple to grab from locally running apps) and nobody can stream anything past a certain point in the day. Such a hack. But hell, at least they have something!

To use the APIs properly, you need to register an app to authenticate, whereas with this approach it's jacking a client ID generated for the Web-based client, it appears.

This approach is necessary because SoundCloud shut down its API app registration form about 9 months ago (around the time they made big layoffs) with no sign it'll open again. Even when registration was open it was just a Google form and people got rejected after waiting weeks for a response - https://twitter.com/JamesPaulDuncan/status/86719870256109158... - so I'm not surprised people are hacking around it.

I haven't seen SC respond to any of the numerous requests about this on Twitter either, so I suspect anything that doesn't directly make money at SoundCloud doesn't get attention anymore.

Reverse engineering the client ID generation would be more useful (maybe their web clients just grab from a pool, I have no idea).

Stack Overflow is full of questions regarding app registration and rate limiting. If writing audio service integrations, steer well clear of SoundCloud.

As someone who actually has audio content posted on SoundCloud, this line gives me pause for thought:

> We will create a Python script which will allow us to download even those songs which are not enabled for downloading.

What is the possible reason for making this achievable? For his next trick, will he post how to download any app from the Apple App Store for free too?

Do programmers only consider their own code sacrosanct, but anyone else's creative output free game?

Note: I make most of my content on SC downloadable anyway because I don't make money from my music, but the principle is still the same - I want the right to control whether my creative output can or cannot be downloaded.

It's not like anyone who wants to download music from soundbutt will be referring to this article and writing their own script. There are dozens of GUI tools and extensions that do exactly this already.

> I want the right to control whether my creative output can or cannot be downloaded.

Then you can't ever upload it online to a place where it can be streamed, ever. Or if you do you have to put audio "watermarks" over the track, and make sure you always have certain sections watermarked so no one can ever play a full "pure" version of your song. (Otherwise someone will just cut together 2 recordings with different spots watermarked).

This method doesn't download the high quality original file. Only the 128kbps compressed file that is used for streaming audio. No matter how much you lock down the website, browser, file format, even the OS.... A $2 pair of cables plugged into a recorder can accomplish the exact same thing and is impossible to counter.

Its basically impossible to make any media both availible on the internet and not availible for illegal/unethical distribution/collection.

The audio quality the code grabs isn't that good.

128kbit/s MP3 vs FLAC is why I buy stuff on Bandcamp instead of ripping it off Youtube (though I still have about 1.6k youtube videos from promotional music channels archived as mp3)

> Note: I make most of my content on SC downloadable anyway because I don't make money from my music, but the principle is still the same - I want the right to control whether my creative output can or cannot be downloaded.

So you want X and !X at the same time, enforced by the client?

First rule: don't trust the client.

Second rule: if you release something online, you lose control of it.

As a corollary of rule 2: accept that scarcity doesn't apply online with regards to digitized content.

Third rule: DRM doesn't work. Giving encrypted files along with the key to decrypt is pointless.

Fourth rule: Obfuscation only buys you time. It buys you even less time against a dedicated attacker.

But, it does take time to understand and wrap your head around these rules. And I know not everyone accepts them up front. Many try to think of ways around these things, using 'creative' ways (aka: logical fallacies).

>Do programmers only consider their own code sacrosanct, but anyone else's creative output free game?

I don't, and I share as much as I can after losing things a couple times.

It's important to keep in mind though that software is really fundamentally different than art: software is a liability and has to be maintained whereas a work of art is (usually) more or less created once. The models that support software development probably don't work well with art.

If you can listen to it, it can be downloaded into a file. If you can read it, it can be scraped. etc

> I want the right to control whether my creative output can or cannot be downloaded.

Then, your only solution is not to release it.

I think the larger point is that on a technical level, once you upload creative content to someone else's server (or even your own internet accessible server), you lose all ability to control where and how that is accessed. Again I'm speaking technically, not legally of course. You haven't lost the legal right to control your work but you will never have 100% technical ability so long as it's accessible online. Especially for music, which can simply be recorded and re-uploaded.

The easier approach:

https://github.com/rg3/youtube-dl

youtube-dl can download content from just about everywhere, including SoundCloud.

It's been a little while since I played with it, but I was wondering how the "private" soundcloud embeds worked. I was seeing musicians and music sites utilize them. The main difference with them is that you can't click on them to listen to the track on Soundcloud.com, you can only listen to them when they're embedded elsewhere.

Turns out, if you view the source on one of those embeds the full URL is right there. It's even called "permalink_url" and has the secret_token for the track as well, which is what lets you listen to private tracks directly on Soundcloud.com. The url structure is:

https://soundcloud.com/[user]/[track]/[secret_token]

If I recall correctly, the API also lets you look up some info on private tracks with that secret_token. Not sure if all of this was intentional, but I reported it back in 2016 via their "whitehat" channel and didn't receive any type of response back.

I just use youtube-dl[1], which downloads embedded Soundcloud media just fine.

[1] - https://rg3.github.com/youtube-dl/

Yeah, I wasn't interested in downloading the file really. I have a different tool I use for that. Was more just curious about how private the "private" songs really were, when shared in an embed.

TLDR: find how SoundCloud generates stream links by observing the browser’s Network tab (one request to an API endpoint with some data from the page’s HTML) and converting that to Python.

A good tutorial for beginners but I’m quite disappointed, I was expecting more complex things like actually reverse-engineering a DRM scheme.

Concerning a DRM scheme: why bother. Audio will be played anyway (the sole purpose of the site), so there is no win gained by implementing a restrictions management.

Nah, the worst SoundCloud has done in my experience is to blacklist an app I registered with them that called their undocumented APIs after watching what their apps called.

Fair enough, I guess it violates TOS but a bit annoying since public API is basically abandoned and lacks a lot of features.

You wouldn't have happened to have been using the api-v2?

Yes, I did :)

Can't remember why, I think some fields needed to stream in the same way as the app, or read some metadata, were only present on v2.

Same here. A cool trick but not exactly reverse engineering the API.

I don't think this qualifies as reverse engineering. The author merely saw how soundcloud streaming worked & automated it using python.

That qualifies as reverse engineering.

Reply on news.ycombinator.com