Digital archaeology of the microcomputer, 1974-1994

Ethan Dicks ethan.dicks at gmail.com
Wed Jan 17 15:47:51 CST 2007


On 1/17/07, Richard <legalize at xmission.com> wrote:
> As with most things, the amount of work done to protect an application
> is directly in response to the perceived threat.  Yeah, some people
> may have gone overboard, but I know in the flexlm licensed 3DPaint
> application I worked on it was a simple license check at the start of
> the app.  Patch up to jump over the check and you're done.  I suspect
> that most software is like this -- find the one place where it polls
> the dongle and jump over that code.

That technique was common with the C-64... typically there were bad
tracks intentionally written to the distribution floppy - in part of
the app startup or perhaps the loader (small program that knew how to
get the rest of the app into memory), some subroutine would be called
that would check a normally unaccessed part of the disk and check the
drive error code against what was expected, then either allow the
program to run or not.  There were techniques for simple utilities to
write any useful error pattern to the disk except perhaps one or two
tricky ones, permitting a working copy of a protected floppy, but all
of that is irrelevant when you run into a copy protection subroutine
that, rather than returning success or failure, is easy to identify
because "success" is returning at all and failure is calling the C-64
ROM reset routine... the memory clears on the next start cycle,
"protecting" the memory from post-mortem (they think).  Once you have
identified that style of routine, it's easy to either patch over the
JSR to the protection routine, or to just stick an RTS at the front of
the routine.  Since there's a known ROM address in the code, it's also
not hard to find the copy protection routine in the first place.



More information about the cctech mailing list