Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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.

share|improve this question
    
I found another tool that does the same link BitDefender USB Immunizer –  MegaNairda May 14 '12 at 8:21
    
Did you inspect the permissions on the file? –  Moab May 14 '12 at 13:25
    
@Moab The filesystem on the USB is FAT32. –  MegaNairda May 17 '12 at 9:04

2 Answers 2

up vote 14 down vote accepted
+50

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.

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

share|improve this answer
    
+1 Thanks. Soo long... –  Jet Sep 11 '13 at 19:28

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.

share|improve this answer
2  
That is the old way of Panda USB vaccine of protecting the USB drive from malicious autorun.inf. Try downloading and using the link I provided and you'll see that it doesn't create any folders. Just a single file called autorun.inf –  MegaNairda May 14 '12 at 8:13
    
@MegaNairda: Weird... I did install the USB Vaccine, but whenever I try to vaccinate my FAT32 thumbdrive, the program creates an AUTORUN.INF (with the same "caacaa..." string mentioned in the article) on the drive and then promptly freezes. I have no problem deleting the autorun file at all... –  Lèse majesté May 14 '12 at 8:32
    
Try BitDefender USB Immunizer link Panda USB Vaccine also sometimes freeze on my system when I insert USB drives. –  MegaNairda May 14 '12 at 8:34
    
@MegaNairda: There seemed to be a problem with that thumbdrive. Neither program was able to vaccinate it. However, this coincidence was helpful in it showed that BitDefender's immunizer at least uses a similar technique. The error log showed that it tried to create a series of nested folders/files under I:\autorun.inf\bdsanitize#\bdsanitize#... where # is "1" or "2". The log file also appended each level's file/dirname with .dir or .file but that may just be shown for logging/debugging purposes. –  Lèse majesté May 14 '12 at 9:04
1  
It seems that there is indeed a problem with your USB. BitDefender's Immunizer do create a folder autorun.inf but after that, it would be replaced by a autorun.inf file. The difference with the autorun.inf Panda USB Vaccine is that the file is empty and doesn't contain the cacaca like the one created by Panda. –  MegaNairda May 21 '12 at 5:46

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.