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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <4F5B6C93.5000605@yahoo.co.jp>
Date: Sun, 11 Mar 2012 00:00:35 +0900
From: 夜神　岩男 <supergiantpotato@...oo.co.jp>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: The Mystery of the Duqu Framework

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.

-IY

1. [Caveat] I say "Lisp" but some other languages come to mind as well; 
maybe Haskell would come out that way. I'm not sure because I'm most 
familiar with Lisp and know it can be cobbled with C/C++ without 
complications because of the way most of its C-based implementations 
work. Anyway, if I were looking for a lock on how this code was 
produced, I would ignore C-based languages and focus instead on 
languages that behave this way natively first, because I think that's 
the least exotic explanation for the features this segment of code exhibits.

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