It is possible a piece of malware belongs to a particular family by its structure, but its writer has used some method in an attempt to conceal this fact. Such concealing could be the conversion of the code into an encrypted or polymorphic form by linking one of the available encryption or polymorphic engines to it, or by compressing it with some runtime compressor (e.g., PKLite, LZEXE, ASPack, PePack, UPX, etc, etc.). If the malware is a virus, the latter method is of concern only if it remains infective in its compressed form. Since one and the same malware could be concealed with different methods (or even with more than one method), this could cause classification confusion.
Such malware should be classified as if the concealing mechanism has not been used, and a ‘packer’ modifier of the form described here may be appended to their names. This modifier indicates the particular concealing mechanism used. If the concealing tool conforms to a naming hierarchy, it’s full name should be used as a modifier. This part of the naming scheme is a modification of the original ‘modifier’ suggestions in NAMING.TXT , quoted at the opening of the <modifiers> section, above. As some work still needs to be done on the handling of ‘standard’ encryptor and polymorphic engine names, no further technical details of this particular naming aspect are given, and only the handling of compressors is described in detail. When the modifier indicates a compression tool, only the tool’s name should be used (e.g ‘#UPX’) and it is invalid to attempt to indicate the compression tool’s version (e.g. ‘Win32/FooBar.A#UPX120’ to indicate ‘Win32/FooBar.A packed with UPX v1.20’ is invalid).
[The proposed ‘-hack’ postfix for the <packer> modifier, indicating that the compressor, or its output, had been ‘hacked’ (usually to prevent easy unpacking), was unintentionally left in the final form the paper submitted to AVAR. This suggested postfix for the <packer> modifier was not accepted under wider discussion and is not part of the official specification.]
Finally, the ‘#<packer>’ nomenclature must not be used to indicate things such as ‘a virus included inside a ZIP archive’, so something like ‘Win32/FooBar.A#ZIP’ is just wrong (however, the PKZip, WinZip, InfoZIP, and other, ‘self-extract and run a program from the archive’ options do produce forms of runtime decompressors which are covered by this modifier). It is hoped that an appendix providing a partial list (covering the common, well-known and/or currently significant, runtime compressors) of the accepted ‘standard’ packer names will be included in the final version of the naming standard.
Note that the issue here is runtime obfuscation rather than encoding, packing or compression per se. Thus, at least for the time being, this modifier is not intended to allow things such as ‘#UUE’ or ‘#Base64’ to indicate a file is a mail-transport encoded copy of a known piece of malware, ‘#EML’ or ‘#RFC822’ to indicate that a file is a ‘raw’ mail-transport stream that includes a known piece of malware, and so on. In a very important sense, these are both just forms of passive archiving or encoding much like ZIP, RAR, etc so are clearly not covered. If a scanner detects that a file is a UUencoded stream, decodes that and scans the contents, that is fine, but it need not do anything other than report something like ‘foobar.uue contains a file infected with Win32/FooBar.1234.A’. Whether the report should elaborate further is entirely up to the product developer to decide — the naming scheme’s concern ends with ‘Win32/FooBar.1234.A’ being ‘correct’.