0

How do I expire an exe after certain date/Time. Like I want to expire an exe/Application on date 12-12-2018.

Currently I only know about two ways ::

  1. Computer Date: I have DateTim.Now in C#, So I can compare user system date with my hard-coded date but it is not trustworthy because it checks the date from the user Computer Date which a user can change.

  2. Internet Date: I make a request to Internet to get date but I can't rely on internet because It is possible that user won't connect to internet at the time using my Exe, so i can't make it dependent on internet.

So how do you expire your exe in safe and secure manner.

(I am not talking about license system etc that many stackoverflow Q/A suggested I am just talking about simply way to do this. If it is not possible please do answer also.)

Muhammad Faizan Khan
  • 10,013
  • 18
  • 97
  • 186
  • 3
    I don't think that you can. Even with an Internet connection someone could fake this data and make your program fail. I don't know your requirements but any information taken from the user device could be forged. – Steve Oct 21 '16 at 13:57
  • Thanks steve, I just want to restrict my application access after certain date – Muhammad Faizan Khan Oct 21 '16 at 13:58
  • You could set a registry value (requires admin) with the date or using some sort of encoding. You could make a web request to get the date from a remote data source. On app start, check the key, if the key does not exist (ie the user removed it) the exe exits, if the encoded date is past, the exe exits. Just a couple if ideas... – Jordan Oct 21 '16 at 13:59
  • It would be helpful if you gave us ALL of your environment constraints (i.e. permissions, remote data access), so we can provide more accurate answers. Long story short, there are more than a few ways to accomplish this. – Jordan Oct 21 '16 at 14:01
  • easiest way, add a date as a constant in the exe and check it at boot. But, that's 100% breakable by any one with a minimum knowledge, just changing the date of the computer or modifying it through reflection would jump that protection. – Gusman Oct 21 '16 at 14:05
  • Similar question with some suggestions: http://stackoverflow.com/q/1211817/1450855 – Georg Patscheider Oct 21 '16 at 14:13
  • Why do questions like this always devolve into people who know nothing about security rambling on about what they think of on the spot, thinking up a "foolproof" but actually broken-by-design system as they type? – CodeCaster Oct 21 '16 at 14:42
  • @CodeCaster do you have any idea? – Muhammad Faizan Khan Oct 24 '16 at 04:49
  • @Gusman yes i have already mention it in my question date in changeable in system so I am looking alternatives . – Muhammad Faizan Khan Oct 24 '16 at 05:00

1 Answers1

0

well, it depends a bit on how reliable the system has to be...

of course you can allways say: the code has left your hands -> from now on nothing is reliable ... your code can be tampered with, the hardware is not under your control... so in the end, this task can not be done right, if you consider every possibility

but you can make it a bit harder for someone to tamper with the system...

let's say you have some sort of application state, that is initialized at first start using an internet service that verifies that the software did not expire yet... of course this has to be secured and authenticated with something like TLS and an embedded certificate... (bonus points if you use the bytes from the certificate elsewhere as constants in your program)

now this state has to hold something the program needs to work on, in other words, it is mandatory that this state is affected by changes that are persisted. additionally the state holds the expiry date, and the greatest timestamp your program has seen so far

for example you can have a counter in there that counts operations in your program ... do something, increment the counter, etc

the counter state then is saved along with the data your program is working on, like in a file header, when you write something

of course this information needs some sort of anti-tampering mechanism ... along with the counter state, save the current timestamp and a hash over the file content... then create some sort of signature over the header

when you load that file, verify the signature, the content hash, the timestamp has to be in the past, and the current counter state has to be greater than the saved counter state

the application state is saved the same way on a regular interval and of course you check the state on every startup (expired, greatest known timestamp < current timestamp, signature)

of course someone with brain.exe can poke around a little and dismantle a mechanism like this, but it is a little harder than just reseting a clock

edit: and of course you can check if there is a filesystem available to write on, that is NTFS formatted, where you can store something hidden in an alternate data stream...

you can also have a config file that you write to AFTER your initial program checks are complete, and compare the last write time of that file to the current system clock to see if it was reset

you can also check for files on the harddrive that are newer than the date the system clock shows you...

DarkSquirrel42
  • 10,167
  • 3
  • 20
  • 31
  • Can you summaries your answer in points. what the possible solutions? – Muhammad Faizan Khan Oct 24 '16 at 05:08
  • all you can do ist to require more effort from someone trying to break your expiry function ... so ... there is no general solution here ... just an idea on a few things that can be done to make it harder to temper with – DarkSquirrel42 Oct 24 '16 at 05:42
  • but where do i actually validate date? through user system date or else? making harder tamper is next stage – Muhammad Faizan Khan Oct 24 '16 at 05:57
  • you validate against the system clock while making it harder to tamper with the clock ... if the user resets the clock to a previous date, there are some indicators for that, that a user would a) have to know of, and b) also fix them to make the clock reset go undetected – DarkSquirrel42 Oct 24 '16 at 09:03