D-Jester:
No, there is no thread at all. If you look at my example code, the code itself is 'self decrypting' as it goes. There are no keys at all because there is no encryption. All it is is a piece of code that writes itself as it goes along. Like an interpreter if you wish, but both the interpreter and code is running together (same thread, same process, same time).

Crackz:
Yes you are right about the lack of keys. My proposed obfuscation does not work with any 'encryption' as such, and hence there is no key.

Regarding your comments on its weakness, it is definitely a problem if all the encrypted code is pointed by switch cases. However, in a limited size procedure, a complete static analysis on the assembler level is definitely possible (IDA does it alreayd). Using the the resulting flow graph, the entire procedure could in theory be encoded in this way, and there would be no obvious entry point as such.

The way I see it personally, to dump such a code completely, you would need to perform a static analysis as the code runs (through an emuator), and ensure that each branch in the procedure is executed at least once. The dumpers today cannot do this right? Or am I underestimating dumpers?

Thanks
Aur

zzsx: