Vous êtes sur la page 1sur 8

Rendre un Virus indtectable

Chez les editeurs d'anti virus, il existe des bataillons d'ingenieurs commandos surentrains qui sont pays des fortunes pour surveiller l'appariton de nouveaux troyens, et en extraire une signature puis la mettre en update chez l'utilisateur. Sans compter avec les sites bnvoles mais quasi-professionnels de scurit informatique, bref tout ceci fait qu'il existe une veille telle qu'a partir du release d'un nouveau serveur, au bout d'une semaine environ toutes machine connecte digne de ce nom pourra le dtecter. Alors, quelles solutions s'offrent a nous ? premierement, beaucoup rpondent qu'il suffit de programmer son propre troyen. C'est vrai, encore faut il savoir sous quelle forme ceci est fait, et quelle est la vritable fonctionnalit du produit en question. Or on voit rarement ces memes personnes publier leur sources, ce qui permet difficilement de se faire une opinion. Deuximement, et c'est ce a quoi nous nous attacherons ici, on fera confiance au programmeur d'un server reconnu et prouv par tous, et nous allons nous permettre de le modifier afin de changer sa signature. En effet, c'est grace a cette empreinte que les antivirus comparent avec leur base de donne que la detection se fait. Description d'une attaque par troyen Ce qui sera expliqu ici est un ensemble de techniques. Dans certains cas, l'application d'une d'entre elle seulement suffira, dans les autres il faudra toutes les appliquer, parfois plusieurs fois. Tous les servers sont diffrents, il vous faudra donc vous adapter a ce sur quoi vous travaillez. Comme dans la nature, ceux qui ne s'adapterons pas...mourrons.

voici les outils qu'il va falloir se procurer : ScoolBus Hex workshop diteur hexadcimal Windasm32 desassembleur win32dsm900 UPXshell compresseur/dcompresseur

Prparation : Comme on veut manipuler des fichiers contenant un code hostile, il va falloir dire a son chien de garde de se tenir tranquille. Prparons donc notre environnement de travail : avant le travail 1* dsactivez l'autoprotect de votre antivirus 2* crez un dossier dans lequel on fera ces manipulations, disons ...\tests 3* dans votre antivirus, excluez ce dossier des scans. Ainsi vous pouvez laisser votre travail tranquillement pour y revenir par la suite. pendant le travail 1* laisser l'autoprotect enlev. Les tests successifs se feront a la main, en demandant un scan de fichier a l'antivirus. 2* prparez dans le dossier \tests une copie du serveur (on ne la modifiera pas, elle sert de tmoins), puis une deuxime (celle ci servira a chaque tape, et sera teste) 3* si plusieurs manipulations sont necessaires, n'hesitez pas a renommer le serveur de test de facon claire, afin de pouvoir s'y retrouver dans les diffrentes tapes. Par exmple, dans le repertoire test on pourra trouver : copie du server server 1000 bytes 00 server 1000 bytes 00 decompression 1 server 1000 bytes 00 decompression 1 compression 1 server 1000 bytes 00 decompression 1 compression 1 decompression 2 c'est un exemple. Il va falloir avoir une certaine organisation pour ce travail, sinon on s'y perd. Ajout de bytes blancs :

le fait d'ajouter un certain nombre de 00 en fin de fichier augmente la taille du serveur, mais a la compression celle ci diminue normement, sans pour autant modifier le comportement du programme en lui mme. De plus, ceci modifie les checksums CRC et MD5, qui sont utiliss par de nombreux serveurs de mails afin de dtecter les menaces. Il ne s'agit pas de rajouter le plus grand nombre possible de bytes, cela n'a aucun interet, mais de trouver quel nombre est suffisant pour faire cette modification. Ne rajoutez donc pas 30Mo l ou 30 bytes suffisaient ! Pratique : Dans l'diteur hexadcimal, ouvrez la copie de travail :

voici une vue de la fin du fichier serveur de schoolbus. A ce stade, on peut rajouter les bytes blancs par ::edit::_____::insert::

Sauvegarder, et tester par un scan de votre antivirus prfer.

Dans le cas qui nous interresse, vous verrez que cela ne suffit pas a rendre schoolbus indetectable. Cependant ceci marche avec de nombreux serveurs, virii etc... Ce qui m'amne a ma transition vers une autre mthode : la compression... Compression UPX : Si vous avez l'habitude de manipuler des serveurs, vous remarquerez qu'avec des fonctions quivalentes, certains psent entre une vingtaine et une cinquantaine de Ko, tandis que d'autres en font quelques centaines. Certains concepteurs de troyens vantent la petite taille de leur serveur, ce qui permet de passer inapercu dans le cas d'un bind avec un autre fichier etc... Ceci est vrai, cependant une autre raison de cette petite taille se trouve rarement explique : Il est possible d'appliquer un type de compression de puissances diffrentes a un executable, et de le rtrcir considrablement tout en ayant comme rsultat un nouvel executable, tout aussi fonctionnel (contrairement au cas des archives Zip, Rar, etc qui ne sont pas executables directement, et perdent donc leur interet dans notre cas). Ce type de compression, la compression UPX est une puissante alternative pour leurer les antivirus. Malheureusement, les concepteurs qui fournissent ces servers de quelques dizaines de Ko les ont donc dja compresss car il connaissent cette technique. Rsultat : les diteurs d'antivirus ont relev la signature du serveur compress, et comme ils ne sont pas idiots, celle du serveur dcompress. On est mal ? Pas du tout ! en effet, a la compression l'utilisateur choisit la force avec laquelle le fichier sera compress. En gnral, la

plus leve (niveau 9, avec compression maxi). En revanche, lorsqu'on a un fichier compress, il est impossible de savoir avec quel niveau il a t compress en premier. Conclusion : les antivirus connaissent la signature d'un fichier compress a une certaine taille, mais pas aux autres niveaux disponibles. Je rsume, deux solutions : 1* fichier non compress : compresser a differents niveaux, en commancant du plus lev, et essayer jusqu'a trouver le bon. 2* fichier compress : dcompresser avec UPX, puis recompresser a diffrents niveaux. Au passage, envoyez quelques bytes blancs, ce ne peut pas faire de mal...

Comme on a fait pas mal de manipulations jusqu'ici, je vous rappelle de bien nommer intelligament vos fichiers d'essai sinon vous allez etre perdu, appliquer des modifications a un fichier dja modifier, voir annuler les modifications effectues... Ne venez pas pleurer apres car ce ne marche pas ! Bref, on fait tout ceci. Dans notre cas, le serveur de schoolbus fait 320 Ko, ce qui signifie qu'il n'est pas compress. On lui applique donc une compression de niveau 9, et on obtient un fichier de 18Ko. Testez-le avec cette mthode...!!! SuRpRiSe !!! Modification assembleur de la signature : Foolfox ayant post une explication claire a ce sujet, je la livre ici telle quelle : 1.rechercher la signature correspondante a l'AV (je vous rappelle que toutes ces definitions sont sur votre HD) 2.localiser la sequence trouvee dans le soft. 3.modifier le programme au niveau asm pour modifier la signature. Pas besoin d'etre une bete, il suffit de modifier la sequence d'opcodes pour que l'AV ne retrouve pas exactement la sequence qu'il cherche. Il faut toutefois preserver la fonctionnalite. exemple: code original: Code: MOV EAX,0

nouveau code: Code: XOR EAX,EAX Conclusion : L'ensemble de ces approches sera a adapter, tester, utilises seules ou entre elles selon le serveur sur lequel vous travaillez. Comme d'habitude, si vous avez d'autres ides, des remarques, postez les a la suite de ce tuto. Si vous avez des questions, merci de les poser dans la partie Hacking. Enfin, sauf cas exceptionnel, inutile de me demander en mp un travail particulier, demandez le plutot en

publique. Ici on travaille pour tous et non pour un. Bon courage ! By 4n9e Complments : Au vu des ractions suite lexplication des mthodes qui permettent de rendre un code hostile indetectable aux antivirus, je me rend compte quon est alls un peu vite, en passant directement aux applications pratiques, sans passer par une phase dexplication des mcanismes qui rgissent les principes de dtection. Je vais donc essayer aujourdhui de combler ce manque, en esperant tre aussi complet que possible. Pour tre clair, jappellerais ici les anti virus AV, et les troyens, virii, etc, Hostile. Que les puristes ne men veuillent pas si jutilise un vocabulaire parfois tres gnraliste dans ce qui va suivre. En effet, je vais essayer de rendre la comprhension de tout ceci accessible au plus grand nombre. Au menu : Mthode de detection de lanti virus (AV) Le principe de la modification dtermination des signatures utilises par lAV dtermination et localisation au sein de lhostile Modifier la signature de lhostile Conclusion Mthode de detection de lanti virus (AV) Comme pr-requis, vous devez savoir que les Av reconnaissent un lment hostile (un troyen par exemple) par analyse dun ou plusieurs morceaux de code binaires, quon appelle signature. Celle-ci devra tre bien sr caractristique de lhostile. On appellera Offset de signature le lieu o est plac ce code dans le programme. Or, le premier problme dans notre dmarche future est que chaque AV va utiliser sa propre mthode pour reconnatre lhostile. Comprennez que tout AV considrera une signature diffrente. Les oprations qui seront dcrites ici devront donc tre rptes, voire adaptes la cible, plus prcisement lAV qui en assure la protection. Un hostile non dtect par Norton peut tout a fait ltre chez KAV. Le principe de la modification La dmarche qui consiste modifier lhostile pour quil passe inapercu aux yeux de lAV sinscrit en trois temps : - dtermination des signatures utilises par lAV - localisation de cette signature au sein de lhostile - modification de celle-ci Jusquici, et vu comme cela, ca lair assez simple. Cependant, pour ceux qui ont suivit, quelques problmes se profilent dj, dont la ncessiter de connatre le stockage de la base de donnes de signatures de lAV, tre capable de situer precisement ces signatures au sein de lhostile, et enfin pouvoir modifier le code sans altrer le fonctionnement du programme. dtermination des signatures utilises par lAV Il sagit ici dtudier lAV qui protge la cible. Pour cela, rien de mieux que de linstaller chez soi, et lobserver afin de connatre lemplacement dans le repertoire dinstallation o sont stockes les donnes de signature. Dans le cas de KAV, il sagira de %repertoire racine%\KAV Shares Files\Bases\. On y trouvera des fichiers en .AVC. Ceux-ci devront tre decrypts (si je retrouve le programme, je le mettrait en dl.)

dtermination et localisation au sein de lhostile Une approche est alors la suivante : il sagit dinstaller dans le mme repertoire le programme AVPOFFSET.EXE et lhostile. Si je dis cela, cest surtout pour la suite du travail. La suite se fait en ligne de commande sous DOS, par lusage AVPOFFSET Hostile.exe. Le travail prend un certain temps, et devrait retourner un rsultat similaire : hostile.exe infected: [infection] Signature 1 found : Offset : 411758 ( 7CF8eh) Length : 7 ( 7h) checksum: (1FAB89C2h) Signature 2 found: Offset : 415732 ( 7CF3AB) Length : 255 ( FFH) Checksum: (231ADD51H) Nota : pour toute manipulation sur les serveurs de troyen, il sera obligatoire que celui-ci soit dcompress auparavent, si vous avez a faire un hostile compress. Il est assez frquent que pour des raisons pratiques de lgeret de lhostile afin de lenvoyer, ou tout simplement dans une dmarche dindetection de lauteur (voir les discutions prcedentes sur le sujet), lhostile soit dj compress, ou, dans le cas dun gnrateur de server pour un troyen, que le gnrateur produise un fichier compress. On pourra appliquer diffrents outils de dcompression, parmis lesquels : UPX StudPE (lui analysera loutil utilis lorigine de la compression) Un-pack, qui marche toujours, bien que surtout connu sous Win 98. Nota II : Dois-je prciser de dsactiver lAV ?... Une autre approche sera ce quon appelle Splitting. Cette mthode se fait en aveugle et suppose une bonne experience, ne serais ce que pour savoir o mettre le doigt au sein de lhostile. Il sagira en effet de remplacer taton, puis en focussant la procdure, loffset de la signature. On peut pour cela remplacer sur loffset des bouts du binaire par des zros ou des NoPs, puis tenter la detection par AV. En cas dindetection, on a tap dans la signature. Il sagit alors de recommencer en ne modifiant quune partie de ce quon a modifi plus haut. Si il est encore indetectable, on recommence sur un bout encore plus petit, etc jusqu' trouver le plus petit bout de code qui, modifi, permet lindetection. Cest la signature purifie , dont on connat prsent loffset prcis. Je shmatise, pour bien comprendre : azertyuiopqsdfghjklmwxcvbn * modification dun bout * azertyuiopqs00000000wxcvbn * et encore : * azertyuiopqs00000klmwxcvbn * jusqu trouver le plus petit bout : * azertyuiopqs0000jklmwxcvbn * dfgh tait donc la signature, son offset est entre s et k

Cette dmarche se fera avec laide dun diteur hexadcimal, WinHex, ou HexWorkshop, etc, vous avez le choix des armes ! Cependant, on voit bien la limite du Splitting : il faut au moins savoir peu pres o frapper. Pour cela, intervient pour une grande part lexperience du manipulateur, sa connaissance des AV, et des structures dun programme. En effet, il existe plusieurs mthodes dapproche pour savoir o modifier, sachant que certains AV cherchent la signature dans l entry point du programme, le lieu de lexecution de la premire commande, tandis que dautres se focalisent plutot sur les ressources du programme. Jajoute a tout ceci que si vous voulez conserver un hostile viable, il ne faudra pas modifer les enttes, ce qui aurait pour effet de transformer lhostile en boullie de bytes peut tre indetectable, mais surtout inutile Quoi quil en soit, considrons que nous avons connaissance a present de loffset de la signature (on laura remise telle quelle si on a utilis la mthode de splitting). Modifier la signature de lhostile Je me rpete, mais avant daller plus loin, je rappelle quon va travailler ici dans le but de cacher une signature bien prcise un AV bien prcis. Si vous avez de la chance, ceci suffira pour la plupart des AV, sinon, il faudra recommencer Bref, on arrive ici au nud du probleme qui en interpelle plus dun, la modification assembleur de lhostile. Au pralable, celui-ci sera dsassembl (cas de la modification froid ), ou dbugg (cas de la modification a chaud ) Vous lavez comprit, il faudra se procurer un dsassembleur ou un debugger. Je vous laisse chercher, peut tre en mettrais- je aussi en dl dans les publiques. Si on se rend loffset quon a dcouvert comme renfermant la signature (ventuellement mme avec un diteur hexadcimal), on trouvera soit la reprsentation hexadcimale des instructions assembleur, soit les instructions assembleur elles mmes, c'est--dire (ceci est un exemple) : Hexa 8D45F8, ou Assembleur LEA EAX,Dword ptr [ebp-08] cette animal est une inscription dans le registre. Le but est donc ici de trouver une instruction quivalente. LEA EAX,Dword ptr [ebp-08] ==> Mov EAX,Dword Ptd ds:[ebp-08] Cest ce genre de modification, crire une commande qui fera le mme travail, mais ne sera pas celle dorigine, attendue par lAV, qui rendra lhostile indetectable puisque sa signature aura chang. Il existe biens sur de nombreux exemples, et selon les AV, loffset modifier etc Dire que pour le troyen troyenutilis , il faut se rendre loffset xxx, et modifier azerty par qwerty afin de le rendre universellement indetectable ne serais pas completement vrai. Toutefois, il est encore possible daborder une autre forme de modification sans faire appel lassembleur. On passera ici uniquement par lhexadcimal, en se branchant sur loffset de signature, et en regardant la correspondance Ascii. On peut avoir de la chance, et tomber sur quelque chose comme 756E5365727669636573000000FFFFFFFF (hexadecimal) RunServices....... (Ascii) Cest le genre de signature qui ne dtecte pas par laction du programme comme plus haut, mais par la prsence dun texte prcis (nota : ne cherchez pas systmatiquement RunService, cest un exemple fictif)

Ca peut paratre tonnant, mais le fait de remplacer lettre pour lettre, sous peine de crasher le code, ce bout de texte qui fait office de signature peut largement suffire leurrer lAV. Cela vous parait incroyable ? Cest pourtant une des genre de signature le plus utilis par Norton ! Qui parmis vous utilise Norton AV ?... Conclusion Les mthodes de modification en profondeur dun code nont rien de facile, et sans quelques bases minimum en assembleur, en connaissance des structures dun programme, en experience face au fonctionnement mme des protections, ne vous imaginez surtout pas que nimporte qui puisse sattaquer ce genre dexercice de style. Cest la dure Loi de la lance et du bouclier : plus le bouclier est solide (et je vous assure que les diteurs dAV ne sont pas que des idiots, loin de l), plus le concepteur de la lance devra avoir un niveau de connaissances techniques approfondit