Re: My pre-Vegas question to Yuji, et. al.

[Matt Hargett <matt () use net>]

I think I missed a message in this thread somewhere..

Dave Aitel wrote:
> spoonm () ghettohackers net wrote:
>
> > Well, right, but who said process state is always going to be static.  
> > What
> > about dynamic heap, dynamic other stuff.  You could end up finding 
> > returns that
> > don't actually work.  It does actually take that long, to prevent 
> > getting stuck
> > in loops, etc, you'd need to set a time out.  What if you miss a 
> > return because
> > it was just a little bit longer than your timeout?  This is halting type
> > problems that have been discussed on vuln-dev etc.
> >  
> Well, you have to test them, which is a fun part of the whole process. 
> Matt was working with using a debugger to restore state, I think, but 
> you could as easily have the program click VMWare's "revert" and get all 
> the OS Handles back to the previous state, and on a fast machine, revert 
> is damn near instantanious.

er.. hopefully you're referring to another Matt. The userland debugger 
approach is a dead end, I believe, for the reasons spoonm stated above 
and then some. I'm talking about full-on virtual machines like you are 
mentioning.

That's not to say the debugger approach won't yield some results, but I 
think that efforts in that direction are probably going to yield very 
limited results.


> > Well, we can do the same stuff FX does except with memdump.exe.  We 
> > just take an
> > image of the whole process, and do things offline, which is much 
> > faster, has a
> > record, etc, etc.  There is no reason to actually stay in the 
> > debugger.  Using
> > memdump is sooo much faster, and nicer.

Isn't this one of the debugging techniques mentioned in 'The Mythical 
Man Month'? Nothing against FX (we need more cute European hackers), but 
I think we can do better given how much more memory and CPU power we 
have today versus in the 1960s.


> > Yeah, it is usually overkill, but taking an intelligent method over a 
> > brute
> > forcing method is always better.  Even if you could get it down to a 
> > week, you
> > still are going to be missing things because of your timeout, or some 
> > state you
> > can control but didn't realize, or wasn't setup right, I mean, there 
> > are so many
> > things.  Moving your shellcode would mean running it all again, 
> > changing the
> > length/padding of shellcode, etc, etc.
> >  
> True, although I think you are drastically overestimating the halting 
> problem here. Non-emulation has another advantage of being able to 
> "trace through" system calls, exception handling, and other fun things.

Well, different things are important to different people. What you 
mention above goes more into reverse engineering -- understanding why 
certain decisions are made, which is necessary for finding logic bugs 
and/or increasing code coverage by tweaking input. On the other hand, 
for exploit development that I believe most people are doing today, I 
don't think the user needs to be explicitly involved at this level to 
the degree they are today.

This isn't the promise of "shiny red button" exploit development, so 
please don't attack me based on that ;> Coming from a software/QA 
process background, I broke the exploit development down into use cases 
and tried to figure out what the interaction would need to be like to 
make those use cases optimal. I'm sure several people will trash me for 
attempting to summarize the 50% of their lives spent doing this stuff 
into use cases, but I think it's necessary to break out of the current 
overextended-edit.com-80x25-text-ui paradigm that most of the current 
tools fit into. Of course, some people like this stuff as well :)

*prepares for flames*

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://www.immunitysec.com/mailman/listinfo/dailydave