💾 Archived View for spam.works › mirrors › textfiles › virus › smallvir.txt captured on 2023-06-16 at 21:04:38.
-=-=-=-=-=-=-
The Smallest Virus I Could Manage
In Nuke InfoJournal #5 I foolishly boasted about a 387-byte TSR COM/EXE
parasitic infector I'd written.. well the days of semi-lameness are gone
(that was almost 2 years ago now) and I've come up with the goods.
This is the smallest virus I could figure out at this point in time.
In all respects it's a fully viable spreader in the wild, although it
does have serious 'security' problems - it doesn't trap i24 (critical
error handler), clean registers before returning control to the host, or
even use i21 functions by chaining on to the old vector (it calls i21
with an INT instruction). I have no pretences in that I fully don't
expect to see this in the wild, since it was only written for
investigative pleasure anyway, to see how small a virus could be
written.
There was another version of this virus which I gave out to a few people
on #virus, which had a slight bug (rather, hasty oversight) in it, where
I changed a bit of code and didn't change a corresponding line a few
lines later.. which results in the i21 vector being partially
overwritten and thus the machine will crash (bad side effect!), which
was 291 bytes. The difference between this virus and the 'old' one is
that this one doesn't change the target EXE file's stack, simply leaving
it and negating the need to carry the extra 4 bytes around with the
virus, as well as cutting code size. Also, the 'old' one didn't trigger
any heuristic flags whereas this one does. (see below)
This virus is a memory-resident parasitic infector of COM and EXE files
on execution, 263 bytes. It doesn't reinfect memory OR files.
The older revision (sm2.asm, and the bug-fix, sm2b.asm) avoided all
heuristic flags (except maybe suspicious stack); it inserted the delta
offset straight into the first instruction of the virus, instead of
doing the usual 'call $+3/pop si/sub si,3'. However this just took up
too much code and besides, it's going to get caught anyway, so why
bother. So in this version it was removed, but the lines are only
commented out. If, for some reason, you want to re-enable the old
system, uncomment the appropriate lines and delete the lines with only a
semicolon after them (ie not the ones with actual comments!). Enabling
this will bring the virus size up to all of 268 bytes.
In its current form I think it's as optimized as I can make it. Apart
from the odd 1-byte improvement, any difference would require a change
in viral architecture. Some hardcore processorhead would have to do it,
perhaps they'd get a virus of 260 bytes.. but below that, I'm sure it'd
have to be deficient or unreliable in some respect (as far as I can
rationally extrapolate, judging how limited this virus is in avoiding
detection). I'm certainly not saying that a smaller virus cannot be
written, however, because it's probably possible. If I could see how,
though, I'd do it! :) Making this smaller would require the removal of
'safety' checks (eg bailing if the file can't be opened, bailing if the
file is less than 24 bytes, etc). However I consider these checks to be
part of a viable virus, so I left them in.
There isn't a great deal of commenting on this virus. A few of the
techniques just aren't applicable to viruses of the normal kind, so
there's no real point. To gain anything much out of examining this
source you more or less have to have a good idea of what's going on
anyway.
Greets on this one go out to Dark Angel (you know why) :> ..
- T?L?N 01/95