🚀 go-pugleaf

Ross: It would be interesting if you, Frisk, & I ever get together
at a bar but they'll have to provide a padded room & unbreakable glasses.

>From:    microsoft!c-rossgr@uunet.uu.net

>>From:    mrs@netcom.com (Morgan Schweers)
>>
>>    *Chuckle* It's a variant of the Flip virus, actually.  A bit of
>>psuedo-encryption code was added, and a bit of infection code was
>>removed, but otherwise it's mostly flip-like.

>Interesting phrase, "psuedo-encryption". What, exactly, does it mean?

(Can't help myself, this is too much like "mock-swedish") Given that
encryption covers both codes (breakable) and cyphers (less so), it
would follow that a "pseudo-encryption" is neither a code nor a cypher
but looks like one. EBCDIC & BAUDOT would probably fall into that
category as would the raw output from most word processors. For that
matter, a DEBUG U(nassemble) of a Master Boot Record) is gibberish to
one who does not understand the conditionals but makes perfect sense
once the constraints are understood. The output from a "Little Orphan
Annie Secret Decoder Ring" would not be "pseudo" since it produces a
real (though trivial) code.

>Sorry: I don't count "wild card" strings as a search pattern.  There's
>too much chance for false positives.

Why do you disagree with "wild cards"? For example, if I find a boot
sector that contains MOV AX,[413] <some code> MOV [413],AX I would
suspect a virus reguardless of what went on in the <some code> area.
To me a variable length "wild card" to replace <some code> would be
very useful in this case.

I agree that the potential for false positives exists, but as an
intial mechanism that determines a maxterm/minterm decision tree
structure or to provide a public signature without revealing to much
of the viral design, such a "wild card" function would be very
effective.

				Warmly,
					Padgett