Whenever a value of some sort (Integer, String, Boolean or another one of the built-in Standard Types) is stored in memory by the VM, it is actually stored in an encrypted form as a typeless sequence of scrambled bytes. The same applies for constants in the encrypted bytecode.
All bytecode constants, variables, class fields, function parameters, function results, internal registers, stack values etc may use and store standard types in its encrypted form.
Due to this we think of standard types as secure types.
Many operations (e.g. push, pop, move etc.) can be performed on secure standard types without having to decrypt the involved content, but other operations can require the involved operands to exist in memory briefly in their decrypted form.
For a simple add operation C := A + B the operands A and B will be decrypted briefly to calculate the result C.
It is not considered unsafe to have a few pieces of decrypted data in memory as long as they are considered to be short-lived.
SCRAMBLECODE implements a number of techniques to make decrypted values short-lived:
Note 1: Please remember this does not refer to long lived encrypted bytecode variables, which may exist until they are garbage collected.
Note 2: This may seem a little over the top as free memory blocks are often recycled by the memory manager quite soon after release, but it increases safety.
The String type requires some special attention.
First two facts:
However, decrypted strings represent a particular problem. They are often very informative by their very nature and easy to detect in memory, especially if they are allowed to exist for a longer period of time, perhaps taking part in operations using core functionality of the OS.
Due to this, the String type is considered to be semi-secure and should be used with care: