Protojo

Introduction into software protection

In the modern world, software authors rely on specialized solutions for software protection to curb piracy. Implementing a robust, in-house custom software protection system has proven to be time-consuming, tedious, and complex. Any mistake during the implementation of software protection features could result in a critical vulnerability, making it easier for hackers to crack the software with minimal effort.

Software protection solutions: the standard default way

Most (if not all) software protection solutions operate in the following manner: the compiled application binary is processed and “packed” into a protective “envelope,” consisting of code created by the software protector. The goal is to “hide and guard” the protected software, making it challenging for hackers to study and modify. The protective envelope actively monitors the application, combats hacking tools, and encrypts and obfuscates its code to divert the hacker’s focus from the application code. A typical protected application generally resembles the figure below:

While this may seem like a good approach, in the real world, it is considered a weak protection against skilled hackers. Once hackers understand the protective envelope, they can create tools to unpack the application, removing the protective envelope and leaving the application susceptible to easy cracking. Furthermore, studying a particular protector’s code allows hackers to easily unpack all software protected with that protector.

Customize it, don’t just click “Protect” button. Enter the Protection Markers and Protection APIs

Software protector authors strongly recommend customizing your application to make it look and behave differently than a standard application embedded inside a protective envelope. This is typically achieved through Protection Markers and Protection APIs. Using Protection Markers guides the software protector on how and where to protect the application. Various software protectors use different Protection Markers; for instance, a Protection Marker might instruct encrypting a critical part of the application with a registration key or transforming it into virtual machine code to obfuscate the algorithm.

Protection APIs, embedded into the protective envelope by various protection solutions, are directly available for a protected application. These APIs enable the protected application to retrieve information such as the registered user name, check the trial period, and verify if there was a cracking attempt, among other functionalities.

A typical protected application with Protection Markers and Protection APIs appears as follows:

Following the recommendations for using Protection Markers generally strengthens the protection enough to make it really hard and even impossible to crack without a valid registration key.

Protecting Xojo applications. Introducing Protojo

Most software protectors don’t fully support Xojo applications because they were primarily designed for lower-level programming languages like C++. Although basic protection works for Xojo applications, extended capabilities like Protection Markers and Protection APIs do not. This is because Xojo is a high-level, cross-platform language that compiles to native code via several stages, using LLVM technologies. As a result, Xojo applications remain vulnerable to cracking even after being protected by proven and reputable software protection solutions.

Protojo is a Software as a Service (SaaS) that preprocesses compiled Xojo applications, allowing them to be protected with various software protectors. Protection Markers and Protection APIs fully function in Xojo applications for each supported software protector. Protojo is easy to use and only requires providing the path to your compiled Xojo application. The Protojo preprocessing step can be seamlessly integrated into Xojo build automation.