-use rom id as a unique number -use armlet for security and also crc the 68k code -user 68k to crc armlet -never numerical keys -always keyfiles (preferably just the unique id, signed using a loooong rsa signature)
makes keygens and hacks hard :) ---- Best Regards, Dmitry Grinberg (847) 226 9295 On Sat, Jan 10, 2009 at 3:34 PM, Doug Reeder <reeder...@gmail.com> wrote: > Computers are fundamentally open systems -- you can't prevent people from > cracking your app, you can only make it more difficult. Furthermore, there > are crackers out there, perhaps most of them, who do it because they find it > personally rewarding, or for status in their subculture. The harder it is > to crack, the greater the status from doing so. Music and movie companies > spent millions developing content protection system that were broken in > weeks or months. And when cracked once, your app is available to anyone > willing to use a cracked version. > > One can divide users in to three categories: those saints who will pay > regardless of what measures you take, those freeloaders who won't pay > regardless, and the largest group, those who will pay if that is a better > experience than not paying. Most people value being able to think of > themselves as honest. They want the software to be easy to install and use. > They want to be able to update easily when bug fixes come out. They want > technical support. They expect their software to run when they get new > hardware. And they don't want to pay more than a "fair" price for it. > (Ideas of what constitute fairness differ.) > > So, you should evaluate every protection measure against the question "Does > this make it a better experience to pay, rather than not pay?". So, if > users must do complicated things to activate their software, it tilts the > equation against you. Making it easy to obtain tech support if you have > paid, and hard if you haven't, tilts the equation your way. Making easy > for paid users to upgrade to a version with new features, vs. waiting for > the the new version to be cracked, tilts the equation in your favor. > > As a citizen, it may advance the social good to deny software to people who > won't pay for it, but as a businessman, you shouldn't care -- if they won't > pay, there's no profit to be made, and it doesn't cost you anything. > > The easier it is to plug a security package or library into an application, > the easier it is for crackers to unplug. So, if you're serious about > technical protection measures, it needs to be intertwined with the > functioning code. You need to implement a system where you can vary the > protection measures with each release, so it can't be cracked the same way > as previous releases. The cracker community has spent thirty years > developing its tactics and tools. Inform yourself before expending effort > on technical protection measures. > > One area that does pay off is making it difficult to generate valid license > codes. Then, at least black marketeers can't sell licenses for your > software that work with uncracked software. A license code is like a > message from the publisher saying 'it's okay to run given such-and-such > environment'. Public key cryptography can make it near-impossible to fake a > message -- if you dot all your i's and cross all your t's. But keep in > mind what you're locking the software to. Palm OS devices don't all have > unique hardware IDs, and most customers expect to be able to take their > software with them to a new model. You can expect that HotSync names are > effectively unique -- but there are hacks to change the HotSync name before > any given app executes, so anyone willing to cheat can use a published > HotSync name - license code pair and still use their normal HotSync name for > syncing. > > This is a simplified overview -- there are caveats to almost everything I've > said above. But learn about the whole situation before expending effort. > > > -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
