@PawelK @mr_poindexter I would explore the Predicate as it includes an executable. Using the VM inside a capable VM could allow for some possible routes. The executable in the Predicate seems pretty solid but it might be vulnerable. If there is a VM that can stop clock cycles, it might be possible to change values in memory and swap back before the next instruction.

Stopping the clock and through the instruction as slowly as possible could bypass a check, change a value and replace it before the next check. This would normally not work as it has a count that would fail. Instead of loading it to memory, it could possibly be a link to a value using the second VM.

So I suppose a very advanced VM running the target VM. Using the clock to stop the instructions and feeding info in from the primary VM. It has to deal with encryption so it might not be possible or feasible.

It seems to be fairly resistant to tampering but this could work as nothing was altered. It gets fed information and the clock stops when it gets to something good. That could potentially be selectively swapped. With enough granular control over a CPU and memory, I could see it being possible.

There are a lot of potentially desirable outcomes but it's seemingly well protected against traditional methods. It could be easier to break the computer instead of the VM. This would seem to be the best way to do it as it is rather robust. Perhaps loading a region of memory before the instruction counter starts and have a pointer to it. It's a really cool exercise and the documentation was good.