Software protection by system time.

[Boki]

Hi All,

In order to implement a timer calculation ( to calculate how long does
the user has used this program since first time )

{
long CurrTime = DateTime.Now.Ticks;
textBox1.Text = CurrTime.ToString();

if ((CurrTime - FirstStartTime) > 10 * 10000000)
{
timer1.Enabled = false;
textBox1.Text = "STOP";
}
}

Pleaes advice the easier way to implement this line:

if ((CurrTime - FirstStartTime) > 10 * 10000000)

This is 10 seconds, how about 10 days ?

Thank you very much!
Best regards,
Boki

 

[Marc Gravell]

minus (on DateTime values) returns a TimeSpan; you can construct a
given TimeSpan very easily using:
TimeSpan.FromSeconds(10);
TimeSpan.FromDays(10);

Marc

 

[Peter Duniho]

minus (on DateTime values) returns a TimeSpan; you can construct a
given TimeSpan very easily using:
TimeSpan.FromSeconds(10);
TimeSpan.FromDays(10);

Very useful if you want to compare the result against a TimeSpan instance.

As an alternative, you could also just get the TotalDays property from the
result:

if ((CurrTime - FirstStartTime).TotalDays > 10)
{
...
}

Pete

 

[Boki]

Very useful if you want to compare the result against a TimeSpan instance.

As an alternative, you could also just get the TotalDays property from the
result:

if ((CurrTime - FirstStartTime).TotalDays > 10)
{
...
}

Pete

Wow, this is great.

Thank you!
Boki.

 

[Mike]

I am working on something simmilar and I'd like to ask you where you
save information about start time etc. (registry)?

 

[Peter Duniho]

I am working on something simmilar and I'd like to ask you where you
save information about start time etc. (registry)?

In .NET, the "standard" way would be to use the Settings for the project.
You can add new settings, and then access them by
Settings.Default.MySettingName.

Of course, for something like this you would probably want to encrypt the
data somehow, so that the user can't trivially just change the data where
it's stored (for settings, that would be in a user.config file, but you
could also store it in the registry or some other place, whatever you
like...and wherever it is, it's a place that the user can look).

Pete

 

[Mike]

If you provide demo application and if these data are removed after
deinstalation it doesn't make sens. My question is; what happens with
data stored in project settings after deinstalation of application.

I can save these data within registry or in some file (encrypted of
course), but if hacker decide to crack application he can track
processes and threads on application and catch the moment of writing
data in some hiden file. I think that is a good idea to hide these
data and encryptit.

I'd like to know what is acceptable standard to do this?

Mike

 

[Peter Duniho]

If you provide demo application and if these data are removed after
deinstalation it doesn't make sens. My question is; what happens with
data stored in project settings after deinstalation of application.

That's up to you, the implementor of your security system. But obviously,
yes...if you remove the data when you uninstall the application, it's not
around if the demo version is reinstalled later.

One way around this I've seen is to provide to the user an encrypted key
containing the expiration date, via some registration process. Then the
key itself used to unlock the demo is entered by the user, and it doesn't
matter if or when the application is installed and/or uninstalled. The
expiration is tied to the key, not the installation.

Other applications either don't delete the data, or make attemps to hide
the data from the user. The more securely this is done, the more likely
users will be annoyed at your security measures. At some point, you
simply need to accept that users will have a way to run your demo
perpetually, rather than doing evil things to their computer to try to
prevent them from doing that.

I can save these data within registry or in some file (encrypted of
course), but if hacker decide to crack application he can track
processes and threads on application and catch the moment of writing
data in some hiden file. I think that is a good idea to hide these
data and encryptit.

You can do that if you like.

I'd like to know what is acceptable standard to do this?

I'm not aware of any standard. Most of the mechanisms succeed primarily
through the obscurity of the mechanism, so obviously having a standard
mechanism would defeat the purpose.

Personally, I think software developers/publishers waste FAR too much time
on copy protection, and fail to take into account the impact that copy
protection has on legitimate, paid users, especially when there's a bug in
the copy protection, or the copy protection relies on some unreliable
mechanism (such as specific behavior of specific hardware on the computer,
or installing some sort of low-level component that makes an attempt to
hide copy protection information more securely than just setting the
"hidden" attribute of the file).

Pete

 

[Mike]

Thanks

Mike

That's up to you, the implementor of your security system. But obviously,
yes...if you remove the data when you uninstall the application, it's not
around if the demo version is reinstalled later.

One way around this I've seen is to provide to the user an encrypted key
containing the expiration date, via some registration process. Then the
key itself used to unlock the demo is entered by the user, and it doesn't
matter if or when the application is installed and/or uninstalled. The
expiration is tied to the key, not the installation.

Other applications either don't delete the data, or make attemps to hide
the data from the user. The more securely this is done, the more likely
users will be annoyed at your security measures. At some point, you
simply need to accept that users will have a way to run your demo
perpetually, rather than doing evil things to their computer to try to
prevent them from doing that.


You can do that if you like.


I'm not aware of any standard. Most of the mechanisms succeed primarily
through the obscurity of the mechanism, so obviously having a standard
mechanism would defeat the purpose.

Personally, I think software developers/publishers waste FAR too much time
on copy protection, and fail to take into account the impact that copy
protection has on legitimate, paid users, especially when there's a bug in
the copy protection, or the copy protection relies on some unreliable
mechanism (such as specific behavior of specific hardware on the computer,
or installing some sort of low-level component that makes an attempt to
hide copy protection information more securely than just setting the
"hidden" attribute of the file).

Pete