Last Modified October 2, 2026
  1. Home
  2. Guides
  3. Must Read Topics
  4. Hacking Protection

Protecting your App from Hacking

Hacking protection to prevent illegitimate Users circumventing your Application licensing should include multiple elements of an overall strategy that includes software_DNA protection.

No solution provides 100% protection from reverse-engineering and hacking, but the objective is to create multiple barriers to make it very difficult to crack through the licensing of your application.

Working to your advantage, in today’s environment, legitimate Users are more careful with hackers promising a hack around App licensing, that may also contain malware, ransomware and other nefarious add-on’s.

To date, hackers have targeted the Application itself and not the licensing library, because it is much easier to hack the App itself.

We highly recommend that you implement an overall Hacking Protection strategy for your App, which may include:

Application Signing / Notarization
(Mac OS / Android)

Applications targeted for MAC OS and Android OS generally need to be "signed" so that they can be distributed in the Apple Store and Google Store, and installed on the target device. Un-signed Applications are either flagged during installations or just not installed.

MAC OS Applications distributed outside the Apple Store need to be "notarized" by Apple to avoid being flagged during installation and start-up.

Users are thus aware if they are downloading and installing an Application from an un-trusted source.
Application Encryption
(Windows / Linux)

Encryption is a robust protection from hacking and is highly recommended for Windows or LINUX based applications, where Application signing is not the norm.
Code Obfuscation

Obfuscation attempts to make the Application's source code or machine code that much harder to understand and difficult for the hacker who may have reverse-engineered the source code or machine code of your application, in an attempt to circumvent your licensing implementation.

Obfuscation has many forms, and tools exist to automate this step. For example, in Android Studio, you can use the built-in ProGuard Obfuscation tool which will change / shorten the names of your app's classes, methods and fields to semantically obscure names. Other tools may alter your code, insert "dead code", replace function signatures, etc..

The overall objective is to make your source or machine code hard to understand for the hacker.
Detecting Runtime Environment

Many IDE's and frameworks allow you to detect if your Application is running on an emulator or in debugging mode, which would be quite suspicious for the "Release" version of your application.

Your application should just abort (immediately or delayed to confuse the hacker / user) if it detects this situation.
DNA Runtime Guards

Hackers may zero in on the API calls to the DNA Library within your Application and try to circumvent the main DNA_Validate() call at start-up.

DNA Runtime Guards take two forms:

  • placing several DNA_Validate() calls at critical / functional locations in addition to the main DNA_Validate() call at start-up
  • using the different DNA_Validate() variants (ex: DNA_Validate2(), DNA_ValidateCDM4() ) in your code that will have different function signatures in your compiled code

See Runtime Guards     for details.
DNA Library Authentication

Ensure that your Application is working with a valid / authenticated DNA Library, versus an illegitimate or hacked Library, as follows:

  • compute the MD5 or SHA1 Hash Code of the DNA Library (ex: DNA.DLL) file on the user’s device

  • compare it to the known MD5 or SHA1 code for the specific version of the DNA Library you are using

  • If it does not match, it is not a valid DNA Library, exit the program.

If your Application is signed, authenticating the library is optional.

For Windows and LINUX environments where Apps are usually not signed, authenticating the DNA Library is recommended.

 

MD5 or SHA1 Hash Algorithm

You must use the SHA1 Hash algorithm if your Users may be subject to FIPS (US Government) compliance. Do not include or use the MD5 Hash algorithm in such situations to prevent your App being blocked from running on Windows computers.

In all other situations, you can use either the MD5 or SHA1 Hash algorithm to authenticate the DNA Library.