How to make a file non-deletable on an USB drive?
Test method
Panda doesn't seem to reveal the exact mechanism of its "vaccine", which is understandable, since it's basically security through obscurity. If you know how it works, you can reverse the effects and the "vaccine" becomes useless.
I downloaded and installed Panda USB Vaccine and "vaccinated" my flash drive, dumped the flash drive's partition with dd for windows using the commands
dd --list
dd if=\\.\Volume{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} of=C:\vaccinated.img
where xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
is the GUID provided by the first command, opened c:\vaccinated.img
in a hex editor and searched for AUTORUN
.
What USB Vaccine does
The entry for AUTORUN.INF
begins with the following twelve bytes:
41 55 54 4F 52 55 4E 20 49 4E 46 42
The first eleven bytes are just the space-padded 8.3 filename: AUTORUN INF
The last byte specifies the file's attributes, and its binary representation is:
01000010
According to the Microsoft EFI FAT32 File System Specification, this last byte is a bit field that takes the following form:
XYADVSHR
where the bits A
, D
, V
, S
, H
and R
are 1
if and only if the file is archived, a directory, the volume ID1, a system file, hidden or read-only. AUTORUN.INF
is hidden, since H
is set to 1
.
The bits X
and Y
are reserved and should both be 0
. However, USB Vaccine sets Y
to 1
.
What the specification says
The upper two bits of the attribute byte are reserved and should always be set to 0 when a file is created and never modified or looked at after that.
Furthermore, it recommends for validation of directory contents:
These guidelines are provided so that disk maintenance utilities can verify individual directory entries for 'correctness' while maintaining compatibility with future enhancements to the directory structure.
DO NOT look at the content of directory entry fields marked reserved and assume that, if they are any value other than zero, that they are "bad".
DO NOT reset the content of directory entry fields marked reserved to zero when they contain non-zero values (under the assumption that they are "bad"). Directory entry fields are designated reserved, rather than must-be-zero. They should be ignored by your application. These fields are intended for future extensions of the file system. By ignoring them an utility can continue to run on future versions of the operating system.
What actually happens
CHKDSK certainly follows the specification and ignores the AUTORUN.INF
entry which the FAT32 driver doesn't understand, but Windows itself doesn't seem to comply with the specification's requirement to never look at the reserved bits again: Any kind of access (other than listing the file and its attributes) is denied.
For example, the command
DIR /A /Q
states that the owner of AUTORUN.INF
is ...
. Since FAT32 doesn't support file ownership, it should state \All
.
The reason for this unexpected behavior is that, according to FAT32 - Wikipedia # Directory entry, Windows uses the bit Y
internally to signal a character device name (CON, PRN, AUX, CLOCK$, NUL, LPT1, COM1, etc.), and it shouldn't be present on storage devices.2
In a manner of speaking, USB Vaccine tricks Windows into assuming that AUTORUN.INF
isn't an actual file, but a device, which it cannot read from or write to.
How to delete the file
If you have direct access to the file system, it suffices to set Y
to 0
(change the byte 42
to 02
) to make the file deletable again. You could also set the first byte of the directory entry to E5
, directly marking the file as deleted.3
Another option would be to use a different driver. Ubuntu 12.04, e.g., can delete the file without problems. Actually, it automatically "fixes" the directory entry when reading it.4
1 This attribute is used for, e.g., the volume label or the folder System Volume Information.
2Certainly enough, setting X
to 1
doesn't seem to have any effect.
3I verified this by changing the corresponding bytes of C:\vaccinated.img
with a hex editor and writing the modified image to the flash drive using the following command:
dd if=C:\vaccinated.img of=\\.\Volume{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
4 While a blatant deviation from the specification, it seems to be thought-out one. Ubuntu leaves the X
intact if it is set to 1
, since it does no harm. Setting the Y
bit to 1
could easily be abused by a malicious application, by, e.g., creating an undeletable file that takes up the drive's entire free space.
This is a clever bit of filesystem trickery that exploits a reserved name in the Win32 namespace. The details of how Panda USB Vaccine does this is outlined here.
Essentially the software creates a folder named autorun.inf
(which prevents a file with the same name being created there), and then in that folder, a file called LTP1
is created. In DOS, LPT1
refers to the printer port, and Windows supports this for backwards compatibility. So when you request a file named LPT1
, Windows tries to open the printer port, and somehow this prevents the folder from being deleted normally.
As for how to remove the folder/file without formatting the drive, this Microsoft Knowledgebase article gives some tips:
Cause 5: The file name includes a reserved name in the Win32 name space
If the file name includes a reserved name (for example, "lpt1") in the Win32 name space, you may not be able to delete the file. To resolve this issue, use a non-Win32 program to rename the file. You can use a POSIX tool or any other tool that uses the appropriate internal syntax to use the file.
Additionally, you may be able to use some built-in commands to bypass the typical Win32 reserved name checks if you use a particular syntax to specify the path of the file. For example, if you use the
Del
command in Windows XP, you can delete a file named "lpt1" if you specify the full path of the file by using the following special syntax:del \\?\c:\path_to_file\lpt1
For more information about deleting files with reserved names under Windows NT and Windows 2000, click the following article number to view the article in the Microsoft Knowledge Base:
120716 How to remove files with reserved names in Windows
For more information about deleting files with reserved names under Windows XP, click the following article number to view the article in the Microsoft Knowledge Base:
315226 How to remove files with reserved names in Windows XP
If you open a handle to a file by using the typical Win32
CreateFile
mechanism, certain file names are reserved for old-style DOS devices. For backward compatibility, these file names are not permitted and they cannot be created by using typical Win32 file calls. However, this issue is not a limitation of NTFS.You may be able to use a Win32 program to bypass the typical name checks that are performed when a file is created (or deleted) by using the same technique that you use to traverse folders that are deeper than
MAX_PATH
. Additionally, some POSIX tools are not subject to these name checks.