Bitsum Technologies
On Software Protection
[ Under Construction ]
Last update: 11/25/05
| Software protection - Software developers know
there is no full-proof protection mechanism, and that there never will
be. Any developer with a reasonable amount of experience knows that any
protection scheme that claims to offer unbeatable protection is full of
****. All we can do is make cracking or reverse engineering as painful a
chore as possible, deterring the faint of heart and unskilled. |
|
| Before applying complex protection mechanisms to your
software, you should first weigh the advantages and disadvantages.
Although it may be a slap in the face, often piracy is helping revenues
more than hurting through an increase in exposure. In many cases, those
who can buy the software will, and those who can't will pirate it. The
best use of those who wouldn't have bought it anyway is to spread word
about your software. |
Piracy isn't always a bad thing .. consider if it is really hurting you. |
| One disadvantage of applying protection mechanisms is that some,
particularly complex ones, may compromise the stability and
compatibility of your application. If we assume that the level of
protection is proportional to the amount of compatibility and stability
problems, then one should select a protection scheme that meets
acceptable errata risks and desired protection. |
The level of protection is often proportional to the amount of errata introduced by it. Be wary of going overboard. |
| Increasingly, 'warez' groups use an unbelievably large database of
stolen credit card numbers to 'card' applications. Therefore, often
times the best protection mechanisms are defeated with a simple 16 digit
credit card number. One should keep this in mind when choosing a method
to protect their software, as it may be less necessary to include
extraordinarily complex mechanisms since cracking is going
'out-of-style' in favor of carding. |
The flavor of the day is carding, not cracking. |
| At this point, we'll assume that you've evaluated your software
protection needs and are ready to get some pointers. The first thing to
understand is that there is not, and never will be, a
generic/shrink-wrapped protection mechanism that will remain effective
for long. The reason is that generic protection mechanisms, being used
on many applications, encourage skilled reverse engineers and crackers
to develop automatic deprotection software. As soon as an automated tool
is developed, even unskilled crackers can easily have at your code. Even
protection software that uses polymorphism to vary its code and function
each time used is vulnerable to automated unpacking tools.
In contrast, custom protection mechanisms require dedicated effort targeted towards only one (or a handful) of applications. There is much less incentive for a skilled cracker to even get involved since the yield is so much lower than had they spent their time and energy on defeating a generic protection scheme. In the end, the best protection is always custom protection. Of
course, this isn't always feasible as not all developers will have the
time and/or money to do a custom job. In such a case, a combination of
generic and custom protection mechanisms is usually quite effective.
* |
No
generic protection mechanism will remain effective for long.
|
The most common list of technical
requirements of software protection are enumerated below. A savvy
software developer will pick the requirements most important to him or
her and allow for compromise if not all can be achieved immediately. One
good approach is to add new protection features incrementally, which has
the benefits of lower initial overhead and keeping your protection
mechanisms changing.
|
|
| As time passes, we'll continue working on this article ... check back as we enumerate the details of the ideal software protection. | |
| - Jeremy Collake / Bitsum Technologies | |