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

[Dave Aitel <dave () immunitysec com>]

You can give it at a Shindig in NYC in September, assuming you can 
afford the flight up here (Shindigs are free and I am poor), and don't 
mind giving it to 30 people instead of 300.  (That being said, however, 
the last Shindig had people from Canada, DC, and NYC, and NYC itself has 
a really strong hacking scene.)

Oh, also, you can't be one of those people who claims they invented 
everything and that any work remotely similar to it must be based on 
your work. Not that you are one of those people, but they're out there, 
and I pick the talks and so I just made that a rule. Shindigs are a 
"software patent free zone".

-dave

Matt Hargett wrote:

> dave wrote:
>
> > BlackHat talk:
> > "Payloads intended to execute attacker-provided code typically 
> > require a static address of code already existing in the vulnerable 
> > process's address space, in order to redirect execution back into code 
>
> ...
>
> This sounds like an internal thing I've been working on called Project 
> Sirius that I designed while at Sundance this year. 
> (Sirius->Black->Blackbox -- I am such a fuqn nerd.)
>
>
>
> > 1. What's the actual gain over standard address corrolation methods? 
> > Immunity's doing fairly well with just that...done properly, it's 
> > pretty exhaustive since valid return addresses are sparce.
>
>
> What I have done in my implementation of these ideas is to use runtime 
> analysis data to seed some of the static analysis with useful data. 
> This can be especially useful for heap oriented things. I don't want 
> to say too much, as I don't want you guys kicking the shit out of me 
> until the 2nd prototype is ready. (The first went rather well.)
>
> I submitted a talk to Blackhat Vegas presenting this project and some 
> of the really nifty things it enables, but it wasn't accepted.
>
>
> > 2. Why bother emulating? Why not use the CPU instead of emulating a 
> > CPU? Reverting state is fairly easy, especially the state you really 
> > need to revert...
>
>
> Hoglund thinks the same thing, and I disagree. In simple programs, 
> this makes sense, but not in anything real world one might get asked 
> to look at. The biggest problem I foresee with standard debuggers 
> and/or process restoration is the process and OS handles getting out 
> of sync. You can do a lot of kernel tricks to try and keep things 
> going, but at that point you're modifying the state enough that I 
> think you'd run into some false situations with the opposite problem 
> -- handles being kept alive for too long.
>
> I have an entire talk ready on this subject; if anyone would care to 
> see/hear it, let me know of a willing venue.

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