I'm trying to make a system that basically allows me to shove a DLL in an installation and some code in an exe that allows me to release all of my future programs as beta releases for a while.
Now the problem is of course if I'd want to do that, i'd need to choose until when the program is valid. Which is fine, except that by changing your system clock, you can easily bypass the system.
Now, I'd like to hear what people generally do for something like this.
I've been trying a few approaches such as contacting a site to give the timestamp and compare that, which would be fine if it didn't always increase the program start time by over 9000
and and the fact that people would then not be able to use it if they're not connected to the internet.
Any suggestions are much appreciated.
This is not 100% guaranteed solution but it will take you there
You will need to implement these things in the config file (Why Config file, because if user deletes it your app won't run). Also encrypt all the following data.
Store the Date and Time on which application ran.
Store the exact amount of time for which application ran.
By doing so you can avoid:
If user change the computer time, you will come to know that, as your app is logging Date and Time, it might overlap the earlier time, say user ran app on 6th and 10th of month, and then he reverts date to 7th, you will come to know about it.
Secondly user can change the date on every run to single date, in that case the total duration used will help you. Say user set date to 1st of month every time he runs it, in that case, he can use app for 24 Hrs only not more than that.
Other options like
Checking time from External Server (Flaw: Requires internet access)
Storing Time in Registry (Flaw: User can easily manipulate registry)
Hope this helps you.
If your software can access some network share on some local server/nas, you can create a new file on this network share, and this file will have a creation time set using the clock of the server/nas, so you can compare the time set on the server/nas to the time of the local computer.
Or you can also save somewhere (a file, in the registry, in a DB) the last time of the last execution, and if the clock go back in time, then you can lock the application and require further assistance :-)
Related
Basically, I wouldn't find this anywhere. All I really need is date last executed, or even date last shutdown (that is, exe ended execution). I don't even need a catalog of all runs/shutdowns, just the last one.
I'm sure they must keep it somewhere. Reason being, in control panel (Win Vista) when you go to "programs & features" you have the option to sort the programs by how often they are used (which is run/executed) since this will not be based on last accessed time. Then, in their description, they quote usage frequency with terms such as "rarely", "sometimes", "often", "regularly" etc...
Now in Win7, if you right click on the columns & select "more..." from the installed programs listing control, you'll see a "Last Used On" option! This implies that last used date is at least kept somewhere in Win7.
Any ideas anyone?
Update: About LastAccess DateTime: LastAccess is too unreliable it seems (correct me if i'm wrong) it keeps on changing as soon as something (such as windows) accesses it. Maybe i should ask, does windows mess this field up by accessing the file to read info out of it (such as file size/dates etc) especially when browsing folders or does windows access files secretly to prevent contaminating the last access dates?
UPDATE 2
This is apparently different for MSI installations.
Information got from this thread (last post):
http://www.tomshardware.co.uk/forum/55552-45-remove-program-date
For an MSI installation Windows Installer maintains a usage count in its own registry > >based on Product and Feature, which can be found for example under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\\Usage
This is maintained by the Windows Installer API.
MsiUseFeature() increments the usage counter (http://msdn.microsoft.com/en-us/library/aa370502(VS.85).aspx)
MsiGetFeatureUsage() gets the Last Used Date and the Use Count
The usage counter is also incremented when launching an application via an advertised shortcut or when using one of the MsiProvide*() functions.
UPDATE
Check out this article:
http://blogs.msdn.com/b/oldnewthing/archive/2004/07/09/178342.aspx
It seems like those values aren't stored anywhere, but more like an assumtion. So you might aswell use the File.GetLastAccessTime to get this.
You could also use a FileSystemWatcher and Process. Then set a flag when the FileSystemWatcher sees a change and the exe is started.
I want to restrict the use of any exe file to specific number of iteration, lets say 10. After that limit is reached user shall not be able to run the exe file, or on running the exe file for the 11th time, he / she shall be greeted with a message "Exceeeded Trial Run" .
This is very much possible in C, like this - http://www.gidforums.com/t-22362.html
An example to accessing the PE header is here - http://code.cheesydesign.com/?p=572 , but it checks the timeststamp, whereas I want the number of occurrences the application has been launched .
I dont want to change the registry.
All suggestions are welcome.
Barring the existing comment about whether you should do this or not, the only other option besides not modifying the registry is to save something to a file in an encrypted fashion. Installing the app or exe would create the file and each launch of the application would decrypt, update, encrypt the file. But even then, that is subject o a user changing things without you wanting it. Security through obscurity is always a pain.
The surest way to prevent a user from exceeding some number of trial runs is to issue them a registration code (a GUID would work well) and then keep track of the remaining trial runs on your own database server. It would be exceedinly difficult to guess another user's GUID and impossible for them to hack the trials remaining (short of hacking into your server).
When the application runs, it could simply hit a small web service that would return the status of the software. If the web service cannot be reached, then the application would ask the user to connect to the internet and try again.
Short of that, there are not many options that could not be easily, easily hacked. Even if you encrypted the number of trials left, all the user would need to do is copy the file to somewhere else, then when they've reached their limit delete the original file and replace it with the copy... repeat ad infinitum.
The nice thing about this model is that, when the user purchases the full version, all you need to do is update your database and grant them full access.
If you wanted to let fully-paid users continue using the software without needing to connect to the internet, then on the first connection to the web server after paying the software could store a key file somewhere confirming the user's paid subscription. You could even create a hash based on the user's registration number to ensure that one user cannot use another user's key file.
If the subscription is annual, then a paid user's application could requery the server whenever an internet connection is available and recheck to make sure their registration is still valid. Or your key file could contain some encrypted date at which it would no longer be valid.
EDIT: A trial run based on a date would be much easier to implement. You could provide a key file with an encrypted date. Since the date would not change, the user would have a much hard time hacking the key file. Even if they borrowed or stole someone else's, they'd only get an extra week or two (depending on your trial period) before that, too, would become invalid. The difference is that a date based key file is static, making it much hard to spoof.
Now, another alternative is to combine the two approaches. You could have a countdown with an encrypted date in the same key file. That would ensure that, even if the user attempts to copy/replace the key file, the trial would still eventually end (maybe 10 uses/1 month, whichever is reached first).
I have an ASP.NET page that gets a list of game server ip addresses (quickly) and loops through them running a command line tool against them to get special game server information. I have to use the command line tool because I don't know how it works to get the information from the machines and I don't want to reinvent the wheel. The looping is the slow part (surprise surprise). Each command line tool run takes up to a second so with approximately 60 ip addresses polled on average, the page load can take from 30-60 seconds to render the results I need.
My obvious thought was "multithread that thing!" Well, I tried that w/ thread pools but ended up with a hanging website if more than one person accessed the page at a time. This was only using 4-5 calls at a time up to the 60 making it a 10 sec load time. So not only did it hang with multiple users, it was still too slow. I'd be happy if I could get it to under 3 seconds.
I should mention this page is in a shared hosting environment. I had a great solution before outside of the shared hosting environment but I had to cut costs and I'm trying to make it work w/ shared now.
Is there any hope?
You shouldn't really be polling these servers "on demand." It would be better to use ASP.NET to show the list of server information, and some other process - like a windows service, or scheduled task - to poll the servers every couple of minutes to generate that list. To summarize: The service would create an XML file (for example) and ASP.NET would display it to users. This way, the amount of users viewing the page does not affect the amount of times you try to poll the servers.
Update:
You need to ensure the process that pings servers is a singleton. Specifically, a singleton is a class in which only a single instance can exist. In more general terms for your case, you need to set a global flag that says "i'm currently pinging servers" and another global datetime value to says "the last time i pinged the servers was at hh:mm:ss" - you could use the Application dictionary to store the boolean flag and the datetime. Each time someone loads your page, check the flag to see if it's already pinging the servers. If it is, don't do it. If the flag says ok, then check the current time against the last time you did it. If it's less than 5 minutes, don't do it. All of this should be done in a background thread. This thread should update an xml file in App_Data. All requests to your pages should render this data immediately. A page request should never block. If the file is not there on the first call, then return "ping in progress, try again in 5 minutes." Follow?
Read about the ASP.NET Application state dictionary here:
http://msdn.microsoft.com/en-us/library/ie/ms178594.aspx
Low tech solution might be to call a bat file that makes each of the exe calls, instead of the exe repeatedly from asp.net. Saves the repeated shells to the OS overhead
Each call to the exe can pipe the results to a text file, which can then be read back all at once, once control returns to the asp.net app from the bat.
If the list of ip's change, then the the asp.net application could create the bat file before running it.
I'm planning to develop an application that will read a log file and display statistics.
The first question, I guess, is to know if I need a database or not?
Will it be quicker to run queries against the database ; or read the file each time a user wants to see the statistics?
If I choose the database method, I will have to read the log file and update the database on a regular basis (between 1 and 10 minutes).
Is this article still good do you think (as it's from 2005): http://www.codeproject.com/KB/aspnet/ASPNETService.aspx
Or is it better to develop a Windows service? In that case, can I add the Windows Serice in my ASP.NET project in Visual Studio, or does it need to be
You mentioned ASP.NET so I believe it is a web application. In such case I would suggest to use Data Base, this is more robust, flexible and distributed solution.
Any way consider using log4net and then you can easily switch on file/DB ouput in any time by simply adding an other one appender section into the configuration file.
If I choose the database method, I will have to read the log file and
update the database on a regular basis (between 1 and 10 minutes)
Exactly, you're going to have to do it anyway. The Database basically just becomes another bottleneck at that point. For this type of app, there's no need to do anything other than read the file when the user requests to see it, and display them the results on the fly.
No need to have a windows service either. I mean, I don't know all your details, but I'm assuming the log file is in a directory on your machine, so just access it, open it, parse it, and display it to the user when they choose to see it on the front end.
If the only data you going to work is LOG files, you don't need any database.
But I assume that your application would do parse logs files, create some statistics and STORE it somewhere, to make possible to users to get back and see statistics for some period of time. It is not cool if any time you will be "re-calculating" that statistics again (further more, you might loose original log files till that time).
Even if you could store it to some files also, I do not recommed that at all. Don't be afraid of using Database, don't be concered on application performace on such early stage. Do the most that helps you to solve the problem.. and as for me using Database will solve your problem;
I have written a program for one customer. I implemented a licensing method for him (signed XML files). This customer wants the application to be installed only once on his customer's PC, and wants me to "secure" this ... especially because his licenses are time-limited. Those PCs do not have internet access.
I told him this is absolutely stupid and it's not able to secure this kind of thing (VM eg.), but he wants at least a little "security".
Now I am looking for a good place on a Windows machine that is writable by every user (no UAC), where I can store some "secret" data (e.g. last time used) so the user can't just turn back time on the PC.
He should also not be able to just delete the application folder, set back the time, reinstall and use the program, nor should he be able to do this by deleting the actual user and using the software from a new created one.
I know this is something really really stupid, but my customer insists so...
I tried finding some places but with no luck so far.
Do any one you know of some directory that meets these requirements?
Maybe the registry would be better? Ya, it's a terrible requirement really. Maybe you could encode the installation date into the XML file as part of the installation process, obfuscate it some way perhaps.
I pretty sure process monitor would destroy this no matter what directory you pick, so just use a normal application data directory. There isn't a magic directory that will somehow help you hide the fact that you're reading/writing from it during the license check, and as long as you've told the customer how not-secure this is I wouldn't spend much time on it
In the past when I've had similar inane requirements I've used the registry. Here's what I do:
In an embedded resource, give the program the public part of an asymmetric key
When running, check for a few registry entries (detailed later). This is the first run, so they'll be absent
Send to a central licensing server the CPU serial numbers (and
possibly product serial number)
Server verifies that the CPU/serial has not been seen before,
generates an expiry date/time. If
they have, pulls up the old expiry
date/time. If expiry date/time is
passed, returns nothing, otherwise
returns old date/time
Server sends the client the expiry date time and all of the
information (expiry, CPU, serial)
signed with the private key
Client stores the expiry date/time and the signed data in the
registry
On subsequent runs, the client takes all of the information and
compares it to the signature. If
the signature is invalid, registry
information is deleted
So now, if the user runs the program after the window, the information is deleted, server will refuse to re-auth. If they try to copy to a new machine with registry info, signature check fails. If they install on a new machine, re-auth fails (due to different CPU serials). The only thing you can't really cover is if they always adjust the time, though you could find the time easily with a NIST check.
Downside is it depends on the internet and you need a licensing server.
Ok. I took a little of everyones suggestions :)
I am putting the file unter {sys}{My-GUID}\
and granting this directory full-permissions for everyone in my setup (innosetup)
Think this should be ... ok ... somehow :)
And # NullUserException : He is paying my car ... i can't fire him :)
Thanks for your answers