10 likes | 106 Views
Rethinking Viruses in the Archives Jane Gruning/ j ane.gru @ gmail.com / School of Information/UT Austin. Virus Timeline 1974, ANIMAL: "asked a number of questions to the user in an attempt to guess the type of animal that the user was thinking of”
E N D
Rethinking Viruses in the Archives Jane Gruning/jane.gru@gmail.com/Schoolof Information/UT Austin Virus Timeline 1974, ANIMAL:"asked a number of questions to the user in an attempt to guess the type of animal that the user was thinking of” 1983, ARF-ARF:Early Trojan Horse distributed via BBS sites; claimed to be a program that would 'sort' DOS a directory. 1987, Stoned: Early boot sector virus created by a student in New Zealand. 1992, Michelangelo: Activated only on Michelangelo’s birthday - caused a lot of media hype, but did not actually do much damage. 1999, Melissa: An early email 'macro' virus.Thevolume of email it created could overload servers. 2000, ILOVEYOU: This email worm (also known as "Love Letter") was extremely damaging and fast-spreading. 2004, Caribe: The first worm designed to infect mobile phones. 2008, Koobface: A multi-platform worm that spreads via social network (including Facebook, MySpace, Friendster, and Twitter) and turns the target computer into part of a botnet. Current digital archival practice often treats virus checking and quarantine as an unproblematic aspect of ingesting digital objects into an archival repository; it is simply a step in the process, that is often taken before any formal appraisal is done. Viruses are separated from the records , and then forgotten about or perhaps disposed of. In doing this, archives are creating a gap in the history of computers and their use in our society – a gap that we could potentially avoid. Viruses are not only an important part of hacker culture, but they have also affected the ways in which we use the Internet and share digital objects. Archivists need to rethink how we, as a profession, are addressing this issue. Current Practice - virus scan - 'infected' files are quarantined - then what? Potential Problems Safety (of Archives and Users): it would be necessary to develop archival standards for storing viruses safely. Limited Access: viruses would need to be stored in a dark archive (non-networked) and archivists would have to make decisions about who, if anyone, would be allowed to access them. Would currently functional viruses need to be kept closed until they reached obsolescence? Authenticity: keeping the virus supports authenticity because it is part of the original context of the records - but reconstructed 'clean' files are not necessarily authentic. Plus many more! One Possible Path A year ago, I worked on a digital archives project in which my group and I were tasked with retrieving cataloging records from 5.25 inch floppy disks. We made our archival master disk images from the original disks without much trouble, made copies of those to use for record retrieval, and had little difficulty mounting the first two disks to the file system of the computer we were using. After those first two disks, we couldn’t get any other disks in the collection mounted to our computer’s file system. Eventually, we found out that the disks had been infected with a boot-sector virus. Six months later, I began to attempt a reconstruction of a ‘clean’ disk from one of the virus infected disks. I accessed a working copy of the original bitstream of an image of a disk 'infected' with the Stoned virus using a hex editor, and compared it to an image of a clean disk from the same collection. This allowed me to isolate the virus code (represented as ASCII text in the hex editor, shown on the right) and remove it - creating a clean access copy of the infected disk. The original bitstream of the infected disk image has been retained and cataloged with the rest of the collection although it is not available to the public. What is a boot sector virus? Boot sector viruses are a type of virus that was common when personal computers loaded their operating systems from an external disk. All floppy disks have boot sectors. But unless the disk is bootable, the code in that sector just tells the computer that it's not a bootable disk and displays a message such as "non-system disk or disk error." Boot sector viruses move that placeholder boot sector code to another sector on the disk, replace it with their code, and load themselves into the computer's internal memory if a user tries to boot from the infected disk. Once the virus is in a computer, it writes itself to every floppy accessed by the computer. Therefore, it is likely that if one floppy in a collection is infected with this type of virus, many others are as well. "It arrived at MIT in the middle of the night. The students were safe. their computers weren't.” - quote from a 1988 news report on viruses