Are there DRM techniques to effectively prevent pirating?

Firstly, I think the skeptics answer pretty much covers it: DRM annoys people. Some of us actively avoid purchasing anything with it.

In terms of software, this is pretty much impossible. One DRM scheme might be to use public key encryption with content encrypted with symmetric keys (performance of symmetric ciphers being vastly superior to most pk ones). You encrypt the content key with the private key and the software can then decrypt that key with the public key, and decrypt the content.

Which works, except that I'm just going to step your program through a debugger or disassemble your code until I find your key, decrypt your content and the game's up. Crypto is for transmission over insecure networks, not for decrypting securely and in isolation on hostile systems.

So, you could send lots of different keys over the internet for different parts of the content. Well, your paying customers are likely to experience problems with this, but, I can just automate the debugging process, or hook your receive events, or whatever. Either way, I can grab those keys. It isn't easy, but it can be done.

So the next stage is to prevent me using my debugger or hooking your system calls in some way, which is where you start writing rootkits. As it happens, I can take the disk offline and examine/disable your rootkit, or modify it so your software believes it is secure. In fact, this will make it easier for me to identify what you're protecting.

There is another case, one where the OS is complicit and provides some form of secure container. If it is possible for me to load code into ring 0, this security becomes irrelevant. If not, if I can clone your microkernel core and modify it to allow me to load code into ring 0, this security becomes irrelevant again.

At this point you have to start using hardware controls. Simply put, since I can modify the operating system any way I please, you probably need hardware-implemented DRM that I have no chance of modifying or reading. You'd need your crypto to happen on-hardware such that it is impossible to read the decrypted data from the operating system. You'd need the public key I mentioned above to reside on that hardware, not on the OS.

At this point, you've probably defeated me personally, but I am sure there are people capable of modifying their HDMI cables (or whatever) to split the data out onto the display and to another device such as storage.

Also, how you store your keys securely on your device is going to be an issue. You'd need to encrypt them! Otherwise, I'm just going to attach your storage device to an offline system. And store the keys... wait... see the pattern?

Once you have physical access, the game is up.

I don't think DRM is technically possible. Whatever methods you employ, there will always be someone with sufficient skill to undo it, since at some level that protected content must be decrypted for their viewing. Whether they have the motivation to is another matter.

From a software engineering perspective, getting it right, whilst not disrupting your users, allowing them to easily move their content to authorised devices, supporting new devices... all nightmares. Who's going to buy your content, when you haven't got Windows 8 support ready for launch? Does your content work on my Windows XP box too? What do you mean you don't support it?! If you use hardware, you have a deployment issue.

Finally, DRM is just deeply unpopular.

DRM works pretty well for anything that you do not hand out to the users. Let's take Second Life as example.

Second life is an 3d online game in which avatars are rather simple on their own in the sense that they cannot do anything beside moving around and using objects. Objects consists of a shape and texture, and they may contain scripts. Those scripts can do all kinds of things, including animating the avatar.

Anything, that is sent to the client, can be copied because the attacker can manipulate the client. Nowadays it is open source, but this already happened using decompilers and debuggers in the past before it was released as open source. Computers are copy machines, copying things from network card to memory, from memory to CPU or GPU are core functionalities.

So the shape and texture of objects, animations applied to avatars cannot be protected. The scripts, however, are only executed on the server. Therefore the client never sees them, unless it got extra permissions. They only way to copy scripts (either on their own or by copying the outer object) is to use the functions provided by the server. And of course they check whether the user has copy permissions for the scripts.

More information on the specific case of Second Life is available in the CopyBot article in their Wiki.

Great answer by ninefingers. Referring to one particular point:

I am sure there are people capable of modifying their HDMI cables (or whatever) to split the data out onto the display and to another device such as storage.

It can be even simpler than that! What about putting a camera in front of the screen and recording it? It might not be the best quality defeat of DRM, but it does defeat DRM.

There's always going to be some data (music, film, book) being emitted from a device and perceived by our eyes and brains. Until they plant DRM decoders inside our brains, there's always a chance to intercept that emission and copy it.