Using Software Registrations to Protect Your Software Product
Software registration is used for a variety of purposes. For many box-item software purchases, registrations are used to obtain logistics information regarding the demographics of users, market penetration, and other valuable information. However, for the vast majority of shareware publishers, registrations are used to activate or de-cripple software.
Registrations also allow shareware software publishers to code in a bypass to lag and nag codes, annoying reminder splash screens, and other features that are used to encourage full copy purchase. The following is a look at some of the common registration techniques used in software code.
Unfortunately, no matter what the particular software package is, registration is often the weakest link to program security and financial profitability for any developer. Registrations often employ exceptionally weak measures that are exploited by even novice hackers allowing a complete bypass of the registration process in many software packages.
What are some common software registration schemes? One of most common software registration tactics is to bundle full version software with a time-limit activation, where a program will run only so many instances or for a limited duration of days or hours before deactivating. The good thing about this, is it removes the typical dishonest software user.
The bad thing about it, even remotely technical users can bypass this setting by changing back the date to avoid registration of your software. With Internet use so prevalent, it’s surprising so many software publishers still rely on system time or system date to drive time limited registrations. A simple lockout from the software if no Internet connection is available coupled with a quick check to a reputable national time observatory site to verify use when the system is on could allow the registration timer to progress without being so easily circumvented.
Another common software registration scheme is to require a identity and a universal software key routine. The good thing about this is it’s very low maintenance, requiring little coding, minimal book keeping, and can be automated through a simple website script. The problem with a USK is that while it was once a very good way of handling software registration, there is a significant problem with registrations resulting from the change from BBS interconnectivity used by a few users to a ubiquitous usage of the internet by a vast segment of population.
While it was once easy to use this technique and know that very few computer users were motivated to pay the toll charges and do the often-times substantial research required to find a valid registration code – it simply is no longer true. The best thing about a USK happening these days is the fact that the vast majority of “serialz” sites bundle malicious browser codes or computer virii which helps discourage the usage of these sites to find registration codes. Unfortunately it is not enough.
An extension of this registration scheme relies on a software specific key. Under this circumstance, the program will read information about its host environment and generate a specific key, which is used during registration process for obtaining an unlock code. This provides a great layer of registration security, as often the user is required to furnish a payment (establishing user’s identity) and the software can actually require registration user name to match payment registration code.
This approach also allows a software publisher to track down the original leak once a pirated copy is found in the wild. It’s by no means full-proof, but is usually much more valuable as a registration option than a universal software key approach. Regardless of the method software uses, software registrations are only as good as the code used to differentiate a registered and unregistered copy.
No comments yet.