How to make a file non-deletable on an USB drive?

Question

Somebody used my USB drive and upon returning it to me, I found a autorun.inf that is undeleteable. I tried changing it's file attribute which is only H (not even set as a system file) but it keeps on saying Access Denied.

The USB is set on FAT32, upon asking my friend, he told me that he uses Panda USB Vaccine

How do they do this? Im trying to use some Disk Sector editor but have no idea which hex file they change to make this kind of file and make it deletable again. Formatting the drive removes it, but I'm curious as to how to be able to set those kind of file attribute.

Answer 1

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 ID¹, 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.

1. 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".

2. 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.²

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.³

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.⁴

---

¹ This attribute is used for, e.g., the volume label or the folder System Volume Information.

²Certainly enough, setting X to 1 doesn't seem to have any effect.

³I 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}

⁴ 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.

Answer 2

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.