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
| ||
|
Message-ID: <CAPGeVWPuGk8aBS3cXGe7eqv4E07Z=2LBZsnt6tpuhJZZZL4e+Q@mail.gmail.com> Date: Sat, 10 Mar 2012 16:06:49 -0700 From: Sanguinarious Rose <SanguineRose@...ultusTerra.com> To: full-disclosure@...ts.grok.org.uk Subject: Re: The Mystery of the Duqu Framework 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/
Powered by blists - more mailing lists