Multipartite Infection ~~~~~~~~~~~~~~~~~~~~~~ OK, you've seen them floating around... these whiz-bang you-bewt mongrel viruses which never seem to go away, even after you disinfect every file in existence... Huh... How the fuck did that come back?! Well it's really quite simple, and I'm sure not all of you out there are complete idiots. The fact is that the virus isn't even in any files! ...It's hiding in the partition table, or the boot sector! There are only a few viruses out there with the capability for multipartite infection, or "boot/file virus". Tequila, Anthrax and Invader are a few examples. My own creation, D�eM��n, is another, going a step further than any other boot/file virus has ever gone before, by infecting almost everything possible. The principle is VERY simple, in fact I kicked myself when I worked out a way to do it. The idea is simple, and it's the very same principle employed in any other TSR method... to hook interrupt 21h (DOS). This is fine. BUT the only hitch is that DOS automatically overwrites the old vector when it loads! So there's no point hooking it as soon as your code loads up off the disk. So what can we do? We will obviously have to wait for DOS to change the interrupt, so we can hook it. But there's one problem! Other stupid programmers were being selfish and change the i21 pointer as a marker so that they can tell if it's been changed... like Invader puts in a -1 in the IP value of int 21h... so if something like DaeMaen is also on the sytem, it thinks it's DOS changing the pointer, hooks it and crashes the entire system... The way I waited for the pointer to change was to hook interrupt 13 TWICE! (huh?) Pretty simple. What I did was have my int-check routine hooked onto i13 first, then my i13 handler over the top. The reason why you can't have it the other way is that in case another "program" hooks i13 over the top, and you can't disable your int-check routine... so it'll keep re-hooking and fuck up the system. (You could do it with flags, but I try and use as few flags as possible to keep code size down to a minimum). At boot-up, the program checks to see if it's already TSR (via an illegal call to some interrupt, and checking the return code) and if it isn't, it steals some memory (something F-Prot and friends can pick up, but who gives a fuck, plus I can get around that now...), hooks int 13h with the int-check routine, hooks it again with our i13 handler, then save the current interrupt 21h vector. On every disk call, it compares the value of i21 with the saved value... if it's different, the int-check routine hooks it and then change the vector that our int 13h handler calls, so it no longer calls our int-check routine but goes straight to the real i13. That's the essentials of boot/file management. Anyhow, here's the code to do what I just said, as it appears in the source code of D�eM��n... new13_2: ; the guts of multipartite infection ; check to see if i21 has changed... if so, hook it call save ; save registers push cs pop es xor ax, ax mov ds, ax mov si, 21h*4 mov di, offset oldvect+8 cld cmpsw je nochange cmpsw je nochange call capture_21 push cs pop ds mov si, offset oldvect+0 ; copy over other ptr so lea di, [si+4] ; that our i13 doesn't call movsw ; here any more [i21 has movsw ; been hooked] nochange: call restore ; restore registers jmp dword ptr cs:[oldvect+0] This method can be used on either floppy boot sector infection or the HD partition table infection. As with many of my routines, stuff which took many other virus writers a few pages of code took me one page... that's not bad! I have many other goodies up my sleeve, like a 387-byte generic COM/EXE parasitic infector on execution, the smallest of its kind in the WORLD... (with room for improvement!). Anyway, next InfoJournal will include the source codes to two of my prerelease Mutation Engines, both of which are fully functional in their own right. They have evolved far beyond my dreams, and I hope to have the world's best mutation engine finished by the end of February/March. (but it can't be the best at everything, but it sure generates a bucket fuckload of arcane bullshit instructions. Heuristical nightmare...) Anyway, have fun screwing around with this little piece of research material... T�L�N/NuKE