This identifier indicates the minimum operating system, interpreter, etc required for the named code to function as its malware type. PlatformNames usually have a LongFormPlatformName and a ShortFormPlatformName with the latter generally being used when names are reported to users. There should be little debate about the basics of platform names except when a new platform is found virusable and suitable ShortFormPlatformName and LongFormPlatformName need to be added to the ‘approved’ list. The list of all platform names currently officially recognized by this standard , and some notes on determining their appropriate use, is included later. Note that such a list is only correct for a moment in history — the list published in the original AVAR conference paper was correct for the conference presentation, but the list in this living document should be updated within a day or so of new platform names being agreed.
DeprecatedPlatforms includes an illustrative list of platform names that have been mooted or used in the past but are now deprecated, or that are being used as a result of vendor capriciousness. The correct replacement platform names to use in their place are explained in the Comments column of that table.
A few developers have bucked the established trend of naming platforms after the OS, interpreter, etc necessary for the virus code’s replication or the malware’s other operation and use platform names derived from the file formats or file types the virus infects. All such platform names (particularly ‘HTML’) are simply wrong and should be avoided. Note, however, that this does not mean platform names that match a file format are erroneous. For example, ‘VBS’ is both a file type and a suitable acronym for the Visual Basic Script interpreter. It’s use as a platform name is not intended to imply that only VBS files may house this type of malware and in fact, many examples of VBS malware are found embedded as scripts inside HTML files and Windows’ Compiled HTML Help (.CHM) files.
Although determining the correct platform name for a piece of malware seldom takes more than a few moments, it seems many vendors spend even less than that amount of effort on the task, given some the things we have seen over the years. There are a few tricky situations and these have become a little more common over the last few years – one is the true cross-platform virus and the other is multi-component malware. The first is dealt with the by the standard rules for combining more than one identifier for use as one name component. This is described in the section Specifying multiple values in a single name component, later in this guide. Multi-component malware, where none (or not all) of the component files is independently worthy of the malware type status ‘deserved’ of the files as a collection can be tricky to assign a ‘primary’ platform to. It is common that such beasts have components that depend on separate, but commonly coexisting platforms – say Win32 executable and VBS script components – and the whole combination is needed so all the component files can play off each other to exhibit the complete intended behaviour. In such cases an almost arbitrary judgement call has to be made that either this is cross-platform malware (in which case the rules discussed for the previous situation apply) or that one platform is in some way ‘primary’ and that becomes the ascribed platform type.
Previous: MalwareType Next: GroupName