Full Disclosure: Re: The Mystery of the Duqu Framework

[夜神 岩男 <supergiantpotato () yahoo co jp>]

--- On Sun, 2012/3/11, William Pitcock <nenolod () systeminplace net> wrote:

> On 3/10/2012 9:00 AM, 夜神　岩男 wrote:
> > On 03/10/2012 03:51 AM, fd () deserted 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/