Anti-Piracy Tips & Tricks

Some Anti-Piracy tips that from my experience regarding software protections I consider very important..

Activation related Strings

Don’t leave unencrypted strings such as “Invalid Serial”, “Code accepted”, etc, in you application.

Decrypt those necessary on runtime and re-encrypt them when you don’t need them anymore.

Even better, don’t use them at all!

Activation related MessageBox

Don’t use serial/keyfile verification MessageBox or anything similar using strings as those mentioned above.

Let your algorithm evaluate the serial, keyfile etc..and just activate or not the software.

Trial related Nag Screens

They are usually used by crackers as a “path” inside the protection itself.

Avoid them at all costs!

Trial Software with limitations

If you have decided to limit the functionality of the trial version of the software, then why would you include the code of the functions which are normally offered in the licensed version?

Just don’t!

Function Names

If you think that naming protection related functions like “IsValidCode()”, “IsRegistered()”, “IsDebuggerDetected()” etc.., is a good idea then shutdown your computer now!

In case you use some ready-made code such as A.R.F, rename these methods and the related class names into something less obvious.

After all, this is one of the reasons, and benefits of having the complete source.

Debugger Detection

If you use any kind of debugger detection methods, do it silently. Don’t let them know… that you know.
In case that a debugger has been detected do not terminate the process or even worse notify the attacker about it.

Do some run-time modifications instead that they will make the application crash later-on.

In case you are using methods that target specific debuggers and/or reversing tools as for example the ProcessDetection method of the A.R.F , then encrypt their names and decrypt them one by one during the detection process.

Code Obfuscation

Create custom code obfuscation for every application and don’t use specific patterns. Do it as more randomly as possible and use different methods.


Use public key cryptography algorithms such as RSA using extremely large integers, bigger than 1024-bits if it’s possible.

Use some variables that get modified in case a debugger has been detected, it will make the algorithm produce wrong verification checks.

Don’t place your serial verification algorithm into a DLL which just does that. It will be much more easy to isolate the algorithm and analyse it.


Encrypt-Decrypt code sections on run-time and re-encrypt them using checksums of sensitive code sections as keys.


Destroying the PE header on runtime, it is effective but well-known. Don’t stick just to that.

Use encryption-decryption and on fly re-encryption of specific code sections that are used only once by using random keys on re-encryption.

In case someone dumps the process image from memory the right decryption keys won’t work anymore.

Commercial Software Protections

Before using any of them such as a Packer, make sure that you have *at least* done all the above.

In case you have created a dedicated DLL just for the activation verification, don’t just pack that. The attacker will have just to patch the return values inside the main application or in the module that DLL returns the values.

Pack everything, if it’s possible.

Do some research before choosing the commercial protection. Ask around…

The above list can be modified/updated. Stay Tuned!