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]
Date: Sat, 10 Mar 2012 17:43:14 -0300
From: Alberto Fabiano <alberto@...puter.org>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: The Mystery of the Duqu Framework

On Sat, Mar 10, 2012 at 17:16, 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.
>

Well, looks like COM, smells like COM , and acts like COM, but  C++
is´nt the unique language that use COM, still has a way familiar...
can be another language.


> 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/



-- 
Alberto Fabiano C. de Medeiros
alberto@...puter.org
PGP Key ID: 232D3D06
- .... .  -... . ... -  .-- .- -.--  - ---  .--. .-. . -.. .. -.-. --
.... .  ..-. ..- - ..- .-. .  .. ...  - --  .. -. ...- . -. -  .. -
.- .-.. .- -.  -.- .- -.--

k'bɪt Y> "The best way to predict the future is to invent it." --Alan Kay
k'bɪt X> "Chance favors the prepared mind."   --Louis Pasteur
k'bɪt Z> "The world is full of fascinating problems waiting to be
solved" --Eric S.Raymond

_______________________________________________
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ