I had some work where I needed to secure streaming. So I looked over all DRM protections that are currently available, and then I found out that I had 3 opinions, first to use very expensive DRM (Adobe) that would cost fortune, second one was to use some cheap one which require installation of some bad quality plugins and doesn't have support for all browsers and third one was to use AES-128 encription which is not really DRM, but can handle some things. Then I start thinking, and here is what I did.

I created streaming server that will: Create separate key for EVERY chunk in EVERY session, that means that key never repeats. chunks are relatively small 1chunk per 3 seconds. then I encoded key by base64 and got 24 bytes that were exactly 192 bits which is same length as AES-192, After that I shifted every byte for specific number of spaces, for each character different shift and replaced padding of 64 with some random chars. As a result I got unrecognizable base64 which looks like random key. Then after that I did reverse in the flash player. and as a result I got player working pretty good. And changed player to fake aes 192 by m3u8 playlist information.

So basically site is intended for small language group of people (around 12mil) and generally doesn't have very valuable content (videos that are valuable for students). Now What do you think, what is possibility for someone to find out what is goung on and how to decrypt (basically i believe they will try to decode first as AES-192 because of key length and m3u8 info)? Do you thinkthis is enough secure for low budget in low salary country?

2 Answers 2


Let's get this out of the way first: DRM is not a solvable problem.

Simply loading the flash player into a reverse engineering tool and reading the code will reveal what you did, and since you're giving them the key they can just decrypt the video. It's something anyone familiar with Flash reverse engineering could do, and it's probably something you could pick up from Google if you've got a background in general code and security concepts.

If you're looking for something more solid, you could look into solutions which use HDCP, which essentially provides end-to-end encryption of content up to the actual display device (e.g. a computer monitor). However, this may limit your userbase, as the HDCP feature was designed primarily for use in devices like BluRay players where TVs are known to support HDCP, rather than cases like computer monitors which may not (though many do).

All in all, you just have to decide how much effort you want to put in as a deterrant. If someone wants your video, they can capture it just fine using a screen capture application (e.g. Fraps) or exploit the analog hole.

  • HDCP and any other DRM raise expenses above earnings, and not worth for my problem. Either way, this is not really big market and videos as videos are not really worth that much as it's interactive video site,not just videos. What I wanted is to drop number of people that can solve such problem without hassle.As when y2be just changed their way of serving stream (they didn't encrypted anything),y2be downloads fell on much lower number than it was before, since all online services for downloading y2be videos didn't worked. This is not really solution for all the times, but rather for some time. Commented Jun 9, 2015 at 15:46

This is a "security by obscurity" design which is wrong because it's based on secrecy of protocol rather than secrecy of an encryption key. As long as there is a motivation to dump the stream, someone (especially students) will break this. On the other hand, if there is no motivation to dump the stream, there is no reason for DRM.

Personally, I think DRM is a bad idea and is never going to work the way it is supposed to (i.e. prevent piracy). In all cases I came across clients either don't care for DRM since it isn't bothering them or they find their way to non-drm content (paid or otherwise) since they don't want to be bothered by restrictions imposed by DRM (like installing Silverlight or such). In either case, piracy is not prevented - the first group isn't going to pirate while the other one may, if the content is not available easily for a reasonable price without DRM.

Security-wise speaking - a DRM only works if the entire chain is secured, therefore all of your 12mil clients would need a DRM-enabled devices, OSes, browsers, graphics cards and displays and you need to pay for DRM to someone who can guarantee the integrity of its data throughout this chain. Anything less isn't a DRM.

  • I know anyone knows not only Flash, but programming can do reverse engineering, but as said, there is no big effort in doing that, except for someones else fun. What I wanted to prevent is that anyone can use extensions, various apps and similar that downloads video, and to make it a bit harder to understand what is going on, that's why I did "Fake" AES-192, because generally I would probably give up at the point where I try to convert AES-192 and it dont work. It would be more obscurity through minority since target is 12mil, it's not actual number of clients. Commented Jun 9, 2015 at 15:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .