AW: OT: locking software to one specific machine?
Andre Garzia
andre at andregarzia.com
Thu Mar 4 14:26:09 EST 2010
funny tale below:
Once I lost both the serial generator for one of my software and the backup
for the given generator. People were buying the software but I could not
generate the serial for them, then, I remembered that I had not removed some
debug messages. So if invoked thru the terminal from inside the bundle
instead of run thru the finder, it would output debug messages.
If the user tried a license that was invalid, it would output the invalid
license and the correct license for the given email to the console.
By running my copy and trying buyers emails, I got all licenses I needed.
I never found my console trick anywhere on the pirates sites. It is quite
impressive the amount of stuff softwares output to the console, lots of
developers leave this kind of stuff behind due to simply forgetting about
them.
These days (9 years later) I am much more organized with my code and backups
and I always have a switch to turn off all debug messages before shipping.
Cheers
andre
On Thu, Mar 4, 2010 at 4:18 PM, Richard Gaskin
<ambassador at fourthworld.com>wrote:
> Marty Knapp wrote:
>
>> I like the idea of pre-generated keys. It seems like a good in-between
>> method. If your user then registered their key and someone else
>> subsequently tried to register the same number you would have some
>> recourse. I don't want to get bogged down in lots of administrative
>> hassles, so I like this method. Does anyone have suggestions about
>> setting up something like this? And a method for verifying the key?
>>
>
>
> Challenging, but fun:
> ---------------------
>
> Start by reading these for inspiration:
>
> The Plain Truth about Casual Software Piracy
> by Matt Slot, Ambrosia Software
> <http://www.windowsusers.org/piracy.html>
>
> Anti Cracking FAQ
> How to make cracking your programs a little harder
> <http://www.inner-smile.com/nocrack.phtml>
>
> Now devise a scheme of between 12 and 20 characters in which some of the
> characters must be in a specific range to be valid, and others are derived
> from combinations of others. For example, character 10 could be the ASCII
> equivalent of the average of characters 9, 4, and 2, and character 2 could
> be the sum of characters 1 and 5 minus character 8, etc. It's sometimes
> useful to have some characters use values you can derive meaning from, such
> as the version number, if needed. Use that to generate your keys.
>
> Avoid schemes that produce any "1" or "0" characters since those will be
> mistyped as "l" and "O" by many users, raising support requests with
> complaints of a "bad reg code". This will reduce the range of acceptable
> keys, but you should still be able to produce at least 10,000 unique keys
> from most schemes you can think up in a few minutes. If you sell 10,000
> copies you've made more than enough money to finance your upgrade with a new
> reg scheme. :)
>
> Also provide a Paste Code button in your reg window so they don't need to
> type the code at all, and handle Cmd-V yourself by cleaning the
> clipboardData["text"] of any extraneous characters before pasting into your
> field (people will include trailing returns and other garbage when copying
> from the reg email you sent them).
>
> Then write the inverse of the generator to validate your codes, but break
> up the validation into multiple handlers each doing a small part of it,
> using obscure function names strewn all over your code base with lots of
> red-herring handlers with similar names littered among them. Extra bonus
> points if the handlers you call also call others; the more the merrier.
> Anyone tracing your code in a low-level debugger will find it far more
> annoying than it's worth.
>
> Run all your keys through the validator before shipping, to ensure the
> generator and the validator are in synch. This batch validator should also
> check uniqueness of all keys to avoid having a single key sent to multiple
> users.
>
> Then of course add at least a half-second delay for validation somewhere in
> your sequence to thrwart brute-force attacks. A half-second won't bother a
> user, but for automated attempts it means the difference between hours and
> years.
>
> Then lock your stack with a good password, after writing down your algo
> somewhere since your code will be unreadable to even yourself. Use v4.0 to
> build, since the password protection is much stronger.
>
> Repeat with each new version, changing your scheme substantially between
> versions so that all the old keygens that showed up on those overseas
> servers within a week of your last release will no longer work with your new
> version.
>
>
>
> Less challenging, but no less fun:
> ---------------------------------
>
> Just use Jacque Gay's Zygodact
> Automated Registration System for Revolution
> <http://www.hyperactivesw.com/solutions_zygodact.html>
>
>
>
> --
> Richard Gaskin
> Fourth World
> Rev training and consulting: http://www.fourthworld.com
> Webzine for Rev developers: http://www.revjournal.com
> revJournal blog: http://revjournal.com/blog.irv
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
--
http://www.andregarzia.com All We Do Is Code.
More information about the use-livecode
mailing list