Re: [Full-disclosure] The Mystery of the Duqu Framework

[夜神 岩男 <supergiantpotato@xxxxxxxxxxx>]

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

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