I personally believe that *all* crippling schemes that end up by comparing two values
are
crackable. Some are easier to crack, some take more time. But all of them can be
disabled
by nooping or changing the operator order, or changing the comparison type. It doesn't
matter if the comparison is against a fixed day number, a record limit, though a known
number makes it easier to search through the assembly code. And it isn't that
difficult,
although crackers tend to be highly proud of what they do, it's just child's play and
requires basic knowledge of assembly and assembly debugging.
I never took the time (never had the need) to invent an elaborate copy protection
scheme.
As I've suggested in this forum before, when I do write it, I'll probably base it on
self-modifying code, with several checksum traps. The best copy protection scheme will
probably be based on an encrypting algorithm, and would require personalized copies.
I'd like to hear other people's experience on the subject. Namely Aaron Ardiri's who, I
believe, started to write one of these self-modifying code copy protection mechanisms
some
time ago. Everytime someone raises this don't-leave-data-behind war, there's a lot of
vague discussion where I'd like to see some good ideas pop up.
Tim Hewitt wrote:
> Yes, I agree, however it still needs to be set up so that a simple
> edit of the file on disk - a crack - does not disable the feature.
> The common "theme" in counter based detection is a compare of
> one value with another. By searching for these magic numbers (3 uses,
> 7 days, whatever) and then looking for compare statements in assember,
> a cracker will often noop the operation, or set a loop counter to
> compare 0>0 or some such thing.
>
> I like the persistent database based key or crack detection feature
> as well.
>
> -Tim
> --
> Tim Hewitt
> Principal Software Engineer
> Fairchild Semiconductor
--
Sergio Carvalho
---------------
[EMAIL PROTECTED]
[EMAIL PROTECTED]
If at first you don't succeed, skydiving is not for you
