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:47:56 +0100
From: Christian Sciberras <uuf6429@...il.com>
To: Sanguinarious Rose <SanguineRose@...ultusterra.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: The Mystery of the Duqu Framework

At this point, I think someone (possibly the guys at securelist) ought to
define 'new programming language'.
By "new" I take it the writers would have created their own language. While
far from impossible, it's quite improbable.
It's possible someone out there decided something can't be achieved in any
language, and thus have created their own.

On the other hand, by 'new' it seems many people seem to relate to
'unconventional languages' as well.
There are many languages out there, some are far from anything related to
C++ (as much as the C++ fanboys want us not to believe).
So the mere speculation that it "looks like 1% C++ <here> and <there>"
simply hinders actual serious investigation.

I can think of at least 3 different languages not mentioned on securelist
nor on FD. I didn't suggest any of them simply because
I don't know what they generate (I'm not proficient in either of them) but
I do know they do not rely on any C++ compiler.




2012/3/11 Sanguinarious Rose <SanguineRose@...ultusterra.com>

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

Content of type "text/html" skipped

_______________________________________________
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