AV et émulation du code: svp , explanations needed !
35 réponses
NickJrIII
Bonjour les pros !
j'ai une questio plutôt technique pour nos boss de la programmation
antiviral:
qu'est ce que "savoir émuler le code" ?
Je suis tombé un jour sur
et sur un contest entre Bogdanov/Daniloff (AVP/Dr.Web) sur l'art de
programmer et les erreurs de programmation de leur logiciel respectif
(fascinant,même pour le profane que je suis, étudiant en droit, c'est
dire si je m'y connais...;-) ).
Je comprend donc que certains AV ont un moteur mieux programmé,alors
doit-on en déduire que le must en matière de moteur serait Dr.Web, AVP
et NOD32 ?
Enfin, sur un tout autre sujet, j'ai cru comprendre que NOD32
bénéficie d'un des meilleurs moteurs heuristiques: reality checked ?
Merci de votre patience pour éclairer un béotien (bon j'exagère quand
même !).
Et j'ai plus de 20 ans d'ASM derrière moi... 12 ;)
Encore des efforts mon gars ;o).
Mais IHMO le choix de l'assembleur au moment de la conception d'un AV sera payant à l'arrivée.
Non. Ah bon ? Cela a été pourtant le choix d'ESET pour son AV et le
résultat est impressionnant. Vitesse d'exécution, faible consommation des ressources, par exemple.
Ne mélangeons pas tout. Qu'est-ce qui fait sa rapidité ? De nouveaux algorithmes ? Sa programmation ? Tu auras bien du mal à le savoir sans bosser chez eux. Ce n'est pas parce que c'est écrit en assembleur ou en machinchose que ce sera plus rapide. Tu sais, un programmeur nul, il fera du nul, que ce soit en ASM ou en JAVA hein ;o). De plus , aujourd'hui, avec les caches, les pipelines, la distribution, l'hyper-threading, etc., c'est très très difficile de comparer deux bouts de code.
Pour simplifier à l'extrême, l'écriture de virus c'est du hack système, la lutte c'est des mathématiques. Pas grand chose en commun... Raccourci simpliste mais amusant ;)
IHMO la démarche intellectuelle n'est pas la même.
Eh oui. Pour détruire un PC un coup de marteau suffit. Donc, un cerveau fonctionnant à son seuil le plus bas est simplement necéssaire. Pour le réparer, faut activer quelques neurones supplémentaires ;o). Bref, détruire c'est facile, créer, construire ou réparer, c'est autre chose...
-- AMcD
http://arnold.mcdonald.free.fr/ (still in fossilization progress but now in english, thus the whole world can see my laziness)
LaDDL wrote:
Et j'ai plus de 20 ans d'ASM derrière moi...
12 ;)
Encore des efforts mon gars ;o).
Mais IHMO le choix
de l'assembleur au moment de la conception d'un AV sera payant à
l'arrivée.
Non.
Ah bon ? Cela a été pourtant le choix d'ESET pour son AV et le
résultat
est impressionnant. Vitesse d'exécution, faible consommation des
ressources, par exemple.
Ne mélangeons pas tout. Qu'est-ce qui fait sa rapidité ? De nouveaux
algorithmes ? Sa programmation ? Tu auras bien du mal à le savoir sans
bosser chez eux. Ce n'est pas parce que c'est écrit en assembleur ou en
machinchose que ce sera plus rapide. Tu sais, un programmeur nul, il fera du
nul, que ce soit en ASM ou en JAVA hein ;o). De plus , aujourd'hui, avec les
caches, les pipelines, la distribution, l'hyper-threading, etc., c'est très
très difficile de comparer deux bouts de code.
Pour simplifier à l'extrême, l'écriture de virus c'est
du hack système, la lutte c'est des mathématiques. Pas grand chose en
commun...
Raccourci simpliste mais amusant ;)
IHMO la démarche intellectuelle n'est pas la même.
Eh oui. Pour détruire un PC un coup de marteau suffit. Donc, un cerveau
fonctionnant à son seuil le plus bas est simplement necéssaire. Pour le
réparer, faut activer quelques neurones supplémentaires ;o). Bref, détruire
c'est facile, créer, construire ou réparer, c'est autre chose...
--
AMcD
http://arnold.mcdonald.free.fr/
(still in fossilization progress but now in english, thus the whole
world can see my laziness)
Et j'ai plus de 20 ans d'ASM derrière moi... 12 ;)
Encore des efforts mon gars ;o).
Mais IHMO le choix de l'assembleur au moment de la conception d'un AV sera payant à l'arrivée.
Non. Ah bon ? Cela a été pourtant le choix d'ESET pour son AV et le
résultat est impressionnant. Vitesse d'exécution, faible consommation des ressources, par exemple.
Ne mélangeons pas tout. Qu'est-ce qui fait sa rapidité ? De nouveaux algorithmes ? Sa programmation ? Tu auras bien du mal à le savoir sans bosser chez eux. Ce n'est pas parce que c'est écrit en assembleur ou en machinchose que ce sera plus rapide. Tu sais, un programmeur nul, il fera du nul, que ce soit en ASM ou en JAVA hein ;o). De plus , aujourd'hui, avec les caches, les pipelines, la distribution, l'hyper-threading, etc., c'est très très difficile de comparer deux bouts de code.
Pour simplifier à l'extrême, l'écriture de virus c'est du hack système, la lutte c'est des mathématiques. Pas grand chose en commun... Raccourci simpliste mais amusant ;)
IHMO la démarche intellectuelle n'est pas la même.
Eh oui. Pour détruire un PC un coup de marteau suffit. Donc, un cerveau fonctionnant à son seuil le plus bas est simplement necéssaire. Pour le réparer, faut activer quelques neurones supplémentaires ;o). Bref, détruire c'est facile, créer, construire ou réparer, c'est autre chose...
-- AMcD
http://arnold.mcdonald.free.fr/ (still in fossilization progress but now in english, thus the whole world can see my laziness)
LaDDL
AMcD wrote:
Encore des efforts mon gars ;o). Ca va le faire ;)
[...]
Ne mélangeons pas tout. Qu'est-ce qui fait sa rapidité ? De nouveaux algorithmes ? Sa programmation ? Tu auras bien du mal à le savoir sans bosser chez eux. Je connais certains éditeurs (à l'est) dont eux ;)
Je n'avance jamais rien ss en être sûr.
[...]
Eh oui. Pour détruire un PC un coup de marteau suffit. Donc, un cerveau fonctionnant à son seuil le plus bas est simplement necéssaire. mdr
Pour le réparer, faut activer quelques neurones supplémentaires ;o). Bref, détruire c'est facile, créer, construire ou réparer, c'est autre chose... On est en phase ça va ;)
Ouf ! lol
AMcD wrote:
Encore des efforts mon gars ;o).
Ca va le faire ;)
[...]
Ne mélangeons pas tout. Qu'est-ce qui fait sa rapidité ? De nouveaux
algorithmes ? Sa programmation ? Tu auras bien du mal à le savoir sans
bosser chez eux.
Je connais certains éditeurs (à l'est) dont eux ;)
Je n'avance jamais rien ss en être sûr.
[...]
Eh oui. Pour détruire un PC un coup de marteau suffit. Donc, un cerveau
fonctionnant à son seuil le plus bas est simplement necéssaire.
mdr
Pour le réparer, faut activer quelques neurones supplémentaires ;o). Bref, détruire
c'est facile, créer, construire ou réparer, c'est autre chose...
On est en phase ça va ;)
Encore des efforts mon gars ;o). Ca va le faire ;)
[...]
Ne mélangeons pas tout. Qu'est-ce qui fait sa rapidité ? De nouveaux algorithmes ? Sa programmation ? Tu auras bien du mal à le savoir sans bosser chez eux. Je connais certains éditeurs (à l'est) dont eux ;)
Je n'avance jamais rien ss en être sûr.
[...]
Eh oui. Pour détruire un PC un coup de marteau suffit. Donc, un cerveau fonctionnant à son seuil le plus bas est simplement necéssaire. mdr
Pour le réparer, faut activer quelques neurones supplémentaires ;o). Bref, détruire c'est facile, créer, construire ou réparer, c'est autre chose... On est en phase ça va ;)
Ouf ! lol
Frederic Bonroy
"Arnold McDonald (AMcD)" wrote:
Ou des pas malins. L'ASM est à réserver à des cas très spécifiques, notamment lorsque tu recherche des optimisation de taille ou que certaines optimisations ne sont pas possibles autrement. Les compilateurs font du très bon boulot de nos jours, inutile de passer 15 heures sur une IHM en ASM si tu peux faire la même en 3 minutes avec un langage de haut niveau. Si tu n'y gagnes rien, c'est stupide, car la programmation ASM est beaucoup plus lourde à gérer. Et j'ai plus de 20 ans d'ASM derrière moi...
Généralement oui, on ne traduit pas tout en assembleur parce qu'on peut très bien se retrouver avec du code plus mauvais qu'avant. Ecrire des interfaces en assembleur c'est un peu ridicule, surtout sous Windows. Quand on examine la procédure de création d'une fenêtre, je ne vois vraiment pas où on pourrait optimiser quoi que ce soit.
Parce que tout simplemnt cette compétence ne sert à rien dans 99.9 % des applications qui sont codées aujourd'hui.
Oui. :-(
Pourquoi malheureusement ? Tu as quoi contre le C# ou le Visual C++ ?
Rien d'efficace. ;-)
Je n'ai jamais utilisé le C# mais il me semble que *tout* est un objet, même les variables int simplissimes. Ils charrient un peu là, c'est encore pire que Java.
"Arnold McDonald (AMcD)" wrote:
Ou des pas malins. L'ASM est à réserver à des cas très spécifiques,
notamment lorsque tu recherche des optimisation de taille ou que certaines
optimisations ne sont pas possibles autrement. Les compilateurs font du très
bon boulot de nos jours, inutile de passer 15 heures sur une IHM en ASM si
tu peux faire la même en 3 minutes avec un langage de haut niveau. Si tu n'y
gagnes rien, c'est stupide, car la programmation ASM est beaucoup plus
lourde à gérer. Et j'ai plus de 20 ans d'ASM derrière moi...
Généralement oui, on ne traduit pas tout en assembleur parce qu'on peut
très bien se retrouver avec du code plus mauvais qu'avant. Ecrire des
interfaces en assembleur c'est un peu ridicule, surtout sous Windows.
Quand on examine la procédure de création d'une fenêtre, je ne vois
vraiment pas où on pourrait optimiser quoi que ce soit.
Parce que tout simplemnt cette compétence ne sert à rien dans 99.9 % des
applications qui sont codées aujourd'hui.
Oui. :-(
Pourquoi malheureusement ? Tu as quoi contre le C# ou le Visual C++ ?
Rien d'efficace. ;-)
Je n'ai jamais utilisé le C# mais il me semble que *tout* est un objet,
même les variables int simplissimes. Ils charrient un peu là, c'est
encore pire que Java.
Ou des pas malins. L'ASM est à réserver à des cas très spécifiques, notamment lorsque tu recherche des optimisation de taille ou que certaines optimisations ne sont pas possibles autrement. Les compilateurs font du très bon boulot de nos jours, inutile de passer 15 heures sur une IHM en ASM si tu peux faire la même en 3 minutes avec un langage de haut niveau. Si tu n'y gagnes rien, c'est stupide, car la programmation ASM est beaucoup plus lourde à gérer. Et j'ai plus de 20 ans d'ASM derrière moi...
Généralement oui, on ne traduit pas tout en assembleur parce qu'on peut très bien se retrouver avec du code plus mauvais qu'avant. Ecrire des interfaces en assembleur c'est un peu ridicule, surtout sous Windows. Quand on examine la procédure de création d'une fenêtre, je ne vois vraiment pas où on pourrait optimiser quoi que ce soit.
Parce que tout simplemnt cette compétence ne sert à rien dans 99.9 % des applications qui sont codées aujourd'hui.
Oui. :-(
Pourquoi malheureusement ? Tu as quoi contre le C# ou le Visual C++ ?
Rien d'efficace. ;-)
Je n'ai jamais utilisé le C# mais il me semble que *tout* est un objet, même les variables int simplissimes. Ils charrient un peu là, c'est encore pire que Java.
LaDDL
Frederic Bonroy wrote:
Ce n'est pas uniquement une question d'assembleur ou pas assembleur. Eset a ses priorités, et ce sont les virus. Justement c'en fut une. Idem chez Dialogue Science et Kaspersky.
Après oui le quotidien de cet éditeur comme tous les autres c'est la lutte antivirale. Of course my dear ! ;)
Pour les chevaux de Troie ce n'est pas formidable. Ils ont fait des progrès dans ce domaine ;)
Frederic Bonroy wrote:
Ce n'est pas uniquement une question d'assembleur ou pas assembleur.
Eset a ses priorités, et ce sont les virus.
Justement c'en fut une. Idem chez Dialogue Science et Kaspersky.
Après oui le quotidien de cet éditeur comme tous les autres c'est la
lutte antivirale. Of course my dear ! ;)
Pour les chevaux de Troie ce n'est pas formidable.
Ils ont fait des progrès dans ce domaine ;)
Ce n'est pas uniquement une question d'assembleur ou pas assembleur. Eset a ses priorités, et ce sont les virus. Justement c'en fut une. Idem chez Dialogue Science et Kaspersky.
Après oui le quotidien de cet éditeur comme tous les autres c'est la lutte antivirale. Of course my dear ! ;)
Pour les chevaux de Troie ce n'est pas formidable. Ils ont fait des progrès dans ce domaine ;)
LaDDL
AMcD wrote:
Ha mais si tu as les code sources, tu as mon e-mail plus bas ;o). mdr
AMcD wrote:
Ha mais si tu as les code sources, tu as mon e-mail plus bas ;o).
mdr
