Board index » cppbuilder » comparing actual time with build-in time

comparing actual time with build-in time

Hello,

I want to make an *.exe that stops working after some period of time, even
if the user has been fooling around with the internal clock of his computer.
My idea is to put the actual date (hours are not important) somewhere in my
code (*.cpp file), and recompile the whole thing.
When the *.exe file is started by the user, it retrieves the date of his
computer and compares it to the "compiled" date I putted in.
Why question is

1. How to put the date in my program (use of TDateTime or something else)
2. How to get the date of the user's computer
3. How to compare both dates

Thanx a lot for your help!

Bob

 

Re:comparing actual time with build-in time


Leslie:

Here's the deal...

You can't put anything in your exe. You can not write data to your exe when
your application is running. Windows prevents it.

My recommendation: Don't stop the app from running on day X of use. No
matter what you do, it's going to be very simple to work around and you'll
be wasting a lot of time. Use two completely different versions. One your
trial and one your retail product. Use defines in your coding to accomplish
this securely. Include good features in your trial version but don't take
full use away or it's useless to test out. Leave the coding out completely
that is the most special part of your application.

To make your application secure...

As part of your install program (InstallShield, etc.) install a special
registry key. Name it something inconspicous. Don't name it checksum or
anything obvious like that. Not directly upon start of your app, add up all
the DWORDs in your exe. Store this value to a variable. With the value do a
little math with it. XOR it, shift it, subtract it, add it, whatever. Now
compare it to a dummy value. For either result, true or false, have it go do
something your program needs to do to initialize anyway. Add in that
function or coding something to get that variable back to the value it was
originally. Compare it to a dummy value again, and do the same thing, do
something you need to do anyway. Now the tricky part, in a different
function again further down in your coding or somewhere away from this last
step. The key is to isolate each coding segment away from each other. Now
you need to make a pointer to this variable and subtract the address of that
pointer by a few. Again in another code segment add the amount you
subtracted by, and finally XOR it with your secret value. Compare the value.
If it is not what it is supposed to be (hacker changed your coding) enable a
timer to go off. Randomize the timer's interval. Preferable a minute or so
at minimum. This will make it utmost annoying if a hacker is trying to step
into your code with a de{*word*81}. Since, the time of leaving the app is
random. Post an Application->Terminate() or something similar. Make sure
nothing gets in the way of the application terminating. DO NOT display a
dialog or any warning.

Change the XOR value for each different release and of course deviate from
this plan a little to make yours unique. Maybe don't use XOR and use >>
(shift). Now the trick is to find out during every different release what
your checksum is. Simple and effective add OnKeyDown() or something similar.
Use a particular keyboard and/or mouse pattern. In other words if within 2
seconds of starting the application you press the 7 key on the number
keyboard or hold down both the left and right mouse buttons, execute your
code to save the checksum calculated into the registry. Again here, deviate
from the plan above. Make sure it something that a user is not going to come
across by accident. Retrieve your checksum with the RegistryEdit windows
program and store it in your setup program.

Keys to security:

1) Don't compare using constant values. If(X==0xFFFFFF) etc. This results in
ASM that looks like CMP eax, 0xFFFFFFFF JNE LABEL. If you use a file editor
like mine and my link below it makes it easy to find the proper compare
value and change it in the exe. Soooooo many trial programs do this. I've
seen it with timers, variables and other things. These include largely known
programs from large companies. Always use 2 variables (mem locations to
compare). Avoid using if(X==true) statements as well. These result in TEST
EAX, EAX JNE(jump not equal) label. Another thing that's really easy to
find.
2) Don't take the first true comparison likely. Don't say just because you
tested your checksum or what have you once that the app wasn't touched. Do
this numerous times throughout the coding. Preferrably with 2 or 3 different
functions and checksums. (thus if one is found and defeated there are still
numerous ones to go)
3) Take a look at your ASM coding with the de{*word*81} CPU view. Since you
wrote the code you have the advantage of looking at each source C++ line. If
you can change one of the J(conditional) statements to the opposite will
your program react well? Example:

if(checksum!=ChkSum)//checksum loading from file, ChkSum loaded from
comparison source.
{
 Application->Terminate();//or other stop program

Quote
}

results in ASM coding

CMP EAX(accumulator or another register), [memlocation+(possible index), or
another register] // says compare the two values in C++ coding above
JNE (or JE [depends upon compiler] LABEL
CALL DWORD PTR [Application->Terminate] (/this will be the address of the
address to call from the compilers map file
LABEL
//continue on

Now if you find this JNE(0x75) or JE(0x74) in a file's exe will changing the
value of JNE or JE to the opposite result in an easy workaround to the
security? Although this would be VERY difficult to find without a de{*word*81}.
To help anti-hardware debugging hacks see my weblink below.

    It's best to use the final comparison in your applications OnIdle()
event handler. Since the de{*word*81}s limitation is that it isn't very useful
stepping through the event handlers since the app needs focus and the
de{*word*81} prevents it without giving the app full focus. And comparisons in
your event handlers are extremely numerous. However, once the main
application is focused the pause in the de{*word*81} may be used to once again
step through the coding. To get around this before you check for your
comparison check to make sure your application has window's focus. ;-) If it
doesn't de{*word*81} might be in use and return from the event handler before
you do the comparison for the checksum.

In this case yes. That's why never trust the first comparison checked.

Read up on Microsofts Help Docs. Use a search for CHECKSUM and you'll find
more info but not this detailed. Good Luck! Hope this wasn't too confusing.

John

--
Use file security for your password and regular applications. Find out how
at http://home.att.net/~special_projects/security.htm
It's Free!

Get The File Editor Professional
http://home.att.net/~special_projects/TheFileEditorProfessional.htm

Join the Shareware Authors Assessment Team see
http://home.att.net/~special_projects/home.htm for more information.

Quote
Leslie Bortels <lbort...@vub.ac.be> wrote in message

news:86nakr$q0q24@bornews.borland.com...
Quote
> Hello,

> I want to make an *.exe that stops working after some period of time, even
> if the user has been fooling around with the internal clock of his
computer.
> My idea is to put the actual date (hours are not important) somewhere in
my
> code (*.cpp file), and recompile the whole thing.
> When the *.exe file is started by the user, it retrieves the date of his
> computer and compares it to the "compiled" date I putted in.
> Why question is

> 1. How to put the date in my program (use of TDateTime or something else)
> 2. How to get the date of the user's computer
> 3. How to compare both dates

> Thanx a lot for your help!

> Bob

Re:comparing actual time with build-in time


Quote
Leslie Bortels <lbort...@vub.ac.be> wrote in message

news:86nakr$q0q24@bornews.borland.com...

Quote
> Hello,

> I want to make an *.exe that stops working after some period of time, even
> if the user has been fooling around with the internal clock of his
computer.
> My idea is to put the actual date (hours are not important) somewhere in
my
> code (*.cpp file), and recompile the whole thing.
> When the *.exe file is started by the user, it retrieves the date of his
> computer and compares it to the "compiled" date I putted in.
> Why question is

> 1. How to put the date in my program (use of TDateTime or something else)
> 2. How to get the date of the user's computer
> 3. How to compare both dates

> Thanx a lot for your help!

> Bob

Er, one second you say that you want your EXE to stop working at a certain
date "even if the user has been fooling around with his clock" (phew, nearly
spelled that incorrectly!) and at another you want to find out what the date
on the user's computer is.  Your solution will not work.  Any solution using
the computer's clock can be circumvented by the simple expedient of changing
the time on the computer.

You will need a more sophisticated method.  Even so most of them are a pain
to implement and can usually be circumvented anyway.

Some developers use 'nag' screens -- the program displays a "Please pay for
this software" dialog every now and then.

Other Threads