More from Taiwan

[Dave Aitel <dave () kof immunityinc com>]

Ok, so here's the thing Ben Nagy and I were going on about at lunch. I
thought I'd share it with thousands of people.

Ben's problem is that he has 200,000[2] crashes in the latest Word. Word
2007 or whatever. He classifies these problems with !exploitable from
Microsoft, which drops them into buckets of various sorts. But saying "This
is probably exploitable"[1] or not is a really hard problem - far beyond
what !exploitable is useful for. (It claims to do data tainting, but this is
clearly a misnomer?). Basically it divides things into "Definitely likely to
be exploitable because EIP is 41414141", "Pretty much likely to be
exploitable cause we're writing to bad memory" and "Everything else".

So here's my little idea (which I'm sure everyone else has had at least
twice cause I'm not a special snowflake): Take each basic block and number
it. Execute the program twice, once with your crashing file, and once with
your template. This generates two signals, which have a stream of numbers in
them (from the execution trace). Then you can do interesting things by
converting to frequency domain (I.E. FFT?) and doing filtering and
visualization. Ben thinks you want to attach state to your numbers too (i.e.
memory and register info?). I'm not so keen on that because I think too much
data can be as bad as too little, but whatever. Each to their own.

I'm not sure what the interesting thing here is that magically tells you
something is worth really digging into? Maybe you take your two signals, and
subtract their frequencies and visualize how different they are? Throw that
at a HMM/NN and make it tell you something?

-dave

[1] Ben: Do you have a !exploitable in Immunity Debugger? Me: Yes, it just
returns true. :>
[2] Literally.

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