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

[William Pitcock <nenolod@xxxxxxxxxxxxxxxxx>]

VC++ generates code like this when used with COM.  The COM implementation used 
on windows is compiler-assisted.  Basically to generate assembly like this, 
just you know, build code that uses COM (#using, various __declspec etc.)

William

On Mar 10, 2012, at 5:06 PM, Sanguinarious Rose 
<SanguineRose@xxxxxxxxxxxxxxxxx> wrote:

> Do you have any suggestions as to what C++ compiler could generate
> such code in such a case and how one could generate similar code that
> matches the decompiled parts? Granted their theory of a new language
> is moonbatty but I think they have the knowledge to recognize a common
> compiler.
> 
> As for ctor and dtor, I am pretty sure they were marked by the
> researcher doing the decompiling or the decompiler and no such symbol
> names are in the executable. I would conclude as such for the other
> symbols named due to how they were named.
> 
> I do agree on the new language being possibly the dumbest insane
> moonbat speculation of the year however I have heard a few other
> things that win over that hands down ;)
> 
> On Sat, Mar 10, 2012 at 1:16 PM, 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.
>> 
>> William
>> 
>> _______________________________________________
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

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