Chez les editeurs d'anti virus, il existe des bataillons d'ingenieurs commandos surentrainés
qui sont payés 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 bénévoles mais quasi-professionnels
de sécurité 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 connectée digne de ce nom pourra le détecter.
Alors, quelles solutions s'offrent a nous ?
premierement, beaucoup répondent 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 véritable fonctionnalité du produit en question. Or on voit
rarement ces memes personnes publier leur sources, ce qui permet difficilement de se faire une opinion.
Deuxièmement, 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 donnée 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 différents, 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 hexadécimal
Windasm32 desassembleur win32dsm900
UPXshell compresseur/décompresseur
Tout ceci est comme d'habitude téléchargeable sur le site de téléchargement. Vous y trouverez aussi
la version non détectée de schoolbus.
Préparation :
Comme on veut manipuler des fichiers contenant un code hostile, il va falloir dire a son chien de
garde de se tenir tranquille.
Préparons donc notre environnement de travail :
avant le travail
1* désactivez l'autoprotect de votre antivirus
2* créez 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* préparez dans le dossier \tests une copie du serveur (on ne la modifiera pas, elle sert de témoins),
puis une deuxième (celle ci servira a chaque étape, et sera testée)
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 différentes é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 même.
De plus, ceci modifie les checksums CRC et MD5, qui sont utilisés par de nombreux serveurs de mails afin de
détecter 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 hexadécimal, 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 préferé.
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'amène a ma transition vers une autre méthode : la compression...
Compression UPX :
Si vous avez l'habitude de manipuler des serveurs, vous remarquerez qu'avec des fonctions équivalentes, certains
pèsent 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 expliquée :
Il est possible d'appliquer un type de compression de puissances différentes a un executable, et de le rétrécir
considérablement tout en ayant comme résultat 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 déja
compressés car il connaissent cette technique. Résultat : les éditeurs d'antivirus ont relevé la signature
du serveur compressé, et comme ils ne sont pas idiots, celle du serveur décompressé.
On est mal ?
Pas du tout !
en effet, a la compression l'utilisateur choisit la force avec laquelle le fichier sera compressé. En général, la
plus élevée (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 résume, 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é : décompresser avec UPX, puis recompresser a différents 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 déja modifier, voir
annuler les modifications effectuées... 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 méthode...!!! 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, utilisées seules ou entre elles selon le serveur
sur lequel vous travaillez.
Comme d'habitude, si vous avez d'autres idées, 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
Compléments :
Au vu des réactions suite à l’explication des méthodes qui permettent de rendre un code hostile indetectable aux antivirus, je me rend compte qu’on est allés un peu vite, en passant directement aux applications pratiques, sans passer par une phase d’explication des mécanismes qui régissent les principes de détection.
Je vais donc essayer aujourd’hui de combler ce manque, en esperant être aussi complet que possible.
Pour être clair, j’appellerais ici les anti virus AV, et les troyens, virii, etc…, Hostile.
Que les puristes ne m’en veuillent pas si j’utilise un vocabulaire parfois tres généraliste dans ce qui va suivre. En effet, je vais essayer de rendre la compréhension de tout ceci accessible au plus grand nombre.
Au menu :
Méthode de detection de l’anti virus (AV) Le principe de la modification détermination des signatures utilisées par l’AV
détermination et localisation au sein de l’hostile
Modifier la signature de l’hostile Conclusion
Méthode de detection de l’anti virus (AV)
Comme pré-requis, vous devez savoir que les Av reconnaissent un élément hostile (un troyen par exemple) par analyse d’un ou plusieurs morceaux de code binaires, qu’on appelle signature. Celle-ci devra être bien sûr caractéristique de l’hostile.
On appellera Offset de signature le lieu où est placé ce code dans le programme.
Or, le premier problème dans notre démarche future est que chaque AV va utiliser sa propre méthode pour reconnaître l’hostile. Comprennez que tout AV considérera une signature différente. Les opérations qui seront décrites ici devront donc être répétées, voire adaptées à la cible, plus précisement à l’AV qui en assure la protection. Un hostile non détecté par Norton peut tout a fait l’être chez KAV.
Le principe de la modification
La démarche qui consiste à modifier l’hostile pour qu’il passe inapercu aux yeux de l’AV s’inscrit en trois temps :
- détermination des signatures utilisées par l’AV
- localisation de cette signature au sein de l’hostile
- modification de celle-ci
Jusqu’ici, et vu comme cela, ca à l’air assez simple. Cependant, pour ceux qui ont suivit, quelques problèmes se profilent déjà, dont la nécessiter de connaître le stockage de la base de données de signatures de l’AV, être capable de situer precisement ces signatures au sein de l’hostile, et enfin pouvoir modifier le code sans altérer le fonctionnement du programme.
détermination des signatures utilisées par l’AV
Il s’agit ici d’étudier l’AV qui protège la cible. Pour cela, rien de mieux que de l’installer chez soi, et l’observer afin de connaître l’emplacement dans le repertoire d’installation où sont stockées les données de signature. Dans le cas de KAV, il s’agira de %repertoire racine%\KAV Shares Files\Bases\. On y trouvera des fichiers en .AVC. Ceux-ci devront être decryptés (si je retrouve le programme, je le mettrait en dl.)
détermination et localisation au sein de l’hostile
Une approche est alors la suivante : il s’agit d’installer dans le même repertoire le programme AVPOFFSET.EXE et l’hostile. Si je dis cela, c’est surtout pour la suite du travail.
La suite se fait en ligne de commande sous DOS, par l’usage AVPOFFSET Hostile.exe.
Le travail prend un certain temps, et devrait retourner un résultat 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 décompressé auparavent, si vous avez a faire à un hostile compressé.
Il est assez fréquent que pour des raisons pratiques de légereté de l’hostile afin de l’envoyer, ou tout simplement dans une démarche d’indetection de l’auteur (voir les discutions précedentes sur le sujet), l’hostile soit déjà compressé, ou, dans le cas d’un générateur de server pour un troyen, que le générateur produise un fichier compressé.
On pourra appliquer différents outils de décompression, parmis lesquels :
UPX
StudPE (lui analysera l’outil utilisé à l’origine de la compression)
Un-pack, qui marche toujours, bien que surtout connu sous Win 98.
Nota II : Dois-je préciser de désactiver l’AV ?...
Une autre approche sera ce qu’on appelle Splitting.
Cette méthode se fait en aveugle et suppose une bonne experience, ne serais ce que pour savoir où mettre le doigt au sein de l’hostile.
Il s’agira en effet de remplacer à taton, puis en focussant la procédure, l’offset de la signature.
On peut pour cela remplacer sur l’offset des bouts du binaire par des zéros ou des NoPs, puis tenter la detection par AV. En cas d’indetection, on a tapé dans la signature. Il s’agit alors de recommencer en ne modifiant qu’une partie de ce qu’on 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 l’indetection. C’est la signature « purifiée », dont on connaît à présent l’offset précis.
Je shématise, pour bien comprendre :
azertyuiopqsdfghjklmwxcvbn
*
modification d’un 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 démarche se fera avec l’aide d’un éditeur hexadécimal, 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 l’experience du manipulateur, sa connaissance des AV, et des structures d’un programme.
En effet, il existe plusieurs méthodes d’approche pour savoir où modifier, sachant que certains AV cherchent la signature dans l’ entry point du programme, le lieu de l’execution de la première commande, tandis que d’autres se focalisent plutot sur les ressources du programme.
J’ajoute a tout ceci que si vous voulez conserver un hostile viable, il ne faudra pas modifer les entêtes, ce qui aurait pour effet de transformer l’hostile en boullie de bytes peut être indetectable, mais surtout inutile…
Quoi qu’il en soit, considérons que nous avons connaissance a present de l’offset de la signature (on l’aura remise telle qu’elle si on a utilisé la méthode de splitting).
Modifier la signature de l’hostile
Je me répete, mais avant d’aller plus loin, je rappelle qu’on va travailler ici dans le but de cacher une signature bien précise à un AV bien précis. Si vous avez de la chance, ceci suffira pour la plupart des AV, sinon, il faudra recommencer…
Bref, on arrive ici au nœud du probleme qui en interpelle plus d’un, la modification assembleur de l’hostile.
Au préalable, celui-ci sera désassemblé (cas de la modification « à froid »), ou débuggé (cas de la modification « a chaud »)
Vous l’avez comprit, il faudra se procurer un désassembleur ou un debugger. Je vous laisse chercher, peut être en mettrais- je aussi en dl dans les publiques.
Si on se rend à l’offset qu’on a découvert comme renfermant la signature (éventuellement même avec un éditeur hexadécimal), on trouvera soit la représentation hexadécimale des instructions assembleur, soit les instructions assembleur elles mêmes, 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]
C’est ce genre de modification, écrire une commande qui fera le même travail, mais ne sera pas celle d’origine, attendue par l’AV, qui rendra l’hostile indetectable puisque sa signature aura changé.
Il existe biens sur de nombreux exemples, et selon les AV, l’offset à modifier etc… Dire que pour le troyen « troyenutilisé », il faut se rendre à l’offset xxx, et modifier azerty par qwerty afin de le rendre universellement indetectable ne serais pas completement vrai.
Toutefois, il est encore possible d’aborder une autre forme de modification sans faire appel à l’assembleur.
On passera ici uniquement par l’hexadécimal, en se branchant sur l’offset de signature, et en regardant la correspondance Ascii.
On peut avoir de la chance, et tomber sur quelque chose comme
756E5365727669636573000000FFFFFFFF (hexadecimal)
RunServices....... (Ascii)
C’est le genre de signature qui ne détecte pas par l’action du programme comme plus haut, mais par la présence d’un texte précis (nota : ne cherchez pas systématiquement RunService, c’est un exemple fictif…)
Ca peut paraître é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 l’AV.
Cela vous parait incroyable ? C’est pourtant une des genre de signature le plus utilisé par Norton ! Qui parmis vous utilise Norton AV ?...
Conclusion
Les méthodes de modification en profondeur d’un code n’ont rien de facile, et sans quelques bases minimum en assembleur, en connaissance des structures d’un programme, en experience face au fonctionnement même des protections, ne vous imaginez surtout pas que n’importe qui puisse s’attaquer à ce genre d’exercice de style.
C’est la dure Loi de la lance et du bouclier : plus le bouclier est solide (et je vous assure que les éditeurs d’AV ne sont pas que des idiots, loin de là), plus le concepteur de la lance devra avoir un niveau de connaissances techniques approfondit…
Je vais donc essayer aujourd’hui de combler ce manque, en esperant être aussi complet que possible.
Pour être clair, j’appellerais ici les anti virus AV, et les troyens, virii, etc…, Hostile.
Que les puristes ne m’en veuillent pas si j’utilise un vocabulaire parfois tres généraliste dans ce qui va suivre. En effet, je vais essayer de rendre la compréhension de tout ceci accessible au plus grand nombre.
Au menu :
Méthode de detection de l’anti virus (AV) Le principe de la modification détermination des signatures utilisées par l’AV
détermination et localisation au sein de l’hostile
Modifier la signature de l’hostile Conclusion
Méthode de detection de l’anti virus (AV)
Comme pré-requis, vous devez savoir que les Av reconnaissent un élément hostile (un troyen par exemple) par analyse d’un ou plusieurs morceaux de code binaires, qu’on appelle signature. Celle-ci devra être bien sûr caractéristique de l’hostile.
On appellera Offset de signature le lieu où est placé ce code dans le programme.
Or, le premier problème dans notre démarche future est que chaque AV va utiliser sa propre méthode pour reconnaître l’hostile. Comprennez que tout AV considérera une signature différente. Les opérations qui seront décrites ici devront donc être répétées, voire adaptées à la cible, plus précisement à l’AV qui en assure la protection. Un hostile non détecté par Norton peut tout a fait l’être chez KAV.
Le principe de la modification
La démarche qui consiste à modifier l’hostile pour qu’il passe inapercu aux yeux de l’AV s’inscrit en trois temps :
- détermination des signatures utilisées par l’AV
- localisation de cette signature au sein de l’hostile
- modification de celle-ci
Jusqu’ici, et vu comme cela, ca à l’air assez simple. Cependant, pour ceux qui ont suivit, quelques problèmes se profilent déjà, dont la nécessiter de connaître le stockage de la base de données de signatures de l’AV, être capable de situer precisement ces signatures au sein de l’hostile, et enfin pouvoir modifier le code sans altérer le fonctionnement du programme.
détermination des signatures utilisées par l’AV
Il s’agit ici d’étudier l’AV qui protège la cible. Pour cela, rien de mieux que de l’installer chez soi, et l’observer afin de connaître l’emplacement dans le repertoire d’installation où sont stockées les données de signature. Dans le cas de KAV, il s’agira de %repertoire racine%\KAV Shares Files\Bases\. On y trouvera des fichiers en .AVC. Ceux-ci devront être decryptés (si je retrouve le programme, je le mettrait en dl.)
détermination et localisation au sein de l’hostile
Une approche est alors la suivante : il s’agit d’installer dans le même repertoire le programme AVPOFFSET.EXE et l’hostile. Si je dis cela, c’est surtout pour la suite du travail.
La suite se fait en ligne de commande sous DOS, par l’usage AVPOFFSET Hostile.exe.
Le travail prend un certain temps, et devrait retourner un résultat 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 décompressé auparavent, si vous avez a faire à un hostile compressé.
Il est assez fréquent que pour des raisons pratiques de légereté de l’hostile afin de l’envoyer, ou tout simplement dans une démarche d’indetection de l’auteur (voir les discutions précedentes sur le sujet), l’hostile soit déjà compressé, ou, dans le cas d’un générateur de server pour un troyen, que le générateur produise un fichier compressé.
On pourra appliquer différents outils de décompression, parmis lesquels :
UPX
StudPE (lui analysera l’outil utilisé à l’origine de la compression)
Un-pack, qui marche toujours, bien que surtout connu sous Win 98.
Nota II : Dois-je préciser de désactiver l’AV ?...
Une autre approche sera ce qu’on appelle Splitting.
Cette méthode se fait en aveugle et suppose une bonne experience, ne serais ce que pour savoir où mettre le doigt au sein de l’hostile.
Il s’agira en effet de remplacer à taton, puis en focussant la procédure, l’offset de la signature.
On peut pour cela remplacer sur l’offset des bouts du binaire par des zéros ou des NoPs, puis tenter la detection par AV. En cas d’indetection, on a tapé dans la signature. Il s’agit alors de recommencer en ne modifiant qu’une partie de ce qu’on 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 l’indetection. C’est la signature « purifiée », dont on connaît à présent l’offset précis.
Je shématise, pour bien comprendre :
azertyuiopqsdfghjklmwxcvbn
*
modification d’un 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 démarche se fera avec l’aide d’un éditeur hexadécimal, 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 l’experience du manipulateur, sa connaissance des AV, et des structures d’un programme.
En effet, il existe plusieurs méthodes d’approche pour savoir où modifier, sachant que certains AV cherchent la signature dans l’ entry point du programme, le lieu de l’execution de la première commande, tandis que d’autres se focalisent plutot sur les ressources du programme.
J’ajoute a tout ceci que si vous voulez conserver un hostile viable, il ne faudra pas modifer les entêtes, ce qui aurait pour effet de transformer l’hostile en boullie de bytes peut être indetectable, mais surtout inutile…
Quoi qu’il en soit, considérons que nous avons connaissance a present de l’offset de la signature (on l’aura remise telle qu’elle si on a utilisé la méthode de splitting).
Modifier la signature de l’hostile
Je me répete, mais avant d’aller plus loin, je rappelle qu’on va travailler ici dans le but de cacher une signature bien précise à un AV bien précis. Si vous avez de la chance, ceci suffira pour la plupart des AV, sinon, il faudra recommencer…
Bref, on arrive ici au nœud du probleme qui en interpelle plus d’un, la modification assembleur de l’hostile.
Au préalable, celui-ci sera désassemblé (cas de la modification « à froid »), ou débuggé (cas de la modification « a chaud »)
Vous l’avez comprit, il faudra se procurer un désassembleur ou un debugger. Je vous laisse chercher, peut être en mettrais- je aussi en dl dans les publiques.
Si on se rend à l’offset qu’on a découvert comme renfermant la signature (éventuellement même avec un éditeur hexadécimal), on trouvera soit la représentation hexadécimale des instructions assembleur, soit les instructions assembleur elles mêmes, 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]
C’est ce genre de modification, écrire une commande qui fera le même travail, mais ne sera pas celle d’origine, attendue par l’AV, qui rendra l’hostile indetectable puisque sa signature aura changé.
Il existe biens sur de nombreux exemples, et selon les AV, l’offset à modifier etc… Dire que pour le troyen « troyenutilisé », il faut se rendre à l’offset xxx, et modifier azerty par qwerty afin de le rendre universellement indetectable ne serais pas completement vrai.
Toutefois, il est encore possible d’aborder une autre forme de modification sans faire appel à l’assembleur.
On passera ici uniquement par l’hexadécimal, en se branchant sur l’offset de signature, et en regardant la correspondance Ascii.
On peut avoir de la chance, et tomber sur quelque chose comme
756E5365727669636573000000FFFFFFFF (hexadecimal)
RunServices....... (Ascii)
C’est le genre de signature qui ne détecte pas par l’action du programme comme plus haut, mais par la présence d’un texte précis (nota : ne cherchez pas systématiquement RunService, c’est un exemple fictif…)
Ca peut paraître é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 l’AV.
Cela vous parait incroyable ? C’est pourtant une des genre de signature le plus utilisé par Norton ! Qui parmis vous utilise Norton AV ?...
Conclusion
Les méthodes de modification en profondeur d’un code n’ont rien de facile, et sans quelques bases minimum en assembleur, en connaissance des structures d’un programme, en experience face au fonctionnement même des protections, ne vous imaginez surtout pas que n’importe qui puisse s’attaquer à ce genre d’exercice de style.
C’est la dure Loi de la lance et du bouclier : plus le bouclier est solide (et je vous assure que les éditeurs d’AV ne sont pas que des idiots, loin de là), plus le concepteur de la lance devra avoir un niveau de connaissances techniques approfondit…
Articles
