Date: Sun, 11 Mar 2012 18:54:30 +0900 (JST)
From: 夜神　岩男 <supergiantpotato@...oo.co.jp>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: The Mystery of the Duqu Framework

--- On Sun, 2012/3/11, William Pitcock <nenolod@...teminplace.net> wrote:

> On 3/10/2012 9:00 AM, 夜神　岩男 wrote:
> > On 03/10/2012 03:51 AM, fd@...erted.net wrote:
> >
> >> http://www.securelist.com/en/blog/667/The_Mystery_of_the_Duqu_Framework
> >>
> >> Haven't seen this (or much discussion around this) here yet, so I
> >> figured I'd share.
> >>
> >    From the description, it looks like someone pushed some code from a
> > Lisp[1] variant (like Common Lisp, which is preprocesed into ANSI C by
> > GCL, for example, before compilation) into a C++ DLL. Normal in the
> > deper end of Linux dev or Hurd communities, but definitely not standard
> > practice in any established industry that makes use of Windows.
> >
> > I could be wrong, I didn't take the time to walk myself through the
> > decompile with any thoroughness and compare it to code I generate.
> > Anyway, I have no idea the differences between how VC++ and g++ do
> > things -- so my analysis would probably be trash. But from the way the
> > Mr. Soumenkov describes things it seems this, or something similar,
> > could be the case and why the code doesn't conform to what's expected in
> > a C++ binary.
> >
> >
> 
> LISP would refer to specific constructor/destructor vtable entries as 
> "cons" and there would be no destructor at all.  The structs use vtables 
> which refer to "ctor" and "dtor", which indicates that the vtables were 
> most likely generated using a C++ compiler (since that is standard 
> nomenclature for C++ compiler symbols).  It pretty much has to be 
> Microsoft COM.  The struct layouts pretty much *reek* of Microsoft COM 
> when used with a detached vtable (such as if the implementation is 
> loaded from a COM object file).  The fact that specific vtable entries 
> aren't mangled is also strong evidence of it being Microsoft COM (since 
> there is no need to mangle vtable entries of a COM object due to type 
> information already being known in the COM object).
> 
> If it looks like COM, smells like COM, and acts like COM, then it's 
> probably COM.  It certainly isn't "some new programming language" like 
> Kaspersky says.  That's just the dumbest thing I've heard this year.

I don't know enough about COM to have an opinion on this analysis (I don't do any work in Windows anymore) -- but if this is the case why is it stumping not just Kaspersky, but others as well?

The reason I mention Lisp is the ease with which it can be implemented in arbitrary ways via Bison -- not because there is anything even approaching a canonical implementation that always does things a certain way. The huge variety of Lisp implementations is why I wouldn't quite so quickly say things like "there would be no destructor", because that is implementation specific. Ruby is/was written this way (not sure if the late versions are, haven't kept up), as are a large number of the GNU constellation language implementations (I think there was an Ada implementation written this way as well). The end result is pretty unpredictable if you just look at the language spec and then a binary with nothing in between, because the way the language compiler or preprocessing is done can really change things around a lot.

After posting I read through a few comments on the Kaspersky post and some interesting discussion focused around both Lisp and SOO, but the timeline for SOO doesn't match up.

Anyway, I'm idly curious now to see what the final verdict is -- and if its COM that would give me a chuckle.

Thanks for writing a real response, by the way. I don't understand what is going on with this list being overrun by HaX0rz and the noisy.

-IY

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists