SCRAMBLECODE   INTRODUCTION
Security-Oriented Programming Language: 
SCRAMBLECODE is an easy to learn programming language based on curly brackets and classes. It uses encrypted compilation to secure the code, and protects the execution while working with encrypted variables.

 
Integrated Development Environment: 
SCRAMBLECODE is deployed with an Integrated Development Environment (IDE) containing the editor, compiler, test bench and debugger. The IDE also provides content aware F1 help, code completion, symbol list of variables, classes, library functions etc.

The SCRAMBLECODE Integrated Development Environment

The IDE is here presented with a project named "License Validator".

ENCRYPTED COMPILATION
Private Assembler: 
SCRAMBLECODE implements a Single Target Compilation technique, that allows the compiler to switch among many different sets of private virtual assembler instructions. Due to this, each development project can use their own private set of instructions, which are not used by any other project.

Customized VM: 
In order to execute this private form of assembler, a virtual machine (VM) is custom created and only this VM can understand and execute the compiled code.

Anti-Tampering: 
Compilation translates the source code (all the classes, methods etc.) into a single block of bytecode based on the private assembler. Each instruction and every piece of data are encrypted, intertwined and bundled in multiple encrypted layers.

Finally the bytecode is signed and sealed with a private key (perhaps using an RSA 8192 bit key and SHA512) and saved as a simple base64 string ready for deployment.

Easy Deployment: 
Typically a VM is permanently deployed to many locations, but the compiled bytecode may be distributed separately as an ordinary string - e.g. as part of a text file or just-in-time deployed as a web response.

 
ENCRYPTED EXECUTION
Safe Load: 
The VM can load and execute the bytecode while keeping vital encryption layers intact. When a VM loads the bytecode, the signature is authenticated by the VM before the compiled code is executed. The required public key is embedded within the VM.

Encrypted Memory: 
While the VM executes the bytecode, the variables are stored encrypted in memory. The location and encryption of a given variable may differ on each execution.

Instructions to push, pop, move and many others can be executed without having to decrypt the involved content. This benefits speed and security.

Kill Actions: 
If an operation requires one or more operands to be decrypted, their values are usually very short-lived and quickly erased.

This is due to the memory management that performs zero-byte overwriting of freed up memory.

A flat stack design is also implemented to minimize deep nested functionality in order to have previous stack content constantly overwritten.

SECURING THE CODE
The Significant 1%: 
In order to protect your software, you must move the confidential parts of your software into SCRAMBLECODE and compile it. For most commercial applications you can probably maintain 99% of your program as it is, and only port less than 1% of your source code.

This 99:1 ratio is also true for SCRAMBLECODE which is used to protect SCRAMBLECODE. Yes, we take our own medicine. Actually the total amount of source code for our secrets is less than one percent. The rest is not that secret and is programmed using another language.

If your existing software is based on C++, Java, C#.NET or another comparable programming language, it should be quite easy for you to accomplish similar results. The SCRAMBLECODE programming language is all about writing classes and functions, as described in the Programmers Reference.

Impossible to Bypass: 
When moving code to SCRAMBLECODE it is important to combine secret functionality with essential functionality, making it impossible to bypass the protected routines.

For example, you could design your application to have certain parts of your application inaccessible, until a SCRAMBLECODE function has read and accepted a license file. The really important aspect is to include (bundle) other essential functions in the same compiled bytecode, which only will execute if the license was accepted.

TIP - Standalone Testing:  Download the SCRAMBLECODE Evaluation version and test your ideas before making any changes to your current software. Simply use the built-in test bench and debugger to verify all requirements are fulfilled.

WRITE, COMPILE, BUILD
The Compile Process: 
The figure below shows, how the source code is compiled and built into highly encrypted bytecode, which is finally signed and sealed with a private key.

It is done in 3 steps:
  1. First the source code [A] is processed and converted into anonymous symbolic structures [B] by removing all meta data.
  2. Then the compiler generates the private assembler, which is targeted exclusively to your VM. The assembler instructions are then scrambled, intertwined and bundled into larger encrypted entities [C]. This ensures nobody can crack and change an item (e.g. an instruction) without having to change perhaps thousands of other encrypted items as well.
  3. Finally the generated bytes are signed and sealed with a private key, which is the secret part of an asymmetric set of RSA keys [D] created by you. This generates the compiled bytecode [E].
The SCRAMBLECODE compile process

Please note: SCRAMBLECODE includes a key generator to create RSA key pairs [D] in 2048, 3072, 4096 or 8192 bit. A private key must be kept secret and safe at all times. The public key is later used by the VM to authenticate, the bytecode is untampered.

Eliminates Meta Data: 
The compiler removes all names and meta data in the compilation process. Feel free to be very explicit in naming your projects, source files, classes, functions, variables etc. It will not be included in the compiled bytecode.

INTEGRATE, LOAD, EXECUTE
Target VM: 
The generated bytecode is targeted at being executed by a unique VM DLL, which actually consists of the two native vm32.dll and vm64.dll files.

These VM DLL files are created by SCRAMBLECODE and have your public key embedded, and only your VM DLL files can decrypt your bytecode and understand the virtual assembler instructions deep inside the multiple layers of encryption.

Load and Execute: 
Your software application (the Host) must load the DLL file and use the API functions to load and communicate with the first VM. The DLL can have multiple VMs loaded and executing in parallel (multi-threading). A VM can also load and start the execution of other VMs.

C# Source for .NET Included: 
The API functions are very easy to use. The documentation contains a complete C#.NET Integration of all API functions with all source code available to demonstrate, how to easily integrate and use the API functions. Copy this C# class to get started.

 
The VM DLL
The VM DLL (the vm32.dll and vm64.dll) has the public key embedded. API functions (left) are used by the host to load and manage multiple VMs.

Safe Load: 
The bytecode exists as a simple base64 string, which is easily fed to the VM using the appropriate API function. When the VM loads the bytecode for execution, it can load the individual virtual instructions and any included hard coded constants without breaking internal encryption layers.

Randomized Memory: 
During execution all variables are stored encrypted in memory and in a randomized manner, which may change unexpectedly during the execution. In fact you get completely different results for each SCRAMBLECODE license, and each compilation, and each execution. The end result is extremely difficult to crack - even when utilizing advanced or specially crafted tools for debugging, disassembling, memory monitoring etc.

A VM with a grid of VM cells
A VM with a grid of VM cells.

 
Transfer Values: 
A VM can store values in a 2-dimensional grid known as VM Cells, which very much resembles a spread sheet with rows and columns. VM Cells are used to transfer values between the host and the VM, or from one VM to another.

A common example could be having the host write a lot of values (perhaps thousands) into the cells of the first VM before execution starts, and once the VM finishes execution (or activates a callback function), the host can read the results back.

VM Cells are by default not encrypted but can, when required, contain protected values.

TEST, DEBUG, DEPLOY
Internal Test Bench: 
You can test your code using the built-in test bench, without having to involve other applications.

This testing tool can feed the starting values to a VM before it is executed by specifying the arguments of the Main function and inserting values into the VM Cells. Once execution completes, the returned results can be read on screen.

Multiple test scenarios can exist simultaneously and be saved to a file to continue testing at a later time.

Full Debugging: 
The debugger can perform the usual tasks. It can debug the source code line by line, set breakpoints, run to breakpoint, run to cursor, step in, step over, step out, present the call stack, trace values etc.

It can also be used for more advanced situations, e.g. repeated debugging of the last thousand (or more) events before an error.

Royalty Free Deployment: 
Once everything is ready, you can xcopy deploy your VM DLL and the bytecode royalty free.

FULL DOCUMENTATION
This was just a small introduction to the most important aspects of SCRAMBLECODE. Please check out the full documentation.