Skip to content

Virtual Machine Settings

Code Virtualizer Virtual Machine settings

Available Virtual Machines

This panel lists the Virtual Machines available to the protected application. Some are public, while others are created for specific customers. Contact info@oreans.com for information about custom Virtual Machines.

If you protect the same application twice with TIGER, each output contains a unique TIGER Virtual Machine. Register positions, instruction handlers, opcode tables, and other details differ between builds. Only the internal TIGER architecture is shared. An attacker must first understand that architecture and then account for each variation.

Code Virtualizer also provides multiple independent architectures. Comparing TIGER and LION is similar to comparing Intel x86 and ARM processors: each uses a different design and instruction set.

The table shows whether each Virtual Machine is used, its number of Instances, relative Complexity and Speed, and estimated Size. These values may change between internal revisions.

The Instances field specifies how many variants of an architecture to generate. Each instance has different register positions, handlers, opcode tables, and other internal details. When several instances are selected, Code Virtualizer distributes protection code and VM macros among them.

Virtualization

For legacy VIRTUALIZER macros that do not name an architecture, select which Virtual Machine should process them.

Guidelines to select Virtual Machines

Adding as many Virtual Machines and instances as possible does not necessarily provide better protection. Use these guidelines:

  1. Use one or two Virtual Machines. Adding many architectures and instances increases the size on disk and in memory; some Virtual Machines exceed 1 MB. SecureEngine omits selected machines that are not assigned to protection code or macros.

  2. Name the architecture in each macro, for example VIRTUALIZER_TIGER_RED_START/END, instead of using the generic VIRTUALIZER macro. This lets you use strong architectures for sensitive code and lighter ones where performance matters.

  3. Consider changing architectures in later application releases. Using a newer or different architecture makes previous analysis less useful to an attacker.