I INVENTED EAX AND EBX. Some other guy came up with ECX though. I want
a nickle everything anybody uses shellcode that copies anything into
either of them. Since I am a nice guy, I don't want anything when
values are copied out. Man if only I had come up with ESI and EDI
instead.
On Wed, 28 Jul 2004 09:22:17 -0400, Dave Aitel <dave_at_immunitysec.com> wrote:
> 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_at_lists.immunitysec.com
> http://www.immunitysec.com/mailman/listinfo/dailydave
>
_______________________________________________
Dailydave mailing list
Dailydave_at_lists.immunitysec.com
http://www.immunitysec.com/mailman/listinfo/dailydave
Received on Jul 28 2004
Intro
