Protection Details

Parent Previous Next

Statical Analysis Protection.

SCRAMBLECODE makes it pointless to crack your application program, because the essential parts of your application does not exist as native assembler instructions.

Once the secret stuff in your application (maybe less than 1%) has been moved to SCRAMBLECODE and compiled to bytecode, there is nothing relevant to crack in your application.

The same applies to your personal VM DLL, which does not contain any secrets.

Your public key is embedded into your DLL, but it reveals nothing about your private key. However please notice that your private key must be kept safe and private within your company at all times as described here.

The compiler generates the bytecode as a simple string in base64 format, which can be stored or transmitted anywhere. It is encrypted in multiple layers and can't be decrypted without the binary identity of the VM DLL.

During compilation all meta data is eliminated - e.g. names for variables, classes, functions etc. do not exist in the bytecode.

The compiled bytecode is sealed using RSA asymmetric signature authentication as described here.

The bytecode contains encrypted virtual assembler instructions (ASM) - which are random selected among a vast number of interchangeable VM dependent sets of ASM opcodes.

Runtime Protection.

When cracking moves beyond statical analysis and starts to use more advanced technologies for memory monitoring, many security schemes offer little or no protection. This is due to the fact, that any protected block of data or instructions will eventually at some point exist in memory in its decrypted, executable form as described here.

Even though this fact always apply, SCRAMBLECODE does not suffer from it and continues to offer great protection, because it is based on the High-level VM Security protection strategy.

This approach involves 4 different levels in the execution of bytecode:

Level 1 (the binary) is the home turf for a cracker doing their usual statical analysis and memory monitoring of the DLL internals. Nothing new here.

But level 2, 3 and 4 require a new SCRAMBLECODE specific expertise for interpretation of memory events.

In addition to this please notice:

Furthermore SCRAMBLECODE implements deterministic garbage collection triggered by the programmer. This allows you to create and later recycle data at your will. If this is done at random, the storage can be even more different on each execution.