Re: Problems to solve

["Matt Oh" <oh.jeongwook () gmail com>]

I don't want to take this long argument but
to make sure, I did some test with bindiff and DG.

And found that bindiff is ignoring minor code changes that has big
security impact.
Like an argument to wcslen or wcscpy.

So for example, if you are analyzing MS06-040 with bindiff, you will
never notice some important security updates in some function.

Actually bindiff was faster but failed to identified some important
change which DG caught and let the analyzer to get some idea. Somewhat
exhaustive and heavy but still useful.

OK this is it. Will not talk about this anymore.
Sorry for the spam.

On 8/15/06, Matt Oh <oh.jeongwook () gmail com> wrote:
> That's only because we chose to use some general GUI toolkit and
> general database and some general script language.
>
> Everyone will use their choice of tools. But I think it's not so fair
> that one shows just one example and says two tools are same. And just
> concentrate on the distribution file size and output file size and
> execution time.
>
> I don't want to argue with anyone, but I think bin-diffing tool is
> about showing the "probable security patches" in two binaries, not the
> tool size and handiness or analysis speed. And that's what DG is
> concentrating on.
>
> Thanks.
>
> On 8/15/06, Nicolas RUFF <nruff () security-labs org> wrote:
> > > You definitely need to read the DG tutorial or see the tutorial video
> > > first before you use it.
> >
> > Look, I do not want to argue with you. It is a nice move to provide the
> > community a free, open source binary diffing suite, and I thank you for
> > this.
> >
> > My points were:
> > - I find the GUI a bit messy (especially the output visualization module),
> > - The toolset is big and could be optimized for speed.
> >
> > Let's consider the recent Centrino patch for instance. We are going to
> > compare DarumGrim ("DG") with some IDA plugin called "PD" (no, it is not
> > BinDiff but I think the results should be very close). Here are the
> > figures on my computer. Input file is "w29n51.sys" (2,1 MB).
> >
> >                    DG     PD
> > -------------------------------
> > Tool directory size 16MB*  90KB
> > (without source)
> >
> > Execution time      5'45"  3'05"
> >                           ( 5" + 2x 1'30" for disassembly )
> >
> > Output file size**  33 MB  0
> >                    (.DB)  (no output file)
> >
> > Results             --- same ----
> >
> > Graphs (big format !)
> > DG: http://nru.free.fr/images/dg.png
> > PD: http://nru.free.fr/images/pd.png
> >
> > * QT-MT334.dll is over 4 MB, LIBMYSQL.dll is over 1 MB
> > ** compressed IDB files are 2x 2,4 MB (not included)
> >
> > So, to answer CIRT.DK's question: now you have my (humble) opinion, with
> > some figures. Feel free to use whatever tool fits your needs.
> >
> > Regards,
> > - Nicolas RUFF
> > Security Researcher @ EADS-CRC
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave