The compiled bytecode consists of SCRAMBLECODE assembler instructions. Each instruction may include a number of operands. The operands typically contain bytecode constants, references to variables, storage locations, jump addresses etc.
SCRAMBLECODE assembler instructions are not machine code instructions and are not bound to a specific platform. This means the same bytecode can be used in both 32 bit and 64 bit environments. Thus we refer to them as virtual assembler instructions.
Although each virtual assembler instruction does not directly refer to a machine instruction, they are still rather low-level to minimize overhead and provide a readiness for execution. It is the responsibility of the compiler to convert the source code into virtual assembler instructions that do not need any further parsing, type considerations etc. This is important for security and for speed as well.
When the bytecode leaves the compiler it has been encrypted on multiple levels. This also means every virtual assembler instruction and every operand are encrypted individually to the lowest level.
This has the advantage that the bytecode can be loaded for execution without breaking vital internal security layers.
During execution the involved assembler instructions and their operands may be briefly decrypted, although many instructions can execute without decrypting some or all of the involved operands. If a code path is not accessed, those internal elements are not decrypted.
All instruction commands and every operand of the bytecode are encrypted and intertwined in several ways to ensure, that if a single piece of bytecode is changed illegally by a cracker, lots of other bytecode items will no longer be correct. This will usually create an avalanche of load-time or runtime problems.
Furthermore the bytecode overall is also protected by an RSA signature, which is packed as an integrated part of the bytecode. The signature is used to authenticate the bytecode has not been illegally tampered with during transport etc. This is described here.
When doing an execution of the bytecode, the assembler instructions are identified and executed by an in-memory execution engine known as a virtual machine (VM).
SCRAMBLECODE is deployed with both a 32 bit and a 64 bit library (both known as VM DLL files), which are responsible for loading, executing and freeing each VM. It is possible to have the VM DLL start up many VMs in memory and have them execute simultaneously, each using different bytecode.
The VM DLL files included as part of the down-loadable SCRAMBLECODE installation are primarily intended for evaluation purposes, but each customer can buy a license that allows them to create and deploy a number of completely unique VM DLLs, which each uses different instruction sets that are only understandable for the customers compiler setup. This is known as Single Target Compilation. The essence of this is: Only you can generate bytecode to execute on your VM DLL.
When a VM executes virtual assembler, these instructions can belong to more than one set of assembler instructions. Each VM can actually recognize and work with many instruction sets at the same time. These additional instruction sets are still unique to only your VM DLL.
This allows the compiler to specify a given instruction using different identities by random selection among the available instruction sets. As a consequence a recurring virtual assembler instruction may be expressed differently on each occurrence.
The internal details of the compiler, bytecode format, assembler instructions or the VM DLL execution engine may change between SCRAMBLECODE versions.