Le trojan Duqu utilise un langage de programmation inconnu

MiaowZedong · 09/03/2012, 11h42

Le mystère du "Framework Duqu" est résolu
Le malware aurait été écrit avec une extension C orientée objet créée sur mesure

Mise à Jour du 20/03/2012 par MiaowZedong

Les chercheurs de Kaspersky ont annoncé hier (19/03/2012) qu’ils avaient résolu « avec un niveau de certitude très élevé » le mystère Duqu.

L’expert Igor Soumenkov commence par remercier les nombreux développeurs qui ont suggéré des pistes d’investigation : il annonce avoir reçu plus de 200 commentaires sur son blog et 60+ emails. Il dit donc « un grand merci » à tous ces participants. Parmi les différentes suggestions, le LISP, le Forth, Google Go, l’Erlang, Delphi, les compilateurs exotiques du C++ ainsi que la possibilité de programmer orienté objet directement en C sont tous revenus plusieurs fois.

C’est finalement cette dernière possibilité qui a été retenue. Suite à un commentaire, Soumenkov a expérimenté avec le compilateur pour C de Microsoft Visual Studio. Il a finalement trouvé une combinaison d’options qui permet, avec MSVC 2008, de reproduire à l’identique un segment de code machine de Duqu à partir d’un segment de code source C orienté objet. Avec d’autres compilateurs testés, y comprit MSVC 2005, il obtient un code machine légèrement différent.

Code de Duqu décompilé à la main en C

Étant données les similarités entre les différents constructeurs et les membres des classes, il semble très peu probable que le module communication de Duqu ait été codé entièrement à la main. Par contre, il n’existait pas, au moment où le trojan a été créé, de framework C orienté objet qui produise un code machine semblable à celui de Duqu. Soumenkov en conclut que les développeurs de Duqu utilisent un framework « maison ».

Pour les chercheurs de Kaspersky, la préférence du C par rapport au C++ reflète des programmeurs expérimentés, qui souhaitent un contrôle plus direct sur le code machine produit ainsi qu’une « extrême portabilité ».

Ils sont désormais certains que ce module de Duqu a été compilé avec MSVC 2008 et ses options /O1 et /Ob1. Il a « sans doute » été écrit avec une extension C orientée objet, créée sur mesure. L’architecture événementielle a été créée avec le Framework Duqu ou son extension OO du C. Il n’est pas impossible que le module communication de Duqu ait servi dans d’autres applications, puis ait été réutilisé pour le trojan.

Kaspersky souligne la très haute qualité du code de Duqu (et Stuxnet), selon eux absolument exceptionnelle par rapport aux malwares contemporains.

Il leur semble que ces programmes ont été créés par des équipes « plutôt professionnelles » qui utilisent du code produit par des « top » développeurs expérimentés. Ils n’hésitent pas à parler de « gemmes » au milieu d’ « une masse de malwares stupides ».

Source: Kaspersky

Le trojan Duqu utilise un langage de programmation inconnu
D'après Symantec, qui va jusqu'à parler d'un "Framework Duqu" et qui fait appel à la communauté pour le déchiffrer

Fin 2011, les chercheurs de Symantec avaient identifié un trojan baptisé "Duqu" qui cible les systèmes de type SCADA (Supervisory Control and Data Acquisition), utilisés dans l'industrie pour contrôler des machines-outils. Duqu aurait infecté principalement des organisations en Europe et au Moyen-Orient.

Les chercheurs Russes de Kaspersky avaient alors réussi à identifier des grandes similarités entre certaines parties du code source de Duqu et celui du ver Stuxnet, qui en 2010 avait saboté les centrifugeuses de cinq usines d'enrichissement d'uranium en Iran.

Contrairement à Stuxnet, Duqu ne sabote pas le fonctionnement du système SCADA. Il s'agit d'un outil d'espionnage, qui se connecte sur des serveurs distants pour leur remonter clandestinement des données collectées sur la machine hôte.

Mais ce qui interpelle aujourd'hui le plus les chercheurs du laboratoire Kaspersky, c'est qu'un des modules de Duqu a été écrit dans un language de programmation qu'ils n'ont pas pu identifier.

Duqu est composé de plusieurs modules, dont la plupart ont été écrits en C++ et compilés avec Microsoft Visual C++.

En revanche, le code qui permet à la charge utile de communiquer avec les serveurs distants n'est certainement pas écrit en C++ ou compilé avec MSVC++. Il s'agit d'un language ou d'un framework C orienté objet, que les chercheurs de Kaspersky n'ont jamais vu auparavant. Ils ont baptisé ce language/framework le "Framework Duqu".

Ce language présente les caracteristiques d'être orienté objet, évènementiel, et optimisé pour la programmation asynchrone et le réseau. Il y aurait des ressemblances avec l'Objective-C, mais pour Kaspersky "ce code ne ressemble pas à du code compilé à partir d'Objective-C".

Le modèle évènementiel du "Framework Duqu" d’après Igor Soumenkov de Symantec

Il est possible que le "Framework Duqu" ait été créé sur mesure.

Il pourrait y avoir plusieurs raisons pour cela. La plus évidente serait l'obfuscation, car le "Framework Duqu" rend la retro-ingéniérie de leur malware plus difficile que s'il n'utilisait que des languages connus. Mais il pourrait aussi avoir facilité le cloisonement des équipes qui ont travaillé sur le trojan : peut-être les intégrateurs n'ont-ils pas été techniquement capables de comprendre les sources du module de connexion, grâce à ce "Framework Duqu".

Les chercheurs de Kaspersky ont donc lancé un appel à tout developpeur qui reconnaîtrait des éléments familiers, dans l'espoir de résoudre le mystère Duqu et de son origine.

Comme Stuxnet, et vu son niveau de sophistication, Duqu est fortement suspecté d'avoir été developpé par une organisation disposant de moyens très importants, un service d'État par exemple.

Source : Kaspersky Labs

PS : au moment où j'écris, les derniers commentaires de Kaspersky disent qu'ils s'intéressent aux compilateurs pour LISP, suggérés par plusieurs commentateurs.

psykokarl · 09/03/2012, 17h54

Citation:

Envoyé par MiaowZedong

Comme Stuxnet, et vu son niveau de sophistication, Duqu est fortement suspecté d'avoir été developpé par une organisation disposant de moyens très importants, un service d'État par exemple.

Ou par des passionnés avec un niveau correct qui n'ont pas à respecter de contraintes de type "à livrer pour avant hier !"

phaetone · 14/03/2012, 00h06

Pour moi, ce nouveau Trojan/Framework caractérise en tout cas un gros trou de sécurité. Je propose que son appellation soit éponyme : le trou "Duqu"

phaetone · 14/03/2012, 00h09

À coup sûr, après le Trojan, ils vont bientôt nous pondre un worm.

Je propose une appellation, là encore, éponyme : le ver Duqu.

j'admets, j'ai franchi les limites admissibles dans l'approximatif du calembour, mais ç'a été plus fort que moi, ce doublé de bartavelle...

Gouyon · 14/03/2012, 07h48

Moi non plus je peux pas résister:
le Framework Duqu a certainement été développé en langage X
(Ok je sors mouarf2

GruntZ · 14/03/2012, 08h18

Citation:

Envoyé par MiaowZedong

Ce langage présente les caractéristiques d'être orienté objet, évènementiel, et optimisé pour la programmation asynchrone et le réseau. Il y aurait des ressemblances avec l'Objective-C, mais pour Kaspersky "ce code ne ressemble pas à du code compilé à partir d'Objective-C".
Il est possible que le "Framework Duqu" ait été créé sur mesure.

Plutôt d'accord avec psykokarl; c'est oublier un peu vite qu'il existe encore des codeurs qui savent manipuler pointeurs programme et pile d'adresses en assembleur et savent s'adresser directement à la machine sans l'intermédiaire d'une couche d'abstraction.

MiaowZedong · 14/03/2012, 10h11

Citation:

Envoyé par GruntZ

Plutôt d'accord avec psykokarl; c'est oublier un peu vite qu'il existe encore des codeurs qui savent manipuler pointeurs programme et pile d'adresses en assembleur et savent s'adresser directement à la machine sans l'intermédiaire d'une couche d'abstraction.

Sans vouloir t'offenser, les chercheurs en sécurité qui font de la rétro-ingénierie à partir des binaires (donc de l'assembleur, puisqu'il est une représentation bijective du language machine) sont justement des spécialistes de ce genre de chose. J'aurais donc davantage tendance à les croire.

P.S. d'après les derniers posts sur le site de Kaspersky, il apparait de plus en plus probable qu'il s'agisse bien d'un framework idiosyncratique.

psykokarl · 14/03/2012, 15h35

L'un n'oppose pas l'autre.
Les chercheurs en questions se basent probablement sur un ensemble de signatures explicite ou implicite que laisse un compilateur dans le binaire. Rien que le fait de pouvoir intégrer des lignes d'assembleur dans le code brouille méchamment les piste.
Ça a tendance à exclure le privé . Les développeurs qui ont ces compétences existent mais ils n'auront pas forcément le temps en milieu professionnel.

rt15 · 14/03/2012, 16h04

En tout cas c'est sacré énigme.

Toujours est ils que le peu publié est très propre, même s'il en faudrait un peu plus pour se faire une idée. Cela implique un langage de bas niveau et/ou un compilateur de très bonne qualité (très mature). Le code généré a d’ailleurs certainement de très bonne performances. On parle de code machine qualité C/Delphi/Fortran. Exit tout langage de haut niveau donc.

L'absence d'utilisation de runtime est aussi un point marquant (Il n'y a pas de "printf" ou autre "println", les appels se font directement au win32). Très peu de langage permettent de se passer facilement de leur "librairie standard".

Pas mal de monde semble songer à un framework pour faire de l'OO en C. Toutefois dans ce cas, le compilateur utilisé aurait certainement été Visual C++. Et le code généré ne semble pas venir de ce compilo qui laisse très souvent malencontreusement des traces de son passage d'une manière ou d'une autre (Ne serait ce que de l'inlining massif, ou les fameux mov edi, edi. Mais tout dépend aussi des options de compile).

L'absence de rigueur structurelle est très curieuse (Pointeur this passé de manière différente, position des pointeurs sur les fonctions placés à des emplacements variable dans la structure représentant les objets...). Un compilateur aurait été probablement plus rigoureux à ce niveau.

Ma conclusion perso est que c'est tout bêtement un framework écrit en asm ou en macro asm écrit à la main.

galyathee · 14/03/2012, 21h43

J'imagine que les mordus d'Erlang ou de ooRexx auront quelques idées. Si ces chercheurs pensent à un nouveau langage, il peut très bien s'agir d'un langage - pourquoi pas codé en assembleur, clair - dont on aurait modifié les sources. On ne compte plus le nombre de langages tombés en désuétude et dont les sources sont libres ... avec un peu de motivation, tout un chacun est amené un jour à leur faire reprendre du service.

MiaowZedong · 20/03/2012, 12h11

Le mystère du "Framework Duqu" est résolu
Le malware aurait été écrit avec une extension C orientée objet créée sur mesure

Mise à Jour du 2012/03/20 par MiaowZedong

Les chercheurs de Kaspersky ont annoncé hier (2012/03/19) qu’ils ont résolu « avec un niveau de certitude très élevé » le mystère Duqu.

L’expert Igor Soumenkov commence par remercier les nombreux développeurs qui ont suggéré des pistes d’investigation : il annonce avoir reçu plus de 200 commentaires sur son blog et 60+ emails. Il dit donc « un grand merci » à tous ces participants. Parmi les différentes suggestions, le LISP, le Forth, Google Go, l’Erlang, Delphi, les compilateurs exotiques du C++ ainsi que la possibilité de programmer orienté objet directement en C sont tous revenus plusieurs fois.

C’est finalement cette dernière possibilité qui a été retenue. Suite à un commentaire, Soumenkov a expérimenté avec le compilateur pour C de Microsoft Visual Studio. Il a finalement trouvé une combinaison d’options qui permet, avec MSVC 2008, de reproduire à l’identique un segment de code machine de Duqu à partir d’un segment de code source C orienté objet. Avec d’autres compilateurs testés, y comprit MSVC 2005, il obtient un code machine légèrement différent.

Code de Duqu décompilé à la main en C

Étant donné les similarités entre les différents constructeurs et les membres des classes, il semble très peu probable que le module communications de Duqu a été codé entièrement à la main. Par contre, il n’existait pas, au moment où le trojan a été créé, de framework C orienté objet qui produise un code machine semblable à celui de Duqu. Soumenkov en conclue que les développeurs de Duqu utilisent un framework « maison ».

Pour les chercheurs de Kaspersky, la préférence du C par rapport au C++ reflète des programmeurs expérimentés, qui souhaitent un contrôle plus direct sur le code machine produit ainsi qu’une « extrême portabilité ».

Ils sont désormais certains que ce module de Duqu a été compilé avec MSVC 2008 et ses options /O1 et /Ob1. Il a « sans doute » été écrit avec une extension C orientée objet, créée sur mesure. L’architecture événementielle a été crée avec le Framework Duqu ou son extension OO du C. Il n’est pas impossible que le module communications de Duqu ait servi dans d’autres applications, puis réutilisé pour le trojan.

Kaspersky soulignent la très haute qualité du code de Duqu (et Stuxnet), selon eux absolument exceptionnelle par rapport aux malwares contemporains.

Il leur semble que ces programmes ont été créés par des équipes « plutôt professionnelles » qui utilisent du code produit par des « top » développeurs expérimentés. Ils n’hésitent pas à parler de « gemmes » au milieu d’ « une masse de malwares stupides ».

Source: Kaspersky

cd090580 · 20/03/2012, 14h34

Citation:

Les chercheurs de Kaspersky ont annoncé hier (2012/04/19) qu’ils ont résolu « avec un niveau de certitude très élevé » le mystère Duqu.

Ils ont vachement anticipé

MiaowZedong · 20/03/2012, 15h30

mea culpa

GLDavid · 20/03/2012, 15h52

En tout cas, c'est bien que Kaspersky puisse stopper ce trojan.
L'arrêt Duqu, on l'attend tous

gagaches · 21/03/2012, 10h22

Ça me fait très nettement penser à des développeurs C embarqués.

pour en avoir fait, ça y ressemble étrangement.

C'est très intéressant en fait ce choix de développement.

Freem · 22/03/2012, 09h48

En tout cas, on sent le respect pour les dev duqu...

Je serai curieux de voir à quoi ressemble ce framework en tout cas.

Muchos · 22/03/2012, 13h11

Citation:

Envoyé par Freem

En tout cas, on sent le respect pour les dev duqu...

Oui, c'est touchant. Les experts en sécu luttent contre les crackers, mais les respectent s'ils sont inventifs et codent bien. Il y a tout un esprit du hack : le défi, l'art presque…

Traroth2 · 22/03/2012, 14h48

Ce type de moyen pour un ver, ça pue, je trouve...

Je suis déjà dehors.

rhludovic · 23/03/2012, 09h15

Citation:

Les experts en sécu luttent contre les crackers, mais les respectent s'ils sont inventifs et codent bien.

C'est touchant, alors même pour un mauvais objectif (c'est quand même un malware), les développeurs savent apprécier du bon travail.

Freem · 26/03/2012, 15h51

Citation:

Envoyé par Traroth2

Ce type de moyen pour un ver, ça pue, je trouve...

Je suis déjà dehors.

A ce rythme, tu vas faire ton vers solitaire dehors...

09/03/2012, 11h42	#1
MiaowZedong Membre Expert Grand Timonier des Chats Inscription : décembre 2011 Messages : 610 Détails du profil Informations professionnelles : Activité : Grand Timonier des Chats Informations forums : Inscription : décembre 2011 Messages : 610 Points : 2 278 Points : 2 278	Le trojan Duqu utilise un langage de programmation inconnu Le mystère du "Framework Duqu" est résolu Le malware aurait été écrit avec une extension C orientée objet créée sur mesure Mise à Jour du 20/03/2012 par MiaowZedong Les chercheurs de Kaspersky ont annoncé hier (19/03/2012) qu’ils avaient résolu « avec un niveau de certitude très élevé » le mystère Duqu. L’expert Igor Soumenkov commence par remercier les nombreux développeurs qui ont suggéré des pistes d’investigation : il annonce avoir reçu plus de 200 commentaires sur son blog et 60+ emails. Il dit donc « un grand merci » à tous ces participants. Parmi les différentes suggestions, le LISP, le Forth, Google Go, l’Erlang, Delphi, les compilateurs exotiques du C++ ainsi que la possibilité de programmer orienté objet directement en C sont tous revenus plusieurs fois. C’est finalement cette dernière possibilité qui a été retenue. Suite à un commentaire, Soumenkov a expérimenté avec le compilateur pour C de Microsoft Visual Studio. Il a finalement trouvé une combinaison d’options qui permet, avec MSVC 2008, de reproduire à l’identique un segment de code machine de Duqu à partir d’un segment de code source C orienté objet. Avec d’autres compilateurs testés, y comprit MSVC 2005, il obtient un code machine légèrement différent. Code de Duqu décompilé à la main en C Étant données les similarités entre les différents constructeurs et les membres des classes, il semble très peu probable que le module communication de Duqu ait été codé entièrement à la main. Par contre, il n’existait pas, au moment où le trojan a été créé, de framework C orienté objet qui produise un code machine semblable à celui de Duqu. Soumenkov en conclut que les développeurs de Duqu utilisent un framework « maison ». Pour les chercheurs de Kaspersky, la préférence du C par rapport au C++ reflète des programmeurs expérimentés, qui souhaitent un contrôle plus direct sur le code machine produit ainsi qu’une « extrême portabilité ». Ils sont désormais certains que ce module de Duqu a été compilé avec MSVC 2008 et ses options /O1 et /Ob1. Il a « sans doute » été écrit avec une extension C orientée objet, créée sur mesure. L’architecture événementielle a été créée avec le Framework Duqu ou son extension OO du C. Il n’est pas impossible que le module communication de Duqu ait servi dans d’autres applications, puis ait été réutilisé pour le trojan. Kaspersky souligne la très haute qualité du code de Duqu (et Stuxnet), selon eux absolument exceptionnelle par rapport aux malwares contemporains. Il leur semble que ces programmes ont été créés par des équipes « plutôt professionnelles » qui utilisent du code produit par des « top » développeurs expérimentés. Ils n’hésitent pas à parler de « gemmes » au milieu d’ « une masse de malwares stupides ». Source: Kaspersky Le trojan Duqu utilise un langage de programmation inconnu D'après Symantec, qui va jusqu'à parler d'un "Framework Duqu" et qui fait appel à la communauté pour le déchiffrer Fin 2011, les chercheurs de Symantec avaient identifié un trojan baptisé "Duqu" qui cible les systèmes de type SCADA (Supervisory Control and Data Acquisition), utilisés dans l'industrie pour contrôler des machines-outils. Duqu aurait infecté principalement des organisations en Europe et au Moyen-Orient. Les chercheurs Russes de Kaspersky avaient alors réussi à identifier des grandes similarités entre certaines parties du code source de Duqu et celui du ver Stuxnet, qui en 2010 avait saboté les centrifugeuses de cinq usines d'enrichissement d'uranium en Iran. Contrairement à Stuxnet, Duqu ne sabote pas le fonctionnement du système SCADA. Il s'agit d'un outil d'espionnage, qui se connecte sur des serveurs distants pour leur remonter clandestinement des données collectées sur la machine hôte. Mais ce qui interpelle aujourd'hui le plus les chercheurs du laboratoire Kaspersky, c'est qu'un des modules de Duqu a été écrit dans un language de programmation qu'ils n'ont pas pu identifier. Duqu est composé de plusieurs modules, dont la plupart ont été écrits en C++ et compilés avec Microsoft Visual C++. En revanche, le code qui permet à la charge utile de communiquer avec les serveurs distants n'est certainement pas écrit en C++ ou compilé avec MSVC++. Il s'agit d'un language ou d'un framework C orienté objet, que les chercheurs de Kaspersky n'ont jamais vu auparavant. Ils ont baptisé ce language/framework le "Framework Duqu". Ce language présente les caracteristiques d'être orienté objet, évènementiel, et optimisé pour la programmation asynchrone et le réseau. Il y aurait des ressemblances avec l'Objective-C, mais pour Kaspersky "ce code ne ressemble pas à du code compilé à partir d'Objective-C". *Le modèle évènementiel du "Framework Duqu" d’après Igor Soumenkov de Symantec* Il est possible que le "Framework Duqu" ait été créé sur mesure. Il pourrait y avoir plusieurs raisons pour cela. La plus évidente serait l'obfuscation, car le "Framework Duqu" rend la retro-ingéniérie de leur malware plus difficile que s'il n'utilisait que des languages connus. Mais il pourrait aussi avoir facilité le cloisonement des équipes qui ont travaillé sur le trojan : peut-être les intégrateurs n'ont-ils pas été techniquement capables de comprendre les sources du module de connexion, grâce à ce "Framework Duqu". Les chercheurs de Kaspersky ont donc lancé un appel à tout developpeur qui reconnaîtrait des éléments familiers, dans l'espoir de résoudre le mystère Duqu et de son origine. Comme Stuxnet, et vu son niveau de sophistication, Duqu est fortement suspecté d'avoir été developpé par une organisation disposant de moyens très importants, un service d'État par exemple. Source : Kaspersky Labs PS : au moment où j'écris, les derniers commentaires de Kaspersky disent qu'ils s'intéressent aux compilateurs pour LISP, suggérés par plusieurs commentateurs.
	151

14/03/2012, 00h06	#3
phaetone Membre à l'essai Sébastien Enseignant Inscription : mars 2012 Messages : 2 Détails du profil Informations personnelles : Nom : Sébastien Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur) Informations professionnelles : Activité : Enseignant Secteur : Enseignement Informations forums : Inscription : mars 2012 Messages : 2 Points : 21 Points : 21	Trojan, Framework, ou autre ? Pour moi, ce nouveau Trojan/Framework caractérise en tout cas un gros trou de sécurité. Je propose que son appellation soit éponyme : le trou "Duqu"
	91

14/03/2012, 00h09	#4
phaetone Membre à l'essai Sébastien Enseignant Inscription : mars 2012 Messages : 2 Détails du profil Informations personnelles : Nom : Sébastien Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur) Informations professionnelles : Activité : Enseignant Secteur : Enseignement Informations forums : Inscription : mars 2012 Messages : 2 Points : 21 Points : 21	Next step ? À coup sûr, après le Trojan, ils vont bientôt nous pondre un worm. Je propose une appellation, là encore, éponyme : le ver Duqu. j'admets, j'ai franchi les limites admissibles dans l'approximatif du calembour, mais ç'a été plus fort que moi, ce doublé de bartavelle...
	71

14/03/2012, 07h48	#5
Gouyon Membre expérimenté Rémi Gouyon Développeur informatique Inscription : novembre 2003 Messages : 586 Détails du profil Informations personnelles : Nom : Rémi Gouyon Âge : 49 Localisation : France, Loiret (Centre) Informations professionnelles : Activité : Développeur informatique Secteur : Aéronautique - Marine - Espace - Armement Informations forums : Inscription : novembre 2003 Messages : 586 Points : 591 Points : 591	Moi non plus je peux pas résister: le Framework Duqu a certainement été développé en langage X (Ok je sors mouarf2 __________________ Il y a des jours où j'éprouve une haine profonde envers microsoft Venez vous défouler ici ou là c'est amusant Mon modeste site et mes modestes oeuvres sont là Rémi
	21

20/03/2012, 12h11	#11
MiaowZedong Membre Expert Grand Timonier des Chats Inscription : décembre 2011 Messages : 610 Détails du profil Informations professionnelles : Activité : Grand Timonier des Chats Informations forums : Inscription : décembre 2011 Messages : 610 Points : 2 278 Points : 2 278	Le mystère du "Framework Duqu" est résolu Le malware aurait été écrit avec une extension C orientée objet créée sur mesure Mise à Jour du 2012/03/20 par MiaowZedong Les chercheurs de Kaspersky ont annoncé hier (2012/03/19) qu’ils ont résolu « avec un niveau de certitude très élevé » le mystère Duqu. L’expert Igor Soumenkov commence par remercier les nombreux développeurs qui ont suggéré des pistes d’investigation : il annonce avoir reçu plus de 200 commentaires sur son blog et 60+ emails. Il dit donc « un grand merci » à tous ces participants. Parmi les différentes suggestions, le LISP, le Forth, Google Go, l’Erlang, Delphi, les compilateurs exotiques du C++ ainsi que la possibilité de programmer orienté objet directement en C sont tous revenus plusieurs fois. C’est finalement cette dernière possibilité qui a été retenue. Suite à un commentaire, Soumenkov a expérimenté avec le compilateur pour C de Microsoft Visual Studio. Il a finalement trouvé une combinaison d’options qui permet, avec MSVC 2008, de reproduire à l’identique un segment de code machine de Duqu à partir d’un segment de code source C orienté objet. Avec d’autres compilateurs testés, y comprit MSVC 2005, il obtient un code machine légèrement différent. Code de Duqu décompilé à la main en C Étant donné les similarités entre les différents constructeurs et les membres des classes, il semble très peu probable que le module communications de Duqu a été codé entièrement à la main. Par contre, il n’existait pas, au moment où le trojan a été créé, de framework C orienté objet qui produise un code machine semblable à celui de Duqu. Soumenkov en conclue que les développeurs de Duqu utilisent un framework « maison ». Pour les chercheurs de Kaspersky, la préférence du C par rapport au C++ reflète des programmeurs expérimentés, qui souhaitent un contrôle plus direct sur le code machine produit ainsi qu’une « extrême portabilité ». Ils sont désormais certains que ce module de Duqu a été compilé avec MSVC 2008 et ses options /O1 et /Ob1. Il a « sans doute » été écrit avec une extension C orientée objet, créée sur mesure. L’architecture événementielle a été crée avec le Framework Duqu ou son extension OO du C. Il n’est pas impossible que le module communications de Duqu ait servi dans d’autres applications, puis réutilisé pour le trojan. Kaspersky soulignent la très haute qualité du code de Duqu (et Stuxnet), selon eux absolument exceptionnelle par rapport aux malwares contemporains. Il leur semble que ces programmes ont été créés par des équipes « plutôt professionnelles » qui utilisent du code produit par des « top » développeurs expérimentés. Ils n’hésitent pas à parler de « gemmes » au milieu d’ « une masse de malwares stupides ». Source: Kaspersky
	40

14/03/2012, 15h35	#8
psykokarl Membre actif Inscription : mars 2011 Messages : 91 Détails du profil Informations forums : Inscription : mars 2011 Messages : 91 Points : 165 Points : 165	L'un n'oppose pas l'autre. Les chercheurs en questions se basent probablement sur un ensemble de signatures explicite ou implicite que laisse un compilateur dans le binaire. Rien que le fait de pouvoir intégrer des lignes d'assembleur dans le code brouille méchamment les piste. Ça a tendance à exclure le privé . Les développeurs qui ont ces compétences existent mais ils n'auront pas forcément le temps en milieu professionnel.
	10

14/03/2012, 16h04	#9
rt15 Membre éprouvé Développeur informatique Inscription : octobre 2005 Messages : 203 Détails du profil Informations personnelles : Sexe : Âge : 28 Localisation : France, Savoie (Rhône Alpes) Informations professionnelles : Activité : Développeur informatique Informations forums : Inscription : octobre 2005 Messages : 203 Points : 435 Points : 435	En tout cas c'est sacré énigme. Toujours est ils que le peu publié est très propre, même s'il en faudrait un peu plus pour se faire une idée. Cela implique un langage de bas niveau et/ou un compilateur de très bonne qualité (très mature). Le code généré a d’ailleurs certainement de très bonne performances. On parle de code machine qualité C/Delphi/Fortran. Exit tout langage de haut niveau donc. L'absence d'utilisation de runtime est aussi un point marquant (Il n'y a pas de "printf" ou autre "println", les appels se font directement au win32). Très peu de langage permettent de se passer facilement de leur "librairie standard". Pas mal de monde semble songer à un framework pour faire de l'OO en C. Toutefois dans ce cas, le compilateur utilisé aurait certainement été Visual C++. Et le code généré ne semble pas venir de ce compilo qui laisse très souvent malencontreusement des traces de son passage d'une manière ou d'une autre (Ne serait ce que de l'inlining massif, ou les fameux mov edi, edi. Mais tout dépend aussi des options de compile). L'absence de rigueur structurelle est très curieuse (Pointeur this passé de manière différente, position des pointeurs sur les fonctions placés à des emplacements variable dans la structure représentant les objets...). Un compilateur aurait été probablement plus rigoureux à ce niveau. Ma conclusion perso est que c'est tout bêtement un framework écrit en asm ou en macro asm écrit à la main.
	01

14/03/2012, 21h43	#10
galyathee Membre du Club Développeur informatique Inscription : mars 2009 Messages : 54 Détails du profil Informations professionnelles : Activité : Développeur informatique Informations forums : Inscription : mars 2009 Messages : 54 Points : 43 Points : 43	J'imagine que les mordus d'Erlang ou de ooRexx auront quelques idées. Si ces chercheurs pensent à un nouveau langage, il peut très bien s'agir d'un langage - pourquoi pas codé en assembleur, clair - dont on aurait modifié les sources. On ne compte plus le nombre de langages tombés en désuétude et dont les sources sont libres ... avec un peu de motivation, tout un chacun est amené un jour à leur faire reprendre du service.
	10

20/03/2012, 15h30	#13
MiaowZedong Membre Expert Grand Timonier des Chats Inscription : décembre 2011 Messages : 610 Détails du profil Informations professionnelles : Activité : Grand Timonier des Chats Informations forums : Inscription : décembre 2011 Messages : 610 Points : 2 278 Points : 2 278	mea culpa
	00

20/03/2012, 15h52	#14
GLDavid Membre Expert Inscription : janvier 2003 Messages : 2 667 Détails du profil Informations personnelles : Âge : 36 Informations forums : Inscription : janvier 2003 Messages : 2 667 Points : 2 487 Points : 2 487	En tout cas, c'est bien que Kaspersky puisse stopper ce trojan. L'arrêt Duqu, on l'attend tous __________________ GLDavid Consultez la FAQ Perl ainsi que mes cours de Perl. N'oubliez pas les balises code ni le tag Je ne répond à aucune question technique par MP.
	21

21/03/2012, 10h22	#15
gagaches Membre éclairé Inscription : novembre 2003 Messages : 65 Détails du profil Informations forums : Inscription : novembre 2003 Messages : 65 Points : 322 Points : 322	Ça me fait très nettement penser à des développeurs C embarqués. pour en avoir fait, ça y ressemble étrangement. C'est très intéressant en fait ce choix de développement.
	00

22/03/2012, 09h48	#16
Freem Expert Confirmé Développeur informatique Inscription : décembre 2008 Messages : 777 Détails du profil Informations personnelles : Sexe : Localisation : France Informations professionnelles : Activité : Développeur informatique Informations forums : Inscription : décembre 2008 Messages : 777 Points : 2 812 Points : 2 812	En tout cas, on sent le respect pour les dev duqu... Je serai curieux de voir à quoi ressemble ce framework en tout cas.
	00

22/03/2012, 14h48	#18
Traroth2 Expert Confirmé Inscription : décembre 2003 Messages : 1 660 Détails du profil Informations forums : Inscription : décembre 2003 Messages : 1 660 Points : 3 318 Points : 3 318	Ce type de moyen pour un ver, ça pue, je trouve... Je suis déjà dehors. __________________ Les brevets ? Le type qui a inventé l'eau chaude doit être grave blindé de thunes !
	01

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email