Voici les moments "forts" d'un test antivirus réalisé par Andreas Marx
(www.av-test.org) pour le compte du magazine allemand c't 3/04.
- Après avoir détecté un virus boot sous Windows 98, Panda s'est planté
et l'ordinateur a redémarré. Et vous savez tous ce qui se passé
lorsqu'un ordinateur démarre avec une disquette infectée dans le lecteur...
- Norman et eTrust sont les plus mauvais dans le catégorie chevaux de
Troie/backdoors avec moins de 50% de détection
- Les performances heuristiques de Nod32 et de eTrust avec moteur de
recherche VET sont particulièrement médiocres. Pour Eset c'est une
sacrée claque puisqu'ils s'en vantent régulièrement. Le test des moteurs
heuristiques a été réalisé comme suit:
- avec des bases de données vieilles de 3 et 6 mois et des virus récents
- avec des bases de données récentes et des virus créés spécialement
pour le test (CIH modifié, générateur de virus macro et VBS et les
générateurs Optix Pro et Assassin 2.0 (connais pas))
- un petit coup d'UPX et AVG, Command, eTrust, Nod32 et Sophos ne voient
plus les cochonneries qu'ils avaient détectées heuristiquement auparavant
- meilleurs résultats heuristiques: AVK, F-Secure, McAfee et Kaspersky
(toujours les mêmes quoi) ainsi que BitDefender et Panda.
- le fameux bac à sable de Norman n'est pas si merveilleux que ça
- les champions (à connotation négative) des fausses alertes:
AVG, McAfee et Nod32 :-/
- Panda ne crypte pas correctement ses définitions de virus, ce qui est
franchement incompréhensible depuis le temps que le problème est connu.
Ils sont têtus.
- les disquettes/CD de secours sont une immense catastrophe. Chez
F-Secure, Sophos et Nod32 il n'y en a pas du tout. Le CD de Norton a des
définitions de virus datant de 2001 (!) - on peut aussi créer un jeu de
9 (!) disquettes de secours - et la disquette de démarrage de McAfee
contient Dr. Solomon's Magic Bullet 8.04 avec des signatures datant des
années 2000/2001.
- Panda et McAfee sont automatiques et ne demandent pas de confirmation
avant de démolir un virus. Ils ne savent plus quoi inventer, j'vous le
dis...
"Frederic Bonroy" a écrit dans le message news: bv8i49$pl6bh$
Un floppy en moins c'est 100 balles de gagné sur chaque config PC.
Tiens? J'ai acheté un lecteur disquettes pour 12,50 il y a quelques années et il fonctionne toujours. 100 euros? Où c'est que vous achetez votre matériel?
parce que 100 balles... c'est 100 francs (français)
l'exception française... ça te dit quelque chose ???
un lecteur de disquette, c'est bien pratique (c'est même universel) et pas cher :-D
@tchao
"Frederic Bonroy" <bidonavirus@yahoo.fr> a écrit dans le message news:
bv8i49$pl6bh$1@ID-75150.news.uni-berlin.de
Un floppy en moins c'est 100 balles de gagné sur chaque config PC.
Tiens? J'ai acheté un lecteur disquettes pour 12,50 il y a quelques
années et il fonctionne toujours. 100 euros? Où c'est que vous achetez
votre matériel?
parce que 100 balles... c'est 100 francs (français)
l'exception française... ça te dit quelque chose ???
un lecteur de disquette, c'est bien pratique (c'est même universel) et pas
cher :-D
"Frederic Bonroy" a écrit dans le message news: bv8i49$pl6bh$
Un floppy en moins c'est 100 balles de gagné sur chaque config PC.
Tiens? J'ai acheté un lecteur disquettes pour 12,50 il y a quelques années et il fonctionne toujours. 100 euros? Où c'est que vous achetez votre matériel?
parce que 100 balles... c'est 100 francs (français)
l'exception française... ça te dit quelque chose ???
un lecteur de disquette, c'est bien pratique (c'est même universel) et pas cher :-D
@tchao
Jaja
Un floppy en moins c'est 100 balles de gagné sur chaque config PC.
Tiens? J'ai acheté un lecteur disquettes pour 12,50 il y a quelques années et il fonctionne toujours. 100 euros? Où c'est que vous achetez votre matériel?
100 balles, pas 100 eurs!
Un floppy en moins c'est 100 balles de gagné sur chaque config PC.
Tiens? J'ai acheté un lecteur disquettes pour 12,50 il y a quelques
années et il fonctionne toujours. 100 euros? Où c'est que vous achetez
votre matériel?
Un floppy en moins c'est 100 balles de gagné sur chaque config PC.
Tiens? J'ai acheté un lecteur disquettes pour 12,50 il y a quelques années et il fonctionne toujours. 100 euros? Où c'est que vous achetez votre matériel?
100 balles, pas 100 eurs!
ppc
Jaja wrote:
100 balles, pas 100 eurs!
Où est la différence entre x'eurs' et 100 balles ?
ppc
Jaja wrote:
100 balles, pas 100 eurs!
Où est la différence entre x'eurs' et 100 balles ?
On ne doit pas venir du même coin, chez nous les euros sont devenus des balles. ;-)
Ca m'etonerais!
Frederic Bonroy
Ouais. Cela me semble évident que ça n'a pas été écrit directement en ASM. La boucle de deRot13 est vraiment tordue ! [...]
Tiens, au lieu de t'acharner sur une boucle de décryptage ROT-13 essaie plutôt de me donner un coup de main. :-)
Une idée pour réaliser sous Windows 9x/ME l'équivalent de CreateFileMapping avec SEC_IMAGE (disponible sous NT/2000/XP seulement)?
Ma question n'est pas sans rapport avec les virus. En fait pour faire une analyse plus approfondie d'un fichier PE, notamment en matière d'émulation, il peut être utile d'avoir en mémoire son image "exécutable" (qui est généralement différente de son image sur disque à cause des alignements). Le problème sous Windows 9x c'est qu'il faut faire ça soi-même, du moins je ne connais pas d'autre solution. Veut dire: créer un file mapping "normal" pour avoir accès au fichier, réserver de la mémoire, décortiquer le PE et créer soi-même cette image exécutable.
Et là se pose le problème des RVA et de l'adresse de base. L'adresse de base est généralement 40000h. Seulement voilà, quand on réserve de la mémoire (pour y inscrire l'image exécutable que l'on va ensuite examiner par émulation), l'adresse de base de cette zone n'est logiquement pas à 40000h. Alors quand on a une image exécutable prévue pour 40000h à une autre adresse, les mov par exemple travaillent avec des adresses complètement fausses. J'ai fait l'essai avec un simple PE prévu pour 40000h. J'ai modifié le champ de l'adresse de base (j'ai mis 70000h) avec un éditeur hexadécimal et évidemment le programme plantait lorsqu'une instruction tentait d'accéder à 42000h (qui était une variable dans la séction de données). Lors de l'émulation on pourrait, à chaque instruction accédant à la mémoire, déterminer son adresse virtuelle relative et à partir de cela calculer sa vraie adresse virtuelle mais ce serait compliqué et lent.
Je débute un peu avec les PE, ça se trouve j'ai négligé quelque chose de fondamental. Remarque, j'ai Windows 2000 là, donc pour commencer je pourrai utiliser SEC_IMAGE et faire des tests sous Windows 2000. Mais je préférerais un truc qui fonctionne sur tous les systèmes.
Ouais. Cela me semble évident que ça n'a pas été écrit directement en ASM.
La boucle de deRot13 est vraiment tordue !
[...]
Tiens, au lieu de t'acharner sur une boucle de décryptage ROT-13 essaie
plutôt de me donner un coup de main. :-)
Une idée pour réaliser sous Windows 9x/ME l'équivalent de
CreateFileMapping avec SEC_IMAGE (disponible sous NT/2000/XP seulement)?
Ma question n'est pas sans rapport avec les virus. En fait pour faire
une analyse plus approfondie d'un fichier PE, notamment en matière
d'émulation, il peut être utile d'avoir en mémoire son image
"exécutable" (qui est généralement différente de son image sur disque à
cause des alignements).
Le problème sous Windows 9x c'est qu'il faut faire ça soi-même, du moins
je ne connais pas d'autre solution. Veut dire: créer un file mapping
"normal" pour avoir accès au fichier, réserver de la mémoire,
décortiquer le PE et créer soi-même cette image exécutable.
Et là se pose le problème des RVA et de l'adresse de base. L'adresse de
base est généralement 40000h. Seulement voilà, quand on réserve de la
mémoire (pour y inscrire l'image exécutable que l'on va ensuite examiner
par émulation), l'adresse de base de cette zone n'est logiquement pas à
40000h. Alors quand on a une image exécutable prévue pour 40000h à une
autre adresse, les mov par exemple travaillent avec des adresses
complètement fausses.
J'ai fait l'essai avec un simple PE prévu pour 40000h. J'ai modifié le
champ de l'adresse de base (j'ai mis 70000h) avec un éditeur hexadécimal
et évidemment le programme plantait lorsqu'une instruction tentait
d'accéder à 42000h (qui était une variable dans la séction de données).
Lors de l'émulation on pourrait, à chaque instruction accédant à la
mémoire, déterminer son adresse virtuelle relative et à partir de cela
calculer sa vraie adresse virtuelle mais ce serait compliqué et lent.
Je débute un peu avec les PE, ça se trouve j'ai négligé quelque chose de
fondamental.
Remarque, j'ai Windows 2000 là, donc pour commencer je pourrai utiliser
SEC_IMAGE et faire des tests sous Windows 2000. Mais je préférerais un
truc qui fonctionne sur tous les systèmes.
Ouais. Cela me semble évident que ça n'a pas été écrit directement en ASM. La boucle de deRot13 est vraiment tordue ! [...]
Tiens, au lieu de t'acharner sur une boucle de décryptage ROT-13 essaie plutôt de me donner un coup de main. :-)
Une idée pour réaliser sous Windows 9x/ME l'équivalent de CreateFileMapping avec SEC_IMAGE (disponible sous NT/2000/XP seulement)?
Ma question n'est pas sans rapport avec les virus. En fait pour faire une analyse plus approfondie d'un fichier PE, notamment en matière d'émulation, il peut être utile d'avoir en mémoire son image "exécutable" (qui est généralement différente de son image sur disque à cause des alignements). Le problème sous Windows 9x c'est qu'il faut faire ça soi-même, du moins je ne connais pas d'autre solution. Veut dire: créer un file mapping "normal" pour avoir accès au fichier, réserver de la mémoire, décortiquer le PE et créer soi-même cette image exécutable.
Et là se pose le problème des RVA et de l'adresse de base. L'adresse de base est généralement 40000h. Seulement voilà, quand on réserve de la mémoire (pour y inscrire l'image exécutable que l'on va ensuite examiner par émulation), l'adresse de base de cette zone n'est logiquement pas à 40000h. Alors quand on a une image exécutable prévue pour 40000h à une autre adresse, les mov par exemple travaillent avec des adresses complètement fausses. J'ai fait l'essai avec un simple PE prévu pour 40000h. J'ai modifié le champ de l'adresse de base (j'ai mis 70000h) avec un éditeur hexadécimal et évidemment le programme plantait lorsqu'une instruction tentait d'accéder à 42000h (qui était une variable dans la séction de données). Lors de l'émulation on pourrait, à chaque instruction accédant à la mémoire, déterminer son adresse virtuelle relative et à partir de cela calculer sa vraie adresse virtuelle mais ce serait compliqué et lent.
Je débute un peu avec les PE, ça se trouve j'ai négligé quelque chose de fondamental. Remarque, j'ai Windows 2000 là, donc pour commencer je pourrai utiliser SEC_IMAGE et faire des tests sous Windows 2000. Mais je préférerais un truc qui fonctionne sur tous les systèmes.
Jaja
"Frederic Bonroy" a écrit dans le message news: bv8mg2$pj0ao$
100 balles, pas 100 eurs!
On ne doit pas venir du même coin, chez nous les euros sont devenus des balles. ;-)
ben ouais, chez nous il y a encore des gens qui comptent... en anciens francs 8-)
C'est mon cas :-) Si > 10000 francs = 1 million
"Frederic Bonroy" <bidonavirus@yahoo.fr> a écrit dans le message news:
bv8mg2$pj0ao$1@ID-75150.news.uni-berlin.de
100 balles, pas 100 eurs!
On ne doit pas venir du même coin, chez nous les euros sont devenus
des balles. ;-)
ben ouais, chez nous il y a encore des gens qui comptent... en anciens
francs 8-)
