In the early part of this year, W32.Blackmal.E@mm and OSX.Leap.A received near blanket coverage from the technical media. W32.Blackmal.E@mm was a mass-mailing worm with two particular features that ensured it quickly became a focus of attention. When run, the worm would execute a Web-based php script, which was intended to function as an infection counter. Cue the daily tech-blog updates: "Clock ticking for Nyxem virus" (Slashdot), "Blackworm worm over 1.8 million infestations and climbing" (Sunbelt). Even the fancy animated .gifs of a counter shot up from 398,000 to 440,000 in seconds (F-Secure). Couple this with the fact that the worm was programmed to delete files with a number of common extensions on the third of the next month, and there's a storm a brewin': "Kama Sutra worm seduces PC users" (cnet), "Countdown for Windows virus" (BBC), "Urgent Alert raised for Blackworm D-Day" (Eweek), "Kama sutra wipeout" (The Register).
OSX.Leap.A was a worm intended for Macintosh OSX. It was intended to spread to iChat contacts and infect recently used executable files on the system. As the first major OSX threat, and a file infecting IM worm at that, it found itself in the full glare of the media: "Macs no longer immune to viruses" (MSNBC), "Malicious worm aims to bite Apple" (BBC), "First Mac OS X Malware infects via iChat" (Techweb).
So, what did these two threats have in common? Well, for one, they both had critical bugs in key parts of their code that hindered – and in the case of some functionality, completely stopped – their ability to work as intended. In this paper that I presented at the recent VB2006 conference, we take a look at bugs in a number of viruses in the wild. We examine the bugs themselves and what impact they had on the threats’ ability to execute on their goals. We also look at what we can learn from these bugs and how it can influence what we do when we analyze new samples.