This isn't really necessary, since its clear what parts are not fully
functional.  The code is very erm *cough* questionable, in its
current state anyway.

but for people who want to see some of the things that are not clear
from the graphs or the code (unless you know this already), here
is a list of "bugs" that arent correcly handled.  its not a list of what
can and cant be done :)

--

call/pop sequences!

	*
			call A
		A:	pop %

	^^ breaks the procedure identification, since its not a procedure!
	an interesting idea is to do like 'metal' for identifying 
	stack screwups.  the expectation, that %esp and %ebp are not
	going to be heavily modified in a program (maybe for %ebp, since
	it can be a general purpose register).  so simple rules, of
	stack depth consistancy could possibly be checked for.  for the
	time being, it may be simple enough to do a naive call/pop
	pair check, then declaring that what was though a procedure, was
	not.  if the call/ret is a sequence directly directly next
	to each other (ie, ret == pc + 5), then we can say that this
	is part of the current procedure.  otherwise, it may be
	considered a goto of sources, or simply a jmp.
	push/ret is another case of the
	classic asm goto that has lots of uses (jumping to an absolute
	address without using a register; jmp *%eax == bad sometimes).
	for non structured asm (ie, doesnt use procedural style
	programming), you get into crazy headaches trying to detect what
	should be considered a procedure :(  using goto's in asm,
	is just as hard to follow sometimes as in a procedural
	based language, if used inapproriately :)

	i think the best thing to do, is to detect a call/ret sequence,
	then delete the procedure entry, and markup the call/ret to
	be a psuedo unconditional jump. analysis code is not ready for this
	currently :(

	--> typically when i'm performing binary analysis by hand,
	i almost never follow top down approach to program understanding
	as a first step.  theres simply too much data to process,
	and alot of time is wasted trying to analyse whack shit.
	for procedures, i will normally try to identify procedure
	entry/exit sequences (the frame pointer setup etc - if this
	is being used, hopefully).  then i will mark off procedures and
	work at decompiling those.. typically the easiest ones
	first.. at a later stage when trying to determine control
	flow, i will cross references the call's to the procedures
	i initially identified, and use this as validation. for
	finding dead code, and to find weird control flow, such as
	entry point obfuscation stuff.  its almost pointless to
	work top down when doing analysis by hand for most of the
	initial stages.. since you end up spending all your time
	working through small amounts of code, without getting an
	overview of what the entire program does at a glance. ie,
	identifying anything like syscalls, and what type of programs
	are possible with the set of syscalls used (ie, does it
	use the network? does it fork at all? does it ptrace, or
	brk, ioctl's ? - which are flaggable syscalls for quick
	suspiciousness ratings without any real analysis).  also
	quick evaluations are useful to determine thigns such as -
	was the code generated by a compiler?  was the code written
	in pure asm?  is their any glue between them? etc.

	anyway.. enough ranting about reverse engineering!


procedure exits!

	+ use 'ret|hlt' instead of 'ret' (not fully robust but works
	+ for _start case)
	+ 0.04.2

	* if a procedure exits without using a 'ret', then it wont
	  know that it has exited, and thus believe flow is possible
	  after this point.  this is why the current graphs
	  fuck up the procedures.  it doesnt see the 'hlt' or realize
	  that __libc_start_main is actually an exit point.
	  thus _start is traced into the following function, which
	  happens to be totally incorrect :)

missing code!

	+  this was added to linker.rel, and linker.py bug fixed so it
	+  would work :) in 0.04.1

	* init/fini (comes from function pointers in _start when
	  calling __libc_start_main, which jumps back into them, like main)
	  that has some ok control flow to follow

08048320 <_start>:
 8048320:       31 ed                   xor    %ebp,%ebp
 8048322:       5e                      pop    %esi
 8048323:       89 e1                   mov    %esp,%ecx
 8048325:       83 e4 f8                and    $0xfffffff8,%esp
 8048328:       50                      push   %eax
 8048329:       54                      push   %esp
 804832a:       52                      push   %edx

 804832b:       68 60 84 04 08          push   $0x8048460
 8048330:       68 98 82 04 08          push   $0x8048298

^^ init/fini

 8048335:       51                      push   %ecx
 8048336:       56                      push   %esi
 8048337:       68 14 84 04 08          push   $0x8048414

^^ main (working)

 804833c:       e8 b7 ff ff ff          call   80482f8 <_init+0x60>

^^ __libc_start_main (working)

 8048341:       f4                      hlt
 8048342:       90                      nop
 8048343:       90                      nop

