Previous Next

SCRAMBLECODE Architecture.

SCRAMBLECODE includes an Integrated Development Environment (IDE) with source code editor, compiler, test bench and debugger all-in-one.

The IDE provides a simple and safe environment, which facilitates easy side-by-side installation of different versions, and that doesn't require the installation of other tools.

SCRAMBLECODE is custom made from the ground up with security in mind. This includes all elements of the IDE and the VM DLL, because it is imperative that the solution can't be cracked to attack the bytecode from you or anyone else. This design strategy is especially evident with regards to the debugger which implements a disconnected functionality as described here to eliminate any risk of being compromised by crackers.

It is also worth mentioning that SCRAMBLECODE is based on SCRAMBLECODE. The IDE uses bytecode for certain security related tasks.

Security Aspects.

SCRAMBLECODE is based on the High-level VM Security protection scheme, which provides the strongest and most versatile protection against debugging, disassembling, memory analysis etc.

Your license allows you to create a number of unique RSA key pairs, and for each key pair SCRAMBLECODE can create a personalized VM DLL for you. Each VM DLL is different from any other DLL, and each DLL uses completely unique virtual assembler instructions and encryption that only works for this particular DLL. Each VM DLL has the public key part embedded to authenticate that the bytecode was compiled by you and signed with your private key - making it impossible for anyone to execute their bytecode on your DLL.

However, SCRAMBLECODE adds even more security measures by including multi-layer encryption techniques, encrypted memory storage and much more as described next.

Securing an Application.

Your application is probably programmed in C/C++, C#, Java, Python, Pascal, VB or another similar programming language capable of loading a DLL. For simplicity we may occasionally refer to your host application as a C/C++ program.

To secure your application, the confidential aspects should be moved to SCRAMBLECODE and executed as compiled bytecode in a VM by the DLL.

Any secret functionality of your current source code must be moved to the IDE and adjusted for the SCRAMBLECODE programming language. As a rule of thumb it is usually only relevant to move a small percentage of the source code, perhaps porting even less than 1% of your code.

TIP: The source code in the SCRAMBLECODE editor can be compiled, tested and debugged in the IDE completely independent of your application. This makes it easy to develop and test your ideas before making any changes to your application.

Encrypted Compilation.

SCRAMBLECODE compiles your source code into encrypted bytecode that contains thousands of virtual assembler instructions, which are only understandable and executable by your personal VM DLL.

The compiler strips the bytecode for any kind of meta data. All assembler instructions, jump addresses, fixed constants etc are encrypted by the compiler using a multi-layered encryption scheme. It offers a lot of randomness to ensure that each compilation returns a very different result each time, and the individual parts of the bytecode are entangled in such a way, that changing a single piece of the bytecode will invalidate perhaps thousands of other pieces of the bytecode.

SCRAMBLECODE uses a Single Target Compilation technique, where the compiled bytecode can only be recognized and executed by your VM. The compiler generates randomized virtual VM assembler by using random selection among interchangeable instruction sets only recognizable by your VM. This means a recurring instruction may be expressed differently on each occurrence.  

Finally the compiler signs the bytecode with a private key only you know about. The associated public key is embedded into your personal VM DLL and is used for authentication to verify the loaded bytecode has not been tampered with.

Encrypted VM Execution.

The DLL can load the bytecode into a VM without breaking vital internal encryption layers.

The VM executes the bytecode using memory encryption of every single variable - even for the VM stack and registers. The type strictness of the source code (eliminated during the compile process) allows the VM to store any kind of encrypted data in typeless binary arrays using ever changing encryption schemes.

Using this approach it is no longer enough for a cracker to do statical or runtime analysis of the executable or the memory. Now the runtime data must constantly be identified and decrypted, and at the same time be properly interpreted as a binary executable, that is running a VM, which is executing an encrypted bytecode program, that is specified in virtual assembler.

And this may extend even further, as any VM may instantiate and call other VMs, if you so desire. Using multi-threaded execution of VMs in separate threads is also possible.