English

The Internet threat alert status is currently normal. At present, no major epidemics or other serious incidents have been recorded by Kaspersky Lab’s monitoring service.

Internet threat level: 1

Home→Blog→Research→March 07 2012→The Mystery of the Duqu Framework→3

The Mystery of the Duqu Framework

Igor Soumenkov
Kaspersky Lab Expert
Posted March 07, 15:58 GMT
Tags: Duqu

1.2

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:

SocketObjectConstructor {
    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.

161 comments

Oldest first

Newest first

Threaded view

Table view

Max

2012 Mar 09, 15:59

Have a try

Maybe javascript, or E language(http://www.dywt.com.cn)? just kidding :-)

Andreas Bogk

2012 Mar 09, 15:59

Definitely not a Lisp

I haven't seen much of the Duqu code except for what is posted here, and I would appreciate more to have a better opinion. But from what I see, I can say this definitely is not a Lisp or any related language (Python, JS, Ruby, younameit).

Clues: the presence of destructors (only makes sense in a language with manual memory management), lack of type bits in pointers (means probably dealing with static types instead of dynamic types).

Another clue to me is the lack of any calling convention different from the C calling convention. My bet is on a thin layer of preprocessing as a C frontend, giving some form of rudimentary OO functionality. Sort of like glibc, but different. Maybe even implemented using C macros.

intointo

2012 Mar 09, 15:41

Magic software

The code looks similar to the one used in the Magic Software eDeveloper solution (now known as UniPaas).

lizardluser

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.

Thanks for the post Igor, this was a lot of fun!

jonwil

2012 Mar 09, 15:06

Possiblities

Borland Delphi? (although if it was Delphi, there would be specific strings in there that would identify it)
C code written to fake object orientation using structures? (glib for one does stuff like this and its not unheard of in other circles)
Whatever it is, its clearly not some sort of blah-to-C++ converter otherwise the output would look like the output of a C++ compiler.

I think that posting any strings from the exe might help identify the compiler, as would identifying any signatures of the linker or the compilers used for other bits of code. If its known that Microsoft Visual C++ was used for other parts of the code, that would probably rule out compilers where the output isn't compatible with Visual C++.

Also examining the memory allocation functions (labeled new and free in the above images) might narrow down if they match any known language or if they are custom written.

EDIT:
I didn't see the mention that the visual C++ 2008 linker was used.

That rules out Delphi and probably Borland C++/Borland C++ Builder.

I still think there may be strings in there that hint at the compiler or that the memory allocate/free functions could give clues (or that details of which dlls it imports from and which APIs it imports could rule in or out possible options)

I can also rule out GCC G++ from the look of the ASM, its definatly not any version of GCC G++ that I know of.

acsMike

2012 Mar 09, 14:34

Is it... Google Go?

acsMike

2012 Mar 09, 14:39

Re: Go

The destructors may point in another direction though.

acsMike

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.

SJP

2012 Mar 09, 12:59

Small Talk

Could this be a variant of SmallTalk?

Matthias Braun

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

At least I like to code in C and often find myself using function pointers and an object-oriented style where it makes sense.

Wladimir

2012 Mar 09, 15:39

Re: object oriented C

I agree. As I see it, the lack of rigid consistency suggests this is an object-oriented C framework with function pointers:

- Method pointers are in the instance, and are sometimes changed after construction, and can be at different offsets in the structure

- No inheritance, but structures might be binary compatible

- "this" pointer can be in different argument positions

- Explicit construction/destruction of objects, and allocation/deallocation of memory, no high level "magic" like GCs, VMs and JITs

Alas, it would have been fun to find a mystery programming language. Does the generated code match any of the known C compilers? And it's interesting that no use is made of libc, all are direct Win32 calls, so this may be some kind of framework for embedded systems.

Edited by Wladimir, 2012 Mar 09, 16:23

pdw

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.

However using Oberon today would be very anachronistic, and the object system is so minimal that it must have been many independent creations.

WilliamOckham

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.

clojuredev

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/ )

"Ferret: An Experimental Clojure Compiler

Ferret is an experimental Lisp to C++ compiler, the idea was to compile code that is written in a very small subset of Clojure to be automatically translated to C++ so that I can program stuff in Clojure where JVM or any other Lisp dialect is not available. "

jgeorge44

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.

puff65537

2012 Mar 09, 02:53

SCIL in microSCADA

Have you tried looking at this? it drags its own event loop because of it history.

Ross Smith

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.

C++ is the only language in which it's a commonly used idiom; the only other languages I know of that make it available (but not often used in practice) are Python (only in CPython), Perl 5, and the most recent incarnation of Objective-C. (Maybe D, I'm not sure.) You seem to have checked all those.

leith

2012 Mar 10, 09:19

Re: Destructors may be a clue

If you're looking for a Python that generates lean C code, look no further than pyrex and cython.

Obscure... but you'd have all the calling semantics of python with the lightness of directly compiled C if you focused on it.

My Assembly is a tad rusty so if this wastes anyone's time, I appologize but I thought it was worth pointing out.

Nick Argall

2012 Mar 10, 03:26

Re: Destructors may be a clue

Delphi also has a destructor architecture like this. Anything that derives from TComponent will be asked to pass a reference to an Owner in the constructor, and the owner calls Free on every child. Free is written as follows
If self != null then
Destroy;

Delphi compiles directly to Windows bytecode, and was the best of the Windows programming languages in the late 90s (up until Microsoft hired the Delphi architect, who went on to design .NET)

thebill

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

Hans

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.
Now for a serious amount of code that would be far too much effort, I'll be the first to admit that.
What if the programming team is not a commercial organisation, and doesn't care about spending a few weeks on this..?? the resulting code would have an uncertain, and unknown signature, somewhat close to an as yet unknown programming language.

nbtaekbfgt

2012 Mar 08, 23:11

realbasic

Could it be realbasic?

This comment was deleted by Derek Jecxz, 2012 Mar 12, 09:20

infernalmachine

2012 Mar 12, 03:44

Re: May I ask...

Most likely the consistency and perhaps optimisations that would only be conceivably possible if done by machine along with a lack of optimisations that could only be conceivably made by hand. Hard to tell without looking at the full code but generally such a large amount of code done by hand will have hints (Edit: Actually, 95663 bytes is quite small, but it should be big enough still to offer good hints).

Also, coding it in assembly by hand would have many significant weaknesses. It's inconceivable someone would do that because the disadvantages of using pure assembly outweighs the advantages immensely.

Even if there coder were able to create it in pure assembly, it is highly likely they would create something such as a set of macros or their own basic higher level language. Most likely inspired by features encountered in other higher level languages. Doing everything in assembly is not a good thing. A human will usually work out something more efficient than copying and pasting the same thing hundreds of times and editing it slightly each time.

It might be a hand made language but tactically, it's worth investigating anyway. Precisely for the fact that it appears to be obscure. It could potentially give clues about the identity of the creators.

I suggest they release the DLL and commented disassembly so that it isn't such a shot in the dark.

Edited by infernalmachine, 2012 Mar 13, 02:50

SCARFP

2012 Mar 08, 22:05

Assembly Language?

Check out this site it looks like old assembly language:

http://www.swansontec.com/sprogram.html

Edited by SCARFP, 2012 Mar 08, 22:24

mrlozer

2012 Mar 08, 21:38

One more guess

It can also be Euphoria...

mrlozer

2012 Mar 13, 17:47

Re: One more guess

Euphoria has this euphoria to c compiler http://www.rapideuphoria.com/e2c.htm

Kenez

2012 Mar 08, 21:37

Timeframe

Don't forget that researchers traced back the activity of this malware to August 2007. This is extraordinary in stealth...

Kenez

2012 Mar 08, 21:25

Unknown compiler, but what linker

It's okay that the compiler is not known. But what linker did they use? If they are linked together MSCPP then the other compiler should have generated MS compatible code. Those lisp, vala, erlang, forth compilers are able to generate that type of output?

I'd seconding to those who guessed it to assembly. Very nice assembly macros can be written with a good assembler, such as was the MASM from MS.

If we know the linker, then we will probably get closer to the questioned language...

billappleton

2012 Mar 08, 20:31

maybe node.js

good for event-driven I/O

marmite

2012 Mar 08, 19:55

Could it be Eiffel Case

I used a programming language at uni which was object orientated called Eiffel Case...Just a thought

flakfizer

2012 Mar 08, 18:07

Google's Go language?

Have you investigated if this could be Google's relatively new Go language? It compiles native, and it has a concurrent messaging infrastructure built into the language.

Igor Soumenkov

2012 Mar 09, 00:45

Re: Google's Go language?

Go was one of the first languages to check. That's definitely not Go.

mrlozer

2012 Mar 08, 17:14

Just a quess

Well i am not a specialist but i would say it could be ruby or envelope programming language... It could also be agena or logtalk...

mtn1980

2012 Mar 08, 16:05

Corman LISP

Looks like Corman Lisp to me. Encapsulated binary object code, use of MFC, dynamic objects, ambiguous calling convention.

tortoiseDoc

2012 Mar 08, 12:36

Javascript?

Or some customized version of it. I have never seen compiled bytecode of Javascript, but given the fact that the classes seem to have modificable interfaces, the first thing that comes to mind is Javascript.

T McGuire

2012 Mar 08, 11:51

RoseRT?

The odd handling of the "this" pointer and the message-passing architecture made me think of this: Rational Software published a "real-time" modelling package in 2000/2001 called RoseRT based off technology from ObjectTime Developer that had an underlying message-passing framework built-in. You would develop the high-level design in UML and then code-gen to a language like C or C++. For C code-gen, the object-structure was flattened so you could compile w/ a standard C compiler. RoseRT was used for secure govt projects...

Russell Emilio Burrows

2012 Mar 08, 11:08

modified report program generator ??

Back in 1982 we used RPG to create some test programs to switch on and off water valves with solenoids.

RPG using object oriented programming with a modified compiler can create something like this.

Never mind.

Wes Brown

2012 Mar 08, 06:39

It's most probably Lisp, inspired by Mosquito Lisp

Howdy, y'all.

This is most probably Lisp. The distinctive features that you mention are very characteristic of a Lisp-based language. Prototype object systems are virtually indistinguishable from functional languages which implement object systems. Reading your description makes me suspect that they were inspired by a talk that I gave about research into injectable virtual machines using Lisp by Scott Dunlop and I.

Here's a link to the video presentation that I gave in Malaysia -- this was back in 2006.
http://video.google.com/videoplay?docid=-468113072359282746

You can find the slides for my talk here:
http://packetstormsecurity.org/files/50716/DAY_2_-_Wes_Brown_-_MOSREF.pdf.html

Our methodology used byte code, but there's no reason why such techniques could not apply to compiled objects.

-Wes

Igor Soumenkov

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?

Wes Brown

2012 Mar 09, 08:12

Re: Re: It's most probably Lisp, inspired by Mosquito Lisp

Igor,

Your first mistake is assuming that they are using an off the shelf compiler. Scott Dunlop wrote Mosquito Lisp, which is an entire virtual machine with a byte code language and a dialect of Scheme combined with Lisp in about nine months or so.

Someone who is smart and motivated, as the Duqu people were, could dedicate someone to writing a compiler in-house in the same timeframe, but targeted towards x86 object systems -- we could have done this, but we wanted to transmit byte code and be portable across multiple architectures. Different goals here. You also presume that they are using an off the shelf linker. Mosquito Lisp and Wasp Lisp append byte code to the end of the VM stub.

-Wes

tomf

2012 Mar 13, 16:06

Re: Re: Re: It's most probably Lisp, inspired by Mosquito Lisp

Wes,

I have to agrre with you esp. rhe comment about Scheme. When I looked at the code snippets it definetly had the Scheme feel about it and was the first language that came to mind. When I was back in college we used that language as well as lisp. It has some pretty interesting capabilities, one of them was the way it handled class objects. All objects were treated as first class objects. Wish I still had a copy of it as it was preety good back in the day and was somewhat easier to use than lisp or forth.

tom

clojuredev

2012 Mar 09, 04:37

Re: Re: It's most probably Lisp, inspired by Mosquito Lisp

Wes Brown

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.

M F

2012 Mar 08, 10:31

Re: It's most probably Lisp, inspired by Mosquito Lisp

I had similar code structure analysis and we couldn't come up with any programming languages...
Our final answers were this is a new and private programming language aka *Cyber Weaponry* framework which they have made or custom C-Like compiler/linker.

I suppose no one will never know what exactly this is, unless you join MOSSAD or something :-)

But what "Wes brown" trying to say is the most close one I heard since! I think he's right, its maybe Lisp.

← Previous page 1 2 3 4 Next page →

If you would like to comment on this article you must first

Analysis

Securing Critical Information Infrastructure: Trusted Computing Base

Gauss: Abnormal Distribution

Monthly Malware Review, March 2012

Stuxnet/Duqu: The Evolution of Drivers

Blog

Narilam: A 'New' Destructive Malware Used In the Middle East

What was that Wiper thing?

Online detection of Gauss

Gauss: Nation-state cyber-surveillance meets banking Trojan

The Day The Stuxnet Died

© 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.

kaspersky.com

securelist.com