Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Comment créer un antivirus
Bonjour et merci pour avoir consacré du temps pour lire mon message.
Je cherche toute informations qui peut m'aider à créer un antivirus :
- Documentations.
- Langages de programmation apropriés.
- Méthodes.
- Cours.
Bref tous ce que vous savez sur ce sujet!
Encore merci et bonne navigation!
Bonjour,
Pour les langages utilisés pour programmer, on peut envisager :
- Un langage "très haut niveau" pour tout ce qui est GUI et interface avec l'utilisateur.
- Un (ou des) langages compilables en natif et performant en terme d'exécution (type C / C++) pour la couche métier.
- Dans de très rare cas, l'assembleur.
Pour la détection des virus, on scinde les diverses en actives (exécution d'un fichier) ou passives (simple recherche, sans exécution) :
- Comme le disait Gorgonite, le "scanning" qui consiste à analyser les fichiers de manières passive en cherchant des signatures contenue dans une BDD.
- Contrôle d'intégrité :
On passe les fichiers (notamment exécutables) dans un contrôleur d'intégrité, via une fonction de checksum / CRC / Hash. On compare le résultat avec une base faites à l'installation de l'antivirus. Si un fichier obtient un résultat différent, on peut le dors et déjà le soupçonner, sans pour autant tout de suite remonter un "faux positif".
- Analyse Heuristique : L'analyse heuristique est une démarche passive ou active suivant le cas.
Dans le cas passif on tente non pas de repérer un ou des patterns de signature mais des "constructions" qui peuvent être marquées comme suspectes. Meilleurs sont les heuristiques, meilleur est l'AV, la difficulté est de trouver les bonnes heuristiques... Un exemple pour être plus parlant : L'instruction assembleur LIDT permet de remplacer tout ou partie de l'IDT (table des interruptions) qui est une table maintenu par le Kernel permettant d'appeler des fonctions résidante du noyau. Tout programme utilisant LIDT doit être marqué comme suspect.
Dans le cas actif, on émule tout ou partie d'un code pour savoir ce qu'il fait. Le terme d'émulation est très important puisque le programme ou le code émuler ne doit en aucun produire un résultat réel. On regarde donc ce que fait le code émuler, et suivant un jeu de règles (les heuristiques) on détermine s'il y a matière à marqué le code ou le binaire suspect.
- Analyse comportementale (dite "behaviour blocking"):
On "hook" certaines fonctions système en bas niveau pour savoir qui fait quoi (écriture, lecture, connexion, etc.) : Pour simplifier on "monitor" le système entier.
Par exemple, un binaire qui se mettrait à ouvrir tous les fichiers exécutables pour y écrire quelque chose doit immédiatement être déclaré suspect voir tout de suite arrêté. Il y a certains jeux facilement applicables: ouverture de binaire + écriture ou ajout, lecture de certians champs du PE, etc.
Le problème ici est de définir un seuil entre un comportement normal et anormal. Arrêté en pleine course un programme "légal" est du plus mauvais effet.
- analyse spectrale : D'approche simple (c'est une technique de recherche en statique), on se contente de faire un histogramme des instructions assembleur utilisées et de dégagés celle qui sont potentiellement aberrante. Dans ce cas là on peut être face à un virus de type polymorphique.
C'est vraiment un tour très très rapide des possibilités. Certaines détectent des macro virus ou virus de script, des virus polymophiques ou même métamorphiques, il faut souvent combiner et ajouter d'autres techniques...
Certaines techniques ont des avantages et/ou des désavantages...
Tu trouvera beaucoup de docs chez les constructeurs d'AV. (par exemple Symantec n'est pas trop avare de ce coté là). Cherche avec des noms de chercheurs reconnus comme Peter Szor et consorts. Beaucoup d'entre eux ont écrit des livres.
Si tu es intéressé, va faire quelques tours dans les conventions autour de la sécurité informatique. On trouve du plus ou moins intéressant, de bonne interventions, et surtout on rencontre du monde avec qui papoter.
Ce qu'il faut c'est :
Une bonne très bonne connaissance du système (Kernel land et user-land) puisqu'il faut développer des drivers, être capable de naviguer dans l'espace kernel sans être perdu, etc.
Une très bonne connaissance d'un langage comme le C ou apparenté.
Une très bonne connaissance de l'assembleur.
De très solides connaissances en algo : data mining, neural networks, etc.
Et enfin : Ne pas être seul... Au vu des compétences requises, une seule personne ne peut tout faire.
Merci les amis, ça fait chaud au coeur de savoir qu'ils des gens qui partagent leurs savoires!
Alors moi, Unixien convaincu connaissant très peu de choses au monde Windows, j'ai une question toute simple : comment se fait-il qu'un programme puisse s'installer chez soi sans que l'on ne s'en rende compte ?
Je me souviens qu'à l'époqie où j'étais sous Windows, quand je navigais sur internet, je me choppais des virus de la mort, pourtant sans jamais rien installer ni télécharger. Souvent, les virus arrivaient dès que l'ordinateur se connectait au site de Wanadoo (mon fournisseur de l'époque).
Des spams ? je n'en n'avais pas. Comme je le dis, je ne téléchargeais rien, et j'allais quasiment toujours sur les mêmes sites, qui étaient au passage plus que de confiance et comportaient très peu, voire jamais, de "fioritures" (JavaScript et autres...).
J'ai du mal à voir, comment d'un point de vue programmation, on peut faire quelque chose qui s'installe automatiquement (parmis les fichiers système en plus !) !
Sous Linux (Mandriva, sans firewall) et Solaris 9, je n'ai aucun problème.
Coté internet et win, cela se joue sur le pare feu.
Et ensuite sous win les droits sur les fichiers ressemblent
plus à un désert par rapport à linux.
Ce sont ces droits qui font qu'un programme peut atteindre
ou non le système.
Hal,
Tu seras ok tant que les créateurs (sic !) de virus ne s'attaqueront pas à Linux mais ils le feront un jour, et tu seras moins tranquille.Envoyé par InOCamlWeTrust
Espérons que ce jour n'est pas trop proche
Répondre avec citation
Partager