Tiens Fred, de la lecture ;o)

Bon puisqu'il n'y a pas grand-chose à lire sur le NG ces temps-ci et puisque
FB m'y a invité, délirons un peu; cela fera toujours un peu de lecture...



Puisque il y a parfois certaines confusions au sujet des virus polymorphes,
voici quelques détails qui, je l'espère, rendront un peu plus clair le
sujet*.



Morphe, cela vient du grec, de morphê plus exactement. Cela signifie
"forme". Un synonyme parfait est apparence. Donc, les cerveaux alertes
auront déjà déduit du terme "polymorphe", la signification "qui peut prendre
plusieurs formes", ou, encyclopédique en diable, "qui peut revêtir plusieurs
aspects ou apparences".



Mais quel est l'intérêt pour un virus, docteur ? Ha mais cher patient,
c'est simple ! Regardez donc un peu l'exemple qui suit là, juste après,
maintenant. Supposons qu'un virus hypothétique soit constitué des octets
suivants (heu on cause en hexadécimal à partir de maintenant, d'abord cela
fait plus h4[k3r, ensuite, ça prend moins de place et les opcodes des
instructions processeur sont généralement donnés en base 16) :



25 43 56 44



Bon, c'est théorique et ça n'existe pas. Déjà, c'est trop court, un virus de
4 octets**... mais c'est un cas d'école. Un scanner sera bien évidemment
judicieux de prendre cette suite d'octets pour signature. Si, après
reproduction, le code de notre virus devient :



33 45 55 12



Eh bien la signature dont nous venons de parler ne peut plus servir à
détecter cette nouvelle "version" du virus. Aucune partie constante d'une
reproduction à l'autre n'est décelable, il est donc difficile d'en faire une
"empreinte". Bref, le scanner se fera avoir s'il n'utilise que ce procédé de
détection...



Donc, en virologie informatique, le polymorphisme sert à la chose suivante :
en changeant de forme à chaque reproduction, un virus polymorphe rend caduc
la détection par signature. Rappelons tout de même que c'est le procédé le
plus utilisé par les AVs.



[Petite note historique] Un des premiers gars à avoir utilisé le truc est
l'inénarrable Dark Avenger. Il avait codé le célèbre DAME*** (Dark Avenger
Mutation Engine), une sorte de module qu'il suffisait (pour le code du
virus) d'appeler à chaque reproduction pour changer d'apparence. Si ma
mémoire ne me fait pas défaut (vas-y papy Arnie, raconte-nous comment
c'était au siècle dernier), c'était aux environs de 1992. Inutile de dire
que la chose fit grand bruit à l'époque. Certains "experts" y virent même la
fin de nos chers PC. Si, si, carrément. Bon, si lesdits experts avaient un
peu regardé en détail le truc... Bref, il y avait quelques bugs dans le
bouzin et il n'a pas eu le succès escompté. [Fin de la note historique].



Mais comment diable le prodige du polymorphisme est-il donc obtenu en
pratique ? Bon, je ne vais pas écrire 50 pages non plus, je vais donc
seulement donner quelques exemples pour que vous vous fassiez une idée.
Gardez toujours à l'idée le concept : le but est que le code soit différent
à chaque reproduction.



Exemple 1. Permutation de registres.



Un classique. Supposons (le code est toujours sans signification, il ne s'
agit que d'illustrer, appelons-le code de test) :



mov ax,0Ah

mov dx,0Bh

int 21h



Dont les opcodes sont : 66 B8 0A 00 66 BA 0B 00 CD 21



À la prochaine reproduction on peut écrire :



mov ax,0Bh

mov dx,0Ah

xchg ax,dx

int 21h



Bof direz vous ? Erreur ! Les opcodes de "mov ax" ou "mov dx" sont
différents. D'après la Intel :



opcodes de mov ax,0ah : B8 0A

opcodes de mov ax,0bh : B8 0B



Certes, un seul octet change, mais c'est parce que l'exemple est trivial. Il
n'empêche, ça gêne la signature, les opcodes du code précédent devenant :



66 B8 0B 00 66 BA 0A 00 66 92 CD 21 (nouveau)

66 B8 0A 00 66 BA 0B 00 CD 21 (ancien)



Bon, c'est une technique qui a ses limites. Tout d'abord, le nombre de
registres est limité, donc, le nombre de possibilités l'est aussi de facto.
Ensuite, si vous regardez bien la suite d'opcodes, il suffit d'effectuer des
recherches avec joker, par exemple, on cherchera 66 B8 * 00 66 BA * 00 au
lieu de 66 B8 0B 00 66 BA 0A 00.



Exemple 2. Décomposition de code.



Cela a été un peu introduit dans l'exemple précédent. On décompose le code
en plusieurs instructions, le résultat étant bien sûr toujours le même. Par
exemple, 3+2 peut s'écrire 3+1+1. Avec notre code de test, cela pourrait
être :



mov ax,09h

inc ax

mov dx,0bh

int 21h



D'opcodes :



66 B8 09 00 66 40 66 BA 0B 00 CD 21 (nouveau)

66 B8 0A 00 66 BA 0B 00 CD 21 (ancien)



Ici aussi, la technique à ses limites. Il n'est pas évident de trouver une
infinité de décompositions et, comme à l'exemple précédent, le polymorphisme
n'est que partiel, on peut isoler des parties constantes et à l'aide de
jokers et "d'offset de parties constantes" on peut démêler la ruse. Enfin,
il me faut parler de la très célèbre "modification lors du runtime"
(utilisée notamment par le virus test de l'EICAR), qui permet des
décompositions savoureuses. Par exemple, si je sais que mon instruction int
21h (CD 21) sera toujours à l'adresse 100h, lors d'une génération on peut
écrire CD 20 à cette adresse et, ailleurs dans le code faire une sorte de
inc [100h]. Cela permet de générer un grand nombre de variations (j'oserai
même dire une infinité. Bon, après, bonjour l'écriture du code).



Exemple 3. Junk code.



L'idée est évidente : insérer des instructions qui ne servent à rien. Noter
que ce procédé pose de sérieux problèmes aux émulateurs. Exemple



mov ax,0Ah

push cx

mov cx,0

push si

pop si

mov dx,0Bh

pop cx

int 21h



Tout le code inséré ne sert strictement à rien, si ce n'est à obtenir un
stock d'opcodes qui vont perturber la prise d'empreinte. On peut ajouter que
c'est une technique très facile à implémenter et quasiment illimitée. On a
par exemple le célèbre cas des jump spaghettis :



Code original



instruction 1

instruction 2

instruction 3



Un exemple de code dupliqué



instruction 1

jmp aa2

aa1

jmp aa3

aa2

instruction 2

jump aa1

aa3

instruction 3



C'est vite le bazar et les opcodes s'ajoutent par dizaines. Notons aussi,
dans la même veine, l'insertion d'instructions nop(s). Mais bon, dans tout
cela, il y a quand même des parties constantes. Cela dit, chose importante,
plus on les noie dan du garbage code et plus le code constant se rapproche
de la simple probabilité qu'un opcode soit présent dans un autre code
différent.



Exemple 4. Métamorphisme.



C'est la solution ultime. Surtout théorique car quasi impossible à
implémenter. Vous allez vite comprendre pourquoi : le but est d'écrire des
mutations qui n'on jamais de parties constantes. Un exemple simple est le
suivant : supposons que j'ai l'instruction suivante dans un code :



inc ax



Les opcodes sont 66 40.



On peut écrire cette instruction de diverses manières, par exemple :



add ax,1



d'opcodes 66 05 01 00



Il n'y a plus d'opcode en commun. Oui, bon, il y a le 66h, mais ce n'est pas
vraiment l'opcode de l'instruction, c'est un octet de préfixe qui permet de
déterminer la taille de l'instruction. Bien sûr, cet exemple est vraiment
trivial. La réalité est toute autre. Il est impossible de varier à l'infini,
alors on se contente juste de faire en sorte que les parties constantes
soient minimales et que les parties constantes communes à chaque génération
soient heu. minimales aussi ;o).



Bon, on pourrait continuer pendant des heures, mais le jeu en réseau m'
appelle ;o). Plus haut, je crois avoir dit qu'en fait le polymorphisme n'a
pas causé de gros soucis. Pourquoi ? D'abord à cause de sa mise en pratique
effective. Le polymorphisme réellement appliqué se contente juste de
chiffrer le code (dit principal) du virus à l'aide d'une routine de cryptage
qui va varier à chaque mutation. Le corps du virus est donc polymorphe
puisqu'il change à chaque génération. Mais la quasi-totalité des virus
polymorphes ont une routine de cryptage quasiment fixe, qui est donc facile
à déceler. Bon, le top est de faire varier cette routine à chaque
génération. Dans son livre (franchement, je sais plus lequel c'est), Mark
Ludwig donne un exemple sympathique. Mais de toute façon, si on se base sur
un XOR (simple exemple), on aura au maximum 65536 possibilités. Ensuite,
réfléchissez un peu au problème et vous verrez qu'écrire une routine de
chiffrement non constante c'est pas évident évident****.



Ouf, j'en ai terminé. Bon, je suis resté "grand public" hein. L'essentiel
est que les béotiens appréhendent un peu mieux le truc. Et toute faute de
frappe est exclusivement à imputer sur le compte de mon chat qui n'a d'autre
endroit que le clavier pour ronfler !



A+



----



* J'aurai pu causer de la tendance exagérée des chats à rechercher la
chaleur alors qu'il fait déjà près de 40° C à l'ombre, mais bon, ce serait
un peu hors charte (et puis, c'est pas possible autrement, mon chat est
débile !)...



** Oui, je sais, il existerait le fameux "0 byte virus", mais bon...



*** En fait, il l'avait appelé MtE, MuTation Engine. Mais chez McAfee, ils
ont préféré renommer en DAME. C'est un procédé très usité chez les éditeurs
d'AVs que de narguer les auteurs de virus en ne tenant pas compte du nom qu'
ils donnent à leurs créations.



**** De toute façon, si vous ne voulez pas réfléchir, j'écrirai un truc
là-dessus un jour ou l'autre sur mon site. Soyez justes patients.


--
AMcD

http://arnold.mcdonald.free.fr/
(still in fossilization progress but now in english, thus the whole world
can see my laziness)