full-disclosure - Re: The Mystery of the Duqu Framework

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4F5BB69A.4060808@systeminplace.net>
Date: Sat, 10 Mar 2012 14:16:26 -0600
From: William Pitcock <nenolod@...teminplace.net>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: The Mystery of the Duqu Framework

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.

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/