Copy Protection

[Pete Bentley]

At Tue, 04 Sep 2001 18:53:46 BST, "Nexus" writes:
>----- Original Message -----
>From: "Pete Bentley" <pete@sorted.org>
>> If the instructions to read the CPU ID register(s) are unprivileged
>> (ie can be executed directly by user mode code), then the OS has very
>> little say in the matter.  It's only where the system ID is stored in
>> a seperate piece of hardware (eg the Sun IDPRAM) where access is
>> mediated through a driver in the OS.
>
>I don't care about privs, that's not the point, sorry, let me clarify.
>Regardless of what privs a program requires, it has to interact via the OS -
>it will need API calls, kernel modules, system libraries.. whatever.   These
>factors can be controlled by the owner of the system.   If I write a
>modified "passthrough" library then the software will never know that it is
>being fooled as it has to "trust" the system files as it were - if it uses
>it's own routines then they will probably hook into the system in a specific
>way (probably an interrupt) and will be easy to find.

Perhaps I am being stupid and/or naive here... Let's leave aside any
RSA issues for a second (making us drift even further off topic,
sorry) and take an imaginary extension to the instruction set of a
CPU.  We add just one instruction, which copies the CPU's 32[*] bit
unique ID to a register. The instruction is unprivileged, so *any*
user program can execute this instruction without the OS having a
chance to intervene. 

As a copy protection programmer we use this instruction to implement a
trivial (naive, stupid) copy protection subroutine in a program for
this CPU as follows (pseudocode):-

  begin {
    load-cpu-id-into-register-a      ; The instruction I just dreamed up
    load authorised-id into register b
                                     ; authorised-id is a static
                                     ; location that was 'branded' when
                                     ; the program was downloaded & installed
    if( register-a != register-b ) {
      call standard-program-exit function
      ; or halt-and-catch-fire
    }
  }

Now, the only point this program interacts with the OS is by calling
the standard-program-exit function (eg exit() in C)...So I assert that
there is no way to circumvent this copy protection simply by
subverting the OS[**], or the C library etc etc.  Granted it is
trivial to circumvent by disassembling and patching the application
binary, but a real world example of this would use obfuscation to make
that much harder.


>> >From my experience in past lives as a software developer, I'd say that
>> a good proportion of them suffer from many holes.  However, your
>> average end user is not going to jump in with a disassembler to find
>> the holes.
>
>True, but if your business is breaking copyright protection then you will
>have the people with the necessary skills to circumvent or remove the
>protection - software pirates could do this and then distribute either
>cracked versions or a key generator.

Agreed.  But most people are not in the business of breaking copyright
protection... And the professionals will always find a way to break it
(if you can load it into memory and run it, then you can copy
it... Well, unless they really do figure out a means to encrypt a
binary such that only a single CPU can run it).

Pete.
[*] Keeping things simple
[**] Unless, of course, the architecture allows the OS to disable
certain instructions, or make them cause some kind of processor trap.