https://www.securelist.com/en/blog/677/The_mystery_of_Duqu_Framework_solved
"The code was written using a custom OO C framework, based on macros or custom preprocessor directives. This was suggested by your comments, because it is the most common way to combine object-oriented programming with C. " Not Told [ ] Told [x] Here let me re-quote my email for prosperity >Yea, I have been thinking on ideas for that as well, I see no one has >thought outside the box yet. >I would look into OO'ed C (www.planetpdf.com/codecuts/pdfs/ooc.pdf) as >being a possibility. Long before in the time when the mighty C++ was >young, it was translated to C code for compilation. I have not had the >time to dig into it yet to see how you could code it in OO C style >code yet. You can implement much of the functionality of OO parts of >C++ including virtual functions and other things. >Well, these are my thoughts on it. More speculation at the moment but >might be of use to someone. So, next time I would suggest actually reading and understanding what I post to the mailing list instead of cheerleader with that crappy "told" and "not told" meme. On Sat, Mar 10, 2012 at 1:40 PM, Laurelai <[email protected]> wrote: > On 3/10/12 2:16 PM, William Pitcock wrote: >> On 3/10/2012 9:00 AM, 夜神 岩男 wrote: >>> On 03/10/2012 03:51 AM, [email protected] 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/ > I think William just told everyone...again. > > _______________________________________________ > 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/
