Vous pouvez télécharger ici:
http://www.antivir.de/download/download.htm
(au bas de la page) une version beta et ligne de commande d'AntiVir avec
détection heuristique.
Elle s'appelle "AntiVir LEXA (heuristical spectral analyser)".
Attention, ça fonctionne uniquement sous NT/2000/XP.
Tapez
avnt chemin -v -s -allfiles -heuristics
J'ai été très surpris par ses performances, notamment dans les cas suivants:
Ya aussi le patch du code qui fait un stackframe dans une fonction du programme.. pour le rediriger vers le corps du virus :)
Definitively kickass ! Quoique certainement chaud à implémenter... Je n'y aurai pas pensé à celle-là ! Quand-est-ce qu'on aura fini d'inventer des techniques avec cette bonne vieille pile :o) ?
Je sais pas si ce que je décris a été implémenté dans les virus sorties. Je sais que Benny avait fait ca dans les fins de fonctions lui. Lors que je testais mon moteur heuristique j'avais fait des essais sur les méthodes EPO, et ca marchait pas mal le patch du stack frame ;-)
Quoique, si j'ai bien compris, avec l'itanium ce genre de sport sera fini...
Je ne sais pas trop ce qu'ils vont apporter. Tu as compris qu'ils vont modifier quoi ? :)
Enfin toutes ses techniques d'EPO ca donne pas mal d'idées pour faires des Packers d'exécutables PE assez sympas. L' application completement dépendante du Packer. Ca me donne des idées de protections à tester en faite.
-- Nicolas Brulez
Chief of Security The Armadillo Software Protection System http://www.siliconrealms.com/armadillo.shtml
AMcD® wrote:
Nicolas Brulez wrote:
Ya aussi le patch du code qui fait un stackframe dans une fonction du
programme.. pour le rediriger vers le corps du virus :)
Definitively kickass ! Quoique certainement chaud à implémenter... Je n'y
aurai pas pensé à celle-là ! Quand-est-ce qu'on aura fini d'inventer des
techniques avec cette bonne vieille pile :o) ?
Je sais pas si ce que je décris a été implémenté dans les virus sorties.
Je sais que Benny avait fait ca dans les fins de fonctions lui.
Lors que je testais mon moteur heuristique j'avais fait des essais sur
les méthodes EPO, et ca marchait pas mal le patch du stack frame ;-)
Quoique, si j'ai bien compris, avec l'itanium ce genre de sport sera fini...
Je ne sais pas trop ce qu'ils vont apporter. Tu as compris qu'ils vont
modifier quoi ? :)
Enfin toutes ses techniques d'EPO ca donne pas mal d'idées pour faires
des Packers d'exécutables PE assez sympas. L' application completement
dépendante du Packer. Ca me donne des idées de protections à tester en
faite.
--
Nicolas Brulez
Chief of Security
The Armadillo Software Protection System
http://www.siliconrealms.com/armadillo.shtml
Ya aussi le patch du code qui fait un stackframe dans une fonction du programme.. pour le rediriger vers le corps du virus :)
Definitively kickass ! Quoique certainement chaud à implémenter... Je n'y aurai pas pensé à celle-là ! Quand-est-ce qu'on aura fini d'inventer des techniques avec cette bonne vieille pile :o) ?
Je sais pas si ce que je décris a été implémenté dans les virus sorties. Je sais que Benny avait fait ca dans les fins de fonctions lui. Lors que je testais mon moteur heuristique j'avais fait des essais sur les méthodes EPO, et ca marchait pas mal le patch du stack frame ;-)
Quoique, si j'ai bien compris, avec l'itanium ce genre de sport sera fini...
Je ne sais pas trop ce qu'ils vont apporter. Tu as compris qu'ils vont modifier quoi ? :)
Enfin toutes ses techniques d'EPO ca donne pas mal d'idées pour faires des Packers d'exécutables PE assez sympas. L' application completement dépendante du Packer. Ca me donne des idées de protections à tester en faite.
-- Nicolas Brulez
Chief of Security The Armadillo Software Protection System http://www.siliconrealms.com/armadillo.shtml
Frederic Bonroy
Nicolas Brulez wrote:
Enfin toutes ses techniques d'EPO ca donne pas mal d'idées pour faires des Packers d'exécutables PE assez sympas. L' application completement dépendante du Packer. Ca me donne des idées de protections à tester en faite.
J'ai pensé à un truc absurde hier: un programme qui s'émule lui-même.
D'accord, c'est sans rapport avec les virus, mais avoue qu'il fallait y penser. :-D
Nicolas Brulez wrote:
Enfin toutes ses techniques d'EPO ca donne pas mal d'idées pour faires
des Packers d'exécutables PE assez sympas. L' application completement
dépendante du Packer. Ca me donne des idées de protections à tester en
faite.
J'ai pensé à un truc absurde hier: un programme qui s'émule lui-même.
D'accord, c'est sans rapport avec les virus, mais avoue qu'il fallait y
penser. :-D
Enfin toutes ses techniques d'EPO ca donne pas mal d'idées pour faires des Packers d'exécutables PE assez sympas. L' application completement dépendante du Packer. Ca me donne des idées de protections à tester en faite.
J'ai pensé à un truc absurde hier: un programme qui s'émule lui-même.
D'accord, c'est sans rapport avec les virus, mais avoue qu'il fallait y penser. :-D
Nicolas Brulez
J'ai pensé à un truc absurde hier: un programme qui s'émule lui-même. D'accord, c'est sans rapport avec les virus, mais avoue qu'il fallait y penser. :-D
:-) Selon la taille du programme, prévoir beaucoup de café ;-)
-- Nicolas Brulez
Chief of Security The Armadillo Software Protection System http://www.siliconrealms.com/armadillo.shtml
J'ai pensé à un truc absurde hier: un programme qui s'émule lui-même.
D'accord, c'est sans rapport avec les virus, mais avoue qu'il fallait y
penser. :-D
:-)
Selon la taille du programme, prévoir beaucoup de café ;-)
--
Nicolas Brulez
Chief of Security
The Armadillo Software Protection System
http://www.siliconrealms.com/armadillo.shtml
J'ai pensé à un truc absurde hier: un programme qui s'émule lui-même. D'accord, c'est sans rapport avec les virus, mais avoue qu'il fallait y penser. :-D
:-) Selon la taille du programme, prévoir beaucoup de café ;-)
-- Nicolas Brulez
Chief of Security The Armadillo Software Protection System http://www.siliconrealms.com/armadillo.shtml
Nicolas Brulez
(Mon truc à moi prend à peu près une demi-seconde pour émuler ça sur un processeur 1 GHz.)
Il est en ou ton truc au fait? :) Il émule quoi exactement maintenant ?
Tu utilises le désassembleur d'olly que tu as recompilé sous la forme d'une dll ou autre pour le désassemblage?
-- Nicolas Brulez
Chief of Security The Armadillo Software Protection System http://www.siliconrealms.com/armadillo.shtml
(Mon truc à moi prend à peu près une demi-seconde pour émuler ça sur un
processeur 1 GHz.)
Il est en ou ton truc au fait? :)
Il émule quoi exactement maintenant ?
Tu utilises le désassembleur d'olly que tu as recompilé sous la forme
d'une dll ou autre pour le désassemblage?
--
Nicolas Brulez
Chief of Security
The Armadillo Software Protection System
http://www.siliconrealms.com/armadillo.shtml
(Mon truc à moi prend à peu près une demi-seconde pour émuler ça sur un processeur 1 GHz.)
Il est en ou ton truc au fait? :) Il émule quoi exactement maintenant ?
Tu utilises le désassembleur d'olly que tu as recompilé sous la forme d'une dll ou autre pour le désassemblage?
-- Nicolas Brulez
Chief of Security The Armadillo Software Protection System http://www.siliconrealms.com/armadillo.shtml
Frederic Bonroy
Nicolas Brulez wrote:
(Mon truc à moi prend à peu près une demi-seconde pour émuler ça sur un processeur 1 GHz.)
Il est en ou ton truc au fait? :) Il émule quoi exactement maintenant ?
En fait j'ai perdu beaucoup de temps avec la routine de chargement PE. Ça m'a coûté plusieurs jours et j'en avais franchement marre. Mais maintenant ça y est, je charge moi même avec ReadFile car je me suis aperçu que le format PE fournissait toutes les informations nécessaires. Ainsi ça marche sur tous les systèmes et je contourne les contraintes liées à MapAndLoad ou CreateFileMapping. Et j'aligne les sections à 4096 octets en mémoire donc la conversion des RVA et même des VA est très facile et rapide. Maintenant j'attaque modr/m et SIB.
Tu utilises le désassembleur d'olly que tu as recompilé sous la forme d'une dll ou autre pour le désassemblage?
Non, je désassemble moi-même. J'avais pensé à utiliser une bibliothèque mais je n'aime pas utiliser des choses toutes prêtes. J'aime bien savoir ce qui se passe derrière les coulisses. :-)
En ce moment il manque plus que le xor et l'émulation de la boucle de Kenston est complète. C'est le plus difficile à cause justement du modr/m et SIB. Mais une fois que ce sera fait, l'ajout des autres instructions (de Poson par exemple) devrait aller très vite.
Nicolas Brulez wrote:
(Mon truc à moi prend à peu près une demi-seconde pour émuler ça sur un
processeur 1 GHz.)
Il est en ou ton truc au fait? :)
Il émule quoi exactement maintenant ?
En fait j'ai perdu beaucoup de temps avec la routine de chargement PE.
Ça m'a coûté plusieurs jours et j'en avais franchement marre. Mais
maintenant ça y est, je charge moi même avec ReadFile car je me suis
aperçu que le format PE fournissait toutes les informations nécessaires.
Ainsi ça marche sur tous les systèmes et je contourne les contraintes
liées à MapAndLoad ou CreateFileMapping. Et j'aligne les sections à 4096
octets en mémoire donc la conversion des RVA et même des VA est très
facile et rapide.
Maintenant j'attaque modr/m et SIB.
Tu utilises le désassembleur d'olly que tu as recompilé sous la forme
d'une dll ou autre pour le désassemblage?
Non, je désassemble moi-même. J'avais pensé à utiliser une bibliothèque
mais je n'aime pas utiliser des choses toutes prêtes. J'aime bien savoir
ce qui se passe derrière les coulisses. :-)
En ce moment il manque plus que le xor et l'émulation de la boucle de
Kenston est complète. C'est le plus difficile à cause justement du
modr/m et SIB. Mais une fois que ce sera fait, l'ajout des autres
instructions (de Poson par exemple) devrait aller très vite.
(Mon truc à moi prend à peu près une demi-seconde pour émuler ça sur un processeur 1 GHz.)
Il est en ou ton truc au fait? :) Il émule quoi exactement maintenant ?
En fait j'ai perdu beaucoup de temps avec la routine de chargement PE. Ça m'a coûté plusieurs jours et j'en avais franchement marre. Mais maintenant ça y est, je charge moi même avec ReadFile car je me suis aperçu que le format PE fournissait toutes les informations nécessaires. Ainsi ça marche sur tous les systèmes et je contourne les contraintes liées à MapAndLoad ou CreateFileMapping. Et j'aligne les sections à 4096 octets en mémoire donc la conversion des RVA et même des VA est très facile et rapide. Maintenant j'attaque modr/m et SIB.
Tu utilises le désassembleur d'olly que tu as recompilé sous la forme d'une dll ou autre pour le désassemblage?
Non, je désassemble moi-même. J'avais pensé à utiliser une bibliothèque mais je n'aime pas utiliser des choses toutes prêtes. J'aime bien savoir ce qui se passe derrière les coulisses. :-)
En ce moment il manque plus que le xor et l'émulation de la boucle de Kenston est complète. C'est le plus difficile à cause justement du modr/m et SIB. Mais une fois que ce sera fait, l'ajout des autres instructions (de Poson par exemple) devrait aller très vite.
Nicolas Brulez
En fait j'ai perdu beaucoup de temps avec la routine de chargement PE. Ça m'a coûté plusieurs jours et j'en avais franchement marre. Mais maintenant ça y est, je charge moi même avec ReadFile car je me suis aperçu que le format PE fournissait toutes les informations nécessaires. Ainsi ça marche sur tous les systèmes et je contourne les contraintes liées à MapAndLoad ou CreateFileMapping. Et j'aligne les sections à 4096 octets en mémoire donc la conversion des RVA et même des VA est très facile et rapide.
Ah ok :) Bien. Tu programmes tout ca en assembleur ?
Maintenant j'attaque modr/m et SIB. Ah oui, tu utilises les noms techniques et tout ;-)
C'est la partie de ton désassembleur ca non ?
Non, je désassemble moi-même. J'avais pensé à utiliser une bibliothèque mais je n'aime pas utiliser des choses toutes prêtes. J'aime bien savoir ce qui se passe derrière les coulisses. :-)
Vi je vois ce que tu veux dire, enfin quand j'ai commencé mon moteur, j'ai utilisé la lib d'un ami, car je sais comment marche un désassembleur, je préfèrai m'attaquer directement à la partie amusante :)
En ce moment il manque plus que le xor et l'émulation de la boucle de Kenston est complète. C'est le plus difficile à cause justement du modr/m et SIB. Mais une fois que ce sera fait, l'ajout des autres instructions (de Poson par exemple) devrait aller très vite.
Oui. Comment géres tu les boucles de décryptage? Dans le sens. tu alloues de la mémoire pour y placer le corps crypté du virus ? Ou alors tu n'as pas encore fait cette partie, puisque tu n'émules pas le XOR encore.
-- Nicolas Brulez
Chief of Security The Armadillo Software Protection System http://www.siliconrealms.com/armadillo.shtml
En fait j'ai perdu beaucoup de temps avec la routine de chargement PE.
Ça m'a coûté plusieurs jours et j'en avais franchement marre. Mais
maintenant ça y est, je charge moi même avec ReadFile car je me suis
aperçu que le format PE fournissait toutes les informations nécessaires.
Ainsi ça marche sur tous les systèmes et je contourne les contraintes
liées à MapAndLoad ou CreateFileMapping. Et j'aligne les sections à 4096
octets en mémoire donc la conversion des RVA et même des VA est très
facile et rapide.
Ah ok :) Bien.
Tu programmes tout ca en assembleur ?
Maintenant j'attaque modr/m et SIB.
Ah oui, tu utilises les noms techniques et tout ;-)
C'est la partie de ton désassembleur ca non ?
Non, je désassemble moi-même. J'avais pensé à utiliser une bibliothèque
mais je n'aime pas utiliser des choses toutes prêtes. J'aime bien savoir
ce qui se passe derrière les coulisses. :-)
Vi je vois ce que tu veux dire, enfin quand j'ai commencé mon moteur,
j'ai utilisé la lib d'un ami, car je sais comment marche un
désassembleur, je préfèrai m'attaquer directement à la partie amusante :)
En ce moment il manque plus que le xor et l'émulation de la boucle de
Kenston est complète. C'est le plus difficile à cause justement du
modr/m et SIB. Mais une fois que ce sera fait, l'ajout des autres
instructions (de Poson par exemple) devrait aller très vite.
Oui.
Comment géres tu les boucles de décryptage?
Dans le sens. tu alloues de la mémoire pour y placer le corps crypté du
virus ? Ou alors tu n'as pas encore fait cette partie, puisque tu
n'émules pas le XOR encore.
--
Nicolas Brulez
Chief of Security
The Armadillo Software Protection System
http://www.siliconrealms.com/armadillo.shtml
En fait j'ai perdu beaucoup de temps avec la routine de chargement PE. Ça m'a coûté plusieurs jours et j'en avais franchement marre. Mais maintenant ça y est, je charge moi même avec ReadFile car je me suis aperçu que le format PE fournissait toutes les informations nécessaires. Ainsi ça marche sur tous les systèmes et je contourne les contraintes liées à MapAndLoad ou CreateFileMapping. Et j'aligne les sections à 4096 octets en mémoire donc la conversion des RVA et même des VA est très facile et rapide.
Ah ok :) Bien. Tu programmes tout ca en assembleur ?
Maintenant j'attaque modr/m et SIB. Ah oui, tu utilises les noms techniques et tout ;-)
C'est la partie de ton désassembleur ca non ?
Non, je désassemble moi-même. J'avais pensé à utiliser une bibliothèque mais je n'aime pas utiliser des choses toutes prêtes. J'aime bien savoir ce qui se passe derrière les coulisses. :-)
Vi je vois ce que tu veux dire, enfin quand j'ai commencé mon moteur, j'ai utilisé la lib d'un ami, car je sais comment marche un désassembleur, je préfèrai m'attaquer directement à la partie amusante :)
En ce moment il manque plus que le xor et l'émulation de la boucle de Kenston est complète. C'est le plus difficile à cause justement du modr/m et SIB. Mais une fois que ce sera fait, l'ajout des autres instructions (de Poson par exemple) devrait aller très vite.
Oui. Comment géres tu les boucles de décryptage? Dans le sens. tu alloues de la mémoire pour y placer le corps crypté du virus ? Ou alors tu n'as pas encore fait cette partie, puisque tu n'émules pas le XOR encore.
-- Nicolas Brulez
Chief of Security The Armadillo Software Protection System http://www.siliconrealms.com/armadillo.shtml
Frederic Bonroy
Nicolas Brulez wrote:
Tu programmes tout ca en assembleur ?
Oui. J'avais pensé aussi éventuellement à créer un "squelette" avec Delphi et d'y insérer les routines en assembleur. Ça m'aurait aussi permis de laisser Delphi s'occuper des trucs désagréables comme l'évaluation des paramètres de la ligne de commande. Mais après je me suis dit que je vais tout faire en assembleur parce que Delphi produit des programmes énormes, et puis ça me fait de l'entraînement.
Maintenant j'attaque modr/m et SIB. Ah oui, tu utilises les noms techniques et tout ;-)
C'est la partie de ton désassembleur ca non ?
Oui. Pour les noms techniques, je ne vois pas comment on aurait pu le formuler différemment. :-)
Vi je vois ce que tu veux dire, enfin quand j'ai commencé mon moteur, j'ai utilisé la lib d'un ami, car je sais comment marche un désassembleur, je préfèrai m'attaquer directement à la partie amusante :)
Ça dépend ce que l'on entend par la partie amusante. ;-)
Oui. Comment géres tu les boucles de décryptage? Dans le sens. tu alloues de la mémoire pour y placer le corps crypté du virus ? Ou alors tu n'as pas encore fait cette partie, puisque tu n'émules pas le XOR encore.
En fait il y a un lien avec la manière dont on charge le fichier PE. Si j'utilise MapAndLoad ou CreateFileMapping, alors toutes les modifications que l'émulateur apporte à l'image seront ensuite écrites dans le fichier dès que j'appelle UnMapAndLoad et UnMapViewOfFile. Du moins je n'ai pas trouvé de moyen d'éviter cela, même en trichant. On se serait alors retrouvé avec un fichier modifié contenant le virus décrypté. Ce n'est pas le but du jeu. Pour éviter cela, j'aurais pu réserver de la mémoire et rediriger les accès en écriture vers cette zone mémoire. Seulement à chaque accès en lecture j'aurais dû également vérifier si l'adresse à lire se trouve dans cette zone mémoire ou pas. Bref, j'aurais dû élaborer un genre de mécanisme de cache. Je me suis dit que ce serait trop compliqué et que ça ralentirait donc une émulation déjà lente d'avance. Par contre il est vrai que ça aurait pu servir pour avoir un aperçu des zones mémoire modifiées par le programme/virus et celles qu'il n'a pas touchées. Et il aurait théoriquement suffi de rechercher la "signature" du virus dans cette zone mémoire. Maintenant ce que je fais, c'est que je laisse le virus modifier sa propre image en mémoire. C'est plus simple pour moi, plus rapide, et plus proche de la réalité.
Nicolas Brulez wrote:
Tu programmes tout ca en assembleur ?
Oui. J'avais pensé aussi éventuellement à créer un "squelette" avec
Delphi et d'y insérer les routines en assembleur. Ça m'aurait aussi
permis de laisser Delphi s'occuper des trucs désagréables comme
l'évaluation des paramètres de la ligne de commande. Mais après je me
suis dit que je vais tout faire en assembleur parce que Delphi produit
des programmes énormes, et puis ça me fait de l'entraînement.
Maintenant j'attaque modr/m et SIB.
Ah oui, tu utilises les noms techniques et tout ;-)
C'est la partie de ton désassembleur ca non ?
Oui. Pour les noms techniques, je ne vois pas comment on aurait pu le
formuler différemment. :-)
Vi je vois ce que tu veux dire, enfin quand j'ai commencé mon moteur,
j'ai utilisé la lib d'un ami, car je sais comment marche un
désassembleur, je préfèrai m'attaquer directement à la partie amusante :)
Ça dépend ce que l'on entend par la partie amusante. ;-)
Oui.
Comment géres tu les boucles de décryptage?
Dans le sens. tu alloues de la mémoire pour y placer le corps crypté du
virus ? Ou alors tu n'as pas encore fait cette partie, puisque tu
n'émules pas le XOR encore.
En fait il y a un lien avec la manière dont on charge le fichier PE. Si
j'utilise MapAndLoad ou CreateFileMapping, alors toutes les
modifications que l'émulateur apporte à l'image seront ensuite écrites
dans le fichier dès que j'appelle UnMapAndLoad et UnMapViewOfFile. Du
moins je n'ai pas trouvé de moyen d'éviter cela, même en trichant. On se
serait alors retrouvé avec un fichier modifié contenant le virus
décrypté. Ce n'est pas le but du jeu.
Pour éviter cela, j'aurais pu réserver de la mémoire et rediriger les
accès en écriture vers cette zone mémoire. Seulement à chaque accès en
lecture j'aurais dû également vérifier si l'adresse à lire se trouve
dans cette zone mémoire ou pas. Bref, j'aurais dû élaborer un genre de
mécanisme de cache. Je me suis dit que ce serait trop compliqué et que
ça ralentirait donc une émulation déjà lente d'avance. Par contre il est
vrai que ça aurait pu servir pour avoir un aperçu des zones mémoire
modifiées par le programme/virus et celles qu'il n'a pas touchées. Et il
aurait théoriquement suffi de rechercher la "signature" du virus dans
cette zone mémoire.
Maintenant ce que je fais, c'est que je laisse le virus modifier sa
propre image en mémoire. C'est plus simple pour moi, plus rapide, et
plus proche de la réalité.
Oui. J'avais pensé aussi éventuellement à créer un "squelette" avec Delphi et d'y insérer les routines en assembleur. Ça m'aurait aussi permis de laisser Delphi s'occuper des trucs désagréables comme l'évaluation des paramètres de la ligne de commande. Mais après je me suis dit que je vais tout faire en assembleur parce que Delphi produit des programmes énormes, et puis ça me fait de l'entraînement.
Maintenant j'attaque modr/m et SIB. Ah oui, tu utilises les noms techniques et tout ;-)
C'est la partie de ton désassembleur ca non ?
Oui. Pour les noms techniques, je ne vois pas comment on aurait pu le formuler différemment. :-)
Vi je vois ce que tu veux dire, enfin quand j'ai commencé mon moteur, j'ai utilisé la lib d'un ami, car je sais comment marche un désassembleur, je préfèrai m'attaquer directement à la partie amusante :)
Ça dépend ce que l'on entend par la partie amusante. ;-)
Oui. Comment géres tu les boucles de décryptage? Dans le sens. tu alloues de la mémoire pour y placer le corps crypté du virus ? Ou alors tu n'as pas encore fait cette partie, puisque tu n'émules pas le XOR encore.
En fait il y a un lien avec la manière dont on charge le fichier PE. Si j'utilise MapAndLoad ou CreateFileMapping, alors toutes les modifications que l'émulateur apporte à l'image seront ensuite écrites dans le fichier dès que j'appelle UnMapAndLoad et UnMapViewOfFile. Du moins je n'ai pas trouvé de moyen d'éviter cela, même en trichant. On se serait alors retrouvé avec un fichier modifié contenant le virus décrypté. Ce n'est pas le but du jeu. Pour éviter cela, j'aurais pu réserver de la mémoire et rediriger les accès en écriture vers cette zone mémoire. Seulement à chaque accès en lecture j'aurais dû également vérifier si l'adresse à lire se trouve dans cette zone mémoire ou pas. Bref, j'aurais dû élaborer un genre de mécanisme de cache. Je me suis dit que ce serait trop compliqué et que ça ralentirait donc une émulation déjà lente d'avance. Par contre il est vrai que ça aurait pu servir pour avoir un aperçu des zones mémoire modifiées par le programme/virus et celles qu'il n'a pas touchées. Et il aurait théoriquement suffi de rechercher la "signature" du virus dans cette zone mémoire. Maintenant ce que je fais, c'est que je laisse le virus modifier sa propre image en mémoire. C'est plus simple pour moi, plus rapide, et plus proche de la réalité.
Frederic Bonroy
Nicolas Brulez wrote:
Ou alors tu n'as pas encore fait cette partie, puisque tu n'émules pas le XOR encore.
Maitenant si! L'émulation de la boucle fonctionne, je l'ai testé sur un échantillon de Kenston. Théoriquement maintenant il suffirait que je fasse encore une recherche de signature pour identifier formellement Kenston et le tour serait joué.
Je ne me fais pas encore d'illusions pour autant, je peux toujours échouer plus tard, notamment quand il s'agira d'incorporer d'autres instructions, celles de Poson par exemple. ;-)
Nicolas Brulez wrote:
Ou alors tu n'as pas encore fait cette partie, puisque tu
n'émules pas le XOR encore.
Maitenant si! L'émulation de la boucle fonctionne, je l'ai testé sur un
échantillon de Kenston. Théoriquement maintenant il suffirait que je
fasse encore une recherche de signature pour identifier formellement
Kenston et le tour serait joué.
Je ne me fais pas encore d'illusions pour autant, je peux toujours
échouer plus tard, notamment quand il s'agira d'incorporer d'autres
instructions, celles de Poson par exemple. ;-)
Ou alors tu n'as pas encore fait cette partie, puisque tu n'émules pas le XOR encore.
Maitenant si! L'émulation de la boucle fonctionne, je l'ai testé sur un échantillon de Kenston. Théoriquement maintenant il suffirait que je fasse encore une recherche de signature pour identifier formellement Kenston et le tour serait joué.
Je ne me fais pas encore d'illusions pour autant, je peux toujours échouer plus tard, notamment quand il s'agira d'incorporer d'autres instructions, celles de Poson par exemple. ;-)
fbonroy
J'ai écrit:
Je crois que la question que beaucoup se posent, c'est "comment ça marche"
D'ailleurs on se la pose toujours. ;-)
J'ai écrit:
Je crois que la question que beaucoup se posent, c'est "comment ça
marche"
Je crois que la question que beaucoup se posent, c'est "comment ça marche"
D'ailleurs on se la pose toujours. ;-)
JBM
J'ai écrit:
Je crois que la question que beaucoup se posent, c'est "comment ça marche"
D'ailleurs on se la pose toujours. ;-) Hello,
je ne sais pas si cela a déjà été fait, mais je vais tenter de me lancer dans l'explication du mécanisme d'analyse heuristique...
Le principe est la recherche de code correspondant à des *fonctions virales* (ca, tout le monde l'a compris je pense...), à la differente du moniteur de comportement qui recherche l'*action virale*. L'analyse heuristique est passive, considérant le code comme une simple données et n'autorisant pas son exécution.
Exemple d'un mécanisme heuristique : recherche d'autodéchiffrement. L'autodéchiffrement consiste à balayer une portion de code de manière séquentielle , à le modifier puis à l'exécuter. Le programme heuristique va donc chercher un programme dont une partie des octets en mémoire sont lus puis ré-écrits avant l'exécution. Il s'agit alors d'un code dit *automodifiant*, qui peut être caractéristique d'un virus. Pour effectuer une telle analyse, des indicateurs ( ou marqueurs) peuvent être placés par le programme d'analyse , mais cela concerne plus la programmation et pourrait faire l'objet d'un bon chapitre.
J'espère avoir un peu éclairé votre lanterne...
@ +
J'ai écrit:
Je crois que la question que beaucoup se posent, c'est "comment ça
marche"
D'ailleurs on se la pose toujours. ;-)
Hello,
je ne sais pas si cela a déjà été fait, mais je vais tenter de me lancer
dans l'explication du mécanisme d'analyse heuristique...
Le principe est la recherche de code correspondant à des *fonctions
virales* (ca, tout le monde l'a compris je pense...), à la differente
du moniteur de comportement qui recherche l'*action virale*. L'analyse
heuristique est passive, considérant le code comme une simple données et
n'autorisant pas son exécution.
Exemple d'un mécanisme heuristique : recherche d'autodéchiffrement.
L'autodéchiffrement consiste à balayer une portion de code de manière
séquentielle , à le modifier puis à l'exécuter. Le programme heuristique
va donc chercher un programme dont une partie des octets en mémoire sont
lus puis ré-écrits avant l'exécution. Il s'agit alors d'un code dit
*automodifiant*, qui peut être caractéristique d'un virus.
Pour effectuer une telle analyse, des indicateurs ( ou marqueurs)
peuvent être placés par le programme d'analyse , mais cela concerne plus
la programmation et pourrait faire l'objet d'un bon chapitre.
Je crois que la question que beaucoup se posent, c'est "comment ça marche"
D'ailleurs on se la pose toujours. ;-) Hello,
je ne sais pas si cela a déjà été fait, mais je vais tenter de me lancer dans l'explication du mécanisme d'analyse heuristique...
Le principe est la recherche de code correspondant à des *fonctions virales* (ca, tout le monde l'a compris je pense...), à la differente du moniteur de comportement qui recherche l'*action virale*. L'analyse heuristique est passive, considérant le code comme une simple données et n'autorisant pas son exécution.
Exemple d'un mécanisme heuristique : recherche d'autodéchiffrement. L'autodéchiffrement consiste à balayer une portion de code de manière séquentielle , à le modifier puis à l'exécuter. Le programme heuristique va donc chercher un programme dont une partie des octets en mémoire sont lus puis ré-écrits avant l'exécution. Il s'agit alors d'un code dit *automodifiant*, qui peut être caractéristique d'un virus. Pour effectuer une telle analyse, des indicateurs ( ou marqueurs) peuvent être placés par le programme d'analyse , mais cela concerne plus la programmation et pourrait faire l'objet d'un bon chapitre.
