I've been doing some research into some DRM solutions, specifically "self-protecting containers". One example of this is DigiBox. Normally, the protected data is encrypted in some kind of container. However, once the data is in use, it is decrypted in memory. What is stopping me from copying that data from memory and into another file on the harddisk?

For example, if I had some sort of Word document that is protected. Can't I click save-as? Or does some DRM solutions work with Word to stop this?

  • 1
    DigiBox seems to be a very antiquated format - the only references I can find to it on Google are from around the year 2000. Am I correct on this?
    – Nic Barker
    Commented Aug 28, 2015 at 3:24
  • 1
    Yes, it is a very antiquated format. However, it has been cited many times.
    – mrQWERTY
    Commented Aug 28, 2015 at 3:25
  • 1
    Relevant: security.stackexchange.com/questions/4637/… Commented Aug 28, 2015 at 6:50
  • 49
    DRM doesn't stop copying. Never has, never will, never can. Period. All it does is slow it down for a little while until someone cracks it. The fundamental principle of cryptography can be phrased as "Alice wants to send a message to Bob without Charlie being able to read it, even if it falls into his hands." The problem with DRM is that Bob and Charlie are the same person. Commented Aug 28, 2015 at 14:08
  • 1
    Well, either Alice should stop hiding things from Charlie, or Charlie should stop trying to steal from himself, er, Bob!
    – user82913
    Commented Aug 28, 2015 at 14:21

3 Answers 3


According to the E-book A survey of complex object technologies for digital libraries, DigiBox seems to be a container format that can contain different file types (although it was mostly used for PDFs). The basic concepts here are:

  • The file is encrypted in a way that it's relatively difficult to read without special software (i.e you can't just read these PDFs with any PDF reader, it has to be "DigiBox complient reader software")

  • The special software then goes to some lengths to prevent you from saving a copy of the file in a non DigiBox format, although you're right - it's not really feasible to protect the contents from being dumped out of memory by a seasoned professional.

For example, if I had some sort of Word document that is protected. Can't I click save-as? Or does some DRM solutions work with Word to stop this?

You're right - the software that you're using to read the file needs to be complicit in the enforcement of DRM.

I think the main point here is not to make it impossible to break the DRM on the file, but to make it so difficult that the average (read: not technically skilled) person would rather just pay for it.

  • 6
    While it certainly is possible, all you need to do in that situation is then dump the memory for the VM itself. It's a losing game shipping files / code out to remote clients and trying to protect the files once they're on a remote system.
    – Nic Barker
    Commented Aug 28, 2015 at 3:37
  • 2
    See my comment - it's not about absolute technological effectiveness but about constructing a barrier that you can be prosecuted for crossing or supplying tools to cross.
    – pjc50
    Commented Aug 28, 2015 at 11:42
  • 1
    For perspective on the limits of DRM, consider the smart cards we use for credit card purchases. In theory, the chip contains a secret that nobody can know unless they're holding onto that physical chip. In reality, individuals in possession of highly valuable cards have been known to literally mill the surface of the card to get access to the raw chip, and physically attach sensors to read the secret right off the transistors. You can never prevent someone from using information they hold, only make it very difficult for them to do so.
    – Cort Ammon
    Commented Aug 28, 2015 at 20:38
  • 1
    @CortAmmon Smart cards have another advantage. With a smart card, it's nearly impossible to steal the key without the owner of the device knowing.
    – Patrick M
    Commented Aug 28, 2015 at 22:02
  • 2
    Yeah, it's DRM is a very fascinating game where constantly losing still makes you win. All that matters is when it's hard enough and enough of an bother for the large majority to not try. Additionally with proper very specialized hardware-based self destruct behaviour you could theoretically get quite far. Commented Aug 28, 2015 at 23:24

For digital restriction management to be effective, it needs to be a sealed hardware implementation the user can not tamper with without destroying the hardware (like a TPM).

Software-based DRM implementations can only work on the user-interface level. A compliant software will just not show the user interface elements necessary to perform the restricted actions. So what stops the user from using a non-compliant software which doesn't respect the restrictions? Technically, nothing. But there might be legal barriers like copyrights, trademarks, anti-reverse-engineering laws and software patents which prevent such a software from being distributed.

  • Technically? The same that stops you from reverse engineering hardware based DRM, encryption.
    – Taemyr
    Commented Aug 28, 2015 at 10:15
  • 9
    @Taemyr You can't encrypt software in a way that it can still be executed.
    – Philipp
    Commented Aug 28, 2015 at 10:45
  • 1
    Citation? The strongest claim I would agree to would be something like; you can't encrypt software in a way that would allow it to be executed unmodified directly by the hardware. I see no technical reason that prevents an interpreted language to be decrypted by the VM. However this is a side track, DRM protects more than just code. The serious challenge is that you have to provide the key in order to acces encrypted content. But this holds for hardware based DRM as well.
    – Taemyr
    Commented Aug 28, 2015 at 10:54
  • 4
    @Taemyr the issue is that anything that an x86 processor ultimately executes can be seen/inspected by an administrator user with the right skills. You can see the instructions going in and the data they operate on. So the VM is decrypting stuff, but what's executing the VM? An x86 CPU with all its internals exposed.
    – RomanSt
    Commented Aug 28, 2015 at 15:23
  • 1
    @cybermonkey In my opinion, both expansions are valid. The former was introduced by publishers and those who sell DRM tools to publishers. The latter was introduced by the FSF to explain the effect of DRM from the user's perspective as opposed to the publisher's. Commented Aug 29, 2015 at 15:57

DRM is part of an attack on copying through the legal system, specifically the DMCA: https://www.law.cornell.edu/uscode/text/17/1201 and equivalent EU legislation (copyright directive).

It provides "a technological measure that effectively controls access to a work". This will come with some approved software for accessing the work which presumably verifies licenses, payment, machine ID, etc. It is then illegal to modify or exploit that software to circumvent the copy protection, AND it is illegal to write or distribute software that circumvents it.

This has obviously given rise to concern, because (for example) if you attach a debugger to DRM software in order to extract copyrighted material, you have committed a crime. And if you write e.g. an open source video driver that doesn't enforce the DRM and it is discovered that people are using it to pirate video, that may also result in liability.

  • So while DRM is impossible to implement, it does cause you to infringe DMCA. Thus allowing a criminal prosecution. Commented Apr 11, 2017 at 22:15

You must log in to answer this question.

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