Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!lll-winken!uwm.edu!zaphod.mps.ohio-state.edu!ncar!tank!msuinfo!netnews.upenn.edu!vax1.cc.lehigh.edu!cert.sei.cmu.edu!krvw From: utoday!greenber@uunet.UU.NET (Ross M. Greenberg) Newsgroups: comp.virus Subject: Re:Signature Programs Message-ID: <0004.9004131250.AA02586@ubu.cert.sei.cmu.edu> Date: 11 Apr 90 21:08:48 GMT Sender: Virus Discussion List Lines: 59 Approved: krvw@sei.cmu.edu >My personal feeling is that an authentication algorithm may be very >simple (CRC or less) provided that it is unknown (or unpredictable). >Since my 4.77 Mhz/ST-412 museum piece is capable of a simple byte >count/XOR/ROR disk file check at 50k bytes/second (and could be faster >if done in RAM by a TSR between LORD and EXECUTE), performance >concerns are unnecessary (quantum economics). This method is suitable >for any physically controlled system. > >Unfortunately, Mr. Greenberg's algorithm fails this test because it is >publicly known. A mechanism designed to subvert his programs is >feasible (worm, trojan, virus, bomb, etc.). However, given a small >number of different algorithms (ADD/SUB/XOR followed by ROL/ROR/NOP >give nine easily) generated by a machine-unique seed (time hack at >initial algorithm load would work), a non-resident intruder would have >a very hard time subverting a system without generating a few errors >first. Sorry: although it would be easy to ascertain via disassembly the particluar method I use in my code for generating a signature, I would hope that the bad guys are as easily fooled by someone using the word "Checksum" or "CRC" as you were. My signature code stuff is proprietary and has never been released to anyone. I use the word "checksum" or "CRC" loosely because it's easier to say than "an assortment of instructions that merely generate a unique number based upon a stream of input with no real formal basis for figuring out just how good the particular algorithm issince it seems good enough so far." >This is particularly effective if even the creator of such a program >cannot predict which algorithm/seed will be used on a particular >machine. I may include such a random seed in the future, but it seems pretty easy to be able to determine that seed and therefore why bother? Remember that DOS isn;t really an operating system anyway and it would be pretty easy for someone to subvert *any* signature generating code easily. Better still would be to use two differing algorithms that combine into one unique signature. >However, over 90% of all PC virii could have been caught early by a >CLI that occasionally compares the Top-Of-Memory, the end of DOS/TSR >memory, and the first byte of the Boot Sector against known values. >MS-DOS doesn't. Fascinating number, that 90%. No justification for it from what I can see. And your statement on the Boot Sector's first byte being the important one to check is totally wrong. If you could send me the background on that number, I'd apreciate it. I believe none of the numbers I see bandied about regarding viruses. Too easy to slip a decimal point or two, or to extrapolate from a limited subset. Mr. Peterson makes some interesting points. They do not, however, seem conclusive to me. I stand by my earlier statements that a simple algorithm for CRC/signature/checksum checks is "good enough". Ross M. Greenberg, Software Concepts Design, greenber@utoday.UU.NET 594 Third Avenue, New York, New York, 10016 Voice:(212)-889-6431 BIX: greenber MCI: greenber CIS: 72461,3212 BBS:(212)-889-6438