RE: Techniques for Vulneability discovery

["Pedro Hugo" <fractalg () highspeedweb net>]

Well that could be done breakpointing system api's like strcpy etc etc
etc or the equivalent in windows.
But doing that without any reference would be a pain in the ass task.
One of the tricks in reverse engineering is breakpointing the right
place. After you get the right place things go a lot easier.
One of the most used tricks in software protections is making it
difficult to find the right places to breakpoint (much others exist of
course, but these ones try to avoid easy dead listing approaches for
example). Without the "entry point" it's much harder to go to the place
you want. So you still have the usual problem about finding the place
with problems. Being in assembler it makes things much harder to
understand. Debugging and disassembling could be, in my opinion, more
helpful to track more complex bugs and to help understanding foreign
code, like trojans and backdoors.
As in Phrack 58 article about runtime binary encryption:
"Forensic work on binary executeables will become very difficult, and
most
of the people who do forensics nowadays will drop out of the field. Most
likely some people from the reverse engineering 'scene' will convert
more
to network security and become forensics."
I think this field is one of the possible futures in the security scene.
Good tools are rare, and good people doing it not very common too.
Encryption and packing is one of the biggest challenges in the reverse
engineering field. Look at popular Windows shareware programs and you
will understand.

 
> Hi all (corrected for the lists..),
>
> How about applying reverse engineering techniques in order to discover
> potential security holes ?
> The most obvious example would be to try and find a buffer overflow in
> a windows application (these are mostly closed source.. heh).
> A good place to start would be a disassembly, looking for any kind of
> buffer assignments, or any type of function call that handles 
> strings, etc..
> If you find lots of them, in what appears to be code that 
> handles input,
> that might be worth a deeper look.
> Of course, it's not always easy to tell what a certain piece 
> of code does,
> or if it's even relevant to what you're trying to achieve 
> (i.e: buffer overflow
> through some user input), but it might work out pretty well.
> Debuggers and disassemblers might prove really handy in situations
> like these (of course, other analysis tools might prove useful too,
> especially under windows).
>
> "LS" Eli