Our clients must pay a monthly Fee... if they don't, what is the best way to block the asp.net software usage?
Note: The application runs on the client own server, its not a SaaS app...
My ideas are:
Idea: Host a Web Service on the internet that the application will use to know if the client can use the software.
Issue 1 - What happen if the client internet fails? Or the data center fails?
Possible Answer: Make each web service access to send a key that is valid for 7 or 15 days, so each web service consult will enable the software to run more 7 or 15 days, this way the application will only be locked after 7 or 15 days without consulting our web service.
Issue 2 - And if the client don't have or don't want to enable internet access to the application?
Idea 2: Send a key monthly to the client.
Issue - How to make a offline key?
Possible Answer: Generate a Hash using the "limit" date, so each login try on software will compare the today hash with the key?
Issue 2 - Where to store the key?
Possible Answer: Database (not good, too easy to change), text file, registry, code file, assembly...
Any opinion will be very appreciated!
Ah, the age old issue of DRM. And that's what you're talking about here. Frankly, the fundamental answer to your question is: you can't. No matter what you do to the system, it can be hacked and modded in such a way that your DRM authentication scheme can be bypassed and/or broken.
This is a fundamental fact of software development: it can and will be pirated.
So, the answer to your question is that you will have to trust the client to pay you the fees you determine to be correct (which is the whole point of contracts in this situation).
Any other actions you take are a hardship and annoyance on your paying customer, and has the potential to erode your customer base.
Now, if you want control of your software in the nature described, then do not provide it to users to run on their own servers. Force them to be SaaS. In that way, you control all of that. But this is the only way.
Something that you don't appear to be thinking about, but I have seen networks which do not allow any type of "dial home" solutions, as a majority of the systems were internally focused and thus these internal servers were NOT allowed to contact the outer internet. At all. It was deemed a security risk to even allow them access. How would you handle those networks?
Frankly, if I was the customer, and I paid my fees to license your software (which I installed on my own device) I would be irate if I had to allow that device access to the internet in order for it to work. Doubly so, if the software in question was any type of financial management, customer management, HR management, quality management, inventory management, sales, or just anything related to my business, customers or employees. I don't trust software developers enough to have their software talk to something else when my business-relevant data is held in their software.
In the end, what you are describing is an antagonistic approach to take with your paying customers. If you don't believe me, look at the comments that UbiSoft is getting for their latest customer-hating DRM scheme.
IMO, you have two good paths here:
Go SaaS
Ensure your contract has a
bite for non-payment
usually you provide an scrambled key that includes a valid authorization token and the expiration date through which service is paid. Then the installer will use this to "activate" your software. Not sure how this would be viewed if you have 1-2 week periods. you'd want to warn them about upcoming expiration. Also not sure how to tell if they've set their own clock back.
In short, nothing will be perfect.
I've dealt with this before and its not possible to make a perfect system. There are risks in anything you do. The best thing is to weigh your options, and determine the method that has the least likelihood of being hacked and the most likelihood of working correctly and easily for the customer.
Like others have said, they could change their clock and invalidate the license checking mechanism. If you didn't trust the user, you could make the license system connect to your servers. You would then need to ensure that they always have a connection to your servers to check the license.
What if there is a valid reason that they cannot access your server?
Their internet connection has a problem.
YOUR internet connection has a problem.
In that case, should you disable the application? Probably not. But then again, what if they shut down the connection on purpose? Then you would WANT to disable the application.
If you give them a monthly key, you're adding a monthly annoyance and you may lose a customer after a while (people tend to do business with those who make it easy).
For example: If you base it on their clock, and the application needs their clock to be accurate for some reason, then its unlikely that the customer will change their clock.
I agree with Stephen but ultimately, I think that your contract is your best ally here.
As been previously mentioned, you don't want to inconvenience customers, especially if you have a large deployment.
As for SaaS, if I were a customer using your product and you said that the model is changing and we need to access the software from your server and ours must be decommissioned, I'd not be happy. I'd probably use the opportunity to switch packages.
In corporate settings, the contract really is the best way to handle these issues. I've worked on licensing issues for desktop and ASP.NET applications and they can cause a number of headaches for both you and your client.
However, if you insist on using something like this I suggest you go with a middle ground. Instead of only unlocking the application for a week or two, provide a license for 6 months or a year. This way, if you run into licensing issues (and you will run into issues) they only occur once a year rather than a couple of times per month. That will be cheaper for you in support and your clients will be less unhappy about dealing with licensing issues. If the company stops paying and you need to terminate the license you can handle that on a one-off basis, using contract enforcement as needed.
On the web service or client license options, I think a good license system would incorporate both. A client license to provide a the application a stable license and a web service to generate and deliver the license key when it is time for the application to be renewed. If the client won't allow the application to call home to get the license key also provide a manual entry method.
If you are going to store a license on the client, do not try to build a component yourself. There are many components available which will be much more robust and reliable than the one you build. There is a .NET .licx-based licensing method and a number of 3rd party methods that you can use. Which one is most appropriate depends on your scenario: how flexible you want the license and what other options you need. Most importantly, find something reliable - any time your customers spend fixing problems caused by licensing is non-productive for them and will reflect poorly on the application.
The important thing to keep in mind is that no system is fool proof. If your application is valuable, someone is going to figure out how to steal it. But at the corporate level and with custom software it's more likely the licensing will be used to remind people to pay rather than stop wholesale piracy.
Related
We've narrowed our selection for an ipaas down to the above 3.
Initially we're looking to pass data from a cloud based HR system to Netsuite, and from Netsuite to Salesforce, and sometimes JIRA.
i've come from a Mulesoft background which I think would be too complex for this. On the other hand it seems that Celigo is VERY drag and drop, and there's not much room for modification/customisation.
Of the three, do you have any experience/recommendations? We aren't looking for any code heavy custom APIs, most will just be simple scheduled data transfers but there may be some complexity within the field mapping, and we want to set ourselves up for the future.
I spent a few years removing Celigo from NetSuite and Salesforce. The best way I can describe Celigo is that it is like the old school anti-virus programs which were often worse than the viruses... lol... It digs itself into the end system, making removing it a nightmare.
Boomi does the job, but is very counter-intuitive, and overly complex. You can't do everything from one screen, you can't easily bounce back and forth between tasks/operations/etc. And, sometimes it is very difficult to find where endpoints are used, as they are not always shown in their "where is this used" feature. Boomi has a ton of endpoint connectors pre-built (the most, I believe), but I have not seen an easy way to just create your own. Boomi also has much more functionality than just the integrations, if that is something that may be needed.
Jitterbit, my favorite, is ridiculously simple to use. You can access everything from one main screen, you can connect to anything (as long as it can reach out to the network, or you can reach it via the network - internal or external). Jitterbit has a lot of pre-built endpoint connectors. It is also extremely easy to just create a connection to anything you want. The win with Jitterbit is that it is super easy to use, super easy to learn, it always works, they have amazing support (if you need it). I have worked with Jitterbit the most (about 6 years), and I have never been unable to complete an integration task in less that a couple of day, max.
I have extensive experience with Dell Boomi platform but none with JitterBit or Celigo. Dell Boomi offers very versatile and well supported iPaaS solution. The technical challenges of Boomi are some UI\usability issues (#W3BGUY mentioned the main ones) and the lack of out-of-the-box support for CI/CD and DevOps processes (code management, versioning, deployments etc.)
One more important component to consider here is the pricing of the platform. Boomi does charge their clients yearly connection prices. Connection is defined as a unique combination of URL, username and password. The yearly license costs vary and can range anywhere between ($1,000 - $12,000) per license per year. The price depends greatly on your integration landscape and the discounts provided so I would advise on engaging with vendor early to understand your costs. Would be great to hear from others on pricing for JitterBit and Celigo.
Boomi is also more than just an iPaaS platform. They offer other modules of their platform to customers: API Management, Boomi Flow (workflow and automation module), Master Data Hub (master data management). Some of these modules are well developed and some are in their infancy (API Management).
From my limited experience with MuleSoft platform, I share the OP's sentiments about it being too complex for simple integrations. They do provide great CI/CD and DevOps functionality though if that is something that is needed.
There is not a simple answer to a question like this. One needs to look at multiple aspects of the platform and make a decision based on multitude of factors. I would advise looking at Gartner and Forrester reports for a general guidelines and working out the pricing (initial and recurring) with the vendor.
I have only used Jitterbit, so can only comment on that. It works fine. It is pretty intuitive and easy to use, but does have some flexibility with writing your own queries, defining and mapping file formats, and choosing different transfer protocols.
I've only used the free version (which you need to host somewhere and also is not supported) and it was good enough for production tasks. If you have the luxury of time, I'd say download it and try it out. If it works for you, throw it on a server or upgrade to the cloud version.
One note: Jitterbit uses background services. If you run it locally and then decide to migrate your account to a server, you need to stop those services on your local. Otherwise, it will try to run jobs from both locations and that doesn't turn out well.
Consider checking out Choreo as well. It has a novel simultaneous code + low-code approach for integration development. And provides rich AI support for performance monitoring, debugging, and data mapping.
Disclaimer: I'm a member of the project.
My website provides extremely sensible information (think of bank account numbers) publicly available through webpages and webservices. The customers may modify these information when authentified with a username and a password.
Any hacking intrusion that would successfully modify the entries of the database, or modify the information displayed on the webpage, would be disastrous, as account numbers might then be incorrect and money could be directed to a malicious bank account.
Do you have any general advices about the architecture that would make such a service as robust as possible? I would not be responsible in case of a weak password, so my main concern is about attacks that would simply bypass the authentication process and modify the database without triggering any alert on my side; it could also be the html code of the webpage that is directly modified to show different information...
Thank you
In this case i would make sure to harden the system itself as good as possible. This includes a very broad spectrum reaching from Security Roles over transaction based usage of the database, logging as well as the prevention of all sorts of attacks like SQL injection, cross site scripting in general and maybe if its a that sensible system use certificates and general IP checks (like have a white list of IPs that are allowed to populate requests to the system that do not instantly get refused). Not to mention your Host architecture has to be protected regardless of the implemented security features inside your system (key words: firewalls, user privileges etc.). During the development process there should always be auto code checking software (like Sonar) running to detect logical errors and stuff.
Then it could also be a good idear to have a second system just to monitor your primary systems status. This system should log and notify you on:
changes made to the system itself (like if someone has access to your business logic and for examply removes authentication logic)
changes made to the database that are not consistent with your primary systems state.
detect suspicious actions: Banks for example have rules that apply on your account. Like if you used to make payments within europe for the last time and then out of nothing make a huge payment to lets say china you would recive a notification to commit this payment. The payment then would not be triggered unless that second commitment of the customer.
In the end you already pointed out correctly that you just can harden it as good as possible but generally not make it "100%" safe (at least in theory) so to have a good level of security part of the total system would include beeing able to detect unwanted changes, identify the exact changes already beeing made and have information on the overall status of your system to allow a rollback or manual correction of a corruptet state in case it already happened.
Even after having implemented mentioned techniques you would have to continously check for security bugs in used frameworks, librarys and the system as a full (like using security penetration frameworks that auto try to corrupt your system).
What i want to show you with my answer is what the comments already suggest: It is a very broad and complex topic with multiple layers of security concernes you will have to either study yourself or have framework solutions that "ensure" you to take care of the topic (like Webframeworks often include basic XSS prevention).
Without wanting to sound harsh, but if you have to ask this question on Stack Overflow, you're not really qualified to work on this project.
The financial value of your data sounds like it's enough for an attacker to expend significant resources breaching your defenses - and the consequences of such a breach would be disastrous for your organization and its customers; it could lead to the organization having to close down. You really don't want to be learning about security from strangers on the internet in this case.
One place to start learning in is with the established standards for managing financial information, often referred to as "PCI standards"; these provide guidelines for hardware, software and processes for organizations that deal with payment details.
There are numerous books on IT security; I like the "Hacking Exposed" series, and "Security Engineering".
You might also bring in specialized IT security consultants; I've worked with a number of these guys, and many of them are very good at helping you engineer security into your solution.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I have a commercial plug-in on top of Visual Studio.
My product is licensed per individual developer, so the developer may make copies on more than one computer, as long as the use of the product is by the same developer.
After a period of time I discovered that many of my customers purchase one developer license and distribute the product over all the team members (and it is not rare case).
I spent many hours (here in StackOverFlow and outside) searching on how to prevent this issue, but I found most of people talk about protecting per-machine license.
My question is how can I prevent my legitimate customers from illegally distribute my product over more machines if I can not restrict them to any number of machines?
Throw my search I get one solution, but I want to ask you if it is acceptable or not?
I can restrict the license per Windows user name, while the customer activate the product for the first time I record the windows username with the product serial number, so he can not run (or even reactivate) the product on any machine with another Window username.
If you purchase any product that licensed per-developer, is this approach is acceptable for you?? (or in the other side this policy may be reduce my sales?).
Best Regards,
You can use many forms of DRM to protect your product. Consider though that you will be hurting and annoying legal owners on occasion. If someone changed computers or reinstalled windows then he will not be able to install your product again. DRMs can also be broken and are usually never worth the time invested in them.
My advice is that you don't try to prevent piracy of your software, since you can't stop it. If you are aware of a specific client that abuses your license, send them a friendly but firm Email requesting they acquire legal licenses for all their copies. Failing that, you might want to pursue legal actions.
All in all, trying to fight software piracy is a lost cause. You might consider other types of licenses that make it easier for a company with multiple developers to acquire your plugin. If you give group discounts they are more likely to pay.
I guess it depends on how the plugin is used. If it's primarily used in an office environment where having computers set up in a windows domain is the de facto standard, then yes, it could be acceptable.
It could become a problem if the developers are used to being able to use the plugin at home on their home computer as well, since the username will probably not match.
Edit: You could perhaps set a limit of 2 usernames per user. That could solve the use-at-home problem.
I'd say trying to bind the license to the windows user name would be sufficient, and somewhat acceptable. In your case you likely don't have any protection against several machines/users/etc. using many copies of your license - making it trivial for several people to use it. Most legitimate people will buy the additional licenses if it becomes non-trivial to do otherwise, binding it to the login name provides easy incentive to get additional licenses.
Just keep in mind:
You can't protect against every way to circumvent licensing.
You don't need fancy license protection, you just need it to be easier
to get an additional license than it is to circumvent the licensing.
Don't make it hard to use a licensed product.
One caveat I have as a sole developer on some projects though, is stuff bound to just 1 machine (or perhaps user account) - I always need 1 additional license for my build server and/or my machine-at-home.
it is very annoying to have to pay for a license for that machine even if it's just me using it - so think about that. For your product, it'd mean I'd have to have at least 2 licenses - one for my work computer, one for my home cumputer (different users/domains).
Invent some kind of setting which everyone will want to have set their own way, and keep that setting value on your server, for a license. If it's the same programmer using the app from three different PCs, he'll have no complaints on that the setting is the same everywhere. (In fact, he'll like it). But different people have different tastes, and people will soon be tired of re-setting the option the way they like it only to later find it reset back to someone else's preference again. They'll think that maybe buying a cheap personal copy instead of going through all this crap is not a bad idea after all.
The more of user preferences you automatically move around, the better it is for a single user and the worse it is for cheaters.
Goerge, what you describe is pretty common in your industry. The battle is lost already. Small companies will not purchase as much license as they should, but bigger ones will eventually respect your licensing terms.
You must adapt your pricing strategy and take in consideration this fact.
Adding more protection will do the inverse, preventing you from getting new customers or keeping the existing ones.
Don't make it hard to use. I have seen bad results, like Blu-ray which almost failed because of so much DRM on them. Some people had to resort to Slysoft Any HD-DVD to play blu-ray because software player that was supposed to play Blu-ray wouldn't play the disc they bought.
I'm about to get finished developing a windows application which I want to release as shareware. It was developed in C# and will be running on .Net 3.5+ machines.
To use it the user will have to be online.
My intent is to let the user try it for 30 days and then limit its functionality until a registration is purchased.
The installer will be made available via an msi file.
Could anyone give the general steps on how to implement this?
Here are some more specific questions:
Since I am trying to avoid having to invest a lot upfront in order to establish an e-commerce site, I was thinking of a way to just let the user pay somehow, while supplying his email in which he then receives the unlock key.
I found some solutions out there like listed here:
Registration services
I am still not sure, if they are the way to go.
One of my main concerns is to prevent the reuse if a given serial, e.g. if two users run the program with the same serial at the same time, this serial should disabled or some other measure be taken.
Another point is, that my software could potentially be just copied from one computer to the other without using an installer, so to just protect the installer itself will not be sufficient.
Maybe someone who already went though this process can give me some pointers, like the general steps involved (like 1. Get domain, 2. Get certain kind of webhost ....) and address some of the issues I mentioned above.
I'm thankful for any help people can give me.
I don't have a useful answer for you, but I did have a couple observations I wanted to share that were too large to fit in a comment. Hopefully someone else with more technical expertise can fill in the details.
One of my main concerns is to prevent the reuse if a given serial, e.g. if two users run the program with the same serial at the same time, this serial should disabled or some other measure be taken.
To ensure that two people aren't using the same serial number, your program will have to "phone home." A lot of software does this at installation time, by transmitting the serial number back to you during the installation process. If you want to do it in real time, your application will have to periodically connect to your server and say "this serial number is in use."
This is not terribly user friendly. Any time that the serial number check is performed, the user must be connected to the Internet, and must have their firewall configured to allow it. It also means that you must commit to maintaining the server side of things (domain name, server architecture) unchanged forever. If your server goes down, or you lose the domain, your software will become inoperative.
Of course, if a connection to your service specifically (rather than the Internet in general) is essential to the product's operation, then it becomes a lot easier and more user friendly.
Another point is, that my software could potentially be just copied from one computer to the other without using an installer, so to just protect the installer itself will not be sufficient.
There are two vectors of attack here. One is hiding a piece of information somewhere on the user's system. This is not terribly robust. The other is to check and encode the user's hardware configuration and encode that data somewhere. If the user changes their hardware, force the product to reactivate itself (this is what Windows and SecuROM do).
As you implement this, please remember that it is literally impossible to prevent illegal copying of software. As a (presumably) small software developer, you need to balance the difficulty to crack your software against the negative effects your DRM imposes on your users. I personally would be extremely hesitant to use software with the checks that you've described in place. Some people are more forgiving than I am. Some people are less so.
The energy and effort to prevent hacks from breaking your code is very time consuming. You'd be better served by focusing on distribution and sales.
My first entry into shareware was 1990. Back then the phrase was S=R which stood for Shareware equals Registered. A lot has changed since then. The web is full of static and you have to figure out how to get heard above the static.
Here's somethings I've learned
Don't fall in love with your software. Someone will always think it should work differently. Don't try and convert them to your way of thinking instead listen and build a list of enhancements for the next release.
Learn how to sell or pay someone to help you sell your stuff
Digital River owns most of the registration companies out there
Create free loss leaders that direct traffic back to you
Find a niche that is has gone unmet and fill it
Prevent copying: base the key on the customer's NIC MAC. Most users will not go to the trouble of modifying their NIC MAC. Your app will have a dialog to create and send the key request, including their MAC.
The open issue is that many apps get cracked and posted to warez sites. Make this less likely by hiding the key validation code in multiple places in your app. Take care to treat honest users with respect, and be sure your key validation does not annoy them in any way.
Make it clear that the key they are buying is node locked.
And worry about market penetration. Get a larger installed base by providing a base product that has no strings attached.
cheers -- Rick
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 wrote a utility for photographers that I plan to sell online pretty cheap ($10). I'd like to allow the user to try the software out for a week or so before asking for a license. Since this is a personal project and the software is not very expensive, I don't think that purchasing the services of professional licensing providers would be worth it and I'm rolling my own.
Currently, the application checks for a registry key that contains an encrypted string that either specifies when the trial expires or that they have a valid license. If the key is not present, a trial period key is created.
So all you would need to do to get another week for free is delete the registry key. I don't think many users would do that, especially when the app is only $10, but I'm curious if there's a better way to do this that is not onerous to the legitimate user. I write web apps normally and haven't dealt with this stuff before.
The app is in .NET 2.0, if that matters.
EDIT: You can make your current licensing scheme considerable more difficult to crack by storing the registry information in the Local Security Authority (LSA). Most users will not be able to remove your key information from there. A search for LSA on MSDN should give you the information you need.
Opinions on licensing schemes vary with each individual, more among developers than specific user groups (such as photographers). You should take a deep breath and try to see what your target user would accept, given the business need your application will solve.
This is my personal opinion on the subject. There will be vocal individuals that disagree.
The answer to this depends greatly on how you expect your application to be used. If you expect the application to be used several times every day, you will benefit the most from a very long trial period (several month), to create a lock-in situation. For this to work you will have to have a grace period where the software alerts the user that payment will be needed soon. Before the grace period you will have greater success if the software is silent about the trial period.
Wether or not you choose to believe in this quite bold statement is of course entirely up to you. But if you do, you should realize that the less often your application will be used, the shorter the trial period should be. It is also very important that payment is very quick and easy for the user (as little data entry and as few clicks as possible).
If you are very uncertain about the usage of the application, you should choose a very short trial period. You will, in my experience, achieve better results if the application is silent about the fact that it is in trial period in this case.
Though effective for licensing purposes, "Call home" features is regarded as a privacy threat by many people. Personally I disagree with the notion that this is any way bad for a customer that is willing to pay for the software he/she is using. Therefore I suggest implementing a licensing scheme where the application checks the license status (trial, paid) on a regular basis, and helps the user pay for the software when it's time. This might be overkill for a small utility application, though.
For very small, or even simple, utility applications, I argue that upfront payment without trial period is the most effective.
Regarding the security of the solution, you have to make it proportional to the development effort. In my line of work, security is very critical because there are partners and dealers involved, and because the investment made in development is very high. For a small utility application, it makes more sense to price it right and rely on the honest users that will pay for the software that address their business needs.
There's not much point to doing complicated protection schemes. Basically one of two things will happen:
Your app is not popular enough, and nobody cracks it.
Your app becomes popular, someone cracks it and releases it, then anybody with zero knowledge can simply download that crack if they want to cheat you.
In the case of #1, it's not worth putting a lot of effort into the scheme, because you might make one or two extra people buy your app. In the case of #2, it's not worth putting a lot of effort because someone will crack it anyway, and the effort will be wasted.
Basically my suggestion is just do something simple, like you already are, and that's just as effective. People who don't want to cheat / steal from you will pay up, people who want to cheat you will do it regardless.
If you are hosting your homepage on a server that you control, you could have the downloadable trial-version of your software automatically compile to a new binary every night. This compile will replace a hardcoded datetime-value in your program for when the software expires. That way the only way to "cheat" is to change the date on your computer, and most people wont do that because of the problems that will create.
Try the Shareware Starter Kit. It was developed my Microsoft and may have some other features you want.
http://msdn.microsoft.com/en-us/vs2005/aa718342.aspx
If you are planning to continue developing your software, you might consider the ransom model:
http://en.wikipedia.org/wiki/Street_Performer_Protocol
Essentially, you develop improvements to the software, and then ask for a certain amount of donations before you release them (without any DRM).
One way to do it that's easy for the user but not for you is to hard-code the expiry date and make new versions of the installer every now and then... :)
If I were you though, I wouldn't make it any more advanced than what you're already doing. Like you say it's only $10, and if someone really wants to crack your system they will do it no matter how complicated you make it.
You could do a slightly more advanced version of your scheme by requiring a net connection and letting a server generate the trial key. If you do something along the lines of sign(hash(unique_computer_id+when_to_expire)) and let the app check with a public key that your server has signed the expiry date it should require a "real" hack to bypass.
This way you can store the unique id's serverside and refuse to generate a expiry date more than once or twice. Not sure what to use as the unique id, but there should be some way to get something useful from Windows.
I am facing the very same problem with an application I'm selling for a very low price as well.
Besides obfuscating the app, I came up with a system that uses two keys in the registry, one of which is used to determine that time of installation, the other one the actual license key. The keys are named obscurely and a missing key indicates tampering with the installation.
Of course deleting both keys and reinstalling the application will start the evaluation time again.
I figured it doesn't matter anyway, as someone who wants to crack the app will succeed in doing so, or find a crack by someone who succeeded in doing so.
So in the end I'm only achieving the goal of making it not TOO easy to crack the application, and this is what, I guess, will stop 80-90% of the customers from doing so. And afterall: as the application is sold for a very low price, there's no justification for me to invest any more time into this issue than I already have.
just be cool about the license. explain up front that this is your passion and a child of your labor. give people a chance to do the right thing. if someone wants to pirate it, it will happen eventually. i still remember my despair seeing my books on bittorrent, but its something you have to just deal with. Don't cave to casual piracy (what you're doing now sounds great) but don't cripple the thing beyond that.
I still believe that there are enough honest people out there to make a for-profit coding endeavor worth while.
Don't have the evaluation based on "days since install", instead do number of days used, or number of times run or something similar. People tend to download shareware, run it once or twice, and then forget it for a few weeks until they need it again. By then, the trial may have expired and so they've only had a few tries to get hooked on using your app, even though they've had it installed for a while. Number of activation/days instead lets them get into a habit of using your app for a task, and also makes a stronger sell (i.e. you've used this app 30 times...).
Even better, limiting the features works better than timing out. For example, perhaps your photography app could limit the user to 1 megapixel images, but let them use it for as long as they want.
Also, consider pricing your app at $20 (or $19.95). Unless there's already a micropayment setup in place (like iPhone store or XBoxLive or something) people tend to have an aversion to buying things online below a certain price point (which is around $20 depending on the type of app), and people assume subconciously if something is inexpensive, it must not be very good. You can actually raise your conversion rate with a higher price (up to a point of course).
In these sort of circumstances, I don't really think it matters what you do. If you have some kind of protection it will stop 90% of your users. The other 10% - if they don't want to pay for your software they'll pretty much find a way around protection no matter what you do.
If you want something a little less obvious you can put a file in System32 that sounds like a system file that the application checks the existence of on launch. That can be a little harder to track down.