Internet threat level: 1
Home→Blog→Research→March 07 2012→The Mystery of the Duqu Framework→2
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.
Code layout
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 Framework
Features
The code that implements the Duqu Framework has several distinctive properties:
- Everything is wrapped into objects
- Function table is placed directly into the class instance and can be modified after construction
- There is no distinction between utility classes (linked lists, hashes) and user-written code
- Objects communicate using method calls, deferred execution queues and event-driven callbacks
- There are no references to run-time library functions, native Windows API is used instead
Objects
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
Event driven framework
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:
- Event objects, based on native Windows API handles
- Thread context objects that hold lists of events and deferred execution queues
- Callback objects that are linked to events
- Event monitors, created by each thread context for monitoring events and executing callback objects
- Thread context storage manages the list of active threads and provides access to per-thread context objects
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:
NativeSocket = socket();
SocketEvent = new MonitoredEvent(NativeSocket);
SocketObjectCallback = new ObjectCallback(this, SocketEvent, OnCallbackFunc);
connect(NativeSocket, ...);
}
OnCallbackFunc {
switch(GetType(Event)) {
case Connected: ...
case ReadData: ...
...}
}
Conclusions
- The Duqu Framework appears to have been written in an unknown programming language.
- Unlike the rest of the Duqu body, it's not C++ and it's not compiled with Microsoft's Visual C++ 2008.
- The highly event driven architecture points to code which was designed to be used in pretty much any kind of conditions, including asynchronous commutations.
- Given the size of the Duqu project, it is possible that another team was responsible for the framework than the team which created the drivers and wrote the system infection and exploits.
- The mysterious programming language is definitively NOT C++, Objective C, Java, Python, Ada, Lua and many other languages we have checked.
- Compared to Stuxnet (entirely written in MSVC++), this is one of the defining particularities of the Duqu framework.
The Duqu Framework: What was that?
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.
|
This comment was deleted by Derek Jecxz, 2012 Mar 12, 09:20 |
2012 Mar 08, 23:11
|
|
2012 Mar 09, 00:03
That code looks familiar The code your referring to .. the unknown c++ looks like the older IBM compilers found in OS400 SYS38 and the oldest sys36. |
|
2012 Mar 09, 00:11
|
|
2012 Mar 09, 00:12
|
|
2012 Mar 09, 00:13
|
|
2012 Mar 09, 00:14
|
|
2012 Mar 09, 00:40
Re: WEB Guess The Duqu Framework shares many principles of libevent, but it is completely object-oriented, even all events and callbacks are wrapped in objects. |
|
2012 Mar 09, 00:42
Re: My first thought... We tried Vala, too. Unfortunately, the generated code is completely different. |
|
2012 Mar 09, 00:45
Re: Google's Go language? Go was one of the first languages to check. That's definitely not Go. |
|
2012 Mar 09, 01:25
Different Rather than listing all programming languages .. when I was much younger I took assembler output from compilers and modified it. |
|
2012 Mar 09, 01:40
Re: It's most probably Lisp, inspired by Mosquito Lisp Thank you Wes! Could you please suggest a Lisp implementation that we should check in the first place? |
|
2012 Mar 09, 02:35
Destructors may be a clue The presence of destructor functions in all classes, which (if I'm reading your sample correctly) deallocate memory as well as releasing anything else owned by the object, may be an important clue. Deterministic destruction, as opposed to garbage collection, is a feature very few languages have. It certainly rules out several of the suggestions in the comments, such as Lisp or JavaScript. |
|
2012 Mar 09, 02:53
SCIL in microSCADA Have you tried looking at this? it drags its own event loop because of it history. |
|
2012 Mar 09, 04:27
It's been a looooong time since I've worked on them, but this does smell to me a little bit like something that'd come out of an AS/400 compiler as well. RPG/400? But not sure why that'd be the way to go to code for Windows. |
|
2012 Mar 09, 04:37
Re: Re: It's most probably Lisp, inspired by Mosquito Lisp It's probably the Ferret Lisp to C++ compiler ( http://nakkaya.com/2011/06/29/ferret-an-experimental-clojure-compiler/ ) |
|
2012 Mar 09, 04:38
Lisp to C++ compiler It's probably the Ferret Lisp to C++ compiler ( http://nakkaya.com/2011/06/29/ferret-an-experimental-clojure-compiler/ ) |
|
2012 Mar 09, 06:03
Re: Destructors may be a clue Good thought on destructors. On other possibility: In Ada, overriding the Finalize procedure creates a destructor for an object. Described here: http://en.wikibooks.org/wiki/Ada_Programming/Object_Orientation#Destructors |
|
2012 Mar 09, 07:04
Re: Guess: Ada tasks? It's also interesting to note: |
|
2012 Mar 09, 07:05
Embedded systems compiler? The description of the features identified makes me think that you are looking at code from a compiler that targets devices. The giveaway is the lack of inheritance in an object based system and the ability to pass the "this" pointer in multiple ways. Those are features that can be useful in a resource constrained system. I would look at something like QNX or a competitor. |
|
2012 Mar 09, 08:12
Re: Re: It's most probably Lisp, inspired by Mosquito Lisp Igor, |
|
2012 Mar 09, 08:17
Re: Re: Re: It's most probably Lisp, inspired by Mosquito Lisp Probably not. Duqu and Stuxnet components date to 2007, predating this. I would also point out that as of 2006, this particular technique of a virtual machine to evade detection and reverse engineering was known. |
|
2012 Mar 09, 11:09
The object system matches what I remember of Wirth's Oberon. In Oberon, an object was really just a struct with method pointers. Conventionally you'd place them at the beginning the struct, but you didn't have to. The "this" pointer had to be passed manually (normally as the first parameter, but this was not required). Inheritance was done by specifying that struct B should start with the same members as struct A. |
|
2012 Mar 09, 12:33
object oriented C Is there any reason why this isn't simply C-code written in an object oriented fashion? Putting a function pointers into structs looks like classes, when you are explicitely passing "this" around as a function parameter then you might sometimes choose to use the 2nd or 3rd argument for it, if the compiler only puts the first 2 arguments into registers and the other arguments on the stack... |
|
2012 Mar 09, 12:59
|
|
2012 Mar 09, 14:34
|
|
2012 Mar 09, 14:39
|
|
2012 Mar 09, 14:48
Re: Re: Go Or has anyone mentioned REALbasic yet? It would probably plug in well in Visual Studio. It would also be prestigious to create a potent virus in Basic. |
|
2012 Mar 09, 15:06
Possiblities Borland Delphi? (although if it was Delphi, there would be specific strings in there that would identify it) |
|
2012 Mar 09, 15:37
Interesting Considering it uses destructors, plus the payload had something to do with breaking non windows systems in a nuclear facility (windows would be exclusively for reading data), plus real-time implications, I would suggest the assembler for a HEX/ROM file generated by a tool like Paradigm C++ destined for an old 386 or 486. If they had a windows box reading data through RS232 from a critical subsystem, and the port wasn't configured exclusively for output, it would be very possible to drop a new ROM into the subsystem. Lots of really weird implications if this is true. |
Analysis
Blog
© 1997-2013 Kaspersky Lab ZAO. All Rights Reserved.
Industry-leading Antivirus Software.
Registered trademarks and service marks are the property of their respective owners.
The authors' opinions do not necessarily reflect the official positions of Kaspersky Lab.