0

My first solution for this problem is to use OS/BIOS timer and check it with encrypted date file ( see below pseudocode )

public void CheckFrequently()
{ 
   DateTime registeredDate = ReadFromBiosOrOSTimer(); 
   DateTime readEncryptedDate = ReadFromEncryptedFile(); 

   if(registeredDate >= readEncryptedDate) 
   { 
      ShowExpireDateForm();
      CloseProgram();
   }
}

In this case its obvious that user could change OS/BIOS timer easily and my method not works.

my questions are :

  1. Is there any way to fix user OS/BIOS timer change problem?
  2. Is there any better way to set expiration date to .Net projects?
Ali Bigdeli
  • 1,286
  • 3
  • 17
  • 35
  • 2
    If you are so concerned about protecting your code that you're protecting against users that intercept BIOS, you really should invest in a professional software protection solution. Hackers with that skill are hugely resourceful. – Eric J. Jul 16 '12 at 16:35
  • Are you trying to create a program that "expires" in 7 days or something like that? – Steve Wellens Jul 16 '12 at 16:35
  • When you finally overcome hackers, you will have to deal with carders (those that purchase your software using stolen credit card numbers). That's a neverending battle, so my advise is to purchase some external protection (like VMProtect or Armadillo) and invest your time into application improvements and marketing. – Eugene Mayevski 'Callback Jul 16 '12 at 17:01

1 Answers1

4

(My answer is assuming you want to have an "expiring" program of some sort.)

The end-all-be-all big brother answer would be to retrieve a trusted time from an external source, say, a web service. Of course, connectivity (or lack thereof) may make this impossible.

Other than that, knowing that if someone is going to cheat the clock, they would likely do it very close to the expiration, periodically write, somewhere, a timestamp of the current time. If you ever encounter a case where the retrieved (via system call) time is less than the last timestamp, someone might be trying to trick the clock and you can invalidate the session/instance with the appropriate error message. Once you've detected the "expired" case, it's simple to flip a switch and refuse to run anymore.

All of that said, a countermeasure like this will most likely always be beaten by an adversary who is determined enough.

Omaha
  • 2,262
  • 15
  • 18