Malware Example: Virus.DOS.Lichen.1024

MS-DOS

A graphical payload-only simulator of Virus.DOS.Lichen.1024, with its memory-residence and infection routines removed. The actual virus is not dangerous to your system, and its payload goes out of its way to save and restore the state of the system. Truly, Lichen is little more than a self-propagating screensaver. Virus Behavior Based on my own disassembly and analysis. The version here does not exhibit any of these behaviors other than showing the payload. System Requirements Lichen makes a few assumptions about the system it’s running upon. Namely, that said system has the following or compatible: MS-DOS 2.0 or later Must also be a version with the ability to seek backward while reading files from disk. As far as I know, this may or may not be supported in all versions of DOS. 32-bit x86 processor (i386 and later) VGA graphics card Extended memory support (HIMEM.SYS) The virus remains infectious if not available, but does not show its payload. None of these features are uncommon, so Lichen should work on most systems. If running Lichen on real hardware, you may have better luck with slightly newer boxes, as you will need a later-generation graphics card. Initialization When an infected file is run, the virus overrides int 21h (DOS system services). It forwards most system calls, allowing them to work as normal. The exceptions are ah = 0x4B (exec) and ah = 0x3E (close file). It’s possible to tell if Lichen is present in memory by using int 21h with ah = 0x3E (For service Close File) and bx = 0x1234 (for file handle). Assuming that 0x1234 is not a valid file handle, using this interrupt would normally set cf (Carry Flag), indicating an error. If the interrupt is overridden by Lichen, then it will return early without setting cf . This is how the virus identifies when it’s already memory resident. Lichen knows when the executable it’s loading from was originally infected. If this was a month ago, then it will arm its payload. Infection Lichen infects both .COM and .EXE files as they are run, provided that all of the following are true: The file’s size is between 1600 and 960,000 bytes. (Roughly; it compares against the segment pointer to the end of the file, and segments can overlap.) The seconds field of the file’s modification time is not 61 (or, equally, 62). This seems to have been an attempt at preventing repeat infection of files, because Lichen will try to set files to this time as it infects them, though FreeDOS refuses to do that. Payload The payload will activate when all of the following are true: the system is in graphics mode 0x3 (text, 80×25 chars, 16 colors) it has been one minute since last keyboard activity the XMS extended memory manager (XMM) is installed and running Note that there is a difference between EMS and XMS, though I don’t understand it well. When the payload initializes: All general-purpose registers are saved The states of the mouse and video drivers are saved and moved to extended memory Before the drivers’ states gets copied to extended memory, they’re stored in video memory. Lichen therefore avoids allocating conventional memory, as the video memory gets overwritten in the next step. The system is set to VGA Mode 13h Graphical; 320×200, 256 colors The first 40 palette entries are set to increasingly bright shades of off-gray Because of an interesting programming choice, the colors alternate between slightly yellowish and slightly bluish. A single white pixel is placed in the center of the screen (At least, as close as possible on an even-sized grid.) The main loop then begins, and continues until a key is pressed. See the sections below for a description of how the main loop works. Algorithm The graphical payload is a cellular automaton with a simple rule set. Each pixel has a palette index, corresponding to its brightness. Start with a spore at the center of the screen. In a loop, chose a random pixel. If the pixel is already 0, then continue. Dim the pixel by one index. If the pixel is above 0x17, then For the four adjacent pixels, if that pixel is not zero, then set it to max brightness. When I originally tried to piece together how the algorithm works, I expected that spores would be randomly dropped periodically, and that the amount of them spawned at a time would slowly increase. Surprisingly, I was not able to come across any such code. I did an experiment using a hex editor to make a version where the one bright pixel is never placed, and sure enough, the screen remains totally black, proving that the increasingly intricate follows only from rules of cell spread and decay. In that moment, I was amazed at how elegant this display hack is. The virus’s payload, despite its disorderly appearance, is completely deterministic; its seed (0x00000361) is always identical. Since we just add or subtract one to/from a pixel’s index to get the pixel horizontally adjacent to it, growth will wrap around the side edges. This is not true of the top or bottom edges, as there are dumm