Question

Folks. I trust that the community will see this as a relevant question. My apologies if not and mods, please close.

I am developing a video playback app with static content for a customer. My customer wants me to implement some basic security to stop someone unpacking the deployed app (it’s for Android) and simply copying the MPEGs. My customer has made basic protection a critical requirement and, he’s paying the bills 🙂

The files are too big to decrpyt on the fly so I’m considering the following approach. I’d welcome thoughts and suggestions as to alternatives. I am aware of the arguments for and against copy protection schemes and security through obscurity, which my proposed approach uses and my question is not “should I?”.

Take a block of bytes, say 256, from somewhere in the header of the MPG. Replace those bytes with random values such that the MPEG won’t play without a lot of effort to repair it. Store the original 256 bytes in one of the apps bitmaps such that the bitmap still displays properly. When playing the video, read it in through a byte stream and replace the bytes with their original values before passing them to the output stream.

In summary:

1. Extract 256 bytes from the header of the MPEG
2. Store these bytes in a bitmap
3. Randomise values in the original bytes
4. At run time, read the 256 bytes back out of the bitmap
5. Read MPEG through an inputstream using a byte array buffer
6. Replace randomised bytes with the original values
7. Stream the input to an outputstream which is the input to the video player.

I do recognise at least 2 ways to defeat this, reverse engineering and screen grabbing but the point is to prevent the average thief simply copying my customers content with no effort.

Thoughts folks?

Thanks

Answer 1

I would suggest using an encryption/decryption scheme for the entire stream:

1. Real time video stream decryption is the standard way to deal with this issue. Its processing overhead is negligible when compared to the actual video decoding. For example, each and every single DVD player out there supports the CSS encryption scheme.

   While using Java does impose some restrictions, such as the inability to make effective use of various CPU-specific instructions, you should be able to find a decryption algorithm that is not very expensive. I would suggest profiling your application before rejecting stream encryption algorithms out of hand.

2. Mangling the header does make some video files hard to read, but far from impossible. Some files have redundant information, others are actually the result of straight-out concatenation which would leave any following segments readable. Some streaming video codecs actually insert enough metadata to rebuild the stream every few seconds. And there are a lot of video formats out there.

   In other words there is no way to guarantee that removing any number of bytes from the start of a file would make it unreadable. I also think that imposing on your client a bunch of restrictions w.r.t. the video formats that they can use is not reasonable and limits the future usefulness of your application.