C O U N T E R	fravia's anonymity pages COUNTER INTELLIGENCE "Intercepting clever protectors' plans" Fravia's Nofrill Web design (1998)		updated September 1998 Ported to searchlore March 2000	Fravia's Anonymity Academy Every web step leaves traces ~ We'll always find what we want :-) The final equality check (John Wigley & Mark Rosen ~ March 1997) [John2Marc] ~ [Marc2John] The Economics of Piracy (Brandon Van Every & Russ Williams ~ September 1998) [First part] ~ [Second part] ~ [Third part]

Command: GET "03_1997&1379792"
Subject:  Re: Registration Algorithm
From: [email protected] (John Wigley)
Date:  6 Mar 1997 21:24:17 GMT
Message-ID:  <[email protected]>
Organization:  University of Southampton
Newsgroups:  sci.crypt
References: <01bc245a$5a5b9820$43c866ce@markdsk>


Mark,
	Unless there is something that I'm missing, the potential hacker,
simply traces his way through the software until the final equality check
is made and then patches the check function to always return true.
This is almost universally the way that cracks are done nowadays, and all
your system seems to prevent from a crackers point of view is the writing
of a key maker program.

	I see little point in implementing complex crypto authentication
systems for product registration when all that will happen is that they
get bypassed.

	If you need this level of security for your product registration
then I think you should allocate at least as much (probably much more) R&D
expenditure to making sure that it won't get bypassed in 5 minutes with
SOFTICE. This could involve all sorts of things from encryption of program
code to timing execution to detect single stepping, and a host of other
anti debug tricks. You may find it useful to look at how current systems
are broken, by disassembling crack programs, and reading tutorials on
cracking.

	john


Mark Rosen ([email protected]) wrote:
: 	I am working on developing a secure registration algorithm. Currently, the
: developer generates two primes, p and q (relatively prime) and computes
: their products. The large composite is stored in the program and one of the
: primes functions as the registration key -- if the (composite) mod
: (registration code) == 0, then the registration code is valid.
: 	To combat users passing registration codes around a system ID is computed
: (from a variety of system-dependent things). The developer generates a
: variable number of composites and primes and the system ID is used as an
: index into the array of composites -- essentially the same thing as above,
: but with many composite numbers. This method can be beaten too, but it
: requires lots of users to register and there to be a group effort.
: 	Ideally, we would like to use something similar to this:
: 		if (f(s) * code(s) == g(s)) then registered.
: 	Where s is the system ID, f and g are known functions, and code(s) is
: input by the user. However, this is easy to break, since g(s) and f(s) are
: known, you can just divide to get the value of code(s). I don't really know
: where to go from here, but I suspect that the best method would involve
: modular exponentiation somehow. For example
: 		if (f(s) ^ code(s)) mod (g(s)) == q(s)) then registered
: 	or something like that. I have no idea what f, g, and q would be though.
: Thanks for any help.


: Mark Rosen
: FireSoft - http://www.geocities.com/SiliconValley/Pines/2690
: Mark Eats AOL - http://www.geocities.com/TimesSquare/6660

And now another interesting example: "The Economics of Piracy", gathered by fravia+: Brandon Van Every and Russ Williams exchanging some very sound (and advanced) ideas about protection... there's a lot of smoke in here, of course, and yet, as you will read, there are quite sound protecting ideas in here, and I can only praise the idea of sticking the key "in the INDEX STRUCTURE of the data, somewhere that takes quite a while to figure out how to transform without breaking everything. Yes! Yes! This is the way of the future for all kinds of protections, and it is, IMO, the only strategy that will work. Once more: "The cracker *has* to solve the structure of your data file to break the protection scheme. No other choice. Has to understand what's a float value, what's an index, etc. And you could make it take a very long time for him to do that. And exactly that will mark the difference between lam-o-crackers and real reversers: real reversers will enjoy this kind of protection!

---

[The Economics of Piracy: part one] ~ [The Economics of Piracy: part two] ~ [The Economics of Piracy: part three]

---

---

(c) 2000: [fravia+], all rights reserved