Copy Protection

[Mike Brodbelt]

Pete Bentley wrote:
> 

<snip>
 
> 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.

<snip>
 
> 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.

I'm of the opinion that you're assertion is wrong, and demonstrably so.
Take the example of the Pentium F0 0F bug. There was an almost identical
situation - any user mode program could execute these two bytes of code,
and bring an affected CPU to an immediate halt state. Sample programs to
do this did indeed bring your machine to a screeching halt, regardless
of operating system. However, when the bug was discovered, it did not
take long for a fix to make its way into the Linux kernel, which
prevented the crash, and logged the attempt.

Now, my understanding of the low level detail of x86 hardware is
insuffiently good to be certain, but I believe that a protected mode OS
has almost complete control over the instructions executed by a child
process, and can mess with it to it's hearts content. You said:-

> the only point this program interacts with the OS is by calling
> the standard-program-exit function (eg exit() in C)

but I believe that you actually mean the C library here, and not the OS.
The OS is responsible for setting up virtual address space for the child
process's code and data, and as such, has pretty much complete control
over the execution environment, down to the ability to inspect each
instruction before execution, if it so wishes.

I confess to being less than completely certain about this, but I'm sure
someone here has a better understanding of the hardware than I.

HTH,

Mike.