in the name of zero

before anything else, lagalopex and devloop solved the crackme. special mention to lagalopex for identifying the cause of the bug that causes the segfault. the obvious fix would be to gurantee zero flag state before doing a jz/jnz but i simply changed the jz to a jnz because it was the most convenient thing to do.

1) the crackme is an elf from scratch binary that contains a few instructions inside the elf header itself.

2) the entire file is mapped “read/execute” to a text segment (thru an Elf32_Phdr) with a data segment mapped “read/write” in the middle (thru another Elf32_Phdr).

3) the crackme uses an array of function pointers to do flow control. the vptr table thingy i learned from studying the simple c++ binaries i made a month ago sort of inspired me implement a simplistic version. the address of the array is acquired by implementing a known/common trick used in many shellcodes. jump to an address, then put the address of the EIP on the stack plus transfer execution flow by doing a “call”, then “pop” to get the desired memory address (ret address) from the stack.

e.g.

_start:		jmp known_add
real_start:	pop edx		; this will pop the ret val on stack which is the address of function1
		...
		...
	
known_add:	call real_start
		dd function1	; start of function pointers...
		dd function2
		...
		...
	
function1:	; function1 block of intructions...

the crackme’s vptr table (which is really just an array of function pointers) start immediately after the elf head. why is this so? this is because i want the “call” instruction to be placed inside the elf header (occupying the last few bytes). so when anyone will do a readelf -h to try to get more info, they’ll notice that the last three fields are whacked.

$ readelf -h grainne
	...
  Size of section headers:           59392 (bytes)
  Number of section headers:         65498
  Section header string table index: 65535
readelf: Error: Out of memory allocating 0xe7dd9000 bytes for section headers

this also has the added benefit that function calls aren’t simply followed by jumping to the address to “call” inside an interactive disassembler.

some people in the crowd would try to fix (or nullify) related key fields in the elf header in the hopes at least getting gdb to work so if ever they did, they’d actually be erasing some instructions found in the elf header, e.g. the call instruction to determine the address of the function pointer array.

and because of how the elf head is contructed we could now expect scenarios like the ones below:

$ file grainne
grainne: ELF 32-bit LSB executable, Intel 80386, version 1, statically linked, corrupted section header size
	
$ objdump -d grainne
objdump: grainne: File format not recognized
	
$ objdump -x grainne
objdump: grainne: File format not recognized
	
$ gdb grainne
“/home/misha/grainne/grainne”: not in executable format: File format not recognized
	
$ ald grainne
Assembly Language Debugger 0.1.7
Copyright (C) 2000-2004 Patrick Alken
	
Segmentation fault

4) the crackme calls functions by first associating a signal handler to the SIGTRAP signal and implicitly calling the handler by using the 0xCC byte.

5) there are some garbage instructions like:

	push 0xbadc0de
	ret

6) lastly, and this is the most predictably easy part is that the crackme encodes user input to compare it to a hard coded string. the result determines the crack state.

i guess that’s all there is to it.

in other news, summer’s coming to a close and i never got to write an entry “summer love lessons 07″. all in all, i think this is a rather relaxing summer. for one, i don’t have to worry about school/enrollments anymore come june. moreover, i made friends with a (pretty/cute) korean girl named “carol” but she’s in malaysia right now for studies. she called the other night and i must say that her voice is sweet and charming. we talked for a few minutes… it’s kinda old fashioned, but we agreed to be penpals. i’m excited about writing and sending her letters already!

well then, i’ll close this blog entry at that.