Analyse spectrale

AMcD®

19/05/2004 à 17:55

Tweakie wrote:

[Je dedie un nouveau fil a l'analyse spectrale, esperant distinguer
le bon troll de l'ivraie]

C'est surtout que nous avons un nouvel interlocuteur assez complexe à suivre
dans ses interventions...

Or ces heuristiques semblent bien meilleurs pour detecter des
malwares de type "cheval de Troie en Delphi" que pour detecter
les derniers virus super-top-mode de 29A (d'apres ce que j'en
ai vu pour le premier et ce que j'en ai lu pour le second).

Bah, ce n'est pas trop grave. Certains te diront que les virus des magazines
underground c'est que des Zoo...

Or distinguer un dialer d'un password stealer d'un webdownloader
sur la base de statistiques sur les opcodes employes, je dois
bien dire que je n'y crois pas. Meme en considerant des courtes
series d'instructions, j'ai du mal a y croire...

Évidemment ! C'est du pipeau. Surtout que, comme je l'ai déjà dit, tu peux
toujours t'arranger pour "simuler" voire même dissimuler. Et quand ce genre
de technique sera au point, eh bien il suffira d'écrire un moteur qui simule
le fonctionneemnt d'un producteur de code "règlementaire" (comilateur dûment
certifié).

Considerons uniquement les malwares "non parasitaires", intuitivement,
on peut se dire que l'AV doit employer une technique grosso-modo
similaire a vous et moi pour savoir si oui ou non un programme est
un malware. Prenons le cas le plus simple : un malware non packe'.

Vi.

Comment procedez vous ? En ce qui me concerne, c'est tres basique :

Je t'écoute :o)

- J'ouvre le machin avec un editeur hexa, et je regarde si il y a
des trucs suspects. La mention d'une clef HKLM/.../Run ou le nom
d'un executable sont des elements suspects.

Ben si c'est crypté tu vas pas loin avec ta technique...

La presence de MZ[...]PE
dans la section ressources (ou ailleurs que dans l'entete du
fichier) encore plus.

Pourquoi ? Tu peux très bien avori ça dans un programme reglo. Par exemple,
un utilitaire système qui utilise un driver installé à al volée, il l'a dans
les ressources, et lors de l'exécution, il l'enregistre en service, etc.
Oui, c'est rare, mais c'est parfaitement valide.

Idem pour des noms de processus correspondant
a des AV/firewall persos connus ou pour des commandes IRC (JOIN/
PRIVMSG...). La presence d'une URL (surtout un truc en no-ip
ou dyndns, incidemment), d'une IP ou d'un nom de fichier .bat peut
aussi etre un indice (beaucoup de backdoor utilisent un .bat pour
effacer le fichier a l'origine de l'infection). La presence de
"RCPT TO, DATA, HELO" peut meme etre indicatrice d'un mass-mailer.
Etc, etc.

Tout cela n'est valable que si c'est pas crypté ton truc...

- Je regarde la liste des fonctions importees. Certaines sont
caracteristiques de certains malwares : fonctions de pstorec.dll
pour un password stealer, CreateRemoteThread/WriteProcessMemory
pour une backdoor, des trucs MAPI pour un vers de messagerie, etc.

Ça aussi, c'est de moins en moins directement visible dans le code. Et comme
je l'ai montré dans une xemple, c'est trop facile à planquer... rappelle-toi
:

mov edx,OFFSET sz
push edx
call pFuncVA[3*4]

Qu'est-ce qui est appelé là ?

- Je regarde si le machin contient des menus/boites de dialogue/etc.
C'est idiot, mais la plupart des tojans ne contiennent que des
icones (eventuellement des messagebox simples).

Les virus avec boîte de dialogue, il y en a un tas quand même ! Tous ceux
qui se font passer pour des patches, etc.

Une fois cette courte etude preliminaire effectuee, je suis
incapable de dire avec certitude si le programme est sain, mais
je suis souvent capable d'affirmer qu'il ne l'est pas.

Lol. Belle envolée :o).

Dans le meme ordre d'idees, on voit souvent assez vite si les
chaines de caracteres sont cryptees. On peut aussi essayer de
savoir ce qui est passe' en argument a LoadLibrary/
GetModuleHandle/GetProcAddress, en emulant, au besoin.

Quand tu vois clairement le nom de ces fonctions...

Alors ne croyez vous pas que l'analyse spectrale porte plutot
sur ce genre de criteres ? Bien sur, c'est "low-tech" et tres
loin d'etre parfait comme methode. Mais pour une bonne partie
des malwares les moins sophistiques, ca fonctionne
raisonnablement bien.

Non, je ne crois pas. Je pense moi que c'est plutôt basé sur des
caractéristiques bien précises, comme des "signatures". Comme, par exemple,
si tu étudies le code généré par un compilateur. Chacun utilise des choses
qui lui sont propres et dont tu peux t'inspirer pour montrer leur
"signature". Au besoin, je détaille.

Donc en fait, je ne crois pas que l'"analyse spectrale" porte
exclusivement ou principalement sur l'analyse des statistiques
des opcodes. Pour resumer. Juste sur l'analyse des "suites d'octets
de longueur suffisante qui ont une probabilite' nettement
plus marquee d'etre dans un malware que dans une application
legitime" et eventuellement des fonctions importees (et
pourquoi pas des ressources).

M'ouais... Plutôt des suites d'opcodes et des *états de processeur*.

Ensuite, IMHO, il suffit de noter "critere present"-->1,
"critere absent"-->0, on obtient une liste de bits qui "decrit"
l'application en question (du point de vue des criteres retenus),
et qu'il suffit de comparer a des "masques" correspondant aux
types de malwares connus.

Oui.

Sinon moi, pour les malwares, je ne fait pas comme ça. De nos jours, c'est
de plus en plus :

- crypté. C'est à dire que le contenu du fichier n'est pas accessible
directement. Il faut donc le decrypter. Ce peut être de simple XOR ou
carrément avec une clé.
- brouillé. Ça c'est fun. par exemple, tu décale de 10h la valeur de 4Ko de
code que tu descrambles (clin d'oeil à LaDDL) ensuite a l'exécution. Bref,
quand tu désassembles, tu voies rien.
- obfusqué. C'est à dire que t'as tout un tas de code qui ne sert à rien.
Donc, ça brouille ton analyse. Et il suffit d'inserer des calls, d'ouvrir
des fichiers temporaires, etc. T'es vite noyé...
- patché. Par exemple, les fonctions d'une DLL sont remplacées par une
autre. Donc, tu peux te faire gruger facilement. Par exemple, imagine une
fonction de crt.dll jamais ou peu utilisée, mais d'une utilisation
absolument sans risque. Le gars la patche. Tu vois l'appel, tu et doutes de
rien. Et voilà...
- polymorphe. Cela c'est le plus pénible, mais je ne m'étendrai pas dessus
maintenant :o).

Bref, une simple analyse avec un éditeur hexa te mène pas loin. Tu ne peux
même pas désassembler puisque 99% des désassembleur vont produire du code
sans queue ni tête.

Donc, moi, je fais ainsi :

- Je regarde si c'est packé. Déjà, ça peut être la galère pour trouver le
bon unpacker !
- Je regarde si c'est scrambled (hihi) et tous les gags genre EPO.
- Ensuite je désassemble. Là il peut y avoir encore des gags, IAT déplacée,
etc.
- Si tu vois que le gars ruse, genre anonymisation des calls, eh bien t'as
pas le choix, tu debuggues ! Et là, tu traces tous les calls à la BR, les
DLLs réellement chargées, etc. Quelle que soient le sruses utilisées, tu
pourras toujours te débrouilelr en exécutant/traçant. Il te suffit d'activer
un espion de fichier, d'API, de BR, etc. Et c'est bon, tu vois tout.
- Au pire, tu dumpes la mémoire une fois que le code a été décompacté,
décrypté, etc. Mais faut avouer qu'il y a parfois des pénibles...

On s'amuse quoi...

--
AMcD®

http://arnold.mcdonald.free.fr/

Tweakie wrote:

[Je dedie un nouveau fil a l'analyse spectrale, esperant distinguer
le bon troll de l'ivraie]

C'est surtout que nous avons un nouvel interlocuteur assez complexe à suivre
dans ses interventions...

Or ces heuristiques semblent bien meilleurs pour detecter des
malwares de type "cheval de Troie en Delphi" que pour detecter
les derniers virus super-top-mode de 29A (d'apres ce que j'en
ai vu pour le premier et ce que j'en ai lu pour le second).

Bah, ce n'est pas trop grave. Certains te diront que les virus des magazines
underground c'est que des Zoo...

Or distinguer un dialer d'un password stealer d'un webdownloader
sur la base de statistiques sur les opcodes employes, je dois
bien dire que je n'y crois pas. Meme en considerant des courtes
series d'instructions, j'ai du mal a y croire...

Évidemment ! C'est du pipeau. Surtout que, comme je l'ai déjà dit, tu peux
toujours t'arranger pour "simuler" voire même dissimuler. Et quand ce genre
de technique sera au point, eh bien il suffira d'écrire un moteur qui simule
le fonctionneemnt d'un producteur de code "règlementaire" (comilateur dûment
certifié).

Considerons uniquement les malwares "non parasitaires", intuitivement,
on peut se dire que l'AV doit employer une technique grosso-modo
similaire a vous et moi pour savoir si oui ou non un programme est
un malware. Prenons le cas le plus simple : un malware non packe'.

Vi.

Comment procedez vous ? En ce qui me concerne, c'est tres basique :

Je t'écoute :o)

- J'ouvre le machin avec un editeur hexa, et je regarde si il y a
des trucs suspects. La mention d'une clef HKLM/.../Run ou le nom
d'un executable sont des elements suspects.

Ben si c'est crypté tu vas pas loin avec ta technique...

La presence de MZ[...]PE
dans la section ressources (ou ailleurs que dans l'entete du
fichier) encore plus.

Pourquoi ? Tu peux très bien avori ça dans un programme reglo. Par exemple,
un utilitaire système qui utilise un driver installé à al volée, il l'a dans
les ressources, et lors de l'exécution, il l'enregistre en service, etc.
Oui, c'est rare, mais c'est parfaitement valide.

Idem pour des noms de processus correspondant
a des AV/firewall persos connus ou pour des commandes IRC (JOIN/
PRIVMSG...). La presence d'une URL (surtout un truc en no-ip
ou dyndns, incidemment), d'une IP ou d'un nom de fichier .bat peut
aussi etre un indice (beaucoup de backdoor utilisent un .bat pour
effacer le fichier a l'origine de l'infection). La presence de
"RCPT TO, DATA, HELO" peut meme etre indicatrice d'un mass-mailer.
Etc, etc.

Tout cela n'est valable que si c'est pas crypté ton truc...

- Je regarde la liste des fonctions importees. Certaines sont
caracteristiques de certains malwares : fonctions de pstorec.dll
pour un password stealer, CreateRemoteThread/WriteProcessMemory
pour une backdoor, des trucs MAPI pour un vers de messagerie, etc.

Ça aussi, c'est de moins en moins directement visible dans le code. Et comme
je l'ai montré dans une xemple, c'est trop facile à planquer... rappelle-toi
:

mov edx,OFFSET sz
push edx
call pFuncVA[3*4]

Qu'est-ce qui est appelé là ?

- Je regarde si le machin contient des menus/boites de dialogue/etc.
C'est idiot, mais la plupart des tojans ne contiennent que des
icones (eventuellement des messagebox simples).

Les virus avec boîte de dialogue, il y en a un tas quand même ! Tous ceux
qui se font passer pour des patches, etc.

Une fois cette courte etude preliminaire effectuee, je suis
incapable de dire avec certitude si le programme est sain, mais
je suis souvent capable d'affirmer qu'il ne l'est pas.

Lol. Belle envolée :o).

Dans le meme ordre d'idees, on voit souvent assez vite si les
chaines de caracteres sont cryptees. On peut aussi essayer de
savoir ce qui est passe' en argument a LoadLibrary/
GetModuleHandle/GetProcAddress, en emulant, au besoin.

Quand tu vois clairement le nom de ces fonctions...

Alors ne croyez vous pas que l'analyse spectrale porte plutot
sur ce genre de criteres ? Bien sur, c'est "low-tech" et tres
loin d'etre parfait comme methode. Mais pour une bonne partie
des malwares les moins sophistiques, ca fonctionne
raisonnablement bien.

Non, je ne crois pas. Je pense moi que c'est plutôt basé sur des
caractéristiques bien précises, comme des "signatures". Comme, par exemple,
si tu étudies le code généré par un compilateur. Chacun utilise des choses
qui lui sont propres et dont tu peux t'inspirer pour montrer leur
"signature". Au besoin, je détaille.

Donc en fait, je ne crois pas que l'"analyse spectrale" porte
exclusivement ou principalement sur l'analyse des statistiques
des opcodes. Pour resumer. Juste sur l'analyse des "suites d'octets
de longueur suffisante qui ont une probabilite' nettement
plus marquee d'etre dans un malware que dans une application
legitime" et eventuellement des fonctions importees (et
pourquoi pas des ressources).

M'ouais... Plutôt des suites d'opcodes et des *états de processeur*.

Ensuite, IMHO, il suffit de noter "critere present"-->1,
"critere absent"-->0, on obtient une liste de bits qui "decrit"
l'application en question (du point de vue des criteres retenus),
et qu'il suffit de comparer a des "masques" correspondant aux
types de malwares connus.

Oui.

Sinon moi, pour les malwares, je ne fait pas comme ça. De nos jours, c'est
de plus en plus :

- crypté. C'est à dire que le contenu du fichier n'est pas accessible
directement. Il faut donc le decrypter. Ce peut être de simple XOR ou
carrément avec une clé.
- brouillé. Ça c'est fun. par exemple, tu décale de 10h la valeur de 4Ko de
code que tu descrambles (clin d'oeil à LaDDL) ensuite a l'exécution. Bref,
quand tu désassembles, tu voies rien.
- obfusqué. C'est à dire que t'as tout un tas de code qui ne sert à rien.
Donc, ça brouille ton analyse. Et il suffit d'inserer des calls, d'ouvrir
des fichiers temporaires, etc. T'es vite noyé...
- patché. Par exemple, les fonctions d'une DLL sont remplacées par une
autre. Donc, tu peux te faire gruger facilement. Par exemple, imagine une
fonction de crt.dll jamais ou peu utilisée, mais d'une utilisation
absolument sans risque. Le gars la patche. Tu vois l'appel, tu et doutes de
rien. Et voilà...
- polymorphe. Cela c'est le plus pénible, mais je ne m'étendrai pas dessus
maintenant :o).

Bref, une simple analyse avec un éditeur hexa te mène pas loin. Tu ne peux
même pas désassembler puisque 99% des désassembleur vont produire du code
sans queue ni tête.

Donc, moi, je fais ainsi :

- Je regarde si c'est packé. Déjà, ça peut être la galère pour trouver le
bon unpacker !
- Je regarde si c'est scrambled (hihi) et tous les gags genre EPO.
- Ensuite je désassemble. Là il peut y avoir encore des gags, IAT déplacée,
etc.
- Si tu vois que le gars ruse, genre anonymisation des calls, eh bien t'as
pas le choix, tu debuggues ! Et là, tu traces tous les calls à la BR, les
DLLs réellement chargées, etc. Quelle que soient le sruses utilisées, tu
pourras toujours te débrouilelr en exécutant/traçant. Il te suffit d'activer
un espion de fichier, d'API, de BR, etc. Et c'est bon, tu vois tout.
- Au pire, tu dumpes la mémoire une fois que le code a été décompacté,
décrypté, etc. Mais faut avouer qu'il y a parfois des pénibles...

On s'amuse quoi...

--
AMcD®

http://arnold.mcdonald.free.fr/

Vous avez filtré cet utilisateur ! Consultez son message

Tweakie wrote:

[Je dedie un nouveau fil a l'analyse spectrale, esperant distinguer
le bon troll de l'ivraie]

C'est surtout que nous avons un nouvel interlocuteur assez complexe à suivre
dans ses interventions...

Or ces heuristiques semblent bien meilleurs pour detecter des
malwares de type "cheval de Troie en Delphi" que pour detecter
les derniers virus super-top-mode de 29A (d'apres ce que j'en
ai vu pour le premier et ce que j'en ai lu pour le second).

Bah, ce n'est pas trop grave. Certains te diront que les virus des magazines
underground c'est que des Zoo...

Or distinguer un dialer d'un password stealer d'un webdownloader
sur la base de statistiques sur les opcodes employes, je dois
bien dire que je n'y crois pas. Meme en considerant des courtes
series d'instructions, j'ai du mal a y croire...

Évidemment ! C'est du pipeau. Surtout que, comme je l'ai déjà dit, tu peux
toujours t'arranger pour "simuler" voire même dissimuler. Et quand ce genre
de technique sera au point, eh bien il suffira d'écrire un moteur qui simule
le fonctionneemnt d'un producteur de code "règlementaire" (comilateur dûment
certifié).

Considerons uniquement les malwares "non parasitaires", intuitivement,
on peut se dire que l'AV doit employer une technique grosso-modo
similaire a vous et moi pour savoir si oui ou non un programme est
un malware. Prenons le cas le plus simple : un malware non packe'.

Vi.

Comment procedez vous ? En ce qui me concerne, c'est tres basique :

Je t'écoute :o)

- J'ouvre le machin avec un editeur hexa, et je regarde si il y a
des trucs suspects. La mention d'une clef HKLM/.../Run ou le nom
d'un executable sont des elements suspects.

Ben si c'est crypté tu vas pas loin avec ta technique...

La presence de MZ[...]PE
dans la section ressources (ou ailleurs que dans l'entete du
fichier) encore plus.

Pourquoi ? Tu peux très bien avori ça dans un programme reglo. Par exemple,
un utilitaire système qui utilise un driver installé à al volée, il l'a dans
les ressources, et lors de l'exécution, il l'enregistre en service, etc.
Oui, c'est rare, mais c'est parfaitement valide.

Idem pour des noms de processus correspondant
a des AV/firewall persos connus ou pour des commandes IRC (JOIN/
PRIVMSG...). La presence d'une URL (surtout un truc en no-ip
ou dyndns, incidemment), d'une IP ou d'un nom de fichier .bat peut
aussi etre un indice (beaucoup de backdoor utilisent un .bat pour
effacer le fichier a l'origine de l'infection). La presence de
"RCPT TO, DATA, HELO" peut meme etre indicatrice d'un mass-mailer.
Etc, etc.

Tout cela n'est valable que si c'est pas crypté ton truc...

- Je regarde la liste des fonctions importees. Certaines sont
caracteristiques de certains malwares : fonctions de pstorec.dll
pour un password stealer, CreateRemoteThread/WriteProcessMemory
pour une backdoor, des trucs MAPI pour un vers de messagerie, etc.

Ça aussi, c'est de moins en moins directement visible dans le code. Et comme
je l'ai montré dans une xemple, c'est trop facile à planquer... rappelle-toi
:

mov edx,OFFSET sz
push edx
call pFuncVA[3*4]

Qu'est-ce qui est appelé là ?

- Je regarde si le machin contient des menus/boites de dialogue/etc.
C'est idiot, mais la plupart des tojans ne contiennent que des
icones (eventuellement des messagebox simples).

Les virus avec boîte de dialogue, il y en a un tas quand même ! Tous ceux
qui se font passer pour des patches, etc.

Une fois cette courte etude preliminaire effectuee, je suis
incapable de dire avec certitude si le programme est sain, mais
je suis souvent capable d'affirmer qu'il ne l'est pas.

Lol. Belle envolée :o).

Dans le meme ordre d'idees, on voit souvent assez vite si les
chaines de caracteres sont cryptees. On peut aussi essayer de
savoir ce qui est passe' en argument a LoadLibrary/
GetModuleHandle/GetProcAddress, en emulant, au besoin.

Quand tu vois clairement le nom de ces fonctions...

Alors ne croyez vous pas que l'analyse spectrale porte plutot
sur ce genre de criteres ? Bien sur, c'est "low-tech" et tres
loin d'etre parfait comme methode. Mais pour une bonne partie
des malwares les moins sophistiques, ca fonctionne
raisonnablement bien.

Non, je ne crois pas. Je pense moi que c'est plutôt basé sur des
caractéristiques bien précises, comme des "signatures". Comme, par exemple,
si tu étudies le code généré par un compilateur. Chacun utilise des choses
qui lui sont propres et dont tu peux t'inspirer pour montrer leur
"signature". Au besoin, je détaille.

Donc en fait, je ne crois pas que l'"analyse spectrale" porte
exclusivement ou principalement sur l'analyse des statistiques
des opcodes. Pour resumer. Juste sur l'analyse des "suites d'octets
de longueur suffisante qui ont une probabilite' nettement
plus marquee d'etre dans un malware que dans une application
legitime" et eventuellement des fonctions importees (et
pourquoi pas des ressources).

M'ouais... Plutôt des suites d'opcodes et des *états de processeur*.

Ensuite, IMHO, il suffit de noter "critere present"-->1,
"critere absent"-->0, on obtient une liste de bits qui "decrit"
l'application en question (du point de vue des criteres retenus),
et qu'il suffit de comparer a des "masques" correspondant aux
types de malwares connus.

Oui.

Sinon moi, pour les malwares, je ne fait pas comme ça. De nos jours, c'est
de plus en plus :

- crypté. C'est à dire que le contenu du fichier n'est pas accessible
directement. Il faut donc le decrypter. Ce peut être de simple XOR ou
carrément avec une clé.
- brouillé. Ça c'est fun. par exemple, tu décale de 10h la valeur de 4Ko de
code que tu descrambles (clin d'oeil à LaDDL) ensuite a l'exécution. Bref,
quand tu désassembles, tu voies rien.
- obfusqué. C'est à dire que t'as tout un tas de code qui ne sert à rien.
Donc, ça brouille ton analyse. Et il suffit d'inserer des calls, d'ouvrir
des fichiers temporaires, etc. T'es vite noyé...
- patché. Par exemple, les fonctions d'une DLL sont remplacées par une
autre. Donc, tu peux te faire gruger facilement. Par exemple, imagine une
fonction de crt.dll jamais ou peu utilisée, mais d'une utilisation
absolument sans risque. Le gars la patche. Tu vois l'appel, tu et doutes de
rien. Et voilà...
- polymorphe. Cela c'est le plus pénible, mais je ne m'étendrai pas dessus
maintenant :o).

Bref, une simple analyse avec un éditeur hexa te mène pas loin. Tu ne peux
même pas désassembler puisque 99% des désassembleur vont produire du code
sans queue ni tête.

Donc, moi, je fais ainsi :

- Je regarde si c'est packé. Déjà, ça peut être la galère pour trouver le
bon unpacker !
- Je regarde si c'est scrambled (hihi) et tous les gags genre EPO.
- Ensuite je désassemble. Là il peut y avoir encore des gags, IAT déplacée,
etc.
- Si tu vois que le gars ruse, genre anonymisation des calls, eh bien t'as
pas le choix, tu debuggues ! Et là, tu traces tous les calls à la BR, les
DLLs réellement chargées, etc. Quelle que soient le sruses utilisées, tu
pourras toujours te débrouilelr en exécutant/traçant. Il te suffit d'activer
un espion de fichier, d'API, de BR, etc. Et c'est bon, tu vois tout.
- Au pire, tu dumpes la mémoire une fois que le code a été décompacté,
décrypté, etc. Mais faut avouer qu'il y a parfois des pénibles...

On s'amuse quoi...

--
AMcD®

http://arnold.mcdonald.free.fr/

NO_eikaewt_SPAM

19/05/2004 à 22:44

Tweakie wrote:

Évidemment ! C'est du pipeau. Surtout que, comme je l'ai déjà dit, tu peux
toujours t'arranger pour "simuler" voire même dissimuler. Et quand ce genre
de technique sera au point, eh bien il suffira d'écrire un moteur qui simule
le fonctionneemnt d'un producteur de code "règlementaire" (comilateur dûment
certifié).

Pour une fois que ca n'est pas moi qui (ab)use du "il suffit" ;-)

Mais justement, c'est encore plus simple que ca : la +part des malwares
actuels sont ecrits en langage de haut niveau...et compiles avec un
compilo dument certifie'.

- J'ouvre le machin avec un editeur hexa, et je regarde si il y a
des trucs suspects. La mention d'une clef HKLM/.../Run ou le nom
d'un executable sont des elements suspects.

Ben si c'est crypté tu vas pas loin avec ta technique...

Ben justement. Ma technique _commence_ toujours comme ca. Entre
autres, ca m'evite les problemes de chargement de dll tandis
que je suis entrain de debugger Notepad ;o)

Si c'est crypte' et que c'est relativement apparent, faut passer
au plan B (mais bon, la derniere fois que j'ai debugge' une verole,
je me suis betement fait infecter, apres avoir distraitement appuye'
sur la mauvaise touche...).

[MZ...PE dans le fichier]

Pourquoi ? Tu peux très bien avori ça dans un programme reglo. Par exemple,
un utilitaire système qui utilise un driver installé à al volée, il l'a dans
les ressources, et lors de l'exécution, il l'enregistre en service, etc.
Oui, c'est rare, mais c'est parfaitement valide.

C'est rare dans un contexte normal, mais extremement courant chez
pas mal de droppers de trojans. C'est donc un bon critere heuristique.
Il faut bien sur considerer le fait que ce critere seul n'est pas
determinant, mais qu'il sera par la suite combine' a d'autres criteres
(eux-meme non determinants individuelement) pour donner le verdict
final.

[Chaines de caracteres]

Tout cela n'est valable que si c'est pas crypté ton truc...

Bah oui. Remarques qu'on peut peut-etre jouer au meme type de
jeu en ajoutant une phase d'emulation preliminaire, si on realise
qu'on a affaire a un truc crypte'.

[Imports de fonctions]

Ça aussi, c'est de moins en moins directement visible dans le code.

Heu...de moins en moins. Pas d'accord. Il y a de plus en plus
de malwares tres peu perfectionnees. Bien 90% du total....et
on espere de toute facon pas mieux des heuristiques.

Et comme je l'ai montré dans une xemple, c'est trop facile
à planquer... rappelle-toi
[...]

J'ai pas oublie'. Mais ca reste la perle rare chez les malwares
actuels ;-)

Les virus avec boîte de dialogue, il y en a un tas quand même ! Tous ceux
qui se font passer pour des patches, etc.

OK. Disons que c'est rare chez certains types de malwares, et
plutot courant pour les executables win32 standards....et que
ca peut donc servir de criteres pour les malwares en question
(dialers/keyloggers, etc.). Je voulais juste illustrer le fait
que certains criteres sont plutot indicatifs de la presence
d'un malware tandis que d'autres sont plutot indicatifs d'un
programme sain. Encore une fois, c'est purement statistique.

Une fois cette courte etude preliminaire effectuee, je suis
incapable de dire avec certitude si le programme est sain, mais
je suis souvent capable d'affirmer qu'il ne l'est pas.

Lol. Belle envolée :o).

Voui, mais c'est exactement ce que je veux dire : il est parfois
plus difficile de savoir si un programme est sain que de savoir
s'il est infecte'. Par exemple, si le notepad de Fred etait
infecte' par un bon vieil infecteur de PE polymorphe avec EPO,
je serais a coup sur passe' a cote'. Par contre, un coup d'oeil a
un serveur optix via un editeur hexadecimal et je suis fixe'.

Alors ne croyez vous pas que l'analyse spectrale porte plutot
sur ce genre de criteres ? Bien sur, c'est "low-tech" et tres
loin d'etre parfait comme methode. Mais pour une bonne partie
des malwares les moins sophistiques, ca fonctionne
raisonnablement bien.

Non, je ne crois pas. Je pense moi que c'est plutôt basé sur des
caractéristiques bien précises, comme des "signatures". Comme, par exemple,
si tu étudies le code généré par un compilateur. Chacun utilise des choses
qui lui sont propres et dont tu peux t'inspirer pour montrer leur
"signature". Au besoin, je détaille.

Oui, mais comme je le disais en debut de message, les AVs pour
lesquels il est question d'analyse spectrale se debrouillent
manifestement mieux avec les malwares de haut niveau. Alors
je sais bien qu'il est tentant de considerer que tout programme
Delphi est un trojan ;o), mais sorti de ca, la connaissance
du compilo apporte peu pour les trucs en HLL.

Sinon moi, pour les malwares, je ne fait pas comme ça. De nos jours, c'est
de plus en plus :

De plus en plus, je dirais pas ca. Il me semble que la majorite'
de la "production" reste extremement basique, meme si quelques
trucs sortent du lot.

- crypté.

Pas si courant que ca dans les malwares "de tous les jours". Generalement,
seules une ou deux chaines de caracteres (celles permettant d'identifier
celui qui a diffuse' une backdoor par exemple) sont cryptees.

- brouillé. Ça c'est fun. par exemple, tu décale de 10h la valeur de 4Ko de
code que tu descrambles (clin d'oeil à LaDDL) ensuite a l'exécution. Bref,
quand tu désassembles, tu voies rien.

J'ai surtout l'impression que beaucoup utilisent des outils
tout faits a la krypton, etc.

- obfusqué. C'est à dire que t'as tout un tas de code qui ne sert à rien.
Donc, ça brouille ton analyse. Et il suffit d'inserer des calls, d'ouvrir
des fichiers temporaires, etc. T'es vite noyé...

Ca c'est malin, mais j'ai l'impression que c'est plutot rare. T'as
des exemples ?

Bref, une simple analyse avec un éditeur hexa te mène pas loin. Tu ne peux
même pas désassembler puisque 99% des désassembleur vont produire du code
sans queue ni tête.

Une fois depackes, tu peux traiter 90% des merdouilles avec un editeur
hexa et un desassembleur, amha. Pour le reste, c'est sur que c'est
insuffisant.

Donc, moi, je fais ainsi :

- Je regarde si c'est packé. Déjà, ça peut être la galère pour trouver le
bon unpacker !

Jusqu'ici, on fait pareil.

- Je regarde si c'est scrambled (hihi) et tous les gags genre EPO.
- Ensuite je désassemble. Là il peut y avoir encore des gags, IAT déplacée,
etc.

.pour un bete webdownloader, ma technique est plus rapide que la tienne
;-)

[...]
- Au pire, tu dumpes la mémoire une fois que le code a été décompacté,
décrypté, etc. Mais faut avouer qu'il y a parfois des pénibles...

Voui, la derniere fois, quand je me suis infecte', j'ai au moins pu
recuperer un dump. Le lot de consolation, en quelque sorte...

--
Tweakie

--
Posté via http://www.webatou.net/
Usenet dans votre navigateur !
Complaints-To:

Tweakie wrote:

Évidemment ! C'est du pipeau. Surtout que, comme je l'ai déjà dit, tu peux
toujours t'arranger pour "simuler" voire même dissimuler. Et quand ce genre
de technique sera au point, eh bien il suffira d'écrire un moteur qui simule
le fonctionneemnt d'un producteur de code "règlementaire" (comilateur dûment
certifié).

Pour une fois que ca n'est pas moi qui (ab)use du "il suffit" ;-)

Mais justement, c'est encore plus simple que ca : la +part des malwares
actuels sont ecrits en langage de haut niveau...et compiles avec un
compilo dument certifie'.

- J'ouvre le machin avec un editeur hexa, et je regarde si il y a
des trucs suspects. La mention d'une clef HKLM/.../Run ou le nom
d'un executable sont des elements suspects.

Ben si c'est crypté tu vas pas loin avec ta technique...

Ben justement. Ma technique _commence_ toujours comme ca. Entre
autres, ca m'evite les problemes de chargement de dll tandis
que je suis entrain de debugger Notepad ;o)

Si c'est crypte' et que c'est relativement apparent, faut passer
au plan B (mais bon, la derniere fois que j'ai debugge' une verole,
je me suis betement fait infecter, apres avoir distraitement appuye'
sur la mauvaise touche...).

[MZ...PE dans le fichier]

Pourquoi ? Tu peux très bien avori ça dans un programme reglo. Par exemple,
un utilitaire système qui utilise un driver installé à al volée, il l'a dans
les ressources, et lors de l'exécution, il l'enregistre en service, etc.
Oui, c'est rare, mais c'est parfaitement valide.

C'est rare dans un contexte normal, mais extremement courant chez
pas mal de droppers de trojans. C'est donc un bon critere heuristique.
Il faut bien sur considerer le fait que ce critere seul n'est pas
determinant, mais qu'il sera par la suite combine' a d'autres criteres
(eux-meme non determinants individuelement) pour donner le verdict
final.

[Chaines de caracteres]

Tout cela n'est valable que si c'est pas crypté ton truc...

Bah oui. Remarques qu'on peut peut-etre jouer au meme type de
jeu en ajoutant une phase d'emulation preliminaire, si on realise
qu'on a affaire a un truc crypte'.

[Imports de fonctions]

Ça aussi, c'est de moins en moins directement visible dans le code.

Heu...de moins en moins. Pas d'accord. Il y a de plus en plus
de malwares tres peu perfectionnees. Bien 90% du total....et
on espere de toute facon pas mieux des heuristiques.

Et comme je l'ai montré dans une xemple, c'est trop facile
à planquer... rappelle-toi
[...]

J'ai pas oublie'. Mais ca reste la perle rare chez les malwares
actuels ;-)

Les virus avec boîte de dialogue, il y en a un tas quand même ! Tous ceux
qui se font passer pour des patches, etc.

OK. Disons que c'est rare chez certains types de malwares, et
plutot courant pour les executables win32 standards....et que
ca peut donc servir de criteres pour les malwares en question
(dialers/keyloggers, etc.). Je voulais juste illustrer le fait
que certains criteres sont plutot indicatifs de la presence
d'un malware tandis que d'autres sont plutot indicatifs d'un
programme sain. Encore une fois, c'est purement statistique.

Une fois cette courte etude preliminaire effectuee, je suis
incapable de dire avec certitude si le programme est sain, mais
je suis souvent capable d'affirmer qu'il ne l'est pas.

Lol. Belle envolée :o).

Voui, mais c'est exactement ce que je veux dire : il est parfois
plus difficile de savoir si un programme est sain que de savoir
s'il est infecte'. Par exemple, si le notepad de Fred etait
infecte' par un bon vieil infecteur de PE polymorphe avec EPO,
je serais a coup sur passe' a cote'. Par contre, un coup d'oeil a
un serveur optix via un editeur hexadecimal et je suis fixe'.

Alors ne croyez vous pas que l'analyse spectrale porte plutot
sur ce genre de criteres ? Bien sur, c'est "low-tech" et tres
loin d'etre parfait comme methode. Mais pour une bonne partie
des malwares les moins sophistiques, ca fonctionne
raisonnablement bien.

Non, je ne crois pas. Je pense moi que c'est plutôt basé sur des
caractéristiques bien précises, comme des "signatures". Comme, par exemple,
si tu étudies le code généré par un compilateur. Chacun utilise des choses
qui lui sont propres et dont tu peux t'inspirer pour montrer leur
"signature". Au besoin, je détaille.

Oui, mais comme je le disais en debut de message, les AVs pour
lesquels il est question d'analyse spectrale se debrouillent
manifestement mieux avec les malwares de haut niveau. Alors
je sais bien qu'il est tentant de considerer que tout programme
Delphi est un trojan ;o), mais sorti de ca, la connaissance
du compilo apporte peu pour les trucs en HLL.

Sinon moi, pour les malwares, je ne fait pas comme ça. De nos jours, c'est
de plus en plus :

De plus en plus, je dirais pas ca. Il me semble que la majorite'
de la "production" reste extremement basique, meme si quelques
trucs sortent du lot.

- crypté.

Pas si courant que ca dans les malwares "de tous les jours". Generalement,
seules une ou deux chaines de caracteres (celles permettant d'identifier
celui qui a diffuse' une backdoor par exemple) sont cryptees.

- brouillé. Ça c'est fun. par exemple, tu décale de 10h la valeur de 4Ko de
code que tu descrambles (clin d'oeil à LaDDL) ensuite a l'exécution. Bref,
quand tu désassembles, tu voies rien.

J'ai surtout l'impression que beaucoup utilisent des outils
tout faits a la krypton, etc.

- obfusqué. C'est à dire que t'as tout un tas de code qui ne sert à rien.
Donc, ça brouille ton analyse. Et il suffit d'inserer des calls, d'ouvrir
des fichiers temporaires, etc. T'es vite noyé...

Ca c'est malin, mais j'ai l'impression que c'est plutot rare. T'as
des exemples ?

Bref, une simple analyse avec un éditeur hexa te mène pas loin. Tu ne peux
même pas désassembler puisque 99% des désassembleur vont produire du code
sans queue ni tête.

Une fois depackes, tu peux traiter 90% des merdouilles avec un editeur
hexa et un desassembleur, amha. Pour le reste, c'est sur que c'est
insuffisant.

Donc, moi, je fais ainsi :

- Je regarde si c'est packé. Déjà, ça peut être la galère pour trouver le
bon unpacker !

Jusqu'ici, on fait pareil.

- Je regarde si c'est scrambled (hihi) et tous les gags genre EPO.
- Ensuite je désassemble. Là il peut y avoir encore des gags, IAT déplacée,
etc.

.pour un bete webdownloader, ma technique est plus rapide que la tienne
;-)

[...]
- Au pire, tu dumpes la mémoire une fois que le code a été décompacté,
décrypté, etc. Mais faut avouer qu'il y a parfois des pénibles...

Voui, la derniere fois, quand je me suis infecte', j'ai au moins pu
recuperer un dump. Le lot de consolation, en quelque sorte...

--
Tweakie

--
Posté via http://www.webatou.net/
Usenet dans votre navigateur !
Complaints-To: abuse@webatou.net

Vous avez filtré cet utilisateur ! Consultez son message

Tweakie wrote:

Évidemment ! C'est du pipeau. Surtout que, comme je l'ai déjà dit, tu peux
toujours t'arranger pour "simuler" voire même dissimuler. Et quand ce genre
de technique sera au point, eh bien il suffira d'écrire un moteur qui simule
le fonctionneemnt d'un producteur de code "règlementaire" (comilateur dûment
certifié).

Pour une fois que ca n'est pas moi qui (ab)use du "il suffit" ;-)

Mais justement, c'est encore plus simple que ca : la +part des malwares
actuels sont ecrits en langage de haut niveau...et compiles avec un
compilo dument certifie'.

- J'ouvre le machin avec un editeur hexa, et je regarde si il y a
des trucs suspects. La mention d'une clef HKLM/.../Run ou le nom
d'un executable sont des elements suspects.

Ben si c'est crypté tu vas pas loin avec ta technique...

Ben justement. Ma technique _commence_ toujours comme ca. Entre
autres, ca m'evite les problemes de chargement de dll tandis
que je suis entrain de debugger Notepad ;o)

Si c'est crypte' et que c'est relativement apparent, faut passer
au plan B (mais bon, la derniere fois que j'ai debugge' une verole,
je me suis betement fait infecter, apres avoir distraitement appuye'
sur la mauvaise touche...).

[MZ...PE dans le fichier]

Pourquoi ? Tu peux très bien avori ça dans un programme reglo. Par exemple,
un utilitaire système qui utilise un driver installé à al volée, il l'a dans
les ressources, et lors de l'exécution, il l'enregistre en service, etc.
Oui, c'est rare, mais c'est parfaitement valide.

C'est rare dans un contexte normal, mais extremement courant chez
pas mal de droppers de trojans. C'est donc un bon critere heuristique.
Il faut bien sur considerer le fait que ce critere seul n'est pas
determinant, mais qu'il sera par la suite combine' a d'autres criteres
(eux-meme non determinants individuelement) pour donner le verdict
final.

[Chaines de caracteres]

Tout cela n'est valable que si c'est pas crypté ton truc...

Bah oui. Remarques qu'on peut peut-etre jouer au meme type de
jeu en ajoutant une phase d'emulation preliminaire, si on realise
qu'on a affaire a un truc crypte'.

[Imports de fonctions]

Ça aussi, c'est de moins en moins directement visible dans le code.

Heu...de moins en moins. Pas d'accord. Il y a de plus en plus
de malwares tres peu perfectionnees. Bien 90% du total....et
on espere de toute facon pas mieux des heuristiques.

Et comme je l'ai montré dans une xemple, c'est trop facile
à planquer... rappelle-toi
[...]

J'ai pas oublie'. Mais ca reste la perle rare chez les malwares
actuels ;-)

Les virus avec boîte de dialogue, il y en a un tas quand même ! Tous ceux
qui se font passer pour des patches, etc.

OK. Disons que c'est rare chez certains types de malwares, et
plutot courant pour les executables win32 standards....et que
ca peut donc servir de criteres pour les malwares en question
(dialers/keyloggers, etc.). Je voulais juste illustrer le fait
que certains criteres sont plutot indicatifs de la presence
d'un malware tandis que d'autres sont plutot indicatifs d'un
programme sain. Encore une fois, c'est purement statistique.

Une fois cette courte etude preliminaire effectuee, je suis
incapable de dire avec certitude si le programme est sain, mais
je suis souvent capable d'affirmer qu'il ne l'est pas.

Lol. Belle envolée :o).

Voui, mais c'est exactement ce que je veux dire : il est parfois
plus difficile de savoir si un programme est sain que de savoir
s'il est infecte'. Par exemple, si le notepad de Fred etait
infecte' par un bon vieil infecteur de PE polymorphe avec EPO,
je serais a coup sur passe' a cote'. Par contre, un coup d'oeil a
un serveur optix via un editeur hexadecimal et je suis fixe'.

Alors ne croyez vous pas que l'analyse spectrale porte plutot
sur ce genre de criteres ? Bien sur, c'est "low-tech" et tres
loin d'etre parfait comme methode. Mais pour une bonne partie
des malwares les moins sophistiques, ca fonctionne
raisonnablement bien.

Non, je ne crois pas. Je pense moi que c'est plutôt basé sur des
caractéristiques bien précises, comme des "signatures". Comme, par exemple,
si tu étudies le code généré par un compilateur. Chacun utilise des choses
qui lui sont propres et dont tu peux t'inspirer pour montrer leur
"signature". Au besoin, je détaille.

Oui, mais comme je le disais en debut de message, les AVs pour
lesquels il est question d'analyse spectrale se debrouillent
manifestement mieux avec les malwares de haut niveau. Alors
je sais bien qu'il est tentant de considerer que tout programme
Delphi est un trojan ;o), mais sorti de ca, la connaissance
du compilo apporte peu pour les trucs en HLL.

Sinon moi, pour les malwares, je ne fait pas comme ça. De nos jours, c'est
de plus en plus :

De plus en plus, je dirais pas ca. Il me semble que la majorite'
de la "production" reste extremement basique, meme si quelques
trucs sortent du lot.

- crypté.

Pas si courant que ca dans les malwares "de tous les jours". Generalement,
seules une ou deux chaines de caracteres (celles permettant d'identifier
celui qui a diffuse' une backdoor par exemple) sont cryptees.

- brouillé. Ça c'est fun. par exemple, tu décale de 10h la valeur de 4Ko de
code que tu descrambles (clin d'oeil à LaDDL) ensuite a l'exécution. Bref,
quand tu désassembles, tu voies rien.

J'ai surtout l'impression que beaucoup utilisent des outils
tout faits a la krypton, etc.

- obfusqué. C'est à dire que t'as tout un tas de code qui ne sert à rien.
Donc, ça brouille ton analyse. Et il suffit d'inserer des calls, d'ouvrir
des fichiers temporaires, etc. T'es vite noyé...

Ca c'est malin, mais j'ai l'impression que c'est plutot rare. T'as
des exemples ?

Bref, une simple analyse avec un éditeur hexa te mène pas loin. Tu ne peux
même pas désassembler puisque 99% des désassembleur vont produire du code
sans queue ni tête.

Une fois depackes, tu peux traiter 90% des merdouilles avec un editeur
hexa et un desassembleur, amha. Pour le reste, c'est sur que c'est
insuffisant.

Donc, moi, je fais ainsi :

- Je regarde si c'est packé. Déjà, ça peut être la galère pour trouver le
bon unpacker !

Jusqu'ici, on fait pareil.

- Je regarde si c'est scrambled (hihi) et tous les gags genre EPO.
- Ensuite je désassemble. Là il peut y avoir encore des gags, IAT déplacée,
etc.

.pour un bete webdownloader, ma technique est plus rapide que la tienne
;-)

[...]
- Au pire, tu dumpes la mémoire une fois que le code a été décompacté,
décrypté, etc. Mais faut avouer qu'il y a parfois des pénibles...

Voui, la derniere fois, quand je me suis infecte', j'ai au moins pu
recuperer un dump. Le lot de consolation, en quelque sorte...

--
Tweakie

--
Posté via http://www.webatou.net/
Usenet dans votre navigateur !
Complaints-To:

AMcD®

19/05/2004 à 23:26

Tweakie wrote:

Pour une fois que ca n'est pas moi qui (ab)use du "il suffit" ;-)

Bah. Ce que je veux dire, c'est que je ne comprends pas cette tendance
typiquement française à ne pas prévoir. Ce n'est pas parce que ce n'est pas
encore fait, encore vu ou qu'on n'en connaît pas que ce n'est pas possible
bon sang ! L'abstraction est tout de même utile parfois. Imagine que tu as
l'idée d'une technique nouvelle mais complexe. Tu ne va pas foncer direct
dans l'implémentation, tu vas d'abord regarder si une contre mesure est
possible. Auquel cas tu gagnes un temps appréciable en ne te lançant pas à
corps perdu dans un travail de titan voué à l'échec. Lors de la phase de
conception, les "il suffit de" vont donc t'être très précieux...

Mais justement, c'est encore plus simple que ca : la +part des
malwares actuels sont ecrits en langage de haut niveau...et compiles
avec un
compilo dument certifie'.

Oui, mais as-tu suivi le sens de mon propos ? Si l'analyse d'un compilateur
te permets de tirer des lois au sujet de ce qui le fera passer pour
"certifié", par exemple, le type "moyen" d'instructions processeur
utilisées, ses méthodes d'optimisation, etc. Eh, bien, il te suffit de
reproduire cela dans ton malware pour brouiller les pistes !

Ben si c'est crypté tu vas pas loin avec ta technique...

Ben justement. Ma technique _commence_ toujours comme ca. Entre
autres, ca m'evite les problemes de chargement de dll tandis
que je suis entrain de debugger Notepad ;o)

OK.

Si c'est crypte' et que c'est relativement apparent, faut passer
au plan B (mais bon, la derniere fois que j'ai debugge' une verole,
je me suis betement fait infecter, apres avoir distraitement appuye'
sur la mauvaise touche...).

Bah, ça c'est le risque de "base". Moi, je ne compte plus les
auto-infections volontaires, lol.

Pourquoi ? Tu peux très bien avori ça dans un programme reglo. Par
exemple, un utilitaire système qui utilise un driver installé à al
volée, il l'a dans les ressources, et lors de l'exécution, il
l'enregistre en service, etc. Oui, c'est rare, mais c'est
parfaitement valide.

C'est rare dans un contexte normal, mais extremement courant chez
pas mal de droppers de trojans. C'est donc un bon critere heuristique.
Il faut bien sur considerer le fait que ce critere seul n'est pas
determinant, mais qu'il sera par la suite combine' a d'autres criteres
(eux-meme non determinants individuelement) pour donner le verdict
final.

Oui, oui, bien sûr. C'est tout un ensemble de règles.

[Chaines de caracteres]

Tout cela n'est valable que si c'est pas crypté ton truc...

Bah oui. Remarques qu'on peut peut-etre jouer au meme type de
jeu en ajoutant une phase d'emulation preliminaire, si on realise
qu'on a affaire a un truc crypte'.

Oui.

Ça aussi, c'est de moins en moins directement visible dans le code.

Heu...de moins en moins. Pas d'accord. Il y a de plus en plus
de malwares tres peu perfectionnees. Bien 90% du total....et
on espere de toute facon pas mieux des heuristiques.

Ha si tu parles des tas de boue porté au pinacle par la presse à sensation,
oui, ça vole pas haut. Mais, néamoins, le niveau monte quand même.

Et comme je l'ai montré dans une xemple, c'est trop facile
à planquer... rappelle-toi
[...]

J'ai pas oublie'. Mais ca reste la perle rare chez les malwares
actuels ;-)

Meuh non, et puis moi, dixit ppc, je suis nul, alors, tu penses bien ce que
quelqu'un de doué peut faire...

Les virus avec boîte de dialogue, il y en a un tas quand même ! Tous
ceux qui se font passer pour des patches, etc.

OK. Disons que c'est rare chez certains types de malwares, et
plutot courant pour les executables win32 standards...

Oui.

et que
ca peut donc servir de criteres pour les malwares en question
(dialers/keyloggers, etc.). Je voulais juste illustrer le fait
que certains criteres sont plutot indicatifs de la presence
d'un malware tandis que d'autres sont plutot indicatifs d'un
programme sain. Encore une fois, c'est purement statistique.

C'est un epu le problème : que ce soit statistique. Il restera toujours le
pauvre programme réglo qui va générer un faux-positif.

Voui, mais c'est exactement ce que je veux dire : il est parfois
plus difficile de savoir si un programme est sain que de savoir
s'il est infecte'.

Ben ça dépend quand même du soft ! Je vais t'envoyer des drivers, bien malin
qui peut me dire si c'est sain !

Par exemple, si le notepad de Fred etait
infecte' par un bon vieil infecteur de PE polymorphe avec EPO,
je serais a coup sur passe' a cote'. Par contre, un coup d'oeil a
un serveur optix via un editeur hexadecimal et je suis fixe'.

Oui, mais parce que ce n'est pas élaboré.

Non, je ne crois pas. Je pense moi que c'est plutôt basé sur des
caractéristiques bien précises, comme des "signatures". Comme, par
exemple, si tu étudies le code généré par un compilateur. Chacun
utilise des choses qui lui sont propres et dont tu peux t'inspirer
pour montrer leur "signature". Au besoin, je détaille.

Oui, mais comme je le disais en debut de message, les AVs pour
lesquels il est question d'analyse spectrale se debrouillent
manifestement mieux avec les malwares de haut niveau. Alors
je sais bien qu'il est tentant de considerer que tout programme
Delphi est un trojan ;o), mais sorti de ca, la connaissance
du compilo apporte peu pour les trucs en HLL.

Ben si, c'est parce qu'un programme compilé par tel compilo censé ne pas
utiliser du cli ou du push ebp utilise un cli que tu avs en déduire de la
suspicsion.

Sinon moi, pour les malwares, je ne fait pas comme ça. De nos jours,
c'est de plus en plus :

De plus en plus, je dirais pas ca. Il me semble que la majorite'
de la "production" reste extremement basique, meme si quelques
trucs sortent du lot.

Cela dépend ce que t'étudie. Moi, sasser, c'est 2' top chrono, après je
jette.

- crypté.

Pas si courant que ca dans les malwares "de tous les jours".
Generalement, seules une ou deux chaines de caracteres (celles
permettant d'identifier celui qui a diffuse' une backdoor par
exemple) sont cryptees.

Cela le sera de plus en plus. Et avec des techniques de plus en plus hard.
Moi, je prend les paris.

- brouillé. Ça c'est fun. par exemple, tu décale de 10h la valeur de
4Ko de code que tu descrambles (clin d'oeil à LaDDL) ensuite a
l'exécution. Bref, quand tu désassembles, tu voies rien.

J'ai surtout l'impression que beaucoup utilisent des outils
tout faits a la krypton, etc.

Quoi du scrambling en en-tête ? t'en as des tonnes ! Au hasard, Bagle.N.

- obfusqué. C'est à dire que t'as tout un tas de code qui ne sert à
rien. Donc, ça brouille ton analyse. Et il suffit d'inserer des
calls, d'ouvrir des fichiers temporaires, etc. T'es vite noyé...

Ca c'est malin, mais j'ai l'impression que c'est plutot rare. T'as
des exemples ?

Pas là sous la main. Mais ce sera, là aussi, de plus en plus utilisé.
Amuse-toi à désassembler un BIOS, tu vas rire, c'est genre 1k de code utile
pour 4k de junk, et c'est du chaud, tu peux me faire confiance...

Une fois depackes, tu peux traiter 90% des merdouilles avec un editeur
hexa et un desassembleur, amha. Pour le reste, c'est sur que c'est
insuffisant.

Donc, là aussi, les gars évolueront. Le but (enfin, le leur) c'est quand
même d'être diffusé :o).

Voui, la derniere fois, quand je me suis infecte', j'ai au moins pu
recuperer un dump. Le lot de consolation, en quelque sorte...

Bah, c'est assez marrant de se faire infecter parfois. Lorsque j'étais plus
jeune, j'avais fait une grosse bourde avec ça. Je bossais sur un infecteur
de fichier marrant, mais j'avais fait la grosse bêtise d'activer le
cross-directory (j'écris anglais pour que LaDDL puisse suivre). Le côté fun
c'était que quand une application était infectée, une autre instance était
lancée qui infectait un repértoire plus haut. Cela faisait un payload bien
visible et surtout pénible, pusique Windows bloquait au bout d'un certain
nombre de fenêtre. Le jour du test, trop fier devant ma copine ! Je lance
et, en quelques secondes, des tas de fenêtre Windows couvrent l'écran...
marrant pendant 40 secondes, jusqu'à ce que je comprenne que je n'avais plus
qu'à reformater ma machine puisque je ne pouvais plus lancer aucun
exécutable sans infecter encore plus le système :o). À l'époque, je ne
faisais pas de sauvegardes, ça m'a coûté plusieurs mois de boulot...
Aujourd'hui, j'en ris encore, mais sur le coup... je riais moins :o) !

Conclusion : utiliser sa machine de boulot pour coder du douteux, paaaaas
bieeeen !

--
AMcD®

http://arnold.mcdonald.free.fr/

Tweakie wrote:

Pour une fois que ca n'est pas moi qui (ab)use du "il suffit" ;-)

Bah. Ce que je veux dire, c'est que je ne comprends pas cette tendance
typiquement française à ne pas prévoir. Ce n'est pas parce que ce n'est pas
encore fait, encore vu ou qu'on n'en connaît pas que ce n'est pas possible
bon sang ! L'abstraction est tout de même utile parfois. Imagine que tu as
l'idée d'une technique nouvelle mais complexe. Tu ne va pas foncer direct
dans l'implémentation, tu vas d'abord regarder si une contre mesure est
possible. Auquel cas tu gagnes un temps appréciable en ne te lançant pas à
corps perdu dans un travail de titan voué à l'échec. Lors de la phase de
conception, les "il suffit de" vont donc t'être très précieux...

Mais justement, c'est encore plus simple que ca : la +part des
malwares actuels sont ecrits en langage de haut niveau...et compiles
avec un
compilo dument certifie'.

Oui, mais as-tu suivi le sens de mon propos ? Si l'analyse d'un compilateur
te permets de tirer des lois au sujet de ce qui le fera passer pour
"certifié", par exemple, le type "moyen" d'instructions processeur
utilisées, ses méthodes d'optimisation, etc. Eh, bien, il te suffit de
reproduire cela dans ton malware pour brouiller les pistes !

Ben si c'est crypté tu vas pas loin avec ta technique...

Ben justement. Ma technique _commence_ toujours comme ca. Entre
autres, ca m'evite les problemes de chargement de dll tandis
que je suis entrain de debugger Notepad ;o)

OK.

Si c'est crypte' et que c'est relativement apparent, faut passer
au plan B (mais bon, la derniere fois que j'ai debugge' une verole,
je me suis betement fait infecter, apres avoir distraitement appuye'
sur la mauvaise touche...).

Bah, ça c'est le risque de "base". Moi, je ne compte plus les
auto-infections volontaires, lol.

Pourquoi ? Tu peux très bien avori ça dans un programme reglo. Par
exemple, un utilitaire système qui utilise un driver installé à al
volée, il l'a dans les ressources, et lors de l'exécution, il
l'enregistre en service, etc. Oui, c'est rare, mais c'est
parfaitement valide.

C'est rare dans un contexte normal, mais extremement courant chez
pas mal de droppers de trojans. C'est donc un bon critere heuristique.
Il faut bien sur considerer le fait que ce critere seul n'est pas
determinant, mais qu'il sera par la suite combine' a d'autres criteres
(eux-meme non determinants individuelement) pour donner le verdict
final.

Oui, oui, bien sûr. C'est tout un ensemble de règles.

[Chaines de caracteres]

Tout cela n'est valable que si c'est pas crypté ton truc...

Bah oui. Remarques qu'on peut peut-etre jouer au meme type de
jeu en ajoutant une phase d'emulation preliminaire, si on realise
qu'on a affaire a un truc crypte'.

Oui.

Ça aussi, c'est de moins en moins directement visible dans le code.

Heu...de moins en moins. Pas d'accord. Il y a de plus en plus
de malwares tres peu perfectionnees. Bien 90% du total....et
on espere de toute facon pas mieux des heuristiques.

Ha si tu parles des tas de boue porté au pinacle par la presse à sensation,
oui, ça vole pas haut. Mais, néamoins, le niveau monte quand même.

Et comme je l'ai montré dans une xemple, c'est trop facile
à planquer... rappelle-toi
[...]

J'ai pas oublie'. Mais ca reste la perle rare chez les malwares
actuels ;-)

Meuh non, et puis moi, dixit ppc, je suis nul, alors, tu penses bien ce que
quelqu'un de doué peut faire...

Les virus avec boîte de dialogue, il y en a un tas quand même ! Tous
ceux qui se font passer pour des patches, etc.

OK. Disons que c'est rare chez certains types de malwares, et
plutot courant pour les executables win32 standards...

Oui.

et que
ca peut donc servir de criteres pour les malwares en question
(dialers/keyloggers, etc.). Je voulais juste illustrer le fait
que certains criteres sont plutot indicatifs de la presence
d'un malware tandis que d'autres sont plutot indicatifs d'un
programme sain. Encore une fois, c'est purement statistique.

C'est un epu le problème : que ce soit statistique. Il restera toujours le
pauvre programme réglo qui va générer un faux-positif.

Voui, mais c'est exactement ce que je veux dire : il est parfois
plus difficile de savoir si un programme est sain que de savoir
s'il est infecte'.

Ben ça dépend quand même du soft ! Je vais t'envoyer des drivers, bien malin
qui peut me dire si c'est sain !

Par exemple, si le notepad de Fred etait
infecte' par un bon vieil infecteur de PE polymorphe avec EPO,
je serais a coup sur passe' a cote'. Par contre, un coup d'oeil a
un serveur optix via un editeur hexadecimal et je suis fixe'.

Oui, mais parce que ce n'est pas élaboré.

Non, je ne crois pas. Je pense moi que c'est plutôt basé sur des
caractéristiques bien précises, comme des "signatures". Comme, par
exemple, si tu étudies le code généré par un compilateur. Chacun
utilise des choses qui lui sont propres et dont tu peux t'inspirer
pour montrer leur "signature". Au besoin, je détaille.

Oui, mais comme je le disais en debut de message, les AVs pour
lesquels il est question d'analyse spectrale se debrouillent
manifestement mieux avec les malwares de haut niveau. Alors
je sais bien qu'il est tentant de considerer que tout programme
Delphi est un trojan ;o), mais sorti de ca, la connaissance
du compilo apporte peu pour les trucs en HLL.

Ben si, c'est parce qu'un programme compilé par tel compilo censé ne pas
utiliser du cli ou du push ebp utilise un cli que tu avs en déduire de la
suspicsion.

Sinon moi, pour les malwares, je ne fait pas comme ça. De nos jours,
c'est de plus en plus :

De plus en plus, je dirais pas ca. Il me semble que la majorite'
de la "production" reste extremement basique, meme si quelques
trucs sortent du lot.

Cela dépend ce que t'étudie. Moi, sasser, c'est 2' top chrono, après je
jette.

- crypté.

Pas si courant que ca dans les malwares "de tous les jours".
Generalement, seules une ou deux chaines de caracteres (celles
permettant d'identifier celui qui a diffuse' une backdoor par
exemple) sont cryptees.

Cela le sera de plus en plus. Et avec des techniques de plus en plus hard.
Moi, je prend les paris.

- brouillé. Ça c'est fun. par exemple, tu décale de 10h la valeur de
4Ko de code que tu descrambles (clin d'oeil à LaDDL) ensuite a
l'exécution. Bref, quand tu désassembles, tu voies rien.

J'ai surtout l'impression que beaucoup utilisent des outils
tout faits a la krypton, etc.

Quoi du scrambling en en-tête ? t'en as des tonnes ! Au hasard, Bagle.N.

- obfusqué. C'est à dire que t'as tout un tas de code qui ne sert à
rien. Donc, ça brouille ton analyse. Et il suffit d'inserer des
calls, d'ouvrir des fichiers temporaires, etc. T'es vite noyé...

Ca c'est malin, mais j'ai l'impression que c'est plutot rare. T'as
des exemples ?

Pas là sous la main. Mais ce sera, là aussi, de plus en plus utilisé.
Amuse-toi à désassembler un BIOS, tu vas rire, c'est genre 1k de code utile
pour 4k de junk, et c'est du chaud, tu peux me faire confiance...

Une fois depackes, tu peux traiter 90% des merdouilles avec un editeur
hexa et un desassembleur, amha. Pour le reste, c'est sur que c'est
insuffisant.

Donc, là aussi, les gars évolueront. Le but (enfin, le leur) c'est quand
même d'être diffusé :o).

Voui, la derniere fois, quand je me suis infecte', j'ai au moins pu
recuperer un dump. Le lot de consolation, en quelque sorte...

Bah, c'est assez marrant de se faire infecter parfois. Lorsque j'étais plus
jeune, j'avais fait une grosse bourde avec ça. Je bossais sur un infecteur
de fichier marrant, mais j'avais fait la grosse bêtise d'activer le
cross-directory (j'écris anglais pour que LaDDL puisse suivre). Le côté fun
c'était que quand une application était infectée, une autre instance était
lancée qui infectait un repértoire plus haut. Cela faisait un payload bien
visible et surtout pénible, pusique Windows bloquait au bout d'un certain
nombre de fenêtre. Le jour du test, trop fier devant ma copine ! Je lance
et, en quelques secondes, des tas de fenêtre Windows couvrent l'écran...
marrant pendant 40 secondes, jusqu'à ce que je comprenne que je n'avais plus
qu'à reformater ma machine puisque je ne pouvais plus lancer aucun
exécutable sans infecter encore plus le système :o). À l'époque, je ne
faisais pas de sauvegardes, ça m'a coûté plusieurs mois de boulot...
Aujourd'hui, j'en ris encore, mais sur le coup... je riais moins :o) !

Conclusion : utiliser sa machine de boulot pour coder du douteux, paaaaas
bieeeen !

--
AMcD®

http://arnold.mcdonald.free.fr/

Vous avez filtré cet utilisateur ! Consultez son message

Tweakie wrote:

Pour une fois que ca n'est pas moi qui (ab)use du "il suffit" ;-)

Bah. Ce que je veux dire, c'est que je ne comprends pas cette tendance
typiquement française à ne pas prévoir. Ce n'est pas parce que ce n'est pas
encore fait, encore vu ou qu'on n'en connaît pas que ce n'est pas possible
bon sang ! L'abstraction est tout de même utile parfois. Imagine que tu as
l'idée d'une technique nouvelle mais complexe. Tu ne va pas foncer direct
dans l'implémentation, tu vas d'abord regarder si une contre mesure est
possible. Auquel cas tu gagnes un temps appréciable en ne te lançant pas à
corps perdu dans un travail de titan voué à l'échec. Lors de la phase de
conception, les "il suffit de" vont donc t'être très précieux...

Mais justement, c'est encore plus simple que ca : la +part des
malwares actuels sont ecrits en langage de haut niveau...et compiles
avec un
compilo dument certifie'.

Oui, mais as-tu suivi le sens de mon propos ? Si l'analyse d'un compilateur
te permets de tirer des lois au sujet de ce qui le fera passer pour
"certifié", par exemple, le type "moyen" d'instructions processeur
utilisées, ses méthodes d'optimisation, etc. Eh, bien, il te suffit de
reproduire cela dans ton malware pour brouiller les pistes !

Ben si c'est crypté tu vas pas loin avec ta technique...

Ben justement. Ma technique _commence_ toujours comme ca. Entre
autres, ca m'evite les problemes de chargement de dll tandis
que je suis entrain de debugger Notepad ;o)

OK.

Si c'est crypte' et que c'est relativement apparent, faut passer
au plan B (mais bon, la derniere fois que j'ai debugge' une verole,
je me suis betement fait infecter, apres avoir distraitement appuye'
sur la mauvaise touche...).

Bah, ça c'est le risque de "base". Moi, je ne compte plus les
auto-infections volontaires, lol.

Pourquoi ? Tu peux très bien avori ça dans un programme reglo. Par
exemple, un utilitaire système qui utilise un driver installé à al
volée, il l'a dans les ressources, et lors de l'exécution, il
l'enregistre en service, etc. Oui, c'est rare, mais c'est
parfaitement valide.

C'est rare dans un contexte normal, mais extremement courant chez
pas mal de droppers de trojans. C'est donc un bon critere heuristique.
Il faut bien sur considerer le fait que ce critere seul n'est pas
determinant, mais qu'il sera par la suite combine' a d'autres criteres
(eux-meme non determinants individuelement) pour donner le verdict
final.

Oui, oui, bien sûr. C'est tout un ensemble de règles.

[Chaines de caracteres]

Tout cela n'est valable que si c'est pas crypté ton truc...

Bah oui. Remarques qu'on peut peut-etre jouer au meme type de
jeu en ajoutant une phase d'emulation preliminaire, si on realise
qu'on a affaire a un truc crypte'.

Oui.

Ça aussi, c'est de moins en moins directement visible dans le code.

Heu...de moins en moins. Pas d'accord. Il y a de plus en plus
de malwares tres peu perfectionnees. Bien 90% du total....et
on espere de toute facon pas mieux des heuristiques.

Ha si tu parles des tas de boue porté au pinacle par la presse à sensation,
oui, ça vole pas haut. Mais, néamoins, le niveau monte quand même.

Et comme je l'ai montré dans une xemple, c'est trop facile
à planquer... rappelle-toi
[...]

J'ai pas oublie'. Mais ca reste la perle rare chez les malwares
actuels ;-)

Meuh non, et puis moi, dixit ppc, je suis nul, alors, tu penses bien ce que
quelqu'un de doué peut faire...

Les virus avec boîte de dialogue, il y en a un tas quand même ! Tous
ceux qui se font passer pour des patches, etc.

OK. Disons que c'est rare chez certains types de malwares, et
plutot courant pour les executables win32 standards...

Oui.

et que
ca peut donc servir de criteres pour les malwares en question
(dialers/keyloggers, etc.). Je voulais juste illustrer le fait
que certains criteres sont plutot indicatifs de la presence
d'un malware tandis que d'autres sont plutot indicatifs d'un
programme sain. Encore une fois, c'est purement statistique.

C'est un epu le problème : que ce soit statistique. Il restera toujours le
pauvre programme réglo qui va générer un faux-positif.

Voui, mais c'est exactement ce que je veux dire : il est parfois
plus difficile de savoir si un programme est sain que de savoir
s'il est infecte'.

Ben ça dépend quand même du soft ! Je vais t'envoyer des drivers, bien malin
qui peut me dire si c'est sain !

Par exemple, si le notepad de Fred etait
infecte' par un bon vieil infecteur de PE polymorphe avec EPO,
je serais a coup sur passe' a cote'. Par contre, un coup d'oeil a
un serveur optix via un editeur hexadecimal et je suis fixe'.

Oui, mais parce que ce n'est pas élaboré.

Non, je ne crois pas. Je pense moi que c'est plutôt basé sur des
caractéristiques bien précises, comme des "signatures". Comme, par
exemple, si tu étudies le code généré par un compilateur. Chacun
utilise des choses qui lui sont propres et dont tu peux t'inspirer
pour montrer leur "signature". Au besoin, je détaille.

Oui, mais comme je le disais en debut de message, les AVs pour
lesquels il est question d'analyse spectrale se debrouillent
manifestement mieux avec les malwares de haut niveau. Alors
je sais bien qu'il est tentant de considerer que tout programme
Delphi est un trojan ;o), mais sorti de ca, la connaissance
du compilo apporte peu pour les trucs en HLL.

Ben si, c'est parce qu'un programme compilé par tel compilo censé ne pas
utiliser du cli ou du push ebp utilise un cli que tu avs en déduire de la
suspicsion.

Sinon moi, pour les malwares, je ne fait pas comme ça. De nos jours,
c'est de plus en plus :

De plus en plus, je dirais pas ca. Il me semble que la majorite'
de la "production" reste extremement basique, meme si quelques
trucs sortent du lot.

Cela dépend ce que t'étudie. Moi, sasser, c'est 2' top chrono, après je
jette.

- crypté.

Pas si courant que ca dans les malwares "de tous les jours".
Generalement, seules une ou deux chaines de caracteres (celles
permettant d'identifier celui qui a diffuse' une backdoor par
exemple) sont cryptees.

Cela le sera de plus en plus. Et avec des techniques de plus en plus hard.
Moi, je prend les paris.

- brouillé. Ça c'est fun. par exemple, tu décale de 10h la valeur de
4Ko de code que tu descrambles (clin d'oeil à LaDDL) ensuite a
l'exécution. Bref, quand tu désassembles, tu voies rien.

J'ai surtout l'impression que beaucoup utilisent des outils
tout faits a la krypton, etc.

Quoi du scrambling en en-tête ? t'en as des tonnes ! Au hasard, Bagle.N.

- obfusqué. C'est à dire que t'as tout un tas de code qui ne sert à
rien. Donc, ça brouille ton analyse. Et il suffit d'inserer des
calls, d'ouvrir des fichiers temporaires, etc. T'es vite noyé...

Ca c'est malin, mais j'ai l'impression que c'est plutot rare. T'as
des exemples ?

Pas là sous la main. Mais ce sera, là aussi, de plus en plus utilisé.
Amuse-toi à désassembler un BIOS, tu vas rire, c'est genre 1k de code utile
pour 4k de junk, et c'est du chaud, tu peux me faire confiance...

Une fois depackes, tu peux traiter 90% des merdouilles avec un editeur
hexa et un desassembleur, amha. Pour le reste, c'est sur que c'est
insuffisant.

Donc, là aussi, les gars évolueront. Le but (enfin, le leur) c'est quand
même d'être diffusé :o).

Voui, la derniere fois, quand je me suis infecte', j'ai au moins pu
recuperer un dump. Le lot de consolation, en quelque sorte...

Bah, c'est assez marrant de se faire infecter parfois. Lorsque j'étais plus
jeune, j'avais fait une grosse bourde avec ça. Je bossais sur un infecteur
de fichier marrant, mais j'avais fait la grosse bêtise d'activer le
cross-directory (j'écris anglais pour que LaDDL puisse suivre). Le côté fun
c'était que quand une application était infectée, une autre instance était
lancée qui infectait un repértoire plus haut. Cela faisait un payload bien
visible et surtout pénible, pusique Windows bloquait au bout d'un certain
nombre de fenêtre. Le jour du test, trop fier devant ma copine ! Je lance
et, en quelques secondes, des tas de fenêtre Windows couvrent l'écran...
marrant pendant 40 secondes, jusqu'à ce que je comprenne que je n'avais plus
qu'à reformater ma machine puisque je ne pouvais plus lancer aucun
exécutable sans infecter encore plus le système :o). À l'époque, je ne
faisais pas de sauvegardes, ça m'a coûté plusieurs mois de boulot...
Aujourd'hui, j'en ris encore, mais sur le coup... je riais moins :o) !

Conclusion : utiliser sa machine de boulot pour coder du douteux, paaaaas
bieeeen !

--
AMcD®

http://arnold.mcdonald.free.fr/

Frederic Bonroy

19/05/2004 à 23:35

AMcD® wrote:

Or distinguer un dialer d'un password stealer d'un webdownloader
sur la base de statistiques sur les opcodes employes, je dois
bien dire que je n'y crois pas. Meme en considerant des courtes
series d'instructions, j'ai du mal a y croire...

Évidemment ! C'est du pipeau. Surtout que, comme je l'ai déjà dit, tu peux
toujours t'arranger pour "simuler" voire même dissimuler.

Je n'ai jamais joué avec l'analyse spectrale donc de mon côté il n'y
aura que des hypothèses. J'ai pas de relations privilégiées avec des
éditeurs AV, moi. :-D

Il est clair pour moi que le but de cette analyse n'est pas de dire
exactement de quel type de programme malveillant il s'agit. Et il est
clair aussi que ça ne marchera pas à tous les coups, notamment quand on
a affaire à du code généré par compilateur ou du code bien blindé.

Mais soyons réalistes: il y aura toujours des programmes malveillants
qui seront écrits en assembleur fait maison et qui ne seront pas
particulièrement bien camouflés. Faut pas croire que tous les auteurs de
virus sans exception vont soudain se mettre à camoufler leur code parce
qu'ils ont entendu parler de cette fameuse analyse spectrale. ;-)

Et les compilateurs modernes génèrent aussi du code plus compact. Là
l'analyse spectrale peut *complémenter* l'émulation par exemple et
fournir des renseignements *supplémentaires* qui peuvent aider
l'antivirus à prendre sa décision concernant la nature du programme en
question.

Oui, c'est rare, mais c'est parfaitement valide.

L'analyse heuristique n'a pas pour but de donner un résultat fiable à
100% dans tous les cas. C'est impossible.
Et ce n'est certainement pas parce qu'il y a un MZ dans une section
quelconque qu'un antivirus digne de ce nom va se mettre à brailler. Mais
s'il y ça ET autre chose ET peut-être encore autre chose, alors il
pourra se dire "trois trucs louches, c'est peut-être malveillant".

Il ne s'agit pas d'identifier un programme malveillant à partir de
seulement un critère.

AMcD® wrote:

Or distinguer un dialer d'un password stealer d'un webdownloader
sur la base de statistiques sur les opcodes employes, je dois
bien dire que je n'y crois pas. Meme en considerant des courtes
series d'instructions, j'ai du mal a y croire...

Évidemment ! C'est du pipeau. Surtout que, comme je l'ai déjà dit, tu peux
toujours t'arranger pour "simuler" voire même dissimuler.

Je n'ai jamais joué avec l'analyse spectrale donc de mon côté il n'y
aura que des hypothèses. J'ai pas de relations privilégiées avec des
éditeurs AV, moi. :-D

Il est clair pour moi que le but de cette analyse n'est pas de dire
exactement de quel type de programme malveillant il s'agit. Et il est
clair aussi que ça ne marchera pas à tous les coups, notamment quand on
a affaire à du code généré par compilateur ou du code bien blindé.

Mais soyons réalistes: il y aura toujours des programmes malveillants
qui seront écrits en assembleur fait maison et qui ne seront pas
particulièrement bien camouflés. Faut pas croire que tous les auteurs de
virus sans exception vont soudain se mettre à camoufler leur code parce
qu'ils ont entendu parler de cette fameuse analyse spectrale. ;-)

Et les compilateurs modernes génèrent aussi du code plus compact. Là
l'analyse spectrale peut *complémenter* l'émulation par exemple et
fournir des renseignements *supplémentaires* qui peuvent aider
l'antivirus à prendre sa décision concernant la nature du programme en
question.

Oui, c'est rare, mais c'est parfaitement valide.

L'analyse heuristique n'a pas pour but de donner un résultat fiable à
100% dans tous les cas. C'est impossible.
Et ce n'est certainement pas parce qu'il y a un MZ dans une section
quelconque qu'un antivirus digne de ce nom va se mettre à brailler. Mais
s'il y ça ET autre chose ET peut-être encore autre chose, alors il
pourra se dire "trois trucs louches, c'est peut-être malveillant".

Il ne s'agit pas d'identifier un programme malveillant à partir de
seulement un critère.

Vous avez filtré cet utilisateur ! Consultez son message

Frederic Bonroy

19/05/2004 à 23:45

Tweakie wrote:

Or distinguer un dialer d'un password stealer d'un webdownloader
sur la base de statistiques sur les opcodes employes, je dois
bien dire que je n'y crois pas.

Moi non plus mais je ne pense pas que ce soit le but cette analyse.

Donc en fait, je ne crois pas que l'"analyse spectrale" porte
exclusivement ou principalement sur l'analyse des statistiques
des opcodes. Pour resumer. Juste sur l'analyse des "suites d'octets
de longueur suffisante qui ont une probabilite' nettement
plus marquee d'etre dans un malware que dans une application
legitime" et eventuellement des fonctions importees (et
pourquoi pas des ressources).

Si on recherche des suites d'octets alors on retourne dans le domaine de
l'analyse heuristique "classique", statique (par opposition à
l'émulation, "dynamique"). Bref, on retourne 10 ans en arrière. ;-)

Frederic Bonroy

19/05/2004 à 23:59

Tweakie wrote:

*A propos, il parait que ca a ete integre' a la derniere version
d'Antivir. J'ai cherche un peu sur le site web, j'ai rien vu.
Tu confirmes, Frederic ?

Je ne trouve rien, ni sur free-av.de, ni sur hbedv.com. Ils ont refait
leur site et avlexa semble avoir disparu. Remarque, pour pouvoir jeter
un oeil aux versions beta, il faut maintenant demander un mot de passe
au préalable.

Frederic Bonroy

20/05/2004 à 16:24

Tweakie wrote:

Les deux fois ou on a parle' d'"analyse spectrale" ici, ca
concernait les heuristiques d'avlexa* et de nod.
[...]

Hier pendant un cours ennuyeux à l'université j'ai eu une petite idée,
et je l'ai réalisée aujourd'hui. C'est du vite fait car je veux profiter
du beau temps, mais bon, le principe y est.

J'ai ajouté à ceci:
http://groups.google.fr/groups?selmÂg0f6%241s7l07%241%40ID-75150.news.uni-berlin.de
une modeste fonction de reconnaissance de boucles.

Vous pouvez essayer avec trois programmes:

Le programme principal:
http://www.uni-koblenz.de/~fbonroy/boucles/akheur.exe
Un programme test avec une boucle:
http://www.uni-koblenz.de/~fbonroy/boucles/boucle.exe
Un programme test sans boucle:
http://www.uni-koblenz.de/~fbonroy/boucles/serie.exe

Mettez les trois dans le même répertoire et tapez akheur sur la ligne de
commande. Il détectera - j'espère ;-) - une boucle dans boucle.exe et
pas de boucle dans serie.exe.

Comment ça fonctionne? L'émulateur comptabilise pour chaque adresse dont
l'instruction qui s'y trouve est exécutée le nombre de fois qu'elle a
été appelée. Ensuite la moyenne est calculée. Puis le programme
recherche des séries d'adresses dont chaque membre a été appelé plus
souvent que la moyenne. Ces séries doivent être longues d'au moins 5
instructions (j'ai choisi ça au hasard).
Par exemple, si la moyenne est de 2 et que le programme trouve une série
d'au moins 5 adresses succéssives appelées 4 fois, alors il croira avoir
trouvé une boucle.
Sont prises en compte uniquement les adresses à moins de 8192 octets du
point d'entrée.

Ouais, je sais, ça se contourne, ça se camoufle, etc. © Mais ici c'est
un mécanisme extrêmement simple. Faut espérer que les éditeurs AV font
ça autrement.

Vous pouvez vous-même tester l'efficacité du mécanisme si vous disposez
d'un assembleur capable de créer des PE. Vous pouvez utiliser les
instructions suivantes (ce sont les seules que l'émulateur connaît):

xor r/m8, reg8
xor al, imm8
jnz rel8
sub (81h)
cmp (83h)
mov reg32, r/m32
lea
nop
stosb
lodsb
loop rel8
call rel32
cld
std

Le tout sans SIB!

Le code de détection de boucle est le suivant:

; premiere etape: calculer la moyenne
lea esi, frequency ; tableau de 8192 * 4
mov ecx, 8192
xor eax, eax ; somme
xor ebx, ebx ; nombre d'adresses visitees au moins une fois
@@loop_1:
mov edx, [esi]
add eax, edx

or edx, edx ; si l'adresse a ete visitee au moins une fois,
setnz dl ; l'inclure dans le calcul
movzx edx, dl
and edx, 1
add ebx, edx

add esi, 4
dec ecx
jnz @@loop_1

xor edx, edx ; diviser la somme par le nombre d'adresses
div ebx
mov ebx, eax ; le quotient (moyenne) dans ebx

; seconde etape: determiner s'il y a des suites d'adresses
; visitees plus souvent que la moyenne

lea esi, frequency
mov ecx, 8192
xor eax, eax ; nombre d'instructions > moyenne de suite
xor edi, edi ; constante = 0
mov edx, 1 ; constante = 1
mov ebp, offset sloop ; adresse du message a afficher si boucle
@@loop_2:
cmp [esi], ebx
cmovng eax, edi ; plus petit -> remettre le compteur a zero
jng @@loop_3

inc eax ; pl. grand/egal a moyenne, augmenter compteur
cmp eax, 5 ; limite de 5 instructions franchie?
cmovae ecx, edx ; ecx = 1 pour forcer la boucle a terminer
cmovae edi, ebp

@@loop_3:
add esi, 4
dec ecx
jnz @@loop_2

Tweakie wrote:

Les deux fois ou on a parle' d'"analyse spectrale" ici, ca
concernait les heuristiques d'avlexa* et de nod.
[...]

Hier pendant un cours ennuyeux à l'université j'ai eu une petite idée,
et je l'ai réalisée aujourd'hui. C'est du vite fait car je veux profiter
du beau temps, mais bon, le principe y est.

J'ai ajouté à ceci:
http://groups.google.fr/groups?selmÂg0f6%241s7l07%241%40ID-75150.news.uni-berlin.de
une modeste fonction de reconnaissance de boucles.

Vous pouvez essayer avec trois programmes:

Le programme principal:
http://www.uni-koblenz.de/~fbonroy/boucles/akheur.exe
Un programme test avec une boucle:
http://www.uni-koblenz.de/~fbonroy/boucles/boucle.exe
Un programme test sans boucle:
http://www.uni-koblenz.de/~fbonroy/boucles/serie.exe

Mettez les trois dans le même répertoire et tapez akheur sur la ligne de
commande. Il détectera - j'espère ;-) - une boucle dans boucle.exe et
pas de boucle dans serie.exe.

Comment ça fonctionne? L'émulateur comptabilise pour chaque adresse dont
l'instruction qui s'y trouve est exécutée le nombre de fois qu'elle a
été appelée. Ensuite la moyenne est calculée. Puis le programme
recherche des séries d'adresses dont chaque membre a été appelé plus
souvent que la moyenne. Ces séries doivent être longues d'au moins 5
instructions (j'ai choisi ça au hasard).
Par exemple, si la moyenne est de 2 et que le programme trouve une série
d'au moins 5 adresses succéssives appelées 4 fois, alors il croira avoir
trouvé une boucle.
Sont prises en compte uniquement les adresses à moins de 8192 octets du
point d'entrée.

Ouais, je sais, ça se contourne, ça se camoufle, etc. © Mais ici c'est
un mécanisme extrêmement simple. Faut espérer que les éditeurs AV font
ça autrement.

Vous pouvez vous-même tester l'efficacité du mécanisme si vous disposez
d'un assembleur capable de créer des PE. Vous pouvez utiliser les
instructions suivantes (ce sont les seules que l'émulateur connaît):

xor r/m8, reg8
xor al, imm8
jnz rel8
sub (81h)
cmp (83h)
mov reg32, r/m32
lea
nop
stosb
lodsb
loop rel8
call rel32
cld
std

Le tout sans SIB!

Le code de détection de boucle est le suivant:

; premiere etape: calculer la moyenne
lea esi, frequency ; tableau de 8192 * 4
mov ecx, 8192
xor eax, eax ; somme
xor ebx, ebx ; nombre d'adresses visitees au moins une fois
@@loop_1:
mov edx, [esi]
add eax, edx

or edx, edx ; si l'adresse a ete visitee au moins une fois,
setnz dl ; l'inclure dans le calcul
movzx edx, dl
and edx, 1
add ebx, edx

add esi, 4
dec ecx
jnz @@loop_1

xor edx, edx ; diviser la somme par le nombre d'adresses
div ebx
mov ebx, eax ; le quotient (moyenne) dans ebx

; seconde etape: determiner s'il y a des suites d'adresses
; visitees plus souvent que la moyenne

lea esi, frequency
mov ecx, 8192
xor eax, eax ; nombre d'instructions > moyenne de suite
xor edi, edi ; constante = 0
mov edx, 1 ; constante = 1
mov ebp, offset sloop ; adresse du message a afficher si boucle
@@loop_2:
cmp [esi], ebx
cmovng eax, edi ; plus petit -> remettre le compteur a zero
jng @@loop_3

inc eax ; pl. grand/egal a moyenne, augmenter compteur
cmp eax, 5 ; limite de 5 instructions franchie?
cmovae ecx, edx ; ecx = 1 pour forcer la boucle a terminer
cmovae edi, ebp

@@loop_3:
add esi, 4
dec ecx
jnz @@loop_2

Vous avez filtré cet utilisateur ! Consultez son message

Tweakie wrote:

Les deux fois ou on a parle' d'"analyse spectrale" ici, ca
concernait les heuristiques d'avlexa* et de nod.
[...]

Hier pendant un cours ennuyeux à l'université j'ai eu une petite idée,
et je l'ai réalisée aujourd'hui. C'est du vite fait car je veux profiter
du beau temps, mais bon, le principe y est.

J'ai ajouté à ceci:
http://groups.google.fr/groups?selmÂg0f6%241s7l07%241%40ID-75150.news.uni-berlin.de
une modeste fonction de reconnaissance de boucles.

Vous pouvez essayer avec trois programmes:

Le programme principal:
http://www.uni-koblenz.de/~fbonroy/boucles/akheur.exe
Un programme test avec une boucle:
http://www.uni-koblenz.de/~fbonroy/boucles/boucle.exe
Un programme test sans boucle:
http://www.uni-koblenz.de/~fbonroy/boucles/serie.exe

Mettez les trois dans le même répertoire et tapez akheur sur la ligne de
commande. Il détectera - j'espère ;-) - une boucle dans boucle.exe et
pas de boucle dans serie.exe.

Comment ça fonctionne? L'émulateur comptabilise pour chaque adresse dont
l'instruction qui s'y trouve est exécutée le nombre de fois qu'elle a
été appelée. Ensuite la moyenne est calculée. Puis le programme
recherche des séries d'adresses dont chaque membre a été appelé plus
souvent que la moyenne. Ces séries doivent être longues d'au moins 5
instructions (j'ai choisi ça au hasard).
Par exemple, si la moyenne est de 2 et que le programme trouve une série
d'au moins 5 adresses succéssives appelées 4 fois, alors il croira avoir
trouvé une boucle.
Sont prises en compte uniquement les adresses à moins de 8192 octets du
point d'entrée.

Ouais, je sais, ça se contourne, ça se camoufle, etc. © Mais ici c'est
un mécanisme extrêmement simple. Faut espérer que les éditeurs AV font
ça autrement.

Vous pouvez vous-même tester l'efficacité du mécanisme si vous disposez
d'un assembleur capable de créer des PE. Vous pouvez utiliser les
instructions suivantes (ce sont les seules que l'émulateur connaît):

xor r/m8, reg8
xor al, imm8
jnz rel8
sub (81h)
cmp (83h)
mov reg32, r/m32
lea
nop
stosb
lodsb
loop rel8
call rel32
cld
std

Le tout sans SIB!

Le code de détection de boucle est le suivant:

; premiere etape: calculer la moyenne
lea esi, frequency ; tableau de 8192 * 4
mov ecx, 8192
xor eax, eax ; somme
xor ebx, ebx ; nombre d'adresses visitees au moins une fois
@@loop_1:
mov edx, [esi]
add eax, edx

or edx, edx ; si l'adresse a ete visitee au moins une fois,
setnz dl ; l'inclure dans le calcul
movzx edx, dl
and edx, 1
add ebx, edx

add esi, 4
dec ecx
jnz @@loop_1

xor edx, edx ; diviser la somme par le nombre d'adresses
div ebx
mov ebx, eax ; le quotient (moyenne) dans ebx

; seconde etape: determiner s'il y a des suites d'adresses
; visitees plus souvent que la moyenne

lea esi, frequency
mov ecx, 8192
xor eax, eax ; nombre d'instructions > moyenne de suite
xor edi, edi ; constante = 0
mov edx, 1 ; constante = 1
mov ebp, offset sloop ; adresse du message a afficher si boucle
@@loop_2:
cmp [esi], ebx
cmovng eax, edi ; plus petit -> remettre le compteur a zero
jng @@loop_3

inc eax ; pl. grand/egal a moyenne, augmenter compteur
cmp eax, 5 ; limite de 5 instructions franchie?
cmovae ecx, edx ; ecx = 1 pour forcer la boucle a terminer
cmovae edi, ebp

@@loop_3:
add esi, 4
dec ecx
jnz @@loop_2

NO_eikaewt_SPAM

21/05/2004 à 13:26

Salut,

Comment ça fonctionne? L'émulateur comptabilise pour chaque adresse dont
l'instruction qui s'y trouve est exécutée le nombre de fois qu'elle a
été appelée. Ensuite la moyenne est calculée. Puis le programme
recherche des séries d'adresses dont chaque membre a été appelé plus
souvent que la moyenne. Ces séries doivent être longues d'au moins 5
instructions (j'ai choisi ça au hasard).

Heu, question stupide : tu risques pas de detecter les fonctions
appelees un peu trop souvent avec cette methode, en plus des
boucles ?

Faudrait peut-etre compter le nombre de calls qui pointent vers
le debut de chacun des blocs repere' et soustraire ce nombre
moins un a ton decompte (ou quelque chose du genre). Qu'en penses-tu ?

--
Tweakie

--
Posté via http://www.webatou.net/
Usenet dans votre navigateur !
Complaints-To:

Frederic Bonroy

21/05/2004 à 21:27

Tweakie wrote:

Heu, question stupide : tu risques pas de detecter les fonctions
appelees un peu trop souvent avec cette methode, en plus des
boucles ?

Oui.

Faudrait peut-etre compter le nombre de calls qui pointent vers
le debut de chacun des blocs repere' et soustraire ce nombre
moins un a ton decompte (ou quelque chose du genre). Qu'en penses-tu ?

C'est sûr qu'il faut prendre des mesures pour éviter ça. C'était juste
une petite démonstration de ce que l'on peut faire en regardant les
fréquences/structures des instructions au lieu des instructions mêmes.

Analyse spectrale

9 réponses

Veuillez sélectionner un problème