This strain is not encrypted and not malignant. The Additive will detect this strain and repair files damaged by it.
This strain is not encrypted but is malignant. I have never heard of an infection with this strain. The Additive will detect this strain and repair files damaged by it.
This strain is encrypted but not malignant. The Additive will detect this strain and repair files damaged by it.
This strain is encrypted but not malignant. It is symbiotic in the way that all the later strains are. The Additive will detect this strain and repair files damaged by it.
F1
This is pretty much the same as 'E', except that
the static part of the data segment (including giveaway strings like
'Graphics Accelerator') has been moved inside the encrypted portion of the
virus. The author must've read my criticisms in AntiGax (no more criticisms
from now on then! :)
The Additive will detect this strain and repair files damaged by it.
This was analysed by me on 4/3/99.
It seems to be another candidate for the strain F - it's certainly not as advanced as G is. But it's still not the Symantec F.
The payload is the same as G and the activation date is the 6th of any month at 6pm
It only washes out WIND resources (instead of MENUs). But it doesn't only pick the Apple menu to infect - it uses the same braindead strategy as E does. (Lowest ID number)
Also, it will only install the INIT in the system file - but it is aware of other strains and will not infect your system if there is a 'Graphics Accelerator' file around. It has its static data encrypted.
It also has the infecting-nearby-apps feature of G where an infected app will infect all apps & control panels in the same folder as itself, regardless of whether the INIT loaded (i.e. whether or not the system is infected)
The Additive will detect this strain and repair files damaged by it.
I first knew of the possible existence of this strain on 1/3/99, but I didn't manage to get an intact infected app from the reporter until the 8th, twenty minutes after I'd updated the Additive to repair an app sent in by someone else, which was coincidentally infected with the same strain :)
It is byte-for-byte exactly the same as G, except that it only installs the INIT into the system file (as opposed to installing it into variously named extensions). It will not, however, reinfect the system if there is another strain already has (i.e. created a 'Graphics Accelerator' file with an INIT ID 33 in it).
The Additive will detect this strain and repair files damaged by it.
From Symantec's description this looks very like my 'G', except that it splits into substrains of differing sizes, with slightly different behaivour, and there is no mention of it bringing up a window, as G does. The trigger times are the same however. The Additive should detect this strain (and substrains), although they will be reported as unknown strains.
I came across this virus when I visited the SevenDust author's web site (since removed), where he kindly provided source code to all the SevenDust strains. It turns out that my chronology of the previous strains was correct, even if the naming was not - i.e. it goes E,F1,F2,F3,G, but they should be called E,F,G,H,I. So I'm calling this final (at time of download) strain J, as that's what he calls it.
Compared to strain G (or should I say 'I'), this virus is nothing. It is not malicious, it doesn't install any extensions, and its code is not even encrypted. It still uses the hijacking a MENU to point to a different MDEF trick, but it now corrupts a 'STR#' resource instead of a 'MENU'. It is also quite careful that its corruption will not be likely to crash the host program, even if the STR# is used before the MENU is invoked. It will only hijack the Apple menu. It always uses ID 666 for its MDEF.
Its method of infection is also different, in that there is no extension component. It simply searches the volume on which it resides for uninfected applications, and then infects them. It always begins its search from the root, so on large volumes, system performance could be expected to drop as more applications get infected and it takes longer to find uninfected ones.
It does however encrypt the target STR# resource when it appends it to the end of MDEF, with what the author calls 'strong encryption'. He claims that this requires A/V writers to do a full search for the encryption key, and indeed this is what the virus does when decrypting the stored resource. However, the logic behind it is seriously flawed. For encryption purposes, the virus chooses a random byte and xors the string with that. And instead of storing this byte somewhere as past versions did, it only stores the first four unencrypted bytes of the resource. The virus then iterates over the 256 possibile keys and tries decrypting the first four encrypted bytes to see if they match the sample. However, the very same logic which allows it to decrypt and encrypt with the same key (i.e. using xor) can be used to overcome this (admittedly minor) hurdle: The key is simply the first unencrypted byte xor'd with the first encrypted byte! No searching is necessary.
The Additive will detect this strain and repair files damaged by it.
Back to SevenDust info
Back to Agax home page
Last updated 5/7/1999