Exetools  

Go Back   Exetools > General > General Discussion

Notices

Reply
 
Thread Tools Display Modes
  #1  
Old 03-21-2005, 21:10
auroras
 
Posts: n/a
Obfuscation - Proof of concept

Hi all

I was just wondering whether the following form of obfuscation will work. It seems to me that it should work against current image dumpers, and if so, how would one go about 'de-obfuscating' it.

The way is for the code to decode itself, without using any external decoders, and such that at no time will an entire copy of the code be present at memory. I have used simple mov [ds:si], xxxx instructions, where ds = cs, to generate instructions in real time starting at where older code used to be. Where there are decisions, only one of those decisions will be generated. Theorectically, other things can be also be done, but probably not by hand.

I hacked up the following in debug, and it works so far (since it is in debug, all code has CS:100 as base). It a simple function that will return a magic number based on the input in BX.

The original code is:
0BEE:0100 81FB5050 CMP BX,5050
0BEE:0104 7403 JZ 0109
0BEE:0106 31C0 XOR AX,AX
0BEE:0108 C3 RET
0BEE:0109 B83412 MOV AX,1234
0BEE:010C C3 RET

I decided to have 2 layers of decode, so the XOR AX, AX; RET and MOV AX, 1234; RET will be generated by generated code. This is what I have after encoding:

; Create CMP BX, 5050; Jz ??? <- we will decide where ??? later
; The created code will reside in CS:100
push cs
pop ds
mov si, 100
mov ax, FB81
mov [si], ax
inc si
inc si
mov ax, 5050
mov [si], ax
inc si
inc si
mov ax, 1074 -> Jmp to mov ax, 1234 etc - which will be at 0116
mov [si], ax
; Create the code to create xor ax, ax; ret - see commented code below
;
inc si
inc si
mov ax, 00Be
mov [si], ax
inc si
inc si
mov ax, B801
mov [si], ax
inc si
inc si
mov ax, C031
mov [si], ax
inc si
inc si
mov ax, 0489
mov [si], ax
inc si
inc si
mov ax, 4646
mov [si], ax
inc si
inc si
mov ax, c3b8
mov [si], ax
inc si
inc si
mov ax, eb90
mov [si], ax
inc si
inc si
mov ax, 90eb
mov [si], ax

; This code is the code to create xor ax, ax; ret
; The code will reside in CS:106
; It will be created
;0BEE:0106 BE0001 MOV SI,0100
;0BEE:0109 B831C0 MOV AX,C031
;0BEE:010C 8904 MOV [SI],AX
;0BEE:010E 46 INC SI
;0BEE:010F 46 INC SI
;0BEE:0110 B8C390 MOV AX,90C3
;0BEE:0113 EBEB JMP 0100

; Create the code to create mov ax, 1234; ret - see commented code below
inc si
inc si
mov ax, 06Be
mov [si], ax
inc si
inc si
mov ax, b801
mov [si], ax
inc si
inc si
mov ax, 34b8
mov [si], ax
inc si
inc si
mov ax, 0489
mov [si], ax
inc si
inc si
mov ax, 4646
mov [si], ax
inc si
inc si
mov ax, 12b8
mov [si], ax
inc si
inc si
mov ax, 89c3
mov [si], ax
inc si
inc si
mov ax, eb04
mov [si], ax
inc si
inc si
mov ax, 90ef
mov [si], ax

; This code is the code to create mov ax, 1234; ret
; The code will reside in 106
; And just to spice thing up, I will put the generated code in 106 instead
; of 100
; It will be created
;0BEE:0106 BE0601 MOV SI,0106
;0BEE:0109 B8B834 MOV AX,34B8
;0BEE:010C 8904 MOV [SI],AX
;0BEE:010E 46 INC SI
;0BEE:010F 46 INC SI
;0BEE:0110 B812C3 MOV AX,C312
;0BEE:0113 8904 MOV [SI],AX
;0BEE:0115 EBEF JMP 0106

jmp 100


Aur
Reply With Quote
  #2  
Old 04-06-2005, 09:54
retroer
 
Posts: n/a
Many of the modern protectors (like Armadillo etc), use on-the-fly decoding, execute and encoding again scheme, new in your scheme only 2 or more layers of decoding, but it nothing changes, because in final layer you decode and execute real code (without any kinda VM) and in this point cracker steal your real code
Reply With Quote
  #3  
Old 04-06-2005, 22:54
visu
 
Posts: n/a
Quote:
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
Reply With Quote
  #4  
Old 04-10-2005, 16:14
auroras
 
Posts: n/a
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
Reply With Quote
  #5  
Old 04-11-2005, 09:29
D-Jester's Avatar
D-Jester D-Jester is offline
VIP
 
Join Date: Nov 2003
Location: Ohio, USA
Posts: 269
Rept. Given: 39
Rept. Rcvd 61 Times in 41 Posts
Thanks Given: 0
Thanks Rcvd at 4 Times in 4 Posts
D-Jester Reputation: 61
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:
Code:
[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
__________________
Even as darkness envelops and consumes us, wrapping around our personal worlds like the hand that grips around our necks and suffocates us, we must realize that life really is beautiful and the shadows of despair will scurry away like the fleeting roaches before the light.
Reply With Quote
  #6  
Old 04-12-2005, 07:46
CrackZ CrackZ is offline
VIP
 
Join Date: Sep 2004
Posts: 49
Rept. Given: 2
Rept. Rcvd 67 Times in 8 Posts
Thanks Given: 0
Thanks Rcvd at 12 Times in 7 Posts
CrackZ Reputation: 67
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.

Last edited by CrackZ; 04-12-2005 at 09:02.
Reply With Quote
  #7  
Old 04-13-2005, 01:15
zzsx
 
Posts: n/a
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.
Reply With Quote
  #8  
Old 04-13-2005, 18:38
randall flagg
 
Posts: n/a
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
Reply With Quote
  #9  
Old 04-13-2005, 21:41
auroras
 
Posts: n/a
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:
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Tiny Basic Downloader Builder (Proof of Concept) YANiS Source Code 2 09-20-2021 17:49


All times are GMT +8. The time now is 02:32.


Always Your Best Friend: Aaron, JMI, ahmadmansoor, ZeNiX
( 1998 - 2022 )