Extraction des fichiers .tor de Star Wars: The Old Republic

Pour ceux qui veulent savoir ce qui se passe dans les fichiers de SW:ToR, voici un petit morceau de code pour "traiter" tous les fichiers .tor dans un repertoire. Le format est base sur des archives "MYP" avec des SHA-256 integres dans les donnees. Les noms de fichiers ne sont pas disponibles dans les archives, seuls un hash particulier sur 64 bits permet d'identifier les fichiers. Une liste partielle des fichiers est disponible avec le projet easymyp.

Le code ne fait pas grand chose, mais donne une idee du format des fichiers.
Il semble au passage que quantites de SHA-256 soient invalides.

Steam tombe

Et un autre Stuxnet...

Apparemment, les auteurs de Duqu seraient les memes que ceux de Stuxnet. Il y a un gros PDF qui regroupe les travaux de Symantec et du "laboratoire" qui a ete publie.

Le certificat utilise pour signer les .sys a semble-t-il ete vole, et bien que cache au sein du PDF (sauf son empreinte), il s'agirait d'un certificat de C-Media Eletronics Incorporation qui est maintenant revoque.

D'apres ce que j'ai lu, le but de Duqu est different de celui de Stuxnet et se concentre davantage sur le C&C que la proliferation et l'exploitation de vulnerabilites. Le rapport du "laboratoire" ne semble pas infirmer la presence de 0days dans les binaires.

Quelques liens:

• Symantec: http://www.symantec.com/connect/w32_duqu_precursor_next_stuxnet
• McAfee: http://blogs.mcafee.com/mcafee-labs/the-day-of-the-golden-jackal-%E2%80%93-further-tales-of-the-stuxnet-files
• F-Secure: http://www.f-secure.com/weblog/archives/00002255.html, http://www.f-secure.com/v-descs/backdoor_w32_duqu.shtml
• Norman: http://blogs.norman.com/2011/security-exposed/w32duqu-stuxnet-lite
• Rapports Virus Total: http://www.virustotal.com/file-scan/report.html?id=f2b631fcdf83b928661a7e09dd11fa640251a4850ff570436f3b16abef0fad10-1317395560 (soumission du 30 Septembre 2011), http://www.virustotal.com/file-scan/report.html?id=1cd11a596ad732e3513aac21bd7e43a9883544b1abc7b775bdbb104a3f61ce0f-1318645582 (soumission du 13 Octobre 2011)
• Contagio: http://contagiodump.blogspot.com/2011/10/duqu-rat-trojan-precursor-to-next.html
• Dell SecureWorks: http://www.secureworks.com/research/threats/duqu/

Edit: tableau & liens.

idapython 1.5.2

La nouvelle version d'idapython semble fixer le probleme du script de graph d'xrefs lorsque je l'ai passe en plugin ("crash" lors du double-clique sur un node et fermeture de l'IDB). Telechargez la si vous aviez un probleme avec xrefgraf.py:

http://code.google.com/p/idapython/downloads/list

Je rajouterai les fonctionalites manquantes dans la semaine. Peut-etre.

XrefGraf.py

Bon j'ai rajoute les quelques lignes necessaires afin de transformer le script en un plugin. Copiez le fichier dans le repertoire de plugin de IDA (n'oubliez pas d'installer la derniere version de idapython), et ALT-F8 vous presentera le dialogue. J'ai aussi corrige un probleme de logique. Alors maintenant un autre bug est apparu: dans le plugin, double-cliquer sur un noeud provoque un crash d'IDA - j'ai essaye de trouve pourquoi ca marche en script et pas en plugin, sans succes. Si quelqu'un sait et peut me dire pourquoi ca serait sympa :)

Script idapython du Dimanche soir

Apres une dure victoire des Miami Heat 88 a 86 contre les Dallas Mavericks pour le 3e match des finales des playoffs de la NBA (2-1!), je me suis decide a essaye de terminer le script d'hier. Apres avoir joue avec les Forms dans l'apres-midi, il se trouve qu'un dialogue se fait plus aisement que prevu. Donc je me suis efforce de faire quelque chose qui ressemblait au menu courant, toujours avec cette notion de filtre par expression reguliere sur les xrefs qui me tenait a coeur

J'ai inclus du code pour les xrefs to et les xrefs from. C'est moche mais ca a l'air de marcher. Comprenez bien qu'a 11:30PM un dimanche soir, ma batterie de test a consiste a tester 3 fonctions et a juger du resultat au nez. Mais comme Google, je vais faire confiance aux utilisateurs finaux pour tester, trouver des bugs, me les envoyer, et me traiter de tous les noms pour avoir pondu du code pourri.

Et comme je ne maitrise toujours pas le web 3.0 et que je n'arrive pas a coller du code proprement formate dans ce blog, je vais faire confiance a pastebin pour cela. Le code complet du script se trouve a l'adresse suivante:

http://pastebin.com/nidWa9U7



Enjoy!

Script idapython du Samedi

Dans IDA, je cherche souvent comment arriver a une fonction depuis d'autres fonctions que j'ai analyse. Halvar dirait que BinNavi est fait pour ca, mais personnellement, vu que je suis vieux et refractaire au progres, j'utilise generalement la fonctionnalite de graphe de IDA (View -> Graph -> User xref chart...), qui utilise toujours en 2011 le tres laid wingraph.exe.

Tout va bien lorsque votre fonction est appelee 2 fois par des fonctions elles-meme appelees 2 fois, etc. On retrouve facilement ce que l'on cherche. Par contre, lorsque votre fonction est appelee 42 fois par des fonctions elles-meme appelees 42 fois, ca devient bordelique.

Lorsque j'audite, je renomme toutes les fonctions que j'analyse avec un prefixe particulier ('imm').Je me suis donc decide a ecrire un script idapython recherchant les recursivement les references en applicant une expression reguliere ('^imm') sur le nom des fonctions. Le resultat est un graphe epure ne contenant que les chemins que je cherchais (provenant d'une fonction analysee vers la fonction ciblee). Au final ca a pris 15 minutes et ca l'air de marcher.

Ce premier graphe correspond a une profondeur maximale de 2, sans expression reguliere appliquee, vers la fonction ciblee: c'est le bordel.

Ce second graphe correspond a une profondeur maxiumale de 8, avec expression reguliere '^imm', vers le meme fonction ciblee: c'est deja moins le bordel, et tous les blocs initiaux respectent effectivement mon expression reguliere.

J'aimerais bien remplacer le menu actuel Xref de IDA par quelque chose utilisant une version plus developpee de ce code, histoire d'avoir les Drefs/Crefs To et From avec application d'expressions regulieres. Ca me semble representer plus de travail que je ne desire y consacrer (surtout que je n'ai jamais essaye de creer un dialogue), mais si quelqu'un a du temps, amusez vous.

Et voici le code (de merde):

Edit: desole je suis infoutu de formater le code proprement.

Memorial Day week-end

Une fois par an, pour "Memorial Day Week-End", South Beach se tranforme en un gigantesque Ghetto. Malgre une presence policiere decuplee, ca se finit toujours en drames. Cette annee, un echange de coups de feu a ete filme entre la police et des criminels. Les officiers finissent par decharger leurs pistolets sur la voiture.

Personnellement, je pense que le blame initial pour de telles situations revient a la ville de Miami Beach, qui se contente de laisser la situation degenerer tout un week-end jusqu'a des conclusions macabres comme celles-ci.

Les drivers graphiques

Recemment, tout le monde s'est mis a s'inquieter du fait que WebGL existait. Ou du moins, commencait a etre integre a des navigateurs populaires comme Chrome ou Firefox. Certes, cela ajoute un niveau additionnel de complexite au code et une nouvelle surface d'attaque associee - ce qui n'est pas ideal - mais surtout ca expose les drivers graphiques aux Internets. Et ca, c'est le debut de la fin (meme si FX ne semble pas etre d'accord). Pour la bonne et simple raison que les drivers graphiques sont gros et tres mal codes (mon .sys ATI est plus gros que mon noyau).

Dans l'eventualite ou vous voudriez en avoir la preuve, je vous invite a vous rendre sur la page du test de conformite WebGL depuis un Windows XP sous VMware avec Chrome, le tout a jour, avec support 3D. Apres quelques tests, ma VM a bluescreene, faute au driver video de VMware qui a tente une division par 0 en ring 0 (dans vmx_fb.dll pour etre precis). La division par 0, ce n'est pas bien grave, mais ca ne represente qu'une portion infime de ce qui peut derailler dans le traitement de la 3D.

Maintenant, est-ce la faute de VMware seulement? Pas vraiment. Je citerai pour demonstration la liste noire de drivers videos dans Firefox 4. Mozilla a pris l'initiative de ne pas activer WebGL si les drivers graphiques sont "pourris" (enfin, ils le sont tous), et ne supporte vraiment que les 3 grandes marques ATI, Intel, Nvidia. Pour crasher votre VM avec Firefox, il faut aller dans about:config, et forcer WebGL. En fait, Chrome fait de meme, plus ou moins. On relevera les notes suivantes:

• NVIDIA drivers older than 257.21 on Windows XP are assumed to be buggy.

• Intel drivers older than 14.42.7.5294 on Windows XP are assumed to be buggy.

• ATI drivers older than 10.6 on Windows XP are assumed to be buggy.

Je trouve relativement interessant qu'il releve aujourd'hui du navigateur de proteger l'utilisateur des couches de vulnerabilites de niveau inferieur. Enfin toujours est-il que lorsque je lis les recherches de "Context Information Security LTD", je me dis qu'ils sont passes a cote du probleme.