In my desktop program, I want to check that to see if the user has set his clock back.
To do so, I compare the timestamp of certain Operating System files to the current computer date. If any are after what the computer thinks is the current date, then he must have set his clock back.
For Windows XP, I have been using such files as:
c:\win386.swp
c:\windows\user.dat
and several others.
Two questions:
Is this a decent way to do this, or is there something better?
(Assuming the answer to 1 is "decent") What would be some good Windows Vista and Windows 7 files to compare with?
Conclusion: Priyank said something obvious that had eluded me: Rather than using any system files, the easiest and simplest way might be to just use the timestamp of your program itself. After all, the date it was installed is exactly the date you want your trial to start from.
As it turns out, your answers and my research of other related StackOverflow questions and mentioned articles has led me to decide on a much simpler scheme. My trial users already have to get a key to use the trial. I've got the date registered embedded into the key. I really don't have to check for setting the clock back. Instead I can just seee if the current time is between the date registered and the date registered plus n days.
If they want to go to the trouble of getting around that scheme, then let them. I agree that those people wouldn't pay anyway. Make your program something worthwhile that people enjoy and want to use and most will pay.
Windows files will be always have earlier date, the best is to check the creation or modified date of your program with the system date. Or any time your program quit make sure to note the timestamp and compare it with the next time you start your program, and there is always NTP: http://en.wikipedia.org/wiki/Network_Time_Protocol
a better way to do that IMHO would be to store the current timestamp in registry the first time your program is ran and then compare that with the current timestamp on next run and update the timestamp if everything is OK.
This is not a direct answer, just to offer some opinion and references. Too long for me to add as comment.
If the purpose is to create a time-limited software for demo/trial use, we need to find a balance between how much you go about implementing it and the tendency for users to 'hack' pass it.
I've often tell people, if your software attracts hackers, it's probably something useful/good. No point protecting a software which no one finds useful.
Anyway, the philosophical talk aside, below are a couple good reads about this topic:
How to Implement time-limited trial on Joel's Forum
Time limited trial and Windows Certification on SO
Need Advice on Implementing a Time-limited Trial on SO
An option would be to get the date from a web service or time server. The problem here is that this only works if there is internet connection available, so this would be just a complementary method for a more safe one.
Windows provides APIs for notification of system time changes. One e.g. is the sysinfo.ocx activex control provided here.
Related
Firstly, I am not a professional coder. I am working for finance unit of an international firm, responsible of preparing financials etc. for regulatory bodies etc.
I have designed a PowerShell solution which looks for specific files in network drive and if it finds the files, sends them via outlook e-mail to my team members. But if it does not find the files, sends the e-mail with a warning text etc.
This was working fine until our IT admins applied a system-wide PowerShell Constrained Language mode. This mode prevents running of outlook-related e-mail automation commands in ps1 file and making my solution useless.
My 1st question is about bypassing this mode and the powershell itself. Can I design a similar solution in visual studio ? If so what kind of project should I work on, in which language?
My 2nd question is about insisting on my current solution. I can understand IT admins in my organization putting PowerShell Constrained Language mode into use, as there are risks of viruses and attacks with bad intentions. Is there any other way which eliminates these risks while keeping my solution still working.
p.s. I have excel vba codes of the same solution but I do not want to use it as it interrupts my work while I was doing something in excel (excel is nearly always open&busy in my PC).
As the comment thread contributors suggested, the way to solve this kind of issue is to talk to the management. Do not try to work around the technical safeguards, although it would be easy to do so. If you do, keep in mind that intentional violation of a security policy might be a fireable offence.
When dealing with your boss, a solution-oriented approach is often useful. Don't just complain about the policy, offer a solution. Write up max two pages memo explaining the issue. Include an estimate how much manual routine work you have to do, if they are error-prone, what are the effects of an human error and what more productive things you could do meanwhile. Even if it's five minutes a day, sum it up to yearly level.
The important thing is that you propose solutions. You could ask IT if they have any ideas. For example, IT could sign the script. They could take over the whole thing, so you wouldn't need to worry about running it anymore. Maybe an existing monitoring system could watch the files for you. Explore the options.
Don't overdo the memo, less your boss is going to wonder how many hours you've used to write a memo instead of, you know, doing your actual work. See The Workplace for further advice.
I am not sure if StackOverflow is the right forum to ask this question. If I am wrong, please point me to the right forum.
I am still junior android developer, and I always wondered about one question.
Do software developers sometimes use internet to check for code syntax or to check for some code for some action, that they never used before, or didn't use for a long time, and simply need to remind themselves about that code?
We use it for anything.
Don't know how to do something at all?
Ask the internet.
Know how, but forget what the function name is?
Ask the internet.
Remember the name, but forget the order of parameters?
Sing it with me: Ask the internet!
There are no rules about when it's OK and when it's not. Use it when it helps.
It depends on the personalty of the developer, I for one had a time in my life when i was code happy and all I try to do then is solve my own problem myself thereby impressing my fellow developers and peers, in return I wasted time doing one simple thing for days and time is money.
But as it is now, money must be made and more money to be made means more jobs to be done for clients.
If I have a whole lot of issues on my mind e.g the flow process of the application, the limited time frame to deliver, another job from a pestering client (who paid higher than the current client), personal problems, etc. The least thing I want to do is to disturb my head about some code I know but cant remember. I look it up in no time.
Yes, I look up a lot of codes i don't remember and wish not to remember and no one cares because at the end of the day it is the developer that get his/her job done at the specified time that is a good developer.
You will find out that as you grow in your career if you work as a freelance programmer, except in limited cases, NO CLIENT will tell you write a sample code to do bla bla bla.
What they care about is the manner in which you solve the problem they have. Your problem solving logic is what makes you a better programmer every single day.
It doesn't mean you should forget all your code but don't stress over it if you don't remember look it up, it doesn't cause a volcanic eruption in central park...lolz.
BUT you must also remember that if you make it an habit to always look up your code, in no time you will have issues reading codes and that is a crime as a computer programmer.
My advise for you as a
junior android developer
is that you learn to disconnect from the internet most times when you write your codes it will strengthen your brain to remember your codes better. Because what i have found out over time is that there are two types of programmers,
offline
online
The offline programmer would survive even in the desert but the Online programmer can only survive in the city.
Lastly if you were a client and you called two programmers to add extra page to an android application. Then you looked at their various systems and one of the was editing his code while the other was on google or other site like stack overflow with page title
How to add extra page to android application?
Be sincere with yourself who will you rather work with next time?
Don't get it wrong there is no crime in asking but sometimes asking is the last thing you want to do because its more shameful that stealing.
Wish you luck in your career path...trust me with consistency you will exceed your peers because you have chosen the extra ordinary careea path.
I am trying to set up an automatic uninstaller for a program. basically I want the program to uninstall after a certain time has passed (lets say 1 year).
Is there any way I could do this? It would basically be a trial version of the software.
Sorry for not being specific about this but i just want some options on how I could do this easily.
Thank You in advance for your responses and sorry for my bad English.
I have never seen such a design. I suppose you could use a scheduled Windows task, but why do this? You can just have the application expire after a year and offer a button on launch to kick off the uninstaller? It can launch the uninstall asynchronously and shut down the application right away.
I have also never seen such a design, likely because it fails to consider several issues, namely how do you keep users from:
reinstalling it?
installing it on another machine, or on a VM with snapshots?
restoring a hard drive backup over it?
killing the uninstallation?
Software licensing is hard to get right. I would recommend using a third-party licensing package that offers trial licensing. I would avoid trying to roll your own solution, as it will likely take you a lot of time to develop and be ineffective nonetheless. Picking the right product for this depends on first answering some questions, though:
How a. skilled and how b. determined will the adversaries be who are costing you the most amount of financial loss? That is determined by:
How much money will you lose if you don't protect it? This should determine the next question, which is:
What is your budget for software protection? It should be less than the amount you would lose without it. This should include the next question, which is:
How many hours do you want to invest to get this working?
It sounds to me like you want an automated wrapper that will work with precompiled applications / installers, as opposed to using an SDK you must integrate into your code.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I would like to add licensing system to application. For example: user buys license for 1 month and after that program expires (Kinda Anti-Virus style?).
Problem is that application is supposed to run in systems which may or may not be connected to internet, so how to protect from date-time changes?
Storing app startup and close times in encrypted file won't work as date can be changed (with program uptime of 8 hours per day, would be possible to extend license to almost 300% in ideal case - change time to app close time + 1 second before launching program).
Another question - is there any way to protect from software like http://en.wikipedia.org/wiki/Deep_Freeze_(software)? (maybe scan drivers?)
EDIT:
I'm currently using smart card to store licensing information and will use code virtualizer on critical functions (I know about making breakpoints on API calls and inspecting passed data - don't need to hide that data, just to ensure things go as planned)
Yes, it would be possible to extend the license by up to 300% but at great effort to the user. Frankly if someone is going to spend every day of a month resetting their time to one second after they quit your program before starting it again to use it longer, there is nothing you are going to do about it, and the time you take to stop them will cost you more than they ever will.
Step 1: Create trial_tracker entry in an encrypted format in a windows registry and in file.
Step 2: Assign app install timestamp ( yyyy-mm-dd-hh-mm-ss ) to trial_tracker
Whenever app starts, check if current system timestamp is greater than trial_tracker and less then expected expiry date
If yes, update trial_tracker to current system timestamp and continue.
If no, trial_tracker has been tampered or trial time expired. Ask user to purchase full version or exit.
Note: User can get away with this by deleting windows registry entry and encrypted file.( if he is able to find them ).
In such case, further checks can be added. For example create secondary windows registry entry which checks for existence of primary registry and encrypted file.
Along with these, additional remote checks can be applied which depends on internet connection ( optional )
Reputable game development manager stated once in a conference that it's impossible to protect software for longer than a month even with internet connection - if your software is popular :-) So you can just write software that no one wants and it will be as safe as you want :-)))
If on the other side you write reasonably popular software then you couldn't care less if a small percentage of paying customers snitch some extra time - they'll renew a week latter anyway. If you really want to do short time licensing you have to put internet as a pre-requisite. It's still going to be cracked in a month if it's good for something :-) but paying customers will by and large remain paying customers with reasonably light enforcement.
If however you piss people off by doing intrusive and scary things then you'll loose paying customers and create much bigger motivation for ppl to crack it.
Create a windows service that gets installed with your app, but is auto-start. Keep track of elapsed time and offsets there. Provide an API for your app to talk to the service to query usage/elapsed time.
I assume the software phones home at least once to let you know the license key has been bought / installed / extended?
After the time has ran out since they bought the license key and they haven't purchased another you could contact them and ask them how they are getting on and to let them know they need to renew. If they do choose to abuse your system a simple call to chat about it may be enough to get them to stop.
Maybe you could combine the use of the date/time with the tick count? Then if you see a date/time with an incompatible tick count, you could flag that as a violation. This would change your worst case scenario to require them to restart the machine whenever they want to manipulate the clock to abuse your license.
From your program you create a log of time when the app is launched and exited.The log is encrypted and prevent the common user to trick its content.
With this log, you can see if time elapsed normally that is time goes to the future. If not then something fishy is occurring on this system. In this case display a dialog box with a phone number where they can call you.
You could also ensure via a data file that the program can run for one month only after that as the said data file don't contain the data to work for the following month, this requires an update.
The idea is that time is flowing linearly to the future, it can only increase the counter from the launch date and external data is required for the program to run in the future so you've created a dependency relationship on updates. This last strategy is what Microsoft and co used and they call it security updates / patches...
You shall decrease the time elapsed between checks. Instead of checking only at application startup and application shutdown, you shall check every 5, 10 or 15 minutes using a timer or a background thread. In this way the user cannot change time (because the software will stops in few minutes).
However, I'd prefer to pay a software that I need instead of not having the correct date/time on my machine.
Create a Windows driver that starts on boot, grabs the system date-time, and runs until shutdown, tracking the time independently from Windows [ sleep(1000); ++time; ].
When your application starts up, check that the service is running, and check the date-time! Compare it to the date-time you were installed on, and you can figure out if you've expired or not.
Note: If any application did this, I wouldn't install it in the first place. If I WAS tasked with cracking it, it would be trivial. There is no way to prevent reverse engineering. NONE. It WILL get cracked no matter what. And when it does, you're going to regret putting any time into this.
Enable Privilege Use logging (in the installation process) and then check for a time changed event in Windows' event log, as explained here:
http://www.stevebunting.org/udpd4n6/forensics/timechange.htm
You can then deduct the time difference from the license (rather than void the license, since some system clock changes are legitimate).
NOTE: This will not protect from changes of the system clock when changed from the BIOS.
You are putting too much effort in the protection itself.
Instead your trial software should contains annoying limitations that will not prevent your users to evaluate it but will certainly prevent them from using it for business.
Maybe you could offer this software as a service if you are so worried about enforcing the licence?
One way to do is to store the current time and date of software download in an encrypted file that should be used along with the package.
Another way is to store file in the user computer and keep checking with your hard coded date in the software with that file.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Question for indie Mac developers out there:
How do I implement a 30-day time trial in a non-evil fashion? Putting a counter in the prefs is not an option, since wiping prefs once a month is not a problem for an average user. Putting the counter in a hidden file somewhere sounds a bit dodgy - as a user I hate when apps sprinkle my hard drive with random files. Any ideas?
This issue comes up repeatedly on the cocoa-dev mailing list and the consensus answer is always do the simplest thing possible. Determined hackers will break all but the most over-engineered solution. And they're unlikely to pay for the software anyways. Go for the 80/20 solution: the easy solution that gets 80% effect for 20% effort. In this case, putting something in ~/Library/Application Support/your.app.com/. You might name the file something innocent if you want to obfuscate things just a bit. Using the user defaults is easy too.
Whatever you do, don't use the MAC address or an other hardware ID. Users with a network home directory (e.g. in a shared lab setting) will hate you. Using hardware IDs is just evil.
If someone is in love with your program so much that they're willing to break your trial limits, let them. The free software costs you nothing and their good will (and maybe recommendation to others) is worth a lot.
Finally, write software that people want to use and price it for its value. If your price is a good value and people want to use it, most people will pay for it.
I would suggest to implement few of things which are less intrusive and may avoid a normal user to either uninstall or buy at one month period.
Use a special series of trial-serial number which stores expiry date in it. You can use encrpytion to store expiry date within the serial number.
Now create a configuration file which stores data in the encypted format and contain the serial number.
Additionally implement these things in the config file.
Make a note of time/date every time user starts the application.
Note the duration of the time application was open.
By doing the logging of timestamp you can avoid these workarounds:
If user reverses the computer date, you would know that app was already run on that day. Say user ran app on 1 and 3 day of month. Now after 30 days reverses the date and sets it to 2nd of month. Now by config file you would know that app already ran on 1 and 3 so user has messed up dates on the computer.
Let’s say every time user starts your app by first setting date to 5th of the month. By logging your application running time you would see that if the total hours in a day exceed 24 then user is fooling around.
Ensure that your app doesn’t run without the config file. So essentially you send the encrypted serial number in a file or maybe upon entering the serial number you can create file. Since the serial number already has the expiry date user can’t reuse the serial number also.
I would not suggest the internet way because people get pissed off when app tries to connect to server every time. Plus, one may get suspicious that you trying to send some personal data of users to your servers.
One thing I would like to say: No matter how strong the anti-piracy technique you use, someone is bound to break it. You are not making your app for those guys. You are making your app for people who would like your software and will buy it happily. So have the anti-piracy in limits without losing the genuine customers by making your application too intrusive during the trial period. One thought also says, if your software is getting cracked that means it’s getting popular also. Again opinions may differ and would not like to digress on these issues.
Consider this. How many potential users of your software are out there, just itching to use it solidly for the next 30 days?
I suspect the far more normal case is: Users encounter a new software package that solves a problem they've had on a site like lifehacker.com. the software gets downloaded, played with briefly, then put aside. Perhaps its mp3 ripping software and they don't have any cd's to rip at that time. Or they're just busy that day, but they'll get round to reviewing that software 'soon'.
30 days pass. Probably more. Only Then do they buy a CD, encounter some sort of 'problem' and remember, 'aha, theres that trial version I downloaded! Where did I put it again?'
It doesn't matter. Without ever being used, the 'trial' has timed out.
I can't count the number of software tools that have fallen into that bucket for me. The day a piece of software is recommended to me, the day I see a positive review on lifehacker, is NEVER the day I actually have a need - or even the time - to use / analyse the program I've downloaded and intalled.
Having the software expire after 30 calendar days is bad because what if someone downloads it, runs it once, and then decides they'll evaluate it a month later? Next time they launch it, a month later, it'll say it's expired.
I'd go with having it limited to 14 launches, or something like 120 minutes of use.
As for implementation, a file (hidden or not) in the user's Preferences folder, with an obfuscated name, seems like the best way to go. The file isn't randomly placed on the hard drive, but the user can't easily figure out which file to delete.
The least evil way is to just ask the user to delete the program after one month or pay for it ;)
We did it for one of our client application. Granted it was done in .NET for Windows, but the same principles can be applied in MAC.
Like eckesickle mentioned, if your user have access to the internet (or should), then you can have a web service that will register some unique id from the host computer with the starting date trial (MAC adress is a good one). With this, the user cannot really cheat the program unless he chances his network card every month.
Now, if the user doesn't have access to the Internet for some reason, you can either shut down the program until he connect to it or use a grace period. This file records the last time the app is opened. When the Internet is not accessible, we stop writing the time (we still write something in it so the user doesn't notice the file is not updated).
Should a user notice that this file contains the information and delete it (or change it using a copy he has), then you need a way to counter that. You can have some other value in another config file (encrypted always) and check for consistency. What you do if you discover that the user is trying to cheat is up to you, but we force the user to connect to the internet for it to work.
It might be overkill for a program, but it definitly works.
At the time of download, provide them with a trial serial number. When they enter the serial number, have it connect to your server and gets expiration information (stored and encrypted locally to prevent any additional "phone home" calls).
By doing it this way, you make it fairly hard for them to get around your 30-day window, as the expiration date is permanently stored on the server. You could set it up so deleting the key and re-entering it would cause your application to connect to your server again and download the same expiration date as before.
Or you can do it like WinZip does (or used to do it?): Provide a 30-day trial and just pop-up a screen at every load that shows how long you've been using it and links to purchase.
I used to offer a 30-day lite edition of my iOS app that embedded the install date and various record dates in the export data file that the user could download to his/her computer.
If the user was a cheapskate and just reinstalled the lite edition and tried to re-import the data, logic would notice that at least one of the date was older than 30 days and the app would set its install date to the earliest such date from the file, rendering it expired again.
In the full paid edition, this logic didn't exist and the data file could be imported easily.
It was a pain supporting people in this data migration (since apps are completely sandboxed from one another) and some other users felt the lite edition was enough for them so they never upgraded.
I've since stopped offering my lite edition and just reduced the price of the full edition. Now potential customers just have to pay a small amount or go find some competing software.
All in all, that was the best strategy for getting paying users.
Read an UUID from some hardware component and make a check against your web service to see if your software has already been installed for 30-days upon program launch?