Comment rendre un fichier non supprimable sur une clé USB?

Quelqu'un a utilisé ma clé USB et en me la retournant, j'en ai trouvé une autorun.infqui n'est pas effaçable. J'ai essayé de changer son attribut de fichier qui n'est que H (même pas défini comme fichier système) mais il continue de dire Accès refusé.

L'USB est réglé sur FAT32, après avoir demandé à mon ami, il m'a dit qu'il utilisait le vaccin USB Panda

comment font-ils ça? J'essaie d'utiliser un éditeur de secteur de disque mais je n'ai aucune idée du fichier hexadécimal qu'ils changent pour créer ce type de fichier et le supprimer à nouveau. Le formatage du disque le supprime, mais je suis curieux de savoir comment définir ce type d'attribut de fichier.

Méthode d'essai

Panda ne semble pas révéler le mécanisme exact de son «vaccin», ce qui est compréhensible, car il s'agit essentiellement de sécurité par l'obscurité . Si vous savez comment cela fonctionne, vous pouvez inverser les effets et le «vaccin» devient inutile.

J'ai téléchargé et installé Panda USB Vaccine et "vacciné" mon lecteur flash, vidé la partition du lecteur flash avec dd pour windows en utilisant les commandes

dd --list

dd if=\\.\Volume{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} of=C:\vaccinated.img

où xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxest le GUID fourni par la première commande, ouvert c:\vaccinated.imgdans un éditeur hexadécimal et recherché AUTORUN.

Ce que fait le vaccin USB

L'entrée pour AUTORUN.INFcommence par les douze octets suivants:

41 55 54 4F 52 55 4E 20 49 4E 46 42

Les onze premiers octets ne sont que le nom de fichier 8.3 avec un espace :AUTORUN INF

Le dernier octet spécifie les attributs du fichier et sa représentation binaire est:

01000010

Selon la spécification du système de fichiers Microsoft EFI FAT32 , ce dernier octet est un champ de bits qui prend la forme suivante:

XYADVSHR

où les bits A, D, V, S, Het Rsont 1si et seulement si le fichier est archivé, un répertoire, le volume ID ¹ , un fichier système, caché ou en lecture seule. AUTORUN.INFest masqué, car Hest défini sur 1.

Les bits Xet Ysont réservés et devraient l'être tous les deux 0. Cependant, USB Vaccine est réglé Ysur 1.

Que dit la spécification

Les deux bits supérieurs de l'octet d'attribut sont réservés et doivent toujours être mis à 0 lorsqu'un fichier est créé et jamais modifié ou examiné par la suite.

De plus, il recommande pour la validation du contenu du répertoire:

Ces directives sont fournies afin que les utilitaires de maintenance de disque puissent vérifier les entrées de répertoire individuelles pour leur «exactitude» tout en conservant la compatibilité avec les améliorations futures de la structure de répertoire.

1. NE regardez PAS le contenu des champs d'entrée de répertoire marqués réservés et supposez que, s'ils ont une valeur autre que zéro, ils sont "mauvais".

2. NE RÉINITIALISEZ PAS le contenu des champs d'entrée de répertoire marqués réservés à zéro lorsqu'ils contiennent des valeurs non nulles (en supposant qu'ils sont "mauvais"). Les champs d'entrée d'annuaire sont désignés réservés , plutôt que doivent être à zéro . Ils doivent être ignorés par votre application. Ces champs sont destinés aux futures extensions du système de fichiers. En les ignorant, un utilitaire peut continuer à s'exécuter sur les futures versions du système d'exploitation.

Que se passe-t-il réellement

CHKDSK suit certainement la spécification et ignore l' AUTORUN.INFentrée que le pilote FAT32 ne comprend pas, mais Windows lui-même ne semble pas se conformer à l'exigence de la spécification de ne plus jamais regarder les bits réservés : tout type d'accès (autre que la liste du fichier et ses attributs) est refusée.

Par exemple, la commande

DIR /A /Q

stipule que le propriétaire AUTORUN.INFest .... Étant donné que FAT32 ne prend pas en charge la propriété des fichiers, il doit indiquer \All.

La raison de ce comportement inattendu est que, selon l'entrée FAT32 - Wikipedia # Directory , Windows utilise le bit en Yinterne pour signaler un nom de périphérique de caractère (CON, PRN, AUX, CLOCK $, NUL, LPT1, COM1, etc.), et il ne devrait pas être présent sur les périphériques de stockage. ²

D'une certaine manière, USB Vaccine incite Windows à supposer qu'il AUTORUN.INFne s'agit pas d'un fichier réel, mais d'un périphérique sur lequel il ne peut pas lire ni écrire.

Comment supprimer le fichier

Si vous avez un accès direct au système de fichiers, il suffit de définir Ysur 0(changer l'octet 42en 02) pour rendre le fichier supprimable à nouveau. Vous pouvez également définir le premier octet de l'entrée de répertoire sur E5, marquant directement le fichier comme supprimé. ³

Une autre option serait d'utiliser un pilote différent. Ubuntu 12.04, par exemple, peut supprimer le fichier sans problème. En fait, il "corrige" automatiquement l'entrée de répertoire lors de sa lecture. ⁴

¹ Cet attribut est utilisé, par exemple, pour l'étiquette de volume ou le dossier System Volume Information .

² Certainement, le réglage Xsur 1ne semble pas avoir d'effet.

³ J'ai vérifié cela en changeant les octets correspondants de C:\vaccinated.imgavec un éditeur hexadécimal et en écrivant l'image modifiée sur le lecteur flash en utilisant la commande suivante:

dd if=C:\vaccinated.img of=\\.\Volume{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}

⁴ Bien qu'il s'agisse d'un écart flagrant par rapport à la spécification, il semble qu'il soit réfléchi. Ubuntu laisse Xintact s'il est défini 1, car il ne fait aucun mal. La définition du Ybit sur 1pourrait facilement être utilisée abusivement par une application malveillante, par exemple en créant un fichier non supprimable qui occupe tout l'espace libre du lecteur.

Il s'agit d'une astuce astucieuse du système de fichiers qui exploite un nom réservé dans l'espace de noms Win32. Les détails de la façon dont Panda USB Vaccine le fait sont décrits ici .

Essentiellement, le logiciel crée un dossier nommé autorun.inf(ce qui empêche la création d'un fichier portant le même nom), puis dans ce dossier, un fichier appelé LTP1est créé. Sous DOS, LPT1fait référence au port d'imprimante et Windows le prend en charge pour une compatibilité descendante. Ainsi, lorsque vous demandez un fichier nommé LPT1, Windows essaie d'ouvrir le port d'imprimante, ce qui empêche en quelque sorte le dossier d'être supprimé normalement.

Quant à la façon de supprimer le dossier / fichier sans formater le lecteur, cet article de la base de connaissances Microsoft donne quelques conseils:

Cause 5: le nom de fichier inclut un nom réservé dans l'espace de noms Win32

Si le nom de fichier inclut un nom réservé (par exemple, "lpt1") dans l'espace de noms Win32, vous ne pourrez peut-être pas supprimer le fichier. Pour résoudre ce problème, utilisez un programme non Win32 pour renommer le fichier. Vous pouvez utiliser un outil POSIX ou tout autre outil qui utilise la syntaxe interne appropriée pour utiliser le fichier.

En outre, vous pourrez peut-être utiliser certaines commandes intégrées pour contourner les vérifications de nom réservé Win32 typiques si vous utilisez une syntaxe particulière pour spécifier le chemin d'accès du fichier. Par exemple, si vous utilisez la Del commande dans Windows XP, vous pouvez supprimer un fichier nommé "lpt1" si vous spécifiez le chemin complet du fichier en utilisant la syntaxe spéciale suivante:

del \\?\c:\path_to_file\lpt1

Pour plus d'informations sur la suppression de fichiers avec des noms réservés sous Windows NT et Windows 2000, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft:

120716 Comment supprimer des fichiers avec des noms réservés dans Windows

Pour plus d'informations sur la suppression de fichiers avec des noms réservés sous Windows XP, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft:

315226 Comment supprimer des fichiers avec des noms réservés dans Windows XP

Si vous ouvrez un descripteur sur un fichier à l'aide du CreateFile mécanisme Win32 classique , certains noms de fichier sont réservés aux périphériques DOS à l'ancienne. Pour des raisons de compatibilité descendante, ces noms de fichiers ne sont pas autorisés et ils ne peuvent pas être créés à l'aide d'appels de fichiers Win32 typiques. Toutefois, ce problème n'est pas une limitation de NTFS.

Vous pourrez peut-être utiliser un programme Win32 pour contourner les vérifications de nom typiques qui sont effectuées lorsqu'un fichier est créé (ou supprimé) en utilisant la même technique que vous utilisez pour parcourir les dossiers qui sont plus profonds que MAX_PATH. En outre, certains outils POSIX ne sont pas soumis à ces vérifications de nom.