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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ