Viridium.ro

Upon releasing my Java virus to major antivirus companies, on the Sun forums, and on computer virus mailing lists, one reply was “your virus is not interesting, because the virus that proved the concept has already been produced”. Well, in defense of my effort, I need to point out that “Strange Brew”, the first Java virus, had its bugs, fact which casts a shadow on the proof. Granted, the bugs in “Strange Brew” were probably fixable, fact which must have restored the credibility of the virus.

Though a proof-of-concept computer virus is mostly a curiosity, I think that a sincere interest for proof-of-concept can’t ignore newer attempts, which may present entirely new answers and approaches to the infection method.

And how about the “first” phenomenon, like “first virus to infect without increasing the size of its host”, or “first Unix shell virus”, “the first, the first, the first”? If the point is proof, then implementation is not the only answer. Sure, a proof-of-concept is proof enough, but, more often than not, proof is at our fingertips without the pains of implementation.

Back in high-school, I had mapped the opcodes of the Intel 80×86 instruction set, largely by creating and disassembling small programs. Later on, I wondered how a multipartite virus could infect both Intel 80×86 and SPARC computing architectures. I had never seen a SPARC, or worked with one, and all I knew about its instruction set was the RISC architecture, with all instructions the same size, and a small code snippet with opcodes from some Unix article. This information alone was enough to prove that a a multipartite virus could be easily produced, even without knowing apriori what platform a program will run. The same viral entrypoint, the same sequence of bytes, could execute on both platforms. I was able to find a sequence of bytes that represented a jump instruction in 80×86 architectures and some harmless instruction that alters a register in SPARC architectures. This sort of “polymorphic” entrypoint would have been sufficient to dispatch to an architecture-specific version of the virus in an elegant manner.

Proof can be achieved in many ways. To assign some importance to the first proof-of-concept implementation, but dismiss those that follow, shows an inconsistency in beliefs akin to hypocrisy. To accept any proof-of-concept implementation when a formal proof is at hand, may well be as incriminating as accepting any computer virus for that matter. The next article says more about how easy it actually is to prove the possibility of computer viruses.