Je ne suis pas spécialiste du truc, mais pour moi un disque dur ne connaît pas la nature des données qu'il manipule (il ne connait que le "va lire ou écrire tel bloc à l'adresse machin", le reste lui passe au dessus de la tête).
Ca rend la détection et le remplacement de fichiers très hasardeux et complexe (il n'y a pas vraiment de liens entre l'écriture dans la table d'alloc et le contenu des fichiers). Je n'ai pas l'accès à la video flash, mais je ne vois pas comment il a pu faire d'autre dans le cas du remplacement de mot de passe qu'un équivalent memcmp/strstr bourrin sur un pattern genre "root:dollar1dollar" (cochonnerie de markdown) pour ensuite remplacer ce qu'il y a derrière. Autant ça marche bien sur un truc aussi trivial (classiquement la ligne en question est en début de fichier, et donc en début de cluster), autant ça devient rapidement complexe si l'on veut faire un remplacement à cheval sur deux clusters, comme ça va être le cas pour un binaire (>512bytes). Pour le disque, deux clusters lus l'un à la suite de l'autre restent deux clusters indépendants.
Ensuite l'impact sur les perfs doit être assez catastrophique, car l'opération doit être faite sur chaque secteur lu ou écrit, car on ne sait pas à l'avance sur quel(s) cluster(s) est le fichier intéressant, et il est probable que les CPU soient dimensionnés en fonction de leur usage prévu et pas forcément pour encaisser une analyse temps réel supplémentaire à 150+Mo/sec.
[^] # Re: Question
Posté par oinkoink_daotter . En réponse au journal De Snowden, Kaspersky, CitizenFour et Gemalto. Évalué à 2. Dernière modification le 24 février 2015 à 20:57.
Oula très très compliqué.
Je ne suis pas spécialiste du truc, mais pour moi un disque dur ne connaît pas la nature des données qu'il manipule (il ne connait que le "va lire ou écrire tel bloc à l'adresse machin", le reste lui passe au dessus de la tête).
Ca rend la détection et le remplacement de fichiers très hasardeux et complexe (il n'y a pas vraiment de liens entre l'écriture dans la table d'alloc et le contenu des fichiers). Je n'ai pas l'accès à la video flash, mais je ne vois pas comment il a pu faire d'autre dans le cas du remplacement de mot de passe qu'un équivalent memcmp/strstr bourrin sur un pattern genre "root:dollar1dollar" (cochonnerie de markdown) pour ensuite remplacer ce qu'il y a derrière. Autant ça marche bien sur un truc aussi trivial (classiquement la ligne en question est en début de fichier, et donc en début de cluster), autant ça devient rapidement complexe si l'on veut faire un remplacement à cheval sur deux clusters, comme ça va être le cas pour un binaire (>512bytes). Pour le disque, deux clusters lus l'un à la suite de l'autre restent deux clusters indépendants.
Ensuite l'impact sur les perfs doit être assez catastrophique, car l'opération doit être faite sur chaque secteur lu ou écrit, car on ne sait pas à l'avance sur quel(s) cluster(s) est le fichier intéressant, et il est probable que les CPU soient dimensionnés en fonction de leur usage prévu et pas forcément pour encaisser une analyse temps réel supplémentaire à 150+Mo/sec.
Compliqué !