Aside from shaking up our ideas about the relative value of infective length and sub-variant identifiers, macro viruses introduced another twist — devolving virus forms. Although not theoretically limited to macro viruses, it was among macro viruses that we first saw real-world examples of virus code devolution. Among macro virus researchers, devolution is generally agreed to be the process whereby, under specific, natural replication conditions, a recursively replicable subset of the virus’ original macro set is created in a new sample and that set cannot return to the original ‘complete’ macro set without some form of external intervention. Such a new, partial, recursively replicative macro set is said to be a ‘devolved form’, or ‘devolution’, of the original virus.
Although clearly a different form, such devolutions are not named as independent sub-variants by taking the next available sub-variant identifiers for their families. Instead, devolutions are named in such a way as to tie them to their originating variant by adding a devolution identifier to the sub-variant identifier. Devolution identifiers, like infective length identifiers, are purely numeric. Thus, WM/Rapi.A can, depending on how it replicates, drop some macros but still remain infective. This devolved form is known as WM/Rapi.A1, and in this particular case it can, in turn, replicate while shedding more macros but still remain recursively replicative in that new form. This second devolved form is known as WM/Rapi.A2. In a slightly different form of devolution, W97M/Eight941.A can devolve in two different ways, one giving rise to the W97M/Eight941.A1 devolution while the other devolution path produces the W97M/Eight941.A2 variant. Neither can devolve further and neither can return to the standard W97M/Eight941.A form without ‘outside help’.
Note that the ‘cannot return to the original complete macro set’ condition is crucially important. WM/Johnny.A was initially considered a devolving virus, but antivirus researchers later ‘retired’ its devolved forms because subsequent replication of those forms sees the virus ‘revert’ to its standard form. Devolved forms of some viruses revert to the complete ‘parent’ form if re-replicated on systems infected with the parent form. These are still considered true devolutionary forms however, if the devolved form does not revert when samples of the devolved form are replicated in a clean environment (as would naturally occur should an infected, devolved sample be transferred from an infected machine to a non-infected one).
There is no strong advice on assigning devolution identifiers other than they must start from ‘1’ for the first devolution of a variant and progress monotonically from there. Conventionally, devolutions that ‘proceed’ generationally (perhaps ‘regress’ would be better!), as in the WM/Rapi.A case, should be assigned devolution identifiers that trace those generations. Thus Rapi.A, .A1 and .A2 follow the generational devolution — .A begat .A1 which begat .A2.
In the W97M/Eight941.A case there is no obvious similar rule to apply — neither devolved form precedes the other ‘generationally’ and there is nothing else in this case that strongly suggests one or the other devolution ‘logically’ precedes the other.
A FSMN will include a devolution number only when such a number is necessary. In theory, the default devolution value is ‘0’, but this must never be specified for non-devolving viruses. The presence of the devolution number indicates important information to a researcher about aspects of the virus’ replication mechanism and thus specifying a value of ‘0’, other than for the ‘complete’ form of a devolving variant is misleading, as the presence of the number does not imply anything special about the virus. Thus, for practical reasons, the default devolution value should be considered to be null. If a devolution number is specified, it must only be used for viruses that are devolved forms or that can devolve in their natural environment — it is incorrect to specify will include a devolution number only when such a number is necessary. in theory, the default devolution value is ‘0’, but this must never be specified for non-devolving viruses. the presence of the devolution number indicates important information to a researcher about aspects of the virus’ replication mechanism and thus specifying a value of ‘0’, other than for the ‘complete’ form of a devolving variant is misleading, as the presence of the number does not imply anything special about the virus. thus, for practical reasons, the default devolution value should be considered to be null. if a devolution number is specified, it must only be used for viruses that are devolved forms or that can devolve in their natural environment – it is incorrect to specify .html ‘FooBar’ .A0 if ‘FooBar’ .A cannot devolve. A purist may wish to use the ‘.A0’ form to differentiate precise identification of the ‘parent’ form from its devolved ‘offspring’, separating such usage from cases where ‘.A’ is used to mean all forms of a devolving variant. Because of the potential confusion between the written forms ‘.A0’ (‘a-zero’) and ‘.AO’ (‘a-oh’), such reports in consumer-level products are strongly contraindicated.
When it comes to reporting detection of devolving viruses, products need not report the devolution number of a specific sample. Simply reporting WM/Rapi.A, regardless of whether the specific instance is .A, .A1 or .A2 is seldom of any consequence to the user of antivirus software. Devolution numbers are a required part of an "FSMN only when you are precisely identifying a specific sample of a virus. Thus, ‘virus://W97M/FooBar.A’ is the correct FSMN for the devolving Word VBA virus only when you are precisely identifying a specific sample of a virus. thus, ‘virus://w97m/foobar.a’ is the correct fsmn for the devolving word vba virus .html FooBar.A and ‘virus://W97M/FooBar.A’ (or ‘virus://W97M/FooBar.A0’) and ‘virus://W97M/FooBar.A1’ are only used as FSMNs when you must clearly identify the different forms of a devolving virus.
Note that as devolution is a function of (imperfect) replication mechanisms or of platform design, devolution identifiers can only apply to viral malware. Further, a devolution identifier is a (rare) component part of a complete sub-variant identifier and thus does not have its own delimiter. Thus, a devolution identifier can only appear after a sub-variant identifier — a name such as W97M/FooBar.1 (perhaps intended to indicate all first generation devolutions of the FooBar family) is plain wrong and must never be used.
Finally, be aware that a few developers have incorrectly adopted devolution sub-variant naming for other purposes. The most common form of this is to use a devolution identifier to indicate a piece of malware that was originally the named sub-variant but has been modified due to a cycle of parasitic virus infection and imperfect disinfection or other environmental effects rendering the sample different but without affecting the process and function of the malware. This non-standard naming practice is frowned upon and should not be copied from the vendors that have adopted it.