Obfuscation - Proof of concept

It seems to me that it should work against current image dumpers, and if so, how would one go about 'de-obfuscating' it.

Any specific reason you think that it work against image dumper? Once it is running, it can still be dumped?

Visu

To: retroer

But there the point is that there is no final layer of code. At any one point in time there is only a fragment of code available. If I had a psedo-code in the form:

select case
{
case 1: do blah;
case 2: do aaa;
case 3: do bbb;
}

At runtime, case 1 will only decode and run when it is selected, and after it finished it will have overwritten itself. I suppose if you knew there are three cases, you can go and capture each case directly, but I don't think image dumpers can grap it automatically and dump the code.

I thought most on-the-fly system merely decrypts a slap of code, runs it, and then deletes or encrypts it again (and hence allows capturing). Here, there is no encryption as such as the code runs itself. There is no distinction between real code and encrypted code. I know my example is obvious to crack because it is hand-written, but I can imagine a computer generated version.

To visu:
I just can't see what is there to dump, there is no point in time when the entire code. If the dumper saves each line that got executed, it will end up with quite a lot of invalid instructions (all the mov CS:IP, xxx ones), that is not conducive to auto dumping.

Aur

PS Thanks for the reply

[D-Jester]

Basically you are decribing armadillo but in your version you don't want to decrypt the entire program just the next part to be executed, and then you want to re-encrypt that part again after it has executed?

so basically:

[Legend]
Thread_1: Encrypt
Thread_2: Decrypt
Thread_3: Program Code

[Example Run]
Thread_1[Paused]
Thread_2[00001000...00002000]
Thread_3[Paused]
Next...
Thread_1[Paused]
Thread_2[00002000...00003000]
Thread_3[00001000...00002000]
Next...
Thread_1[00001000...00002000]
Thread_2[00004000...00005000]
Thread_3[00002000...00003000]

I think thats what you are saying...Its very possible to code such a protector, however because of how complicated it would be...I think it would be very predictable, and once you find a decryption key...

Reguards

[CrackZ]

Hiya,

D-Jester, I don't think his point is really about 'keys' of any sort since his obfuscation doesn't incorporate any such thing (correct me if I'm misunderstanding something though ;-) ).

The point here is to obfuscate the code flow and try to fool dumpers in the process since only one path is taken through the code on each run. I just can't see how this will work since if in all cases the code is presumably going to run, why will any dumper care whether its obfuscated or not?, a disassembler would be affected though.

So the first time the dumper gets case 1 which decrypts 1 piece of code, the rest of the cases stay encrypted (so any dump doesn't contain the decrypted other cases), on another run it gets case 3 and the others remain encrypted and so on.....

The weaknesses of this approach as I see it is 2 fold.

i). The manner in which you do the selection of a value for your switch statement;

and,

ii). Connecting each of the code block cases to actually do something useful and/or different in each case and that isn't very very obvious.

So this technique isn't really going to prevent even basic dumpers unless we need to care what happens inside each case.

Regards

CrackZ.