in the name of zero

June 29, 2006

e_entry hijacking

[ out of the blue personal project ]
school work is slowly getting the better part of me. that’s bad news. anyway, yesterday, i ditched class to start working on an idea that popped in my head (mainly because i found a new inspiration) for my very own crackme. it will be a very easily crackable crackme. no challenge whatsoever. in a nutshell, i’ll mainly be implementing a simple encrypted binary (hopefully with lots of pitfalls) thru the use of a polymorphic elf virii engine attached at a defined place where i fancy. i still haven’t gotten to the encryption and polymorphic engine part but at least i’ve made some progress with e_entry hijacking.

some rough ideas for the crackme:
a fully working elf binary would have an entry point defined in the e_entry section of its header. i’ll manually infect a program to attach the code fragment somewhere. distort every byte at the executable section and then update the entry point to the start of the decryption loop i inserted.

so onto the subject matter at hand - e_entry hijacking.

first, the asm program:

	global _start
section .text
_start
	mov eax, 0x4
	mov ebx, 1
	mov ecx, msg2
	mov edx, (emsg - msg2)
	int 0x80
	
	xor eax, eax
	inc eax
	xor ebx, ebx
	int 0x80
	
_end
	mov eax, 0x4
	xor ebx, ebx
	inc ebx
	mov ecx, msg1
	mov edx, (msg2 - msg1)
	int 0x80
	jmp _start
	
section .data
	msg1	db 'this is stage 1', 0xa, 0x0
	msg2	db 'this is stage 2', 0xa, 0x0
	emsg

a normal looking program. but look! you might have noticed that block _end is actually just some byte declarations enlarging the program. they don’t really get to resolve. why? because the program calls exit(0) before _end.

if executed, the above program would give.

steph@heaven ~/git/null/experiments $ ./custom_e_entry
this is stage 2

i verifed the entry address of the binary just for checking’s sake.

steph@heaven ~/git/null/experiments $ readelf -h custom_e_entry | grep -i entry
  Entry point address:               0x80480a0
and sure enough, that address was the entry point of _start
from objdump, i got the address of block _end. which is 080480bd <_end>:
so my task now is to located e_entry in the elf header and point to to block _end - that is point it to address 0x080480bd of course, it’s ideal if i had symbol resolution inside as well as manual address entry.

i modified the program here so it will adjust e_entry instead of corrupting the section information.

steph@heaven ~/git/null/experiments $ ./e_entry custom_e_entry

then i ran the patched binary to see if it behaves as expected.

steph@heaven ~/git/null/experiments $ ./custom_e_entry
this is stage 1
this is stage 2

now, instead of starting at _start the program begins executing at _end. hence the “this is stage 1″ string being displayed before “this is stage 2″. oh well, this whole thing is still pretty mediocre at it’s current state so it’s best if i move on.

[ love of condor heroes ]
need i say more?

[ graphics class ]
…makes me wanna sleep. especially because there are lots and lots of math involved.

Comments »

The URI to TrackBack this entry is: http://gnurbs.blogsome.com/2006/06/29/e_entry-hijacking/trackback/

No comments yet.

RSS feed for comments on this post.

Leave a comment

Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>


Get free blog up and running in minutes with Blogsome | Theme designs available here