Protecting audio assets with JavaScript and Web Audio API

In our previous post we looked at protecting audio assets for playback on a client's browser using the HTML5 <audio> tag. The downside is that the underlying audio track can still easily be downloaded by simply using the attribute src location. In this post we'll be looking at an alternative strategy.

Another modern but lesser known method for playing sound is the Web Audio API, it's supported by all modern browsers (except IE, of course). The API is very rich with interesting features such as multi-playback, sound generators, transformations and more. But also the ability to play sound from binary data such as an arraybuffer, which is very interesting for our purpose.

From the server-side perspective we don't need to change any of our code from our previous post.

The client-side changes just a little bit:

let source = null;
let oReq = new XMLHttpRequest();
oReq.open("GET", 'http://localhost:3007/audio', true)
oReq.responseType = "arraybuffer"

oReq.onload = function(oEvent) {
  webapi()
};
oReq.send()

async function webapi() {
  // obtain and decrypt the audio data
  const arr = oReq.response
  let byteArray = new Uint8Array(arr)
  let key = byteArray[byteArray.length - 1] 
  byteArray = byteArray.map(x => x ^ key).map(x => ~x)
  byteArray[0] = key

  // Web Audio API
  // use the decrypted audio data as input
  const context = new AudioContext();
  const buffer = await context.decodeAudioData(byteArray.buffer)
  source = context.createBufferSource()
  source.buffer = buffer
  source.connect(context.destination)
}

// use 'source.start()' in some click event

The advantage of this method is that we no longer leave a footprint for the user to easily download the audio data from. In other words, we no longer have a <audio> tag whose src value can be copied/downloaded.

To steal the audio contents the hacker/pirate is left with three choices:

1. Figure out how to decrypt the audio.
2. Export the arraybuffer's contents.
3. Record the audio while it's playing.

There may be more advanced methods of course, but it does raise the bar pretty high for most novice amateurs to steal your content.

The downside is that the Web Audio API isn't perfect yet, playing mp3 formats doesn't always seem to work in Firefox for me, but it does in Chrome. It throws the following exception:
Uncaught (in promise) DOMException: The buffer passed to decodeAudioData contains an unknown content type.
I haven't tested other formats such as ogg and wav, but I do recall that ogg doesn't work in Safari. Maybe wav is the best of all three?

Final words

To maximize this protection technique we have to make static analysis as hard as possible.

First, make sure to always obfuscate and minify your JavaScript code, which is always recommended for both security and performance reasons.

Second, try to make the encryption/decryption code as complex-looking as possible, yet keep it highly performant. If a hacker uses Node/JS they can just copy paste the function, but a lot of amateur hackers may use non-JavaScript code like Python/Java/C# for writing their bot/scraper/downloader. Having a complex-looking decryption function will force them to fully understand and having to translate it into their language of choice, which may not be so trivial (unless using a translation tool).

Comments

[Raffael Zica]

And then after all this effort the pirate just records the audio file from his sound card per loopback. Isn't as fast as straightforward as downloading the song but also not as hard as cracking encryption.

[Ilya Nevolin]

That's mentioned in the article as well, no way of stopping that. But the goal is to prevent people from building scrapers/bots, which are as destructive as individual piracy acts.