Reverser's Anonymity Academy
Every web step leaves traces
We'll always find what we want :-)
Command: GET "03_1997&1379792" Subject: Re: Registration Algorithm From: email@example.com (John Wigley) Date: 6 Mar 1997 21:24:17 GMT Message-ID: <firstname.lastname@example.org> 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@example.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 reverser+: 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!