Le MBR qui est le 1er secteur d'un HD,sur la 1er piste
peut etre infecté par un virus ,dit-on, et lors d'un reformatage
ce meme MBR n'est pas reformaté.
Mais comment un petit programme peut-il venir infecté ce secteur
qui ne comprend que 512 byte.
Par les ports, disent certains.
D'abord en quel langage ce petit programme est-il écrit ?
En C, en JAVA..etc......
Comment les constructeurs d'HD ne prevoient-ils pas un
reformatage de ce secteur ?
Enfin tout ces programmes antispam, antivirus, qui sont
inefficaces, devraient pouvoir prévenir ce genre de désagrément
Quelques réflexions..............
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Thierry Boudet
On 2005-01-14, Marilyn Dubois wrote:
Le MBR qui est le 1er secteur d'un HD,sur la 1er piste peut etre infecté par un virus ,dit-on, et lors d'un reformatage ce meme MBR n'est pas reformaté.
# mke2fs /dev/hdc
Mais comment un petit programme peut-il venir infecté ce secteur qui ne comprend que 512 byte.
Parce qu'il est bien écrit ? Parce qu'il se réserve d'autres secteurs planqués ailleurs sur le disque, par exemple les autres secteur du premier cylindre, souvents inutilisés ?
Par les ports, disent certains.
Si c'est par les ports, il faut peut-être poser un foutou vers fcob ?
D'abord en quel langage ce petit programme est-il écrit ? En C, en JAVA..etc......
Non, c'est de l'assembleur 8086, pour pouvoir être
Comment les constructeurs d'HD ne prevoient-ils pas un reformatage de ce secteur ?
Parce qu'ils sont imprévoyants ?
Enfin tout ces programmes antispam, antivirus, qui sont inefficaces, devraient pouvoir prévenir ce genre de désagrément
Marketing et marketong sont dans une belle galère...
-- _/°< coin
On 2005-01-14, Marilyn Dubois <mari.lyn@skynet.be> wrote:
Le MBR qui est le 1er secteur d'un HD,sur la 1er piste
peut etre infecté par un virus ,dit-on, et lors d'un reformatage
ce meme MBR n'est pas reformaté.
# mke2fs /dev/hdc
Mais comment un petit programme peut-il venir infecté ce secteur
qui ne comprend que 512 byte.
Parce qu'il est bien écrit ? Parce qu'il se réserve d'autres
secteurs planqués ailleurs sur le disque, par exemple les
autres secteur du premier cylindre, souvents inutilisés ?
Par les ports, disent certains.
Si c'est par les ports, il faut peut-être poser un
foutou vers fcob ?
D'abord en quel langage ce petit programme est-il écrit ?
En C, en JAVA..etc......
Non, c'est de l'assembleur 8086, pour pouvoir être
Comment les constructeurs d'HD ne prevoient-ils pas un
reformatage de ce secteur ?
Parce qu'ils sont imprévoyants ?
Enfin tout ces programmes antispam, antivirus, qui sont
inefficaces, devraient pouvoir prévenir ce genre de désagrément
Marketing et marketong sont dans une belle galère...
Le MBR qui est le 1er secteur d'un HD,sur la 1er piste peut etre infecté par un virus ,dit-on, et lors d'un reformatage ce meme MBR n'est pas reformaté.
# mke2fs /dev/hdc
Mais comment un petit programme peut-il venir infecté ce secteur qui ne comprend que 512 byte.
Parce qu'il est bien écrit ? Parce qu'il se réserve d'autres secteurs planqués ailleurs sur le disque, par exemple les autres secteur du premier cylindre, souvents inutilisés ?
Par les ports, disent certains.
Si c'est par les ports, il faut peut-être poser un foutou vers fcob ?
D'abord en quel langage ce petit programme est-il écrit ? En C, en JAVA..etc......
Non, c'est de l'assembleur 8086, pour pouvoir être
Comment les constructeurs d'HD ne prevoient-ils pas un reformatage de ce secteur ?
Parce qu'ils sont imprévoyants ?
Enfin tout ces programmes antispam, antivirus, qui sont inefficaces, devraient pouvoir prévenir ce genre de désagrément
Marketing et marketong sont dans une belle galère...
-- _/°< coin
Nicolas Le Scouarnec
Le MBR qui est le 1er secteur d'un HD,sur la 1er piste peut etre infecté par un virus ,dit-on, et lors d'un reformatage ce meme MBR n'est pas reformaté.
Ca dépend de comment tu formattes, si tu essayes: dd if=/dev/zero of=/dev/hda , tout part, meme le MBR...
Mais comment un petit programme peut-il venir infecté ce secteur qui ne comprend que 512 byte.
496 bits , parce qu'un byte, c'est un octet, soit 8 bits.
Par les ports, disent certains.
Faut pas rever, a 496 bit, je doute qu'un vers passe dans un si petit trou...
D'abord en quel langage ce petit programme est-il écrit ? En C, en JAVA..etc......
En C, en ASM, en LISP, en Java, ... en tout ce que tu veux.
Comment les constructeurs d'HD ne prevoient-ils pas un reformatage de ce secteur ?
C'est prévu, normalement quand tu réinstalles un boot loader il disparait...
Enfin tout ces programmes antispam, antivirus, qui sont inefficaces, devraient pouvoir prévenir ce genre de désagrément
-- Nicolas Le Scouarnec
Le MBR qui est le 1er secteur d'un HD,sur la 1er piste
peut etre infecté par un virus ,dit-on, et lors d'un reformatage
ce meme MBR n'est pas reformaté.
Ca dépend de comment tu formattes, si tu essayes:
dd if=/dev/zero of=/dev/hda , tout part, meme le MBR...
Mais comment un petit programme peut-il venir infecté ce secteur
qui ne comprend que 512 byte.
496 bits , parce qu'un byte, c'est un octet, soit 8 bits.
Par les ports, disent certains.
Faut pas rever, a 496 bit, je doute qu'un vers passe dans un si petit
trou...
D'abord en quel langage ce petit programme est-il écrit ?
En C, en JAVA..etc......
En C, en ASM, en LISP, en Java, ... en tout ce que tu veux.
Comment les constructeurs d'HD ne prevoient-ils pas un
reformatage de ce secteur ?
C'est prévu, normalement quand tu réinstalles un boot loader il
disparait...
Enfin tout ces programmes antispam, antivirus, qui sont
inefficaces, devraient pouvoir prévenir ce genre de désagrément
Le MBR qui est le 1er secteur d'un HD,sur la 1er piste peut etre infecté par un virus ,dit-on, et lors d'un reformatage ce meme MBR n'est pas reformaté.
Ca dépend de comment tu formattes, si tu essayes: dd if=/dev/zero of=/dev/hda , tout part, meme le MBR...
Mais comment un petit programme peut-il venir infecté ce secteur qui ne comprend que 512 byte.
496 bits , parce qu'un byte, c'est un octet, soit 8 bits.
Par les ports, disent certains.
Faut pas rever, a 496 bit, je doute qu'un vers passe dans un si petit trou...
D'abord en quel langage ce petit programme est-il écrit ? En C, en JAVA..etc......
En C, en ASM, en LISP, en Java, ... en tout ce que tu veux.
Comment les constructeurs d'HD ne prevoient-ils pas un reformatage de ce secteur ?
C'est prévu, normalement quand tu réinstalles un boot loader il disparait...
Enfin tout ces programmes antispam, antivirus, qui sont inefficaces, devraient pouvoir prévenir ce genre de désagrément
-- Nicolas Le Scouarnec
Galkine Guy
Le Fri, 14 Jan 2005 13:24:56 +0100, Marilyn Dubois a écrit :
Bonjour,
Le MBR qui est le 1er secteur d'un HD,sur la 1er piste peut etre infecté par un virus ,dit-on, et lors d'un reformatage ce meme MBR n'est pas reformaté. Il contient la table de partitons ,donc vaut mieux pas
Mais comment un petit programme peut-il venir infecté ce secteur qui ne comprend que 512 byte. Par les ports, disent certains. un truc qui pointe vers d'autre secteur du disque ?
D'abord en quellangage ce petit programme est-il écrit ? En C, en JAVA..etc...... Comment les constructeurs d'HD ne prevoient-ils pas un reformatage de ce secteur ? pour voir une horde de gens gueuler , après la perte de leur partition
du a cette manipulation?
Enfin tout ces programmes antispam, antivirus, qui sont inefficaces,
devraient pouvoir prévenir ce genre de désagrément Quelques réflexions.............. certains programmes surveillent l'ajout de clefs dans la base de registre
, la modificaion de la mbr etc
Le Fri, 14 Jan 2005 13:24:56 +0100, Marilyn Dubois a écrit :
Bonjour,
Le MBR qui est le 1er secteur d'un HD,sur la 1er piste peut etre infecté
par un virus ,dit-on, et lors d'un reformatage ce meme MBR n'est pas
reformaté.
Il contient la table de partitons ,donc vaut mieux pas
Mais comment un petit programme peut-il venir infecté ce secteur qui ne
comprend que 512 byte.
Par les ports, disent certains.
un truc qui pointe vers d'autre secteur du disque ?
D'abord en quellangage ce petit programme est-il écrit ? En C, en
JAVA..etc......
Comment les constructeurs d'HD ne prevoient-ils pas un reformatage de ce
secteur ?
pour voir une horde de gens gueuler , après la perte de leur partition
du a cette manipulation?
Enfin tout ces programmes antispam, antivirus, qui sont
inefficaces,
devraient pouvoir prévenir ce genre de désagrément Quelques
réflexions..............
certains programmes surveillent l'ajout de clefs dans la base de registre
Le Fri, 14 Jan 2005 13:24:56 +0100, Marilyn Dubois a écrit :
Bonjour,
Le MBR qui est le 1er secteur d'un HD,sur la 1er piste peut etre infecté par un virus ,dit-on, et lors d'un reformatage ce meme MBR n'est pas reformaté. Il contient la table de partitons ,donc vaut mieux pas
Mais comment un petit programme peut-il venir infecté ce secteur qui ne comprend que 512 byte. Par les ports, disent certains. un truc qui pointe vers d'autre secteur du disque ?
D'abord en quellangage ce petit programme est-il écrit ? En C, en JAVA..etc...... Comment les constructeurs d'HD ne prevoient-ils pas un reformatage de ce secteur ? pour voir une horde de gens gueuler , après la perte de leur partition
du a cette manipulation?
Enfin tout ces programmes antispam, antivirus, qui sont inefficaces,
devraient pouvoir prévenir ce genre de désagrément Quelques réflexions.............. certains programmes surveillent l'ajout de clefs dans la base de registre
, la modificaion de la mbr etc
Miod Vallat
Mais comment un petit programme peut-il venir infecté ce secteur qui ne comprend que 512 byte.
496 bits , parce qu'un byte, c'est un octet, soit 8 bits.
Je me permets de répondre avant que tu ne remplaces ton message après t'être rendu compte de la boulette dans ta réponse, Nicolas.
Je me permets aussi de rire doucement parce que je ne vois vraiment pas comment tu trouves 496. 512 - 64 ou 512 - 66, je pense que je comprendrai le cheminement de ta pensée, mais 496, non, je ne vois pas.
Mais comment un petit programme peut-il venir infecté ce secteur
qui ne comprend que 512 byte.
496 bits , parce qu'un byte, c'est un octet, soit 8 bits.
Je me permets de répondre avant que tu ne remplaces ton message après
t'être rendu compte de la boulette dans ta réponse, Nicolas.
Je me permets aussi de rire doucement parce que je ne vois vraiment pas
comment tu trouves 496. 512 - 64 ou 512 - 66, je pense que je
comprendrai le cheminement de ta pensée, mais 496, non, je ne vois pas.
Mais comment un petit programme peut-il venir infecté ce secteur qui ne comprend que 512 byte.
496 bits , parce qu'un byte, c'est un octet, soit 8 bits.
Je me permets de répondre avant que tu ne remplaces ton message après t'être rendu compte de la boulette dans ta réponse, Nicolas.
Je me permets aussi de rire doucement parce que je ne vois vraiment pas comment tu trouves 496. 512 - 64 ou 512 - 66, je pense que je comprendrai le cheminement de ta pensée, mais 496, non, je ne vois pas.
Nicolas George
Miod Vallat , dans le message <41e8307d$0$12269$, a écrit :
Je me permets aussi de rire doucement parce que je ne vois vraiment pas comment tu trouves 496.
Ben c'est juste la touche de son clavier qui ne marche pas.
Miod Vallat , dans le message <41e8307d$0$12269$636a15ce@news.free.fr>,
a écrit :
Je me permets aussi de rire doucement parce que je ne vois vraiment pas
comment tu trouves 496.
Ben c'est juste la touche de son clavier qui ne marche pas.
Miod Vallat , dans le message <41e8307d$0$12269$, a écrit :
Je me permets aussi de rire doucement parce que je ne vois vraiment pas comment tu trouves 496.
Ben c'est juste la touche de son clavier qui ne marche pas.
Richard Delorme
Je passe sur les chiffres bizarres que d'autres ont relevé, mais je sursaute néanmoins sur cette affirmation :
parce qu'un byte, c'est un octet, soit 8 bits.
Car byte se traduit un français par multiplet, octet étant la traduction de l'anglais octet, et on ne peut rien dire sue la taille en bits d'un multiplet (qui peut être 9, 16, etc.).
-- Richard
Je passe sur les chiffres bizarres que d'autres ont relevé, mais je
sursaute néanmoins sur cette affirmation :
parce qu'un byte, c'est un octet, soit 8 bits.
Car byte se traduit un français par multiplet, octet étant la traduction
de l'anglais octet, et on ne peut rien dire sue la taille en bits d'un
multiplet (qui peut être 9, 16, etc.).
Je passe sur les chiffres bizarres que d'autres ont relevé, mais je sursaute néanmoins sur cette affirmation :
parce qu'un byte, c'est un octet, soit 8 bits.
Car byte se traduit un français par multiplet, octet étant la traduction de l'anglais octet, et on ne peut rien dire sue la taille en bits d'un multiplet (qui peut être 9, 16, etc.).
-- Richard
memyself_
Marilyn Dubois wrote:
Bonjour,
Le MBR qui est le 1er secteur d'un HD,sur la 1er piste peut etre infecté par un virus ,dit-on, et lors d'un reformatage ce meme MBR n'est pas reformaté.
Non, je ne vois pas l'interêt de formater une MBR puisque son format est fixé une bonne fois pour toutes (512 octets sur le premier secteur).
La MBR est simplement écrasée par ce que tu mets dedans.
Mais comment un petit programme peut-il venir infecté ce secteur qui ne comprend que 512 byte.
La MBR ne contient qu'une toute petite partie du boot, celle qui dit où se trouve le boot loader. Je suppose que ton virus fait de même.
Par les ports, disent certains.
? je ne vois pas le rapport
D'abord en quel langage ce petit programme est-il écrit ? En C, en JAVA..etc......
En tout ce qu'on veut, mais ça parait plus logique d'utiliser les mnémoniques de l'assembleur pour ça.
Comment les constructeurs d'HD ne prevoient-ils pas un reformatage de ce secteur ?
Parcequ'il n'y a pas lieu de modifier le format de ce secteur.
Enfin tout ces programmes antispam, antivirus, qui sont inefficaces, devraient pouvoir prévenir ce genre de désagrément Quelques réflexions..............
<impertinence>ben déjà, si ils sont inefficaces...</impertinence>
C'est déjà le cas sous windows, scandisk détécte lorsque la zone amorce a été modifiée.
Sous linux, je ne m'étais jamais posé la question, mais un bon shell script fera l'affaire, dans le genre:
#! /bin/bash mount /boot dd if=/dev/hda of=/boot/mbr.img count=1 md5sum -c /boot/mbr.img.md5 || logger -i -t MBR -p auth.crit La MBR semble avoir été modifiée! umount /boot
Je l'ai testé dans la foulée, ça marche pour moi (je n'ai pas testé en modifiant la MBR par contre :-P)
il faut préciser le chemin d'accès complet au fichier dans le fichier md5, sinon le test ne sera jamais validé (il ne trouvera pas le fichier).
Bon, c'est un peu fait "à la va vite", mais ça présente l'interêt de conserver une image réputée "valide" de la MBR, ainsi, non seulement ça contrôle la MBR, mais ça offre aussi la possibilité de la restaurer.
++
Marilyn Dubois wrote:
Bonjour,
Le MBR qui est le 1er secteur d'un HD,sur la 1er piste
peut etre infecté par un virus ,dit-on, et lors d'un reformatage
ce meme MBR n'est pas reformaté.
Non, je ne vois pas l'interêt de formater une MBR puisque
son format est fixé une bonne fois pour toutes
(512 octets sur le premier secteur).
La MBR est simplement écrasée par ce que tu mets dedans.
Mais comment un petit programme peut-il venir infecté ce secteur
qui ne comprend que 512 byte.
La MBR ne contient qu'une toute petite partie du boot,
celle qui dit où se trouve le boot loader. Je suppose que ton virus
fait de même.
Par les ports, disent certains.
? je ne vois pas le rapport
D'abord en quel langage ce petit programme est-il écrit ?
En C, en JAVA..etc......
En tout ce qu'on veut, mais ça parait plus logique
d'utiliser les mnémoniques de l'assembleur pour ça.
Comment les constructeurs d'HD ne prevoient-ils pas un
reformatage de ce secteur ?
Parcequ'il n'y a pas lieu de modifier le format de ce secteur.
Enfin tout ces programmes antispam, antivirus, qui sont
inefficaces, devraient pouvoir prévenir ce genre de désagrément
Quelques réflexions..............
<impertinence>ben déjà, si ils sont inefficaces...</impertinence>
C'est déjà le cas sous windows, scandisk détécte lorsque la zone amorce
a été modifiée.
Sous linux, je ne m'étais jamais posé la question, mais un bon shell script
fera l'affaire, dans le genre:
#! /bin/bash
mount /boot
dd if=/dev/hda of=/boot/mbr.img count=1
md5sum -c /boot/mbr.img.md5 || logger -i -t MBR -p auth.crit La MBR semble
avoir été modifiée!
umount /boot
Je l'ai testé dans la foulée, ça marche pour moi (je n'ai pas testé en
modifiant la MBR par contre :-P)
il faut préciser le chemin d'accès complet au fichier dans le fichier md5,
sinon le test ne sera jamais validé (il ne trouvera pas le fichier).
Bon, c'est un peu fait "à la va vite", mais ça présente l'interêt de
conserver une image réputée "valide" de la MBR, ainsi, non seulement ça
contrôle la MBR, mais ça offre aussi la possibilité de la restaurer.
Le MBR qui est le 1er secteur d'un HD,sur la 1er piste peut etre infecté par un virus ,dit-on, et lors d'un reformatage ce meme MBR n'est pas reformaté.
Non, je ne vois pas l'interêt de formater une MBR puisque son format est fixé une bonne fois pour toutes (512 octets sur le premier secteur).
La MBR est simplement écrasée par ce que tu mets dedans.
Mais comment un petit programme peut-il venir infecté ce secteur qui ne comprend que 512 byte.
La MBR ne contient qu'une toute petite partie du boot, celle qui dit où se trouve le boot loader. Je suppose que ton virus fait de même.
Par les ports, disent certains.
? je ne vois pas le rapport
D'abord en quel langage ce petit programme est-il écrit ? En C, en JAVA..etc......
En tout ce qu'on veut, mais ça parait plus logique d'utiliser les mnémoniques de l'assembleur pour ça.
Comment les constructeurs d'HD ne prevoient-ils pas un reformatage de ce secteur ?
Parcequ'il n'y a pas lieu de modifier le format de ce secteur.
Enfin tout ces programmes antispam, antivirus, qui sont inefficaces, devraient pouvoir prévenir ce genre de désagrément Quelques réflexions..............
<impertinence>ben déjà, si ils sont inefficaces...</impertinence>
C'est déjà le cas sous windows, scandisk détécte lorsque la zone amorce a été modifiée.
Sous linux, je ne m'étais jamais posé la question, mais un bon shell script fera l'affaire, dans le genre:
#! /bin/bash mount /boot dd if=/dev/hda of=/boot/mbr.img count=1 md5sum -c /boot/mbr.img.md5 || logger -i -t MBR -p auth.crit La MBR semble avoir été modifiée! umount /boot
Je l'ai testé dans la foulée, ça marche pour moi (je n'ai pas testé en modifiant la MBR par contre :-P)
il faut préciser le chemin d'accès complet au fichier dans le fichier md5, sinon le test ne sera jamais validé (il ne trouvera pas le fichier).
Bon, c'est un peu fait "à la va vite", mais ça présente l'interêt de conserver une image réputée "valide" de la MBR, ainsi, non seulement ça contrôle la MBR, mais ça offre aussi la possibilité de la restaurer.
++
Thierry Boudet
On 2005-01-14, Nicolas Le Scouarnec wrote:
Mais comment un petit programme peut-il venir infecté ce secteur qui ne comprend que 512 byte.
496 bits , parce qu'un byte, c'est un octet, soit 8 bits.
Ah oui, mais 7Go de swap, ça aide bien...
-- _/°< coin
On 2005-01-14, Nicolas Le Scouarnec <root@india.ath.cx> wrote:
Mais comment un petit programme peut-il venir infecté ce secteur
qui ne comprend que 512 byte.
496 bits , parce qu'un byte, c'est un octet, soit 8 bits.
