Home→Blog→Research→March 07 2012→The Mystery of the Duqu Framework
While analyzing the components of Duqu, we discovered an interesting anomaly in the main component that is responsible for its business logics, the Payload DLL. We would like to share our findings and ask for help identifying the code.
At first glance, the Payload DLL looks like a regular Windows PE DLL file compiled with Microsoft Visual Studio 2008 (linker version 9.0). The entry point code is absolutely standard, and there is one function exported by ordinal number 1 that also looks like MSVC++. This function is called from the PNF DLL and it is actually the “main” function that implements all the logics of contacting C&C servers, receiving additional payload modules and executing them. The most interesting is how this logic was programmed and what tools were used.
The code section of the Payload DLL is common for a binary that was made from several pieces of code. It consists of “slices” of code that may have been initially compiled in separate object files before they were linked in a single DLL. Most of them can be found in any C++ program, like the Standard Template Library (STL) functions, run-time library functions and user-written code, except the biggest slice that contains most of C&C interaction code.
Layout of the code section of the Payload DLL file
This slice is different from others, because it was not compiled from C++ sources. It contains no references to any standard or user-written C++ functions, but is definitely object-oriented. We call it the Duqu Framework.
The code that implements the Duqu Framework has several distinctive properties:
All objects are instances of some class, we identified 60 classes. Each object is constructed with a “constructor” function that allocates memory, fills in the function table and initializes members.
Constructor function for the linked list class.
The layout of each object depends on its class. Some classes appear to have binary compatible function tables but there is no indication that they have any common parent classes (like in other OO languages). Furthermore, the location of the function table is not fixed: some classes have it at offset 0 of the instance, but some does not.
Layout of the linked list object. First 10 fields are pointers to member functions.
Objects are destroyed by corresponding “destructor” functions. These functions usually destroy all objects referenced by member fields and free any memory used.

Member functions can be referenced by the object’s function table (like “virtual” functions in C++) or they can be called directly. In most object-oriented languages, member functions receive the “this” parameter that references the instance of the object, and there is a calling convention that defines the location of the parameter – either in a register, or in stack. This is not the case for the Duqu Framework classes – they can receive “this” parameter in any register or in stack.
Member function of the linked list, receives “this” parameter on stack
The layout and implementation of objects in the Duqu Framework is definitely not native to C++ that was used to program the rest of the Trojan. There is an even more interesting feature of the framework that is used extensively throughout the whole code: it is event driven.
There are special objects that implement the event-driven model:
This event-driven model resembles Objective C and its message passing features, but the code does not have any direct references to the language, neither does it look like compiled with known Objective C compilers.
Event-driven model of the Duqu Framework
Every thread context object can start a “main loop” that looks for and processes new items in the lists. Most of the Duqu code follow the same principle: create an object, bind several callbacks to internal or external events and return. Callback handlers are then executed by the event monitor object that is created within each thread context.
Here is an example pseudocode for a socket object:
After having performed countless hours of analysis, we are 100% confident that the Duqu Framework was not programmed with Visual C++. It is possible that its authors used an in-house framework to generate intermediary C code, or they used another completely different programming language.
We would like to make an appeal to the programming community and ask anyone who recognizes the framework, toolkit or the programming language that can generate similar code constructions, to contact us or drop us a comment in this blogpost. We are confident that with your help we can solve this deep mystery in the Duqu story.
|
2012 Aug 08, 01:33
¿Estoy Mas Que Seguro Que es protollua? si es igual fue creado por un grupo de estudiantes para facilitar |
|
2012 Aug 08, 01:31
¿Estoy mas que seguro que es protollua? este es un nuevo lenguaje de programacio creado por la univesidad nacional de colombia pero aun no ha sido sacado a luz. |
|
2012 Apr 01, 15:27
ZeroMQ? http://www.zeromq.org/ |
|
2012 Mar 27, 17:05
Some languages to check http://en.wikipedia.org/wiki/List_of_programming_languages_ by_type#Object-oriented_class-based_languages |
|
2012 Mar 26, 09:55
iscoD knows well basics of micro controller and processor.It Designed in all language and used effective parts assembler code. |
|
2012 Mar 21, 02:20
Since The language is C compiled with Microsoft C++, perhaps the library is the Microsoft SDK, a C library. |
|
2012 Mar 19, 21:08
I know what the language is! I've programmed in that language. It's assembly language. |
|
2012 Mar 19, 15:18
|
|
2012 Mar 15, 23:29
What about nesC I've been looking into TinyOS and Sensor Network VM's and came across this nesC thing that seems would be right up the alley for someone doing this type of work... |
|
0 |
|
2012 Mar 15, 18:25
Check-out older possibilities http://www.sics.se/~adam/lwip/ : IP stack |
|
0 |
Re: Check-out older possibilities
Have Ch been mentioned ? Here it is : http://www.softintegration.com/products/
|
2012 Mar 15, 17:23
An interesting aside Of some kind of passing interest is the comment from Ken of Caffeine Security suggesting some level of similarity between Duqu and the recent Linux malware Linux/Bckdr-RKC. he claims to have sent material to Kasperski, but it may have fallen through the cracks. |
|
0 |
Re: An interesting aside
Ken just seems to have the feeling that there are similarities. And I really don't find anything obvious.
On one side:
Win32 OO programming.
On the other side:
Procedural programming with C runtime.
|
2012 Mar 15, 14:54
Hand written asm Like eyenot, I think that it is hand written asm. |
|
2012 Mar 14, 22:55
|
|
2012 Mar 14, 17:52
sniffing from wrong direction, what does history tell you? both As400tech and SCooke handed you the best hints. |
|
2012 Mar 14, 17:48
>they can receive “this” parameter in any register or in stack. |
|
2012 Mar 14, 14:21
OOOAC ? Is the C framework could be an extention of the "OOOAC" homemade framework ? It implement class system inheritance and event management in ansi c language. |
|
0 |
|
0 |
Re: Re: OOOAC ?
Could we see the entire source code (asm, of course) of DUQU for reverse engineering ? That could help you more than expect found an hypothetical framework. I saw that no one known is same as the DUQU's one. If they did it home-made, it is probable that no one would tell you how they did !
|
2012 Mar 14, 11:02
I typed in "; lpMem" into google and was then in a hunt for a win32 compiler ==>PowerBasic. |
|
2012 Mar 14, 05:34
Brainstorming For some reason - call it a hunch - I delved into the AI related programming languages after seeing the output. Edited by M-Boy, 2012 Mar 14, 06:32 |
|
2012 Mar 14, 01:55
Could be one of these. Could it be made in L (http://www.bitmover.com/lm/L/L.html) |
|
2012 Mar 13, 18:42
PL/1,PL/S II,PL/AS,PL/X Many IBM operating systems are written in these languages. As previous users mentioned the similarities to code they had seen on IBM systems i figured it might be worth while to take a look at these. IBM has a compiler for PL/1 that runs on windows. The other languages are derived from PL/1 and are mostly used interally on IBM so i wouldn't be a long shot to assume that they might have compilers for windows for those to. I should also add that this is all speculation on my part. i don't have the knowledge required to properly read and analyze the code posted. |
|
0 |
Re:
I stumbled upon this site: http://autodiff.piotrbania.com /get_function_listing.php?diff_id=84 module_id=167 np_module_id=168 function_rva=0x0001f9b8 os=1#
What is AutoDiff?
AutoDiff is a project which performs automated binary differential analysis between two executable files. This is especially useful for reverse engineering vulnerability patches and spotting other additional code updates. AutoDiff allows to find executable code similarities and differences among two executable files. Additionally it also includes some heuristics methods for matching variables (objects) between two executable files. AutoDiff is ultra fast, standalone tool. It was especially designed to diff Portable Executable files released by Microsoft every time in the security bulletin.
More about the AutoDiff story:
http://blog.piotrbania.com/2010/12/rebootless-windows-updates-ksplice-for.html
That´s my contribution for the possibility list.
|
2012 Mar 13, 18:15
The facts 1.Its calling Windows APIs so it has to be a Windows compiler (and not one for PLCs or SCADA or mainframes or anything else) |
|
0 |
Re: The facts
There are various ways of adding runnable code to a PE file, ranging from linking at compile time to embedding as a runnable resource to even injecting code (think buffer overflow security exploits). One does not necessarily need to link to a compilable resource - although it's probably one of the easier ways.
Given the install base of SCADA systems, any runnable file would have to assume that all necessary runtime libraries were not available and must be included somewhere in the running PE file. This rules out all interpreted languages (non-natively compiled java, basic, etc), any language requiring an external runtime (all CLR based languages, VB 5/6, etc), to name but a few. Some languages allow native compilation, eg, delphi and java but they have already been investigated, or so I understand.
|
2012 Mar 13, 18:12
Obfuscated ASM ? It's been a very long time (like 15-20 years) since I wrote any C or C++, but I remember from those times contests of obfuscated C where the game was to write the most obscure piece of code possible (that would actually do something). I'm not in that kind of activity anymore, so I apologize if I'm stating something really obvious to this community. |
|
0 |
Re: Obfuscated ASM ?
it's possible but looking at the naming conventions used in the disassembly, it looks more like a dedicated tool created the payload from an OO based language structure. Of course, there's nothing stopping someone creating a tool to deliberately obfuscate code to make it look like OO but that's an order of magnetude more difficult than creating a straight compiler. And if you're going to the trouble of creating and maintaining a custom compiler, you're going to keep it pretty simple - which is probably why it looks 'old'. Older systems were a little more direct in their compiled code. This being an event-driven architecture and therefore capable of being used for multi and single-threaded applications (not quite but bear with me), a lot of effect went into making it. If it was a custom compiler and deliberately obfuscating code, it'd make it very hard to maintain and debug. The level of sophestication of the existing stuxnet and duqu code and their use of the VS C++ library suggests they were using an off-the-shelf compiler albeit an obscure one.
Following ocham's razor; "The most simple explanation is usually the correct one" (actually it's not in all circumstantes but I digress), the 'obvious' answer is that a tool was used to compile from a standard OO language or variant thereof
|
2012 Mar 13, 16:47
It still looks like a dialect of Scheme Igor, |
|
2012 Mar 13, 14:07
feasability of automated check I've read through all the material given and the comments and while there are some interesting avenues of investigation, the general concensus is one you've already come to - that this is a custom OO framework. This concensus is one given by many skilled individuals who are familiar with decompiled code. |
|
0 |
looking wider
having seen just about every programming environment suggested, I'd like to suggest a somewhat tangential environment.
We've seen the on-again-off-again-on-again suggestion that Duqu is related to Stuxnet (I'm still not convinced they're related, by that's by-the-by) and with that in mind, has anyone compared the code with the product of any of the SCADA / PLC development environments? Perhaps this is a payload directed at a similar target to that targeted by Stuxnet (North Korea, anyone?)
|
0 |
Re: looking wider
Its making Windows API calls directly so it has to be a Windows toolkit and not something for SCADA/PLC
|
0 |
Re: Re: looking wider
but many SCADAs (most?) run under Windows.
PLCs on the other hand don't have Windows anywhere near them.
|
2012 Mar 13, 12:40
Google's Dart Coding looks very familiar. Just giving another option here. If anyone has time to take a look at google's Dart language which is similar to Javascript. |
|
2012 Mar 13, 05:22
its not Eiffel Hi IGOR |
|
2012 Mar 13, 03:27
This is very intriguing! Have you considered comparing and analyzing it to RPGII it somewhat resembles that? |
|
2012 Mar 13, 03:08
|
|
2012 Mar 12, 21:44
Another suggestion for Forth As two others put forward - might be Forth. |
|
2012 Mar 12, 20:17
Pike ? Maybe it's written in Pike? Some of the features reminded me of what i have read about Pike, and according to Wikipedia it is used for Server/Gateway code for Opera Mini. |
Analysis
Blog