I have an application which license should expire after some period of time.
I can check the time in the applicatino against the system time, but system time can be changed by the administrator, therefore it's not a good idea to check against the system time in my opinion.
What alternatives do I have?
Thank you
You could check against an online NTP server or, alternatively, at every run, note how many days have elapsed on the system clock. If they ever set this back before the time you know has currently elapsed, it will be obvious and you will know they are trying to cheat.
I'd say that forcing the user to run with the wrong date set would be enough deterent for most people. However, you could always combine it by storing the last run date in the registry and every time you compare that with today's date, if the the last run date is higher than today's date they've probably reset the date. There could be legit reasons for this though so you might want to have a check that you only disable the software after this has been done x number of times or similar.
you can use a counter so the user can use the software n times
anotherway is that you store the start- and enddate of the user starting the application.
If the user starts the application another time, you check against it.
Another way is to always check with an online server.
Related
I'm creating in-memory local cache of a network filesystem.
I want every directory/file to have LastDownloadedTime attribute, and then compare it with current time to decide whether the directory/file is too old to be used from cache.
But I'm uncertain whether DateTime.Now() is what I need. What happens if the user changes system time? How can simestamps suitable for my task be obtained in .NET?
Take a look at System.DateTime.UTCNow(). It'll return the UTC time. Just make sure you are consistently calling on both ends (when you store the cache as well as when you test it for expiration).
More info: https://msdn.microsoft.com/en-us/library/system.datetime.utcnow(v=vs.110).aspx
You should use DateTimeOffset. According to the docs:
Uniquely and unambiguously identify a single point in time. The DateTimeOffset type can be used to unambiguously define the meaning of "now", to log transaction times, to log the times of system or application events, and to record file creation and modification times.
If your application is running on a user's machine, though, they could change their system time (as you mentioned). The only way to prevent that is to have your application ping a time server to get an authoritative timestamp.
I think I'm going to use Stopwatch for timestamps, because my filesystem cache is in-memory, it does not survive system reboot. Timestamps are going to be relative to the start of the Stopwatch.
Though, Stopwatch is known to be buggy.
But I consider system clock-dependent solutions to be even more dangerous, as the user may set system clock to some date in the past, messing everything up.
If you are staying within bounds of local server then DateTime.UtcNow is the most convenient option for the task. Yes, if user changes local time, then that will invalidate cache and trigger unnecessary update.
You will need to use NTP (time) servers to avoid that problem. So, instead of using local server UTC time, you will obtain UTC time from NTP server (there are plenty of them available around the world).
Please refer to NTP wikipedia article
I am developing a windows application using C# and SQL and i want to store the time of some specific events in the db , i tried using the C# Datetime class but when i change my windows local time it does not give me the real date and then i thought maybe SQL has it's own date system,i searched but nothing comes up so what is the best way to have a secure time system? which the user can not easily manipulate the time that is storing in the data base?
Usually users cannot change the system time without administrator privileges. If your code is running on a untrusted machine where the user is admin, then you need another source of time. (Admittedly, your whole program can be compromised but this is another topic).
You can query MSSQL for current time as described here
SELECT CURRENT_TIMESTAMP
GO
SELECT {fn NOW()}
GO
SELECT GETDATE()
GO
Another way would be to query a NTP server somewhere else on the internet. This requires network programming. There is this SO question about it here
If you don't trust your workstation or the server time you can get the time from a NTP server and if that's not available still fall back to the local clock. An short example how to get the current time from an NTP server can be found here https://stackoverflow.com/a/12150289/2360972
I am actually very late for this answer.
I also had done lots of search for this answer & finally I got the best solution for this.
UTC is thestandard format to store your datatime in your application.
What is UTC?
UTC, or Coordinated Universal Time, is the standard international time that all time zones are expressed as offsets of. UTC does not get adjusted for daylight savings. To compute local time from UTC, simply add the time zone offset and then add an additional hour if daylight savings time is in effect.
Please Refer this link Your all doubts will get clear after refering this :
Click To refer
UTC time will always take server datetime & will not take your system datetime.
Also, If your application is running on different country then there is only one way to remove conflict between Time is to use UTC
This is very good Example for time related Issues :
Click Here
I'm looking for an example code how to know if it is the first time that the application is open in the day?
I tried saving the current date in a .ini file and an key named open defined with boolean value and then compare:
DateTime.Now.Substract(*old date from .ini file*).TotalMinutes >= 0
and after this, set open key in .ini file as true. how to implement it? there an way more easy to do it?
I need know of it because in first time that the application was open I'II update a list in database.
any help is appreciated. Thanks in advance.
Per user in Application Settings would be the place I would choose.
"Best" is a moving target. For one app, one method may be best, but another app may need something completely different.
That said, you need a few concepts to be covered:
Some place to remember the "last opened" time.
Some code to check the time, update it, and do the once-per-day work.
From your question, #2 is pretty straightforward, once you know what #1 should be. So, here are some potential options for #1.
Database (in a table tied to something like a user id)
Ini file (as you mentioned)
An xml file (maybe even inside app.config)
See my comments in your question regarding whether you are tracking on a lone workstation/multi-user, etc -- that will dictate where you store your date time (in the database, in machine-level scope, in user-level scope, etc).
Now as for what you store, if you are a multi-user app (or even mobile, like on a phone or laptop), don't forget to consider timezones. For that matter, don't forget to consider daylight savings time. (those changes in time could cause you to think that a day has passed, when it has not, or vice-versa).
I would recommend that you always store the time in UTC, and always compare in UTC:
// save the start time:
var startTime = DateTime.UtcNow;
(save the start time)
...
// comparing the times:
// also, are you worried about doing the check once per 24 hours, or do you want to go by calendar date?
// you already have code that does a once per 24hr check, so I will show code that goes by calendar days
if(startTime.Date < DateTime.UtcNow.Date)
// hasn't run today
else
// has run today
I'm developing an application and I need to make a demo version of it that will expire in lets say 30 days.
My idea for now is to store the current time when the application is first started in a simple txt file stored in the projects resource (so it doesen't have to be written on the hard disk or the registry), and every time the program is started check if 30 days have passed.
But, what if the user resets the time to an earlyer state?
Then my app would still start becouse now the "current date" can be 1 day after the "first start"..
Is there any way I can get some info along with the first date (or, insted of) that would assure that specific time that the application is first started?
Thank you for your time.
One of the option is to check the date time from some external server and not from local system. But this is also possible to crack as the user can put a proxy in between which will act as the external server to your app and this proxy can send any time the user want. In case you want the solution for novice users, external server approach is fine, but any smart user can still crack the application. Remember, any code that runs on a client machine can be cracked, you just need to flip the correct bit in the application code :)
I have a simple check in the code of one of my programs when in beta. It pretty much does what you say. In the initial code is a hard coded date. The logic then just tests to see if the current date is earlier than the hard coded date. Pretty primitive and it relies on the users system date. However once it is past the program will not run unless the system date is changed. As I mention I use this for betas not for my production programs that have an evaluation period. For that I use Infralution License Tracker. This is payware but it does allow the setting of evaluation periods and also the actual licensing of the code.
Interesting question - how about encoding the initial datetime somehow - base64 or even encryption of somekind), then also storing the datetime each time your application is run.
That way you can detect inconsistencies by checking each datetime and if there's funny business going on (eg. todays date is older than the last date) you can shut the user out.
I want to provide a trial version of my software. This version should only be evaluated within a specific period of time. Let's say only during January 2011.
As this software massively uses the system clock in processing, it would be quite annoying to set the clock to an earlier time to be able to use it over and over. So because of this, I wound't think of a more complicated protection mechanism.
So I have thought about exiting after a test like:
if (DateTime.Now.Year != 2011 && DateTime.Now.Month != 1)
{
MessageBox.Show("expired!");
Application.Exit();
}
How easy will this be cracked :-) ?
Is there a "safe" way to do this ?
Basicly you can say it is impossible to secure trial software against cracking. Everything you do in Software can be bypassed (Yes! Even Ring-0 Drivers).
Even if you have an external dongle from which you recieve the authentication to start can be spoofed through software. Although it isn't easy :-)
You can only make it hard not impossible :-)
It's not exactly related to cracking it, but it's worth noting that if this is an app that can be used internationally, it'll show as being 'expired' for many users before they've even had a chance to try it at all. The values returned by DateTime reflect the local users culture, so DateTime.Now.Year returns 1431 for Arabic cultures and 2553 for the Thai culture for instance. Months can similarly differ, so you shouldn't hardcode values for them without checking the culture first.
You can get round this by using the InvariantCulture each time ,e.g. DateTime.Now.Year.ToString(System.Globalization.CultureInfo.InvariantCulture);
This method could be cracked if the user set his computer Date to 2009: your software will be used for other two years.
If you want to use this method I think the best way is to check the actual date on the internet.
However some users couldn't have a connection; in that case you can use something like a countdown that makes the software executable for n-days.
You ship your software with an encrypted file that contains the date of installation;
The next time you will check for that file:
If exists and the day is different increment a counter;
If exists but is corrupted or if it doesn't exists update the counter to "max-day";
If exists but the counter is equal to "max-day" exit the application;
Update the old file with the new values;
Obviously the counter will be another encrypted file and, as for the other file, you have to check his state (corruption or deletion).
Here's my opinion.
The weak point of any time-limit or dongle-protection is that in the end everything must be checked with an 'if' statement. In the old 'x86 days there is JNE, JE, JNZ family of instructions. Such 'if' statement must exist in hundreds if not thousands or more in the application. So any cracker must find out where to start looking, for instance, dongle checkers almost always use DeviceIoControl API, which could be pinpointed quickly. After the calls to DeviceIoControl API found, the cracker just reverse engineered the routine around the API call, and try change JNE instructions around that to JE or the other way around.
In your case, the usage of DateTime is the tell-tale (but of course, there is a lot of place where DateTime being used for other things, that makes it harder for the cracker). To make things difficult for the cracker, copy the current date to some object's values, and try to make, like, 20 places or something that stores the DateTime. Or even better, retrieve current date from the net and also from the current computer. Don't check the DateTime directly, but use the value that you store in some objects before, to make it harder for the cracker. Use consistency check mechanism to ensure the dates are within tolerance, and kill the app if you find out that 2 of the datetime is different to the other stored datetime (give 2 days tolerance or so).
Also check whether the clock is not turned back by the user, if you found out that CurrentDateTime < StoredDateTimeInRegistry then you should store a kill flag somewhere in the registry. Or you might also want to use a file in addition to the registry.
For every kind checks you do, try to do it in many places and in different ways.
At the end, I must say that what Bigbohne said is true (nothing is impossible to crack) - it is just that, by making it difficult for the cracker, we changed his/her effort-to-result ratio, and hopefully discouraging him from continuing the cracking process.
Checking trial period expiration in C# code is easy to crack, even if you will obfuscate code due to it is compiled into CLR. It is better carry out this check into code that is compiled to byte code. Also you can read topic Protect .NET code from reverse engineering? about protecting .NET code from reverse engineering
Software licensing is a complete subject on its own, and it looks like that you are looking for a simplest solution to be implemented for your trial software.
What simply you can do, on startup of your application log the current date/time in registry and use it is as a reference point for validation. So even if the system time would be changed it wouldn't effect your application validation logic.
If possible, write the registry access library in C++, which wouldn't be possible to crack. Good luck.