Bonjour à tous,
Suite au comportement que je jugeais anormal de ma messagerie (je recevais
régulièrement des messages infectés, et il semble que le virus utilise mon
adresse pour infecter d'autres personnes), j'ai lancé un scan de mon disque.
Il semble que je sois effectivement infecté, puisque l'antivirus m'annonce avoir
découvert:
Trojan.Spy.Bispy.C
Backdoor.Ralpha.A
Je ne trouve pas sur les sites des antivirus la référence à ces deux virus, et
ne sais donc pas quel utilitaire utiliser pour me désinfecter.
Quelqu'un peut-il m'aider?
Si vous voulez: l'analyse spectrale est une forme d'heuristique. Oui on est d'accord.
L'analyse spectrale est un *procédé* heuristique. Pourquoi pas ce n'est pas faux.
Alors pourquoi contestiez-vous l'usage du mot "heuristique" pour décrire l'analyse spectrale, Je ne l'ai pas contesté mais dans le champ d'application de la lutte
antivirale ce sont pour moi deux analyseurs distincts.
et pourquoi tenez-vous à ce niveau là à faire la différence entre les deux? Parce que dans les AV ce sont des analyseurs distincts.
Je m'explique ci-dessous :
L'analyse heuristique, ce n'est pas la recheche d'une "instruction". Si et correspondant à des fonctions virales. L'analyseur recherchera du
code dont l'action est suspecte ou malveillante s'il vient à être exécuté par exemple.
L'analyse heuristique dans le contexte antiviral, c'est tout ce qui peut mener, mais ne mène pas forcément, à la découverte d'un virus. Et l'analyse spectrale en fait partie. Tout à fait.
Non vous m'avez mal compris. Le fait de dire qu'un FW est inutile sème le doute dans l'esprit des users. C'est pourquoi j'ai réagi ainsi. Bien sûr nous savons vous et moi qu'un FW échoue face à certaines attaques par Trojans.
Au contraire. Ça leur fait comprendre qu'il n'y a pas que des backdoors, mais autre chose aussi. Ça leur fait comprendre qu'il leur faut employer d'autres outils aussi pour se protéger contre les chevaux de Troie. Même si je trouve que les épidémies virales depuis un an ont eu pour
effet de faire prendre conscience des problèmes de sécurité aux users et à certains éditeurs. Je ne suis pas d'accord pour la pédagogie/sensibilisation par l'emploi de techniques illégales. Car cela entraine la confusion dans tous les esprits. Et l'on en finit par légitimer certains actes de délinquance informatique.
C'est *grave* que certains croient qu'un pare-feu protège contre tous les chevaux de Troie. Tous les users ne sont pas des bidouilleurs, chercheurs, connaisseurs,
étudiants, passionnés ou professionnels etc. La plupart ne savent pas administrer leur environnement donc ne leur demander pas de gèrer leur niveau de sécurité.
Frederic Bonroy wrote:
Si vous voulez: l'analyse spectrale est une forme d'heuristique.
Oui on est d'accord.
L'analyse spectrale est un
*procédé* heuristique.
Pourquoi pas ce n'est pas faux.
Alors pourquoi contestiez-vous l'usage du mot "heuristique" pour décrire
l'analyse spectrale,
Je ne l'ai pas contesté mais dans le champ d'application de la lutte
antivirale ce sont pour moi deux analyseurs distincts.
et pourquoi tenez-vous à ce niveau là à faire la
différence entre les deux?
Parce que dans les AV ce sont des analyseurs distincts.
Je m'explique ci-dessous :
L'analyse heuristique, ce n'est pas la recheche d'une "instruction".
Si et correspondant à des fonctions virales. L'analyseur recherchera du
code dont l'action est suspecte ou malveillante s'il vient à être
exécuté par exemple.
L'analyse heuristique dans le contexte antiviral, c'est tout ce qui peut
mener, mais ne mène pas forcément, à la découverte d'un virus. Et
l'analyse spectrale en fait partie.
Tout à fait.
Non vous m'avez mal compris. Le fait de dire qu'un FW est inutile sème
le doute dans l'esprit des users. C'est pourquoi j'ai réagi ainsi. Bien
sûr nous savons vous et moi qu'un FW échoue face à certaines attaques
par Trojans.
Au contraire. Ça leur fait comprendre qu'il n'y a pas que des backdoors,
mais autre chose aussi. Ça leur fait comprendre qu'il leur faut employer
d'autres outils aussi pour se protéger contre les chevaux de Troie.
Même si je trouve que les épidémies virales depuis un an ont eu pour
effet de faire prendre conscience des problèmes de sécurité aux users et
à certains éditeurs. Je ne suis pas d'accord pour la
pédagogie/sensibilisation par l'emploi de techniques illégales. Car cela
entraine la confusion dans tous les esprits. Et l'on en finit par
légitimer certains actes de délinquance informatique.
C'est *grave* que certains croient qu'un pare-feu protège contre tous
les chevaux de Troie.
Tous les users ne sont pas des bidouilleurs, chercheurs, connaisseurs,
étudiants, passionnés ou professionnels etc. La plupart ne savent pas
administrer leur environnement donc ne leur demander pas de gèrer leur
niveau de sécurité.
Si vous voulez: l'analyse spectrale est une forme d'heuristique. Oui on est d'accord.
L'analyse spectrale est un *procédé* heuristique. Pourquoi pas ce n'est pas faux.
Alors pourquoi contestiez-vous l'usage du mot "heuristique" pour décrire l'analyse spectrale, Je ne l'ai pas contesté mais dans le champ d'application de la lutte
antivirale ce sont pour moi deux analyseurs distincts.
et pourquoi tenez-vous à ce niveau là à faire la différence entre les deux? Parce que dans les AV ce sont des analyseurs distincts.
Je m'explique ci-dessous :
L'analyse heuristique, ce n'est pas la recheche d'une "instruction". Si et correspondant à des fonctions virales. L'analyseur recherchera du
code dont l'action est suspecte ou malveillante s'il vient à être exécuté par exemple.
L'analyse heuristique dans le contexte antiviral, c'est tout ce qui peut mener, mais ne mène pas forcément, à la découverte d'un virus. Et l'analyse spectrale en fait partie. Tout à fait.
Non vous m'avez mal compris. Le fait de dire qu'un FW est inutile sème le doute dans l'esprit des users. C'est pourquoi j'ai réagi ainsi. Bien sûr nous savons vous et moi qu'un FW échoue face à certaines attaques par Trojans.
Au contraire. Ça leur fait comprendre qu'il n'y a pas que des backdoors, mais autre chose aussi. Ça leur fait comprendre qu'il leur faut employer d'autres outils aussi pour se protéger contre les chevaux de Troie. Même si je trouve que les épidémies virales depuis un an ont eu pour
effet de faire prendre conscience des problèmes de sécurité aux users et à certains éditeurs. Je ne suis pas d'accord pour la pédagogie/sensibilisation par l'emploi de techniques illégales. Car cela entraine la confusion dans tous les esprits. Et l'on en finit par légitimer certains actes de délinquance informatique.
C'est *grave* que certains croient qu'un pare-feu protège contre tous les chevaux de Troie. Tous les users ne sont pas des bidouilleurs, chercheurs, connaisseurs,
étudiants, passionnés ou professionnels etc. La plupart ne savent pas administrer leur environnement donc ne leur demander pas de gèrer leur niveau de sécurité.
LaDDL
Frederic Bonroy wrote:
Un cheval de Troie qui formate le disque dur n'exploite aucune vulnérabilité dans quoi que ce soit Un Trojan exploite une/des vulnérabilités pour s'installer sur le
système de la victime. Une fois installé c'est clair il agit point barre.
, et les pare-feu ne peuvent rien faire contre. Ca dépend du type d'attaques par Trojan.
L'analyse des flux peut fournir beaucoup d'informations.
Frederic Bonroy wrote:
Un cheval de Troie qui formate le disque dur n'exploite aucune
vulnérabilité dans quoi que ce soit
Un Trojan exploite une/des vulnérabilités pour s'installer sur le
système de la victime. Une fois installé c'est clair il agit point
barre.
, et les pare-feu ne peuvent rien
faire contre.
Ca dépend du type d'attaques par Trojan.
L'analyse des flux peut fournir beaucoup d'informations.
Un cheval de Troie qui formate le disque dur n'exploite aucune vulnérabilité dans quoi que ce soit Un Trojan exploite une/des vulnérabilités pour s'installer sur le
système de la victime. Une fois installé c'est clair il agit point barre.
, et les pare-feu ne peuvent rien faire contre. Ca dépend du type d'attaques par Trojan.
L'analyse des flux peut fournir beaucoup d'informations.
Frederic Bonroy
LaDDL wrote:
Si vous voulez: l'analyse spectrale est une forme d'heuristique. Oui on est d'accord.
L'analyse spectrale est un *procédé* heuristique. Pourquoi pas ce n'est pas faux.
Alors pourquoi contestiez-vous l'usage du mot "heuristique" pour décrire l'analyse spectrale, Je ne l'ai pas contesté mais dans le champ d'application de la lutte
antivirale ce sont pour moi deux analyseurs distincts.
C'est contradictoire ce que vous dites, enfin. :-( En haut vous dites être d'accord sur le fait que l'analyse spectrale est une forme d'heuristique et maintenant vous dites que ce sont deux analyseurs distinct.
C'est comme pour les tests dans la presse. :-(
L'analyse heuristique, ce n'est pas la recheche d'une "instruction". Si et correspondant à des fonctions virales. L'analyseur recherchera du
code dont l'action est suspecte ou malveillante s'il vient à être exécuté par exemple.
Et il fait ça comment? Par émulation par exemple. Allors appelons ça "émulation" et pas "analyse heuristique", car l'analyse spectrale est aussi une analyse heuristique.
Bien sûr que l'émulation est *une* forme d'analyse heuristique, mais si vous appelez ça analyse heuristique on est tenté de croire que vous considérez que l'analyse spectrale n'est pas heuristique parce que vous la mentionnez *en plus*.
Même si je trouve que les épidémies virales depuis un an ont eu pour effet de faire prendre conscience des problèmes de sécurité aux users et à certains éditeurs. Je ne suis pas d'accord pour la pédagogie/sensibilisation par l'emploi de techniques illégales. Car cela entraine la confusion dans tous les esprits. Et l'on en finit par légitimer certains actes de délinquance informatique.
???
Je ne suis pas pour leur faire comprendre par l'expérience et des attaques. Vous m'avez mal compris. Je suis pour leur dire qu'un pare-feu ne protège pas contre tous les chevaux de Troie. Cela sème peut-être le doute mais... ce peut être une bonne chose aussi.
C'est *grave* que certains croient qu'un pare-feu protège contre tous les chevaux de Troie. Tous les users ne sont pas des bidouilleurs, chercheurs, connaisseurs,
étudiants, passionnés ou professionnels etc. La plupart ne savent pas administrer leur environnement donc ne leur demander pas de gèrer leur niveau de sécurité.
C'est grave dans la mesure où ça montre qu'il y a encore du boulot au niveau de l'éducation. Je ne leur donne pas la faute, ce n'est pas ça que j'ai voulu exprimer.
LaDDL wrote:
Si vous voulez: l'analyse spectrale est une forme d'heuristique.
Oui on est d'accord.
L'analyse spectrale est un
*procédé* heuristique.
Pourquoi pas ce n'est pas faux.
Alors pourquoi contestiez-vous l'usage du mot "heuristique" pour décrire
l'analyse spectrale,
Je ne l'ai pas contesté mais dans le champ d'application de la lutte
antivirale ce sont pour moi deux analyseurs distincts.
C'est contradictoire ce que vous dites, enfin. :-( En haut vous dites
être d'accord sur le fait que l'analyse spectrale est une forme
d'heuristique et maintenant vous dites que ce sont deux analyseurs distinct.
C'est comme pour les tests dans la presse. :-(
L'analyse heuristique, ce n'est pas la recheche d'une "instruction".
Si et correspondant à des fonctions virales. L'analyseur recherchera du
code dont l'action est suspecte ou malveillante s'il vient à être
exécuté par exemple.
Et il fait ça comment? Par émulation par exemple. Allors appelons ça
"émulation" et pas "analyse heuristique", car l'analyse spectrale est
aussi une analyse heuristique.
Bien sûr que l'émulation est *une* forme d'analyse heuristique, mais si
vous appelez ça analyse heuristique on est tenté de croire que vous
considérez que l'analyse spectrale n'est pas heuristique parce que vous
la mentionnez *en plus*.
Même si je trouve que les épidémies virales depuis un an ont eu pour
effet de faire prendre conscience des problèmes de sécurité aux users et
à certains éditeurs. Je ne suis pas d'accord pour la
pédagogie/sensibilisation par l'emploi de techniques illégales. Car cela
entraine la confusion dans tous les esprits. Et l'on en finit par
légitimer certains actes de délinquance informatique.
???
Je ne suis pas pour leur faire comprendre par l'expérience et des
attaques. Vous m'avez mal compris. Je suis pour leur dire qu'un pare-feu
ne protège pas contre tous les chevaux de Troie. Cela sème peut-être le
doute mais... ce peut être une bonne chose aussi.
C'est *grave* que certains croient qu'un pare-feu protège contre tous
les chevaux de Troie.
Tous les users ne sont pas des bidouilleurs, chercheurs, connaisseurs,
étudiants, passionnés ou professionnels etc. La plupart ne savent pas
administrer leur environnement donc ne leur demander pas de gèrer leur
niveau de sécurité.
C'est grave dans la mesure où ça montre qu'il y a encore du boulot au
niveau de l'éducation. Je ne leur donne pas la faute, ce n'est pas ça
que j'ai voulu exprimer.
Si vous voulez: l'analyse spectrale est une forme d'heuristique. Oui on est d'accord.
L'analyse spectrale est un *procédé* heuristique. Pourquoi pas ce n'est pas faux.
Alors pourquoi contestiez-vous l'usage du mot "heuristique" pour décrire l'analyse spectrale, Je ne l'ai pas contesté mais dans le champ d'application de la lutte
antivirale ce sont pour moi deux analyseurs distincts.
C'est contradictoire ce que vous dites, enfin. :-( En haut vous dites être d'accord sur le fait que l'analyse spectrale est une forme d'heuristique et maintenant vous dites que ce sont deux analyseurs distinct.
C'est comme pour les tests dans la presse. :-(
L'analyse heuristique, ce n'est pas la recheche d'une "instruction". Si et correspondant à des fonctions virales. L'analyseur recherchera du
code dont l'action est suspecte ou malveillante s'il vient à être exécuté par exemple.
Et il fait ça comment? Par émulation par exemple. Allors appelons ça "émulation" et pas "analyse heuristique", car l'analyse spectrale est aussi une analyse heuristique.
Bien sûr que l'émulation est *une* forme d'analyse heuristique, mais si vous appelez ça analyse heuristique on est tenté de croire que vous considérez que l'analyse spectrale n'est pas heuristique parce que vous la mentionnez *en plus*.
Même si je trouve que les épidémies virales depuis un an ont eu pour effet de faire prendre conscience des problèmes de sécurité aux users et à certains éditeurs. Je ne suis pas d'accord pour la pédagogie/sensibilisation par l'emploi de techniques illégales. Car cela entraine la confusion dans tous les esprits. Et l'on en finit par légitimer certains actes de délinquance informatique.
???
Je ne suis pas pour leur faire comprendre par l'expérience et des attaques. Vous m'avez mal compris. Je suis pour leur dire qu'un pare-feu ne protège pas contre tous les chevaux de Troie. Cela sème peut-être le doute mais... ce peut être une bonne chose aussi.
C'est *grave* que certains croient qu'un pare-feu protège contre tous les chevaux de Troie. Tous les users ne sont pas des bidouilleurs, chercheurs, connaisseurs,
étudiants, passionnés ou professionnels etc. La plupart ne savent pas administrer leur environnement donc ne leur demander pas de gèrer leur niveau de sécurité.
C'est grave dans la mesure où ça montre qu'il y a encore du boulot au niveau de l'éducation. Je ne leur donne pas la faute, ce n'est pas ça que j'ai voulu exprimer.
Noshi
On Tue, 18 May 2004 18:42:55 +0200, Ewa (siostra Ani) N. wrote:
AMcD® wrote:
Cela serait plus simple si tu utilisais le français pur et dur quand même,
plutôt que ce sabir mi-anglais/mi-3l33tz. t'as pourtant dépassé l'âge moyen des lecteurs de hackinzdaweurldemy non :-) ?
Merci... moi j'ai du mal à dire simplement ces choses là.
Pourquoi tu crois que je réponds pas :/
Ewcia
-- Noshi
On Tue, 18 May 2004 18:42:55 +0200, Ewa (siostra Ani) N. wrote:
AMcD® wrote:
Cela serait plus simple si tu utilisais le français pur et dur quand
même,
plutôt que ce sabir mi-anglais/mi-3l33tz. t'as pourtant dépassé l'âge moyen
des lecteurs de hackinzdaweurldemy non :-) ?
Merci... moi j'ai du mal à dire simplement ces choses là.
OK. Alors, une petite question : "Quel cheval de Troie récent serait bloqué par un pare-feu faisant un suivi de sessions correct ?"
Eh Nicolas on est à l'école là ? MDR
Et au fait, cher "Bruno", il est extrêmement mal-poli, en tout cas à mes yeux, d'appeller les gens par leur prénom IRL quand ils sont sous pseudo.
A bon entendeur ...
Nicob
Utilisateur_anonyme_et_non_membre_de_webatou.net
LaDDL wrote:
L'analyse heuristique, ce n'est pas la recheche d'une "instruction". Si et correspondant à des fonctions virales. L'analyseur recherchera du
code dont l'action est suspecte ou malveillante s'il vient à être exécuté par exemple.
Non. C'est ce qu'on se tue a vous dire. Il existe plusieurs types d'informations qui peuvent aider a conclure qu'un fichier a une nature virale. Prenons par exemple l'analyseur heuristique ecrit il y a quelque temps de ca par Nicolas Brulez (et qui, si j'ai bien suivi, va etre presente' prochainement aux SSTIC). Il y a deux ans, on pouvait lire, parmis les criteres utilises par l'analyse heuristique :
http://groups.google.com/groups?selmª4amo%2419j0%241%40norfair.nerim.net --- Entry Point does not start with a standard instruction. Suspicious JMP FAR found at Entry point+19.Might be some OEP obfuscation. Execution starts in last section. Suspicious section characteristics for last section. Suspicious difference between OEP RVA and Section RVA.OEP obfuscation? ---
Les trois derniers criteres ne correspondent pas du tout a votre definition : aucune recherche d'"instruction". Et pour les deux premiers, ce n'est pas l'instruction qui est suspecte, c'est le fait de la trouver la ou elle se trouve.
Autre exemple, messagelabs a depose' un brevet portant sur une de ses techniques d'analyse heuristique, dediee a la decouverte d'infecteurs de fichiers. J'ai tente' de le resumer dans ce fil : http://groups.google.com/groups?selm 040227014242.S81859%40areba.vasb J'avais tente' de le resumer ainsi : --- La portion de code de l'executable situee a proximite' du point d'entree est comparee avec une serie de templates. Chaque template correspondant au code normalement produit par un compilateur connu. Si le code analyse' ne correspond a aucun de ces templates, ou si du code correspondant a un template est effectivement trouve' mais qu'il n'est pas localise' au niveau du point d'entree, le code est classe' suspect et sera analyse' plus en profondeur ---
La, sont declarees suspectes toutes les instructions qui ne correspondent pas aux instructions standards.
Enfin, Norman (et ESET manifestement) font tourner les programmes malveillants dans une sorte de machine virtuelle, pour observer leur comportement. Ce qui fait aussi partie de l'analyse heuristique.
Notez aussi que les deux premieres techniques que 'ai evoquees ne sont applicables qu'aux infecteurs de fichiers. Pour distinguer un vers de messagerie ou un cheval de Troie, on ne peut pas travailler a si bas niveau : ces codes sont (la plupart du temps) issus de compilateurs tout a fait legitimes. Il faut donc imperativement emuler le code ou travailler a un autre niveau (quelle sont les fonctions importees ?).
L'analyse heuristique dans le contexte antiviral, c'est tout ce qui peut mener, mais ne mène pas forcément, à la découverte d'un virus. Et l'analyse spectrale en fait partie. Tout à fait.
..et cela *inclut* votre analyse spectrale. Ca ne "cohabite pas" avec.
Par contre, je ne sais toujours pas vraiment en quoi consiste cette fameuse analyse spectrale. Et je commence a croire que je ne suis pas le premier a ne pas le savoir. A vous entendre, c'est "l'étude de la fréquence d'apparition des intructions." Mais heu, je suis sans doute naif, mais je suppose que ce n'est pas des instructions assembleur dont vous parlez, si ? Vous pourriez expliciter un peu ?
-- Tweakie
-- Posté via http://www.webatou.net/ Usenet dans votre navigateur ! Complaints-To:
LaDDL wrote:
L'analyse heuristique, ce n'est pas la recheche d'une "instruction".
Si et correspondant à des fonctions virales. L'analyseur recherchera du
code dont l'action est suspecte ou malveillante s'il vient à être
exécuté par exemple.
Non. C'est ce qu'on se tue a vous dire. Il existe plusieurs types
d'informations qui peuvent aider a conclure qu'un fichier a une
nature virale. Prenons par exemple l'analyseur heuristique ecrit
il y a quelque temps de ca par Nicolas Brulez (et qui, si j'ai bien
suivi, va etre presente' prochainement aux SSTIC). Il y a deux ans,
on pouvait lire, parmis les criteres utilises par l'analyse heuristique :
http://groups.google.com/groups?selmª4amo%2419j0%241%40norfair.nerim.net
---
Entry Point does not start with a standard instruction.
Suspicious JMP FAR found at Entry point+19.Might be some OEP obfuscation.
Execution starts in last section.
Suspicious section characteristics for last section.
Suspicious difference between OEP RVA and Section RVA.OEP obfuscation?
---
Les trois derniers criteres ne correspondent pas du tout a votre
definition : aucune recherche d'"instruction". Et pour les deux
premiers, ce n'est pas l'instruction qui est suspecte, c'est le fait
de la trouver la ou elle se trouve.
Autre exemple, messagelabs a depose' un brevet portant sur une
de ses techniques d'analyse heuristique, dediee a la decouverte
d'infecteurs de fichiers. J'ai tente' de le resumer dans ce fil :
http://groups.google.com/groups?selm 040227014242.S81859%40areba.vasb
J'avais tente' de le resumer ainsi :
---
La portion de code de l'executable situee a proximite' du point d'entree
est comparee avec une serie de templates. Chaque template correspondant
au code normalement produit par un compilateur connu. Si le code analyse'
ne correspond a aucun de ces templates, ou si du code correspondant a un
template est effectivement trouve' mais qu'il n'est pas localise' au
niveau du point d'entree, le code est classe' suspect et sera analyse'
plus en profondeur
---
La, sont declarees suspectes toutes les instructions qui ne correspondent
pas aux instructions standards.
Enfin, Norman (et ESET manifestement) font tourner les programmes
malveillants dans une sorte de machine virtuelle, pour observer leur
comportement. Ce qui fait aussi partie de l'analyse heuristique.
Notez aussi que les deux premieres techniques que 'ai evoquees ne
sont applicables qu'aux infecteurs de fichiers. Pour distinguer un
vers de messagerie ou un cheval de Troie, on ne peut pas travailler
a si bas niveau : ces codes sont (la plupart du temps) issus de
compilateurs tout a fait legitimes. Il faut donc imperativement emuler
le code ou travailler a un autre niveau (quelle sont les fonctions
importees ?).
L'analyse heuristique dans le contexte antiviral, c'est tout ce qui peut
mener, mais ne mène pas forcément, à la découverte d'un virus. Et
l'analyse spectrale en fait partie.
Tout à fait.
..et cela *inclut* votre analyse spectrale. Ca ne "cohabite pas"
avec.
Par contre, je ne sais toujours pas vraiment en quoi consiste cette
fameuse analyse spectrale. Et je commence a croire que je ne suis
pas le premier a ne pas le savoir. A vous entendre, c'est "l'étude de
la fréquence d'apparition des intructions." Mais heu, je suis sans
doute naif, mais je suppose que ce n'est pas des instructions
assembleur dont vous parlez, si ? Vous pourriez expliciter un peu ?
--
Tweakie
--
Posté via http://www.webatou.net/
Usenet dans votre navigateur !
Complaints-To: abuse@webatou.net
L'analyse heuristique, ce n'est pas la recheche d'une "instruction". Si et correspondant à des fonctions virales. L'analyseur recherchera du
code dont l'action est suspecte ou malveillante s'il vient à être exécuté par exemple.
Non. C'est ce qu'on se tue a vous dire. Il existe plusieurs types d'informations qui peuvent aider a conclure qu'un fichier a une nature virale. Prenons par exemple l'analyseur heuristique ecrit il y a quelque temps de ca par Nicolas Brulez (et qui, si j'ai bien suivi, va etre presente' prochainement aux SSTIC). Il y a deux ans, on pouvait lire, parmis les criteres utilises par l'analyse heuristique :
http://groups.google.com/groups?selmª4amo%2419j0%241%40norfair.nerim.net --- Entry Point does not start with a standard instruction. Suspicious JMP FAR found at Entry point+19.Might be some OEP obfuscation. Execution starts in last section. Suspicious section characteristics for last section. Suspicious difference between OEP RVA and Section RVA.OEP obfuscation? ---
Les trois derniers criteres ne correspondent pas du tout a votre definition : aucune recherche d'"instruction". Et pour les deux premiers, ce n'est pas l'instruction qui est suspecte, c'est le fait de la trouver la ou elle se trouve.
Autre exemple, messagelabs a depose' un brevet portant sur une de ses techniques d'analyse heuristique, dediee a la decouverte d'infecteurs de fichiers. J'ai tente' de le resumer dans ce fil : http://groups.google.com/groups?selm 040227014242.S81859%40areba.vasb J'avais tente' de le resumer ainsi : --- La portion de code de l'executable situee a proximite' du point d'entree est comparee avec une serie de templates. Chaque template correspondant au code normalement produit par un compilateur connu. Si le code analyse' ne correspond a aucun de ces templates, ou si du code correspondant a un template est effectivement trouve' mais qu'il n'est pas localise' au niveau du point d'entree, le code est classe' suspect et sera analyse' plus en profondeur ---
La, sont declarees suspectes toutes les instructions qui ne correspondent pas aux instructions standards.
Enfin, Norman (et ESET manifestement) font tourner les programmes malveillants dans une sorte de machine virtuelle, pour observer leur comportement. Ce qui fait aussi partie de l'analyse heuristique.
Notez aussi que les deux premieres techniques que 'ai evoquees ne sont applicables qu'aux infecteurs de fichiers. Pour distinguer un vers de messagerie ou un cheval de Troie, on ne peut pas travailler a si bas niveau : ces codes sont (la plupart du temps) issus de compilateurs tout a fait legitimes. Il faut donc imperativement emuler le code ou travailler a un autre niveau (quelle sont les fonctions importees ?).
L'analyse heuristique dans le contexte antiviral, c'est tout ce qui peut mener, mais ne mène pas forcément, à la découverte d'un virus. Et l'analyse spectrale en fait partie. Tout à fait.
..et cela *inclut* votre analyse spectrale. Ca ne "cohabite pas" avec.
Par contre, je ne sais toujours pas vraiment en quoi consiste cette fameuse analyse spectrale. Et je commence a croire que je ne suis pas le premier a ne pas le savoir. A vous entendre, c'est "l'étude de la fréquence d'apparition des intructions." Mais heu, je suis sans doute naif, mais je suppose que ce n'est pas des instructions assembleur dont vous parlez, si ? Vous pourriez expliciter un peu ?
-- Tweakie
-- Posté via http://www.webatou.net/ Usenet dans votre navigateur ! Complaints-To:
Nicob
On Tue, 18 May 2004 20:49:49 +0200, LaDDL wrote:
Une menace existe parce qu'il y a des vulnérabilités qui sont exploitées par des attaquants.
On va me reprocher de pinailler, mais je trouve cette définition du terme "menace" fort étrange ... Et une vulnérabilité privée, comme un 0-day sur IIS, Apache, ou OpenSSH, ce n'est pas une menace ?
Nicob
On Tue, 18 May 2004 20:49:49 +0200, LaDDL wrote:
Une menace existe parce qu'il y a des vulnérabilités qui sont exploitées
par des attaquants.
On va me reprocher de pinailler, mais je trouve cette définition du
terme "menace" fort étrange ... Et une vulnérabilité privée, comme un
0-day sur IIS, Apache, ou OpenSSH, ce n'est pas une menace ?
Une menace existe parce qu'il y a des vulnérabilités qui sont exploitées par des attaquants.
On va me reprocher de pinailler, mais je trouve cette définition du terme "menace" fort étrange ... Et une vulnérabilité privée, comme un 0-day sur IIS, Apache, ou OpenSSH, ce n'est pas une menace ?
Nicob
joke0
Salut,
LaDDL:
Loin d'être la majorité donc.
La majorité par rapport à qui, à quoi stp ?
Par rapport au nombre de chevaux de Troie qui existent.
Tu es sûr que tu m'as lu?
-- joke0
Salut,
LaDDL:
Loin d'être la majorité donc.
La majorité par rapport à qui, à quoi stp ?
Par rapport au nombre de chevaux de Troie qui existent.
