informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/virus/DOCUMENTATION/daemaen.txt

159 lines
12 KiB
Plaintext
Raw Normal View History

Initial commit
2021-04-15 11:31:59 -07:00
D<EFBFBD>eM<EFBFBD><EFBFBD>n Virus <20>
~~~~~~~~~~~~~ <20>
<20>
This virus took me a while to write (about two weeks), because I was <20>
writing a lot of it for the first time. Some of the code is a bit <20>
overboard, like I don't think the SYS entry has to be quite that complex <20>
in order to work... but never mind. At least it works and it's quite <20>
well-behaved. <20>
<20>
This virus is my first boot/file virus, and that also works perfectly. <20>
I worked all my own routines from scratch (my virus collection is <20>
extremely small, and I don't want to be influenced by other <20>
implementations unless they're better). <20>
<20>
It infects both floppy boot sectors, moving the original boot sector to <20>
the 5th last sector of the disk and writing the virus code on the last <20>
four. It also infects the Master Boot Record (partition table) on the <20>
first physical hard disk. Booting off an infected floppy will infect <20>
the MBR, as will the execution of an infected file. However, trying to <20>
read the partition table results in the redirection of the call, <20>
resulting in the original partition table (prior to infection) being <20>
read/written. <20>
<20>
Floppies are infected on read/write access, and won't be infected if the <20>
drive is still spinning (ie. no disk change). It will take the boot <20>
sector and use the BPB to calculate the last sectors of the disk, no <20>
matter what format, be it 160k, 1.44meg, or even a 20meg floptical disk. <20>
It makes sure it's a valid BPB by checking the OEM name to see if it's <20>
valid alphanumeric characters, but I was a bit selfish in that I overwrite <20>
the last word of OEM to mark infection. <20>
<20>
Files ending with the extensions .COM, .EXE, .BIN, .OVL and .SYS will be <20>
infected on every possible file handle access I could find, ie. they <20>
will be infected on Open (3D), Close (3E), Attrib Change (43), Execution <20>
(4B), Handle Rename/Move (56), and Extended Open (6C). It manages to <20>
infect on file close by recording the filename by intercepting Create <20>
(3C) call, and the handle if it was created successfully. <20>
<20>
If resident off infected file, it will not hook int 13h directly, <20>
instead searching segment 70h for DOS's call to the original interrupt <20>
handler, then putting our address in there instead and using the old <20>
address for our calls. It would have been possible to search the ROM <20>
BIOS for the correct handler, but that would circumvent future <20>
generations of boot/file viruses. <20>
<20>
D<EFBFBD>eM<EFBFBD><EFBFBD>n employs a small decryption algorythm, however it is not variable <20>
mutation, since a few registers have to be saved in order for the SYS <20>
infection to work. The code is thoroughly encrypted, and McAfee and <20>
friends will have to write a new disinfection engine for this baby. <20>
However, disk infections are not encrypted, although it would have been <20>
easily done. <20>
<20>
The routine to load the virus off the disk has been altered to avoid <20>
detection as Generic Boot Sector/Generic Partition virus. The changes <20>
are trivial, and it makes it look as if I don't know what I'm doing. <20>
The fact that I'm avoiding detection isn't readily apparent. Here is <20>
a code comparison, take a look for yourself. <20>
<20>
Generic D<>eM<65><4D>n <20>
mov si, 413h mov si, 412h <20>
sub word ptr [si], 3 add word ptr [si+1], -3 ; take 3k <20>
int 12h lodsb <20>
lodsw <20>
mov cl, 6 mov cl, 6 <20>
shl ax, cl shl ax, cl <20>
mov es, ax mov es, ax <20>
xor bx, bx xor bx, bx <20>
<20>
The one on the left will be detected by SCAN, the one on the right will <20>
not. The differences are trivial. SCAN is such a stupid program, it's <20>
just ridiculous that millions of PC users rely on it utterly for total <20>
virus protection. That's great... <20>
<20>
D<EFBFBD>eM<EFBFBD><EFBFBD>n is partially selective in which files it infects. Firstly, it <20>
will scan the filename for the characters SC, VS, CL and F-, which <20>
excludes a lot of scanners (eg SCAN, TBSCAN etc), VSHIELD, CLEAN and <20>
F-PROT. <20>
<20>
Nor will it infect programs which have internal overlays. This is a <20>
great advantage since people running WinDoze won't have their favourite <20>
XYZ program fuck up because a virus infected it. D<>eM<65><4D>n simply will <20>
not infect programs with internal overlays. Here is the code to detect <20>
them: <20>
<20>
chkovl: call file_end <20>
push ax ; check for internal overlays <20>
push dx <20>
mov ax, word ptr [page_cnt] <20>
mov cx, 512 <20>
mul cx <20>
pop cx <20>
pop bp <20>
cmp ax, bp <20>
jb done <20>
cmp dx, cx <20>
jb done <20>
[...] <20>
done: ret <20>
<20>
Pretty simple routine, huh? <20>
<20>
The beauty of this beast is that one small mistake, like trying to boot <20>
an infected disk by accident, or perhaps running an infected file, is <20>
that next time you boot up your system, EVERY file in your CONFIG.SYS, <20>
AUTOEXEC.BAT and everything henceforth will become infected! It is very <20>
easy to expose a large number of files to the virus in a very short <20>
space of time. Again, SCAN will probably help the spread of this virus <20>
immensely, by stupid users scanning their HD habitually, with the virus <20>
in memory... of course, EVERY file will then be infected. <20>
<20>
As if that weren't enough for one virus, D<>eM<65><4D>n will also hide the <20>
increase of file size on the DOS directory. However, like most other <20>
viruses which employ this stealth method, CHKDSK will not report any <20>
allocation errors on these files. File size increase will be only 2048 <20>
bytes, or 4096 bytes for SYS files. It will account for the different <20>
increase of the SYS. <20>
<20>
To hide the increase, D<>eM<65><4D>n employs a little-exploited method, which <20>
is by adding 100 years to the date of the file. This way, other <20>
over-exploited methods (like setting the seconds field to a certain <20>
value) will not interfere with D<>eM<65><4D>n's stealth operation, and <20>
vice-versa. <20>
<20>
D<EFBFBD>eM<EFBFBD><EFBFBD>n also includes a number of text strings: <20>
<20>
"[D<>eM<65><4D>n] by T<>L<EFBFBD>N-{N<>K<EFBFBD>}" 25 bytes <20>
"Hugs to Sara Gordon" 19 bytes <20>
"Hey John! If this is bad, wait for [VCL20]!" 43 bytes <20>
"For Dudley" 11 bytes <20>
"[VCL20<32>]/T<>L<EFBFBD>N" 15 bytes <20>
total 113 bytes <20>
<20>
(That stuff about VCL20<32> is <20>ogus, just to make McAsshole shit his <20>
pants. But AV researchers be warned: a fair few of the routines <20>
contained in D<>eM<65><4D>n will also appear in VCL 2.0, like the boot/file <20>
infect capability!) <20>
<20>
Virus Length = 2048 <20>
Message Length = 113 <20>
...Code Length = 1935 bytes!!! <20>
<20>
Totally unheard of! <20>
<20>
I seriously doubt anybody can beat that, at least not for a while yet. <20>
<20>
For a quick rehash of what this virus does... <20>
<20>
COM/EXE/BIN/OVL/SYS/MBR/BS Parasitic Self-Encrypting Stealth virus, a <20>
mere 2048 bytes long... but I can say Patricia Hoffman will totally fuck <20>
up her description of this virus, she is so pathetically brain-dead. <20>
<20>
Anyway, look out for a FULL STEALTH, WILDLY POLYMORPHIC COM/EXE/MBR <20>
INFECTOR coming soon to a computer installation near you! From T<>L<EFBFBD>N of <20>
course! And another one minus the polymorphism, under 800 bytes! <20>
<20>
Have fun! And good night, John! <20>
<20>
T<>L<EFBFBD>N/NuKE <20>