1994-11-26 - Re: JPR1: PC MSDOS hardware key

Header Data

From: jamesd@netcom.com (James A. Donald)
To: jp@pitsa.pld.ttu.ee (Jyri Poldre)
Message Hash: 0dd8d4df1de073f565bbc428a35a650fcf0743f54c46c802d1ee0f2b2bb84daf
Message ID: <199411261832.KAA28290@netcom13.netcom.com>
Reply To: <Pine.3.07.9411261643.A5759-b100000@pitsa.pld.ttu.ee>
UTC Datetime: 1994-11-26 18:33:41 UTC
Raw Date: Sat, 26 Nov 94 10:33:41 PST

Raw message

From: jamesd@netcom.com (James A. Donald)
Date: Sat, 26 Nov 94 10:33:41 PST
To: jp@pitsa.pld.ttu.ee (Jyri Poldre)
Subject: Re: JPR1: PC MSDOS hardware key
In-Reply-To: <Pine.3.07.9411261643.A5759-b100000@pitsa.pld.ttu.ee>
Message-ID: <199411261832.KAA28290@netcom13.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Jyri Poldre writes
> It seems to me, that the problem lies in the function of HW key in
> program. If it is used in "check the existance" way then you can easily
> remove the checks from binary code. And it does not matter what is the
> essence of checking- You will always have 
> CMP KNOWN_DATA, HW_KEY RESPONSE. 

"Check the existence" is only used by amateurs.

A typical gimmick, one that I wrote, is get information from the
hardware, mangle it, put it on the stack, and execute it.   And
there are loads of tricks like that that can seriously obfuscate 
code.

No software protection scheme is unbreakable, but it is easy
to make a protection scheme that is not worth breaking. 

Of course the inconvenience to the user may well be such that
it is not worth protecting, either.



-- 
 ---------------------------------------------------------------------
We have the right to defend ourselves and our
property, because of the kind of animals that we        James A. Donald
are.  True law derives from this right, not from
the arbitrary power of the omnipotent state.            jamesd@acm.org





Thread