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	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]

On other pages of mine
corporate survival stalking matters enemy tracking
steganography What Fravia knows about you Tweak your browser!

Command: GET "03_1997&1379792"

Subject:  Re: Registration Algorithm

From: jw94@ecs.soton.ac.uk (John Wigley)

Date:  6 Mar 1997 21:24:17 GMT

Message-ID:  <5FNCM1$pfq@wapping.ecs.soton.ac.uk>

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 (mrosen@peganet.com) 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]

---

homepage links anonymity +ORC Reality cracking antismut
how to search academy database tools cocktailssearch_formsmail_fravia