In principle that is an interesting approach. It makes the analysis/cracking the code much more and in some cases the cracker just gives up because of the long time needed to analyze the program. However, this does not mean that this approach is cracker-proof! Think of it, programs written in p-codes, like old QuickBasic programs or even VB are much similar in concept to the emulation idea. And we all know though difficult, they CAN be cracked/patched. The basic problem is that the emulated/p-coded/VMed/anything program is yet a PROGRAM: a sequence of bytes that do something logical. Each one or few bytes represents an operation or some data and together, they form a routine or logical sequence of operations. Now, one your x86 computer you may execute/interpret/emulate the bytecode sequences of x86, Z80, QuickBasic p-code, Java VM, ... but theoritically you are doing the same thing and the cracker using a generic approach can analyze and crack/patch your program. This methology, relies one hiding the information and once you know the meaning of the byte-code, you can read and understand it with no problem. So there is no surprize that such methods, however complex in first look, will be finally cracked. Well, only if the cracker is really motivated to do so...