Software Cracks 
Author Message
 Software Cracks

Hi,
I develop applications to sell as shareware on the internet and recently
I've noticed cracks have already become available for my software. I created
my own code generation algorithm for unique reg codes for my customers.  I
was wondering if anyone has any idea how I could make a crackers life harder
in my software's internal code design. How could I stop the cracking?  Is
there any way? I'd be greatful for any ideas!
Thanks
Kris


Thu, 08 Nov 2001 03:00:00 GMT  
 Software Cracks
One thing you can do is make sure that you do not have passwords that can be
found by a hex editor.   Some people have their passwords write to an external
file, and that is ok if it is not readable and it is not the only
"check" to see if the user is legitimate.   If there is only one place in the
program where a check is made to see if the user is legitimate, it makes for an
easy hack.  Don't compile your program to P-code either......that makes it
easy to dissassemble.    If I was writing a program that I very seriously
wanted to protect, here is what I would do........ I would spend some time
studying some of the hacker's pages to find out HOW they are doing
it.......and......some of these pages, (for example, Fravia's page)  actually
post some good protection scemes.  
   Lastly.......there is another way people can get cracks.......and that is
from people who legitamately bought your program, then shared it with their
neighbor John down the street.    I'm not to sure what can be done about that,
but I have thought along the lines of this......   when someone registers for
the program,  have a place where the specific user ID, Name, etc can be written
onto the CDROM.......before it is sent to the user......then, when your user
saves any file,
make sure that that info is written to the file.
You should see where I'm going with this idea now.......

http://www.angelfire.com/az/desertavatar/
Interlinear Latin, Some History, Picture of Great Pyrimid and of a Castle
at Palma de Mallorca, no Visual Basic yet!.......


Thu, 08 Nov 2001 03:00:00 GMT  
 Software Cracks
Hello, i would like no how to search for these cracks, we encrypt our
applications and i don't know if it's been hacked or not.

Was your procedure a very standard one?

Quote:

>Hi,
>I develop applications to sell as shareware on the internet and recently
>I've noticed cracks have already become available for my software. I
created
>my own code generation algorithm for unique reg codes for my customers.  I
>was wondering if anyone has any idea how I could make a crackers life
harder
>in my software's internal code design. How could I stop the cracking?  Is
>there any way? I'd be greatful for any ideas!
>Thanks
>Kris



Thu, 08 Nov 2001 03:00:00 GMT  
 Software Cracks
The company who deals with all my online customer credit card transactions
provides me with links and search engines to find cracks for my software -
this way I know whether I need to make a new code generation algorithm for
the next version.  If you go to http://www.happyhippo.com
there are loads of search engines there for cracks. I've managed to get the
cracks off some sites by complaining about it etc..  But after a while you
give up and you just have to hope that people would rather pay for your hard
work.  As you'll all know as programmers we put ALOT of work into software,
even for the smallest things, so we deserve to make money to carry on, it's
just a shame that it's so easy for people crack software.

Kris



Quote:
> Hello, i would like no how to search for these cracks, we encrypt our
> applications and i don't know if it's been hacked or not.

> Was your procedure a very standard one?


> >Hi,
> >I develop applications to sell as shareware on the internet and recently
> >I've noticed cracks have already become available for my software. I
> created
> >my own code generation algorithm for unique reg codes for my customers.
I
> >was wondering if anyone has any idea how I could make a crackers life
> harder
> >in my software's internal code design. How could I stop the cracking?  Is
> >there any way? I'd be greatful for any ideas!
> >Thanks
> >Kris



Thu, 08 Nov 2001 03:00:00 GMT  
 Software Cracks
Thankyou, I was thinking along the same lines in relation to the checking to
see if the user is legitimate part, in future versions I'm going to be quite
crafty (i hope!) and put user validation routines in unusual places and try
very different techniques in user validation.  I'm going to think carefully
how I can outsmart the crackers.

I don't think that there's much that can be done about the legimate
customers who then give out their codes, there's a point where you just
don't have that kind of control.  I may just have to ignore the copying home
user!

Thanks very much for your help, I'll go and read up!
Kris


Quote:
> One thing you can do is make sure that you do not have passwords that can
be
> found by a hex editor.   Some people have their passwords write to an
external
> file, and that is ok if it is not readable and it is not the only
> "check" to see if the user is legitimate.   If there is only one place in
the
> program where a check is made to see if the user is legitimate, it makes
for an
> easy hack.  Don't compile your program to P-code either......that makes it
> easy to dissassemble.    If I was writing a program that I very seriously
> wanted to protect, here is what I would do........ I would spend some time
> studying some of the hacker's pages to find out HOW they are doing
> it.......and......some of these pages, (for example, Fravia's page)
actually
> post some good protection scemes.
>    Lastly.......there is another way people can get cracks.......and that
is
> from people who legitamately bought your program, then shared it with
their
> neighbor John down the street.    I'm not to sure what can be done about
that,
> but I have thought along the lines of this......   when someone registers
for
> the program,  have a place where the specific user ID, Name, etc can be
written
> onto the CDROM.......before it is sent to the user......then, when your
user
> saves any file,
> make sure that that info is written to the file.
> You should see where I'm going with this idea now.......

> http://www.angelfire.com/az/desertavatar/
> Interlinear Latin, Some History, Picture of Great Pyrimid and of a Castle
> at Palma de Mallorca, no Visual Basic yet!.......



Thu, 08 Nov 2001 03:00:00 GMT  
 Software Cracks
One method which I have "played with" of preventing the user of a
legitimately purchased copy from simply copying the CD or floppies and
giving them to a friend is to have your program write a hidden file when it
is first run (maybe a file with a nondescript name and a DLL extension in
the Windows/System folder - people don't like playing with these!) or a well
disguised Registry entry. Evert time your program is run it can then check
this file and if it does not contain a particular code then it can pop up a
VBModal Form which gives the user a product ID number (which is selected at
random on the very first run and then saved to the hidden file). The user
can be given a choice of ignoring this and continuing to use the program, or
of telephoning you and quoting the number so that he can be given a
Registration Code which he can then enter in a box on the VBModal Form. You
keep a count of these requests (also in the hidden file) and when he has
ignored the registration request a specific number of times then your
program ceases to function. All you then need is some sort of encryption
program (which can easily be written in VB) which will take the Product ID
number and generate a Registration Code from it. You run this when the user
telephones you with his Product ID and you give him the resultant
Registration Code which he enters in the box. When he then clicks the OK
button on the VBModal Form your code in the user's program also runs the
same encryption code on the Product ID and, if the result matches what the
user has entered in the box then you just write the appropriate code into
the hidden file which will prevent these requests from popping up again.

Mike

Quote:

>One thing you can do is make sure that you do not have passwords that can
be
>found by a hex editor.   Some people have their passwords write to an
external
>file, and that is ok if it is not readable and it is not the only
>"check" to see if the user is legitimate.   If there is only one place in
the
>program where a check is made to see if the user is legitimate, it makes
for an
>easy hack.  Don't compile your program to P-code either......that makes it
>easy to dissassemble.    If I was writing a program that I very seriously
>wanted to protect, here is what I would do........ I would spend some time
>studying some of the hacker's pages to find out HOW they are doing
>it.......and......some of these pages, (for example, Fravia's page)
actually
>post some good protection scemes.
>   Lastly.......there is another way people can get cracks.......and that
is
>from people who legitamately bought your program, then shared it with their
>neighbor John down the street.    I'm not to sure what can be done about
that,
>but I have thought along the lines of this......   when someone registers
for
>the program,  have a place where the specific user ID, Name, etc can be
written
>onto the CDROM.......before it is sent to the user......then, when your
user
>saves any file,
>make sure that that info is written to the file.
>You should see where I'm going with this idea now.......

>http://www.angelfire.com/az/desertavatar/
>Interlinear Latin, Some History, Picture of Great Pyrimid and of a Castle
>at Palma de Mallorca, no Visual Basic yet!.......



Fri, 09 Nov 2001 03:00:00 GMT  
 Software Cracks
One method which I have "played with" of preventing the user of a
legitimately purchased copy from simply copying the CD or floppies and
giving them to a friend is to have your program write a hidden file when it
is first run (maybe a file with a nonedescript name and a DLL extension in
the Windows/System folder - people don't like playing with these!) or a well
disguised Registry entry. Every time your program is run it can then check
this file and if it does not contain a particular code then it can pop up a
VBModal Form which gives the user a product ID number (which is selected at
random on the very first run and then saved to the hidden file). The user
can be given a choice of ignoring this and continuing to use the program, or
of telephoning you and quoting the number so that he can be given a
Registration Code which he can then enter in a box on the VBModal Form. Your
program can keep a count of these requests (also in the hidden file) and
when the user has ignored the registration request a specific number of
times then your program ceases to function. All you need is some sort of
encryption program (which can easily be written in VB) which will take the
Product ID number and generate a Registration Code from it. You run this
when the user telephones you with his Product ID and you give him the
resultant Registration Code which he enters in the box. When he then clicks
the OK button on the VBModal Form, your code in the user's program also runs
the same encryption code on the Product ID and, if the result matches what
the user has entered in the box then you just write the appropriate code
into the hidden file which will prevent these requests from popping up
again.

Mike

Quote:

>One thing you can do is make sure that you do not have passwords that can
be
>found by a hex editor.   Some people have their passwords write to an
external
>file, and that is ok if it is not readable and it is not the only
>"check" to see if the user is legitimate.   If there is only one place in
the
>program where a check is made to see if the user is legitimate, it makes
for an
>easy hack.  Don't compile your program to P-code either......that makes it
>easy to dissassemble.    If I was writing a program that I very seriously
>wanted to protect, here is what I would do........ I would spend some time
>studying some of the hacker's pages to find out HOW they are doing
>it.......and......some of these pages, (for example, Fravia's page)
actually
>post some good protection scemes.
>   Lastly.......there is another way people can get cracks.......and that
is
>from people who legitamately bought your program, then shared it with their
>neighbor John down the street.    I'm not to sure what can be done about
that,
>but I have thought along the lines of this......   when someone registers
for
>the program,  have a place where the specific user ID, Name, etc can be
written
>onto the CDROM.......before it is sent to the user......then, when your
user
>saves any file,
>make sure that that info is written to the file.
>You should see where I'm going with this idea now.......

>http://www.angelfire.com/az/desertavatar/
>Interlinear Latin, Some History, Picture of Great Pyrimid and of a Castle
>at Palma de Mallorca, no Visual Basic yet!.......



Fri, 09 Nov 2001 03:00:00 GMT  
 Software Cracks
We have also encountered this problem.
After considerable (heated) discussion here, we came up with a few ideas
which may be of assistance.
1. As another respondent pointed out, don't keep your ID where it can be
found. Either encrypt it somehow, or split the individual characters off
and store them in scattered places throughout the EXE file (or wherever).
2. Have an external file, even  in ASCII form, which lists the user
name, the ID, and other pertinent information (perhaps his system info,
as well.) The program checks for the existence of this file when it
boots, and if it is not found, either refuses to run ("Please input User
ID off installation disk"), or switches to demo mode ("Unregistered. If
you wish to register, call..."). This means that if they copy your
program to a different user, either it is copied in demo mode (fine by
us), or the original user's information is copied along with it.
Assuming you are willing to prosecute, this leaves a clear trail.
3. Get PACE, which provides a unique serial number linked to the user's
hard disk. Expensive, but quite secure.

Quote:

> Hi,
> I develop applications to sell as shareware on the internet and recently
> I've noticed cracks have already become available for my software. I created
> my own code generation algorithm for unique reg codes for my customers.  I
> was wondering if anyone has any idea how I could make a crackers life harder
> in my software's internal code design. How could I stop the cracking?  Is
> there any way? I'd be greatful for any ideas!
> Thanks
> Kris

--
Edward Lipsett
Intercom, Ltd.
Fukuoka, Japan

http://www.intercomltd.com
Fax: +81-92-712-9220


Fri, 09 Nov 2001 03:00:00 GMT  
 Software Cracks

Quote:
> 3. Get PACE, which provides a unique serial number linked to the user's
> hard disk. Expensive, but quite secure.

Not a good solution -- what if they format or get a new HD?

Paul.



Fri, 09 Nov 2001 03:00:00 GMT  
 Software Cracks

Quote:
> One method which I have "played with" of preventing the user of a
> legitimately purchased copy from simply copying the CD or floppies and
> giving them to a friend is to have your program write a hidden file when
it
> is first run

No good -- they can keep a backup copy BEFORE it is first run, which
they can give to friends.

Paul.



Fri, 09 Nov 2001 03:00:00 GMT  
 Software Cracks
Some ideas:
    * Any keys or password should be stored as ASCII codes.
    my name would be: Chr(74) & Chr(65) & Chr(83) & Chr(79) & Chr(78)
    this would appear as just a bunch of code in the EXE rather than a hex
    editable text string "JASON"
    * Perhaps when the runs the program it generates a unique code based
upon
    file dates and times of system files (generally unique per system) and
have the     user send you this code along with contact details  in exchange
for a code
    that is complexly related to their code. Keep track of how many times
    someone registers and after a grace period of about 3 registrations,
then hit
    them with another fee.

Jason


Quote:
> Hi,
> I develop applications to sell as shareware on the internet and recently
> I've noticed cracks have already become available for my software. I
created
> my own code generation algorithm for unique reg codes for my customers.  I
> was wondering if anyone has any idea how I could make a crackers life
harder
> in my software's internal code design. How could I stop the cracking?  Is
> there any way? I'd be greatful for any ideas!
> Thanks
> Kris



Fri, 09 Nov 2001 03:00:00 GMT  
 Software Cracks
What about incorporating a Hasp hardware key?
Quote:


> > 3. Get PACE, which provides a unique serial number linked to the user's
> > hard disk. Expensive, but quite secure.

> Not a good solution -- what if they format or get a new HD?

> Paul.



Fri, 09 Nov 2001 03:00:00 GMT  
 Software Cracks
This is a common method of protecting fonts here (Asia), and the
customer has no choice but to call up and get a new serial number. This
is generally charged, for maybe US$10 or US$20.
For fonts, users are generally willing to put up with it.

Quote:


> > 3. Get PACE, which provides a unique serial number linked to the user's
> > hard disk. Expensive, but quite secure.

> Not a good solution -- what if they format or get a new HD?

> Paul.

--
Edward Lipsett
Intercom, Ltd.
Fukuoka, Japan

http://www.intercomltd.com
Fax: +81-92-712-9220


Fri, 09 Nov 2001 03:00:00 GMT  
 Software Cracks
That doesn't matter. Sooner or later they are all going to have to 'phone
you for a registration code (or your program will stop running) and, since a
different product ID number will have been generated on each computer, then
they will each need a different registration code. If you keep records of
who you sold the legitimate copies to then you simply refuse to give out
registration codes to anyone else.

Mike

Quote:

>snip<
>No good -- they can keep a backup copy BEFORE it is first run, which
>they can give to friends.

>Paul.



Fri, 09 Nov 2001 03:00:00 GMT  
 Software Cracks
I can see how making things as indirect as possible and "scattered" can
definitely provide good protection, it also makes code maintence hellish as
you need to keep track of just where validation routines are and how they
are executed. The best thing to do would be maybe documenting (for internal
use!) just where the validation routines are and how they work exactly so
when you come back to adjust the code in a few months you can do it
successfully.  I try my best to practice OOP in my projects and make code as
easy to follow as possible, but I can now see that this also makes a
crackers life easy.

Kris


Quote:
> Some ideas:
>     * Any keys or password should be stored as ASCII codes.
>     my name would be: Chr(74) & Chr(65) & Chr(83) & Chr(79) & Chr(78)
>     this would appear as just a bunch of code in the EXE rather than a hex
>     editable text string "JASON"
>     * Perhaps when the runs the program it generates a unique code based
> upon
>     file dates and times of system files (generally unique per system) and
> have the     user send you this code along with contact details  in
exchange
> for a code
>     that is complexly related to their code. Keep track of how many times
>     someone registers and after a grace period of about 3 registrations,
> then hit
>     them with another fee.

> Jason



> > Hi,
> > I develop applications to sell as shareware on the internet and recently
> > I've noticed cracks have already become available for my software. I
> created
> > my own code generation algorithm for unique reg codes for my customers.
I
> > was wondering if anyone has any idea how I could make a crackers life
> harder
> > in my software's internal code design. How could I stop the cracking?
Is
> > there any way? I'd be greatful for any ideas!
> > Thanks
> > Kris



Fri, 09 Nov 2001 03:00:00 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Protection from password cracks? i.e. alt.cracks

2. project design software , compare website design software , web developers , website design software review , nof shop , software quality , nof 7.5 , bestellen preisvergleich , web site design , custom web design ,

3. Australia changed software copyright law - cracking is now legal!

4. Best way to prevent cracking of vb software ??? any suggestions..

5. Best way to prevent cracking of vb software ??? any suggestions..

6. Best way to prevent cracking of vb software ??? any suggestions..

7. Best way to prevent cracking of vb software ??? any suggestions..

 

 
Powered by phpBB® Forum Software