How does the Panda USB vaccination work?

47022668_c03c3a6bf4_b I stumbled on the Panda USB and AutoRun Vaccine on the Panda Research blog and it peaked my interest because autorun-based malware is very wide-spread these days and also because I’ve written extensively about the topic.

An other reason is that I don’t like black boxes and it is my opinion that all knowledge should be disseminated in the open :-).

So how does the “vaccination” work? (as a sidenote: in the “olden days” – meaning DOS – the idea of “vaccination” was quite common and was based on the idea of emulating the checks which different viruses used to detect if they already infected the system. This quickly became unmanageable, since not all viruses checked for previous infections and some used the same vector but wanted different results. This program however has nothing to do with this method of vaccination.)

There are actually two components to it:

  • The “immunization” of the computer: this is done by the IniFileMapping feature I also discussed.
  • The “vaccination” of the USB drives: this is done by creating a folder named “autorun.inf” on the drive. Since folders and files are the same on most file systems, you can’t create a file and a directory with the same name. There is also some additional magic involved: the tool creates a file named lpt1 in the folder named autorun.inf (so you have the structure U:autorun.inflpt1) in which it writes “caacaacaacaacaa” (don’t ask my why, I have no idea – it seems to be gene sequence).

    This makes the folder undeletable by conventional tools. The reason is the interaction with compatibility (in DOS LPT1 referred to the printer port, so for compatibility reasons Windows tries to open the printer port whenever you ask for LPT1). For a more detailed description and workarounds which can be used see the section “Cause 5: The file name includes a reserved name in the Win32 name space” in KB320081 from Microsoft. A couple of errors in the announcement:

    • The announcement claims "USB drives that have been vaccinated cannot be reversed except with a format". This is not actually true, in fact the "vaccination" can be undone as described in the Microsoft KB.
    • "Panda USB Vaccine currently only works on FAT & FAT32 USB drives" – while this is true, the reason for it is that the program explicitly checks for the given filesystems (possibly because the authors thought that the method works because of quirks in the FAT filesystem, but in fact it works because the compatibility layer in the Win32 API, independent of the underlying FS). Also, on the NTFS filesystem other tricks can be played to create “undeletable” files / folders (like removing all the permissions for the given item, playing with the fact that NTFS is case sensitive – even though case insensivity is emulated by the Win32 API, etc), but none of them is irreversible as the blogpost claims. A possibly irreversible (or more accurately: very hard to reverse) change would be to open the disk directly and much around in the allocation tables / MFT and selectively corrupting it, but this would be very risky.

So there you have it. Nothing too magical and some errors/misunderstanding in the original post. Also, it is quite possible that future malware will look for the “immunization” on USB drives and reverse it.

Picture taken from Clearly Ambiguous’ photostream with permission.

, ,

16 responses to “How does the Panda USB vaccination work?”

  1. somebody knows the easy way to delete U:autorun.inf..1.txt ? Linux couldn’t delete it either. I did it by modifing fat table directly with winhex, but its not easy way.

  2. @Anonymous: How did you create the folder in the first place? If it was by hex-editing the FAT structures, it is normal that you only can remove it using a hex editor.

    I tried to create such a folder using the “normal” way (using the \? prefix), but had no success.

  3. Hi.

    You may want to have a look to a more recent version… Checking that software now (, it looks like Panda has enhanced the trick.

    Now it creates a file autorun.inf instead of a folder, and it cannot be erased. It cannot either be viewed (which BTW makes it very "suspicious" if one does not know that the drive has been "vaccinated"… an autorun.inf that is a folder looks clearly as an autorun.inf "disabled", but an autorun.inf that cannot be opened nor deleted is quite scaring).

    Not sure of how they make it now… Maybe for doing the trick they now go directly on hacking the FAT (as you mention in your article)? And maybe that's why they say that NTFS support is still in beta.

    BTW, and for your information:
    Panda and the developper are spanish (like me). "Caca" means shit in spanish. Some spanish programmers usually use for example as temporal file names "kk" (pronounced in spanish as caca) as a quick (and literally dirty) way to mean "foo" or "temp".
    So I would bet that this is the reason of this "caacaacaacaacaa" (although I may be wrong).

    Regards from Spain.

  4. I tried Panda for my NTFS drive and somehow the application hangs. Somehow I end the program and tested and seems like the autorun.inf has been installed.

    I also tried Autorun Protector which supports both FAT32 and NTFS.

    Both seems to be using different method for protecting but the latter one can choose to remove the protection without formatting the drive.

  5. How could one sure that the autorun.inf by panda for PC as well as pen drive does not contain some suspicioos autorun feature? Could you thro some light on this aspect

  6. @Anonymous: getting a little philosophical here: there is no possibility to be absolutely sure about anything, not even in IT. Everything is a shade of gray.

    Getting back on the question:
    – you could (should) trust Panda mostly. It is a reputable company and with some extreme exceptions I can't imagine it releasing anything harmful.

    – you could (and should if you are concerned about it) look at the file in a safe environment (such as a virtual machine) and possibly look at the executable with a disassembler

  7. As I am interested in protecting some of my files using this trickery, I reverse engineered the protection.
    If a dir /ah /q autorun.inf is done, you can see that the "owner" (in FAT32!) of this file is "…" while the rest of the files have ownership All.

    Along my manipulations (I asked in W7 for attributes, I got HX -sorry, I found nothing on the "X"; I opened the usb in linux, made a dosfcsk read only, etc.) , the ownership changed from … to All !!!!

    After that I have been able to delete autorun.inf from explorer

    Now, I will try to find out how ownership was changed … and if any other thing also changed. I keep looking to find out an utility to change ownership in fat32 under windows …

  8. I suspect that the utility "corrupts" then entry for the file just enough so that it isn't deletable, but not so much to freak out other tools.

    Maybe you could try running dosfcsk from cygwin?

Leave a Reply

Your email address will not be published. Required fields are marked *