Re: Software protection

From: Jamie (jamie_5_not_valid_after_5_Please_at_charter.net)
Date: 01/01/05

  • Next message: Michael Brown: "Re: Software protection" 
    Date: Fri, 31 Dec 2004 17:00:55 -0800

    John E. Doe wrote:
    > On Fri, 31 Dec 2004 15:02:29 +0000, Steve <nomail@here.com> wrote:
    >
    >
    >>But a "cracker"/pirate would just use the same keygen technique to watch my
    >>program and remove the bit that loads the license information, making a "safe"
    >>pirate version to distribute.
    >
    >
    > No, it's not the same scenario.
    >
    > When you're working on a key generator, you have to constantly track
    > various registers and memory locations to figure out what algorithm is
    > being used so that you can replicate it. You're not making any
    > changes to the actual program.
    >
    > In this case, it would be a much more complicated job to completely
    > rip out an entire procedure (assuming he can even find it) and then
    > still maintain the integrity of the executable.
    >
    > To make it even more difficult, you should have multiple checks
    > throughout your program, but make sure that it's not just the same
    > function being called. Create about 3-4 different check routines, and
    > make each one slightly different from the others. For a more
    > hair-pulling experience, put your check routines into timers and have
    > them go off at random intervals. Or you can also incorporate them
    > into threads. By this point you'll have weeded out about 95% of all
    > "crackers", because the majority of them are completely useless when
    > it comes to any real programming work. Most of these guys learn their
    > cracking techniques by reading "How to Crack" text files, which very
    > rarely ever teach anything beyond the simple CMP/JNE bypassing
    > technique.
    >
    > The top three things crackers hate the most:
    >
    > 1) Encryption
    > 2) Multiple, disguised checks
    > 3) Threads
    >
    > In the end, you're still left with the reality that there's no way to
    > protect your software 100%...but with some effort, you can make it so
    > irritating that the vast majority of crackers will give up long before
    > they get close. The remaining few who do actually have the necessary
    > skills will probably have better things to do..
    you know its funny, i have a Ham radio program that has the CALL sign
    encrypted in it., this program does transmit on the air along with the
    call sign, i have had many reports of hackers trying to change the
    call sign in it, no success as of yet.
       and yes, i been at those hacker sites where they list cracks for
    programs etc..
       all of my competetors are in there. the only one of mine they have is
    the shareware , where they crippled the timer which is no big deal
    because i knew that could be done how ever, i also used the Multimedia
    Timer which has to be active for the program to function., so if the
      System timer fails to fire off and reset the down counter in the media
    section that will kill it.
       on top of that, the shareware is not 100% code compiled into it.
      so all they did was extend the timer for an additional 10 mins..
      the program booms anyways :).
      as far as the registered version with their call sign in it?> i have
    had many e-mails informing me known hackers hard at work to break it.
      i just told them, bring it on....
       i haven't seen a broken version yet, and most hams i know won't give
    out software that transmit their call sign on the air..
        since its a digital app, i do have the option to remotely make their
      app non operational until they reboot., that was just a simple ATOM i
    created since they stay alive until you reboot and do not leave any file
    trials behind. :)
       i will not get into details on how i was able to hide the info in the
    EXE file for which i had to write a registration utility to do so.
      i will say this how ever, the info is encrypted as part of Execution
    code. if any of this gets changed the program will fail anyways.
      i use the Virtual Memory functions to change things in memory.

  • Next message: Michael Brown: "Re: Software protection"

    Relevant Pages

    • Re: Getting an out of memory error
      ... > I have a VBV.NET application that runs on a timer to do a job at one hour ... > the code executes an FTP transfer from an FTP site. ... > out of memory error message. ... you could end up running into memory problems. ...
      (microsoft.public.dotnet.languages.vb)
    • Re: CLOCK change problem
      ... specifically on the 168 my memory is iffy on the 155/158 but I think ... TOD was introduced with 370 (interval timer & clock comparator) ... The univ. had some number of ascii/tty terminals ... ... reverse engineer channel interface and building channel interface board ...
      (bit.listserv.ibm-main)
    • RE: Data caching question
      ... All this stuff is built in to ASP.NET ... I was thinking about making another caching singleton that would cache ... the CacheDB object would have a timer ... My primary concerns are the memory usages of in memory tables ...
      (microsoft.public.dotnet.framework.aspnet)
    • Re: Creating Modeless Dialogs continually causing application to grow
      ... Adding the timer to give the main application a moment of rest seems to remove the modelss dialog memory growth. ... MFC's definition of "idle time" is checking the message queue and finding no messages to dispatch. ... So if you are keeping the message queue continually busy, or the processor continually busy, the temporary objects will tend to build up, awaiting idle time. ...
      (microsoft.public.vc.mfc)