Obfuscation - Proof of concept

Auroras' idea seems very similar to what the self-encryption/decryption algorithm MoleBox used: Basically, when the packer decrypts an instruction block before executing and encrypts the block again after execution.

Therefore, the file is never fully decrypted in memory.

This reminds me old int01 trick under dos.. like rob norten's copylock..
Hook int 01 -> decrypt instruction -> execute instruction and encrypt it again
So if you break into the code, ull get a bunch of illegal instructions.. kinda hard to understand...

RF

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: