Being able to debug and test the execution of a program is a must for almost any kind of programming language, and it is especially true for SCRAMBLECODE, given the fact that the bytecode is executed by a VM DLL in an encrypted "black box" kind of way, which also makes it necessary to use a customized debugging tool.
Tools to debug the execution of an application can represent a security conflict, as the transparency provided by these tools can be used by crackers to gain valuable knowledge.
When developing the SCRAMBLECODE debugger it was evident that it should be based on a design which even in theory could not be cracked to acquire any form of knowledge about the internals of a VM DLL - especially not providing insight into the execution of bytecode made by others.
The seemingly most obvious thing to decide was, whether the debugger should be able to monitor the VM DLL in real-time from the outside or from the inside?
After careful consideration neither option was chosen because:
Instead it was decided:
The security implications are:
This design is simple and safe. It isolates the involved elements and eliminates functionality which could otherwise be of interest to crackers.
Having the debugger work in this detached (non-real-time) manner has some consequences:
When the bytecode has been compiled to include trace instructions, the VM execution will produce a trace file with a list of recorded trace events. This file is considered confidential and should not be revealed to outsiders.
The trace file contains values in plain text, which to some degree may reveal what your bytecode is doing. It also contains certain indirect references to your source code, however these references do not reveal much about your code. Never the less a cracker might find the information helpful.
WARNING: Released bytecode should never include trace instructions.
You are strongly advised not to execute bytecode containing trace instructions in less trustworthy remote environments.
If this can't be avoided you should switch off as much trace functionality as possible and only manually insert library functions for trace into your source code at the hot spot, where analysis is needed.
In case analysis is required for situations related to a potentially unsafe customer site, you are advised to bypass tracing all together and instead implement your own proprietary functions in bytecode to report logged information in an encrypted manner. Please keep in mind the semi-secure nature of big strings and perhaps use an encrypted blob for each part of the log-information instead.