VX Heaven

Library Collection Sources Engines Constructors Simulators Utilities Links Forum

Source code of computer viruses

Cabanas - Virus for Windows by Jacky Qwerty

Virus for Windows

Jacky Qwerty
Show all viruses by this author


Download (28377 bytes) or browse online

Author's notes

I'm very proud to introduce the first "resident" WinNT/Win95/Win32s virus. Not only it's the first virus stayin resident on NT, but is also the first with stealth, antidebuggin and antiheuristic capabilitiez. In short wordz, this babe is a "per process" memory resident, size stealth virus infecting Portable Executable filez on every existin Win32-based system. Those who dont know what a "per process" resident virus is, it means a virus staying resident inside the host Win32 aplication's private space, monitoring file activity and infectin PE filez opened or accesed by such Win32 aplication.

The purpose of this virus is to prove new residency techniquez that can be exploited from genuine Win32 infectorz, without all the trouble of writing especific driverz for Win95 (VxDs), and WinNT. A genuine Win32 infector is a virus bein able to work unmodified across all Win32 platformz available: Win95, WinNT and any other future platform suportin the Win32 API interface. So far only Win95 especific virusez have been found, not Win32 genuine onez. Make sure to read the complete description about Win32.Cabanas written by Peter Szor, available at U can also read description by Igor Daniloff from Dr.Web, available at as well.

After readin Peter Szor's description about Win32.Cabanas, i realized he'd really made a very serious profesional work. So good that he didnt seem to miss any internail detail in the virus, as if he had actually writen the bug himself or as if he was actually me, hehe. Obviosly, none of the prior onez are true. But, nevertheless, i think it's worth to take his work into account even from the VX side of the fence. Really i dunno what's left for me to say after such description, so i will simply add my own personal comentz to Peter's log. Erm.. btw why dont u join us? heh >8P

Technical Description

Win32.Cabanas is the first known 32-bit virus that works under Windows NT Server, Windows NT workstation, Windows 95 and Windows 3.x extended with Win32s sub-system. It was found in late 1997.

Win32.Cabanas is a per-process memory resident, fast infecting, antidebugged, partially packed/encrypted, anti-heuristic, semi-stealth virus. The "Win32" prefix is not misleading, as the virus is also able to spread in all Win32 based systems: Windows NT, Windows 95 and Win32s. The author of the virus is a member of the 29A group, the same young virus writer who wrote the infamous CAP.A virus.

Running an infected PE file

When a Win32.Cabanas infected file is executed, the execution will start at the original host entry point. Surprisingly, Cabanas does not touch the entry point field in the Image File Header. Instead it patches the host program at its entry point. Five bytes at the entry point is replaced with a FAR JMP to the address where the original program ended. This can be considered as an anti-heuristic feature, as the host entry point value in the PE header keeps pointing inside the code section, possibly turning off some heuristic flags.

Thus the first JMP points to the real entry point. The first function in Cabanas unpacks and decrypts a string table which consists of Win32 KERNEL API names. The unpack mechanism is simple but effective enough. Cabanas is also an armored virus. It uses "Structured Exception Handling" (typically abbreviated as "SEH") as an anti-debug trick. This prevents debugging from any application-level debugger, such as TD32.

When the unpack/decryptor function is ready, the virus calls a routine to get the original Base Address of KERNEL32.DLL. During infection time, the virus searches for GetModuleHandleA and GetModuleHandleW API in the Import Table, respectively. When it finds them, it saves a pointer to the actual DWORD in the .idata list. Since the loader puts the addresses to this table before it executes the virus, Cabanas gets them easily.

If the application does not have a GetModuleHandleA / GetModuleHandleW API import, the virus uses a third undocumented way to get the Base Address of KERNEL32.DLL by getting it from the ForwarderChain field in the KERNEL32 import. Actually this will not work under Windows NT, but on Win95 only. When the virus has the Base Address/Module Handle of KERNEL32.DLL, it calls its own routine to get the address of GetProcAddress function. The first method is based on the search of the Import Table during infection time. The virus saves a pointer to the .idata section whenever it finds a GetProcAddress import in the host. In most cases Win32 applications import the GetProcAddress API, thus the virus should not use a secondary routine to get the same result. If the first method fails, the virus calls another function which is able to search for GetProcAddress export in KERNEL32. Such function could be called as GetProcAddress-From-ExportsTable. This function is able to search in KERNEL32's Exports Table and find the address of GetProcAddress API.

This function is one of the most important ones from the virus point of view and it is compatible with all Win32 based systems. If the entry point of GetProcAddress was returned by the GetProcAddress-From-ExportsTable function, the virus saves this address and use it later on. Otherwise, the GetProcAddress-From-ExportsTable function will be used several times. This function is also saved with "Structured Exception Handling" to avoid from possible exceptions. After this, the virus gets all the API addresses it wants to use in a loop. When the addresses are available, Cabanas is ready to replicate and call its direct action infection routine.

Direct action infection

The direct action infection part is surprisingly fast. Even though the virus goes through all the files in Windows directory, Windows System directory and in the current directory respectively, the file infection is fast enough to go unnoticed in much systems. This is because the virus works with "memory mapped files", a new feature implemented in Win32 based systems which simplifies file handling and increases system performance.

First the virus gets the name of Windows directory, then it gets the name of Windows System directory and calls the function which searches for non- infected executable images. It searches for non directory entries and check the size of the files it found.

Files with size dividable by 101 without reminder are assumed to be infected. Other files which are too huge will not be infected either. After this, the virus checks the file extension, if it matches EXE or SCR (screen saver files), the virus opens and maps the file. If the file is considered too short, the file is closed. Then it checks the`MZ' marker at the beginning of the image. Next it positions to the possible `PE' header area and checks the `PE' signature. It also checks that the executable was made to run on 386+ machines and looks for the type of the file. DLL files are not infected.

After this, the virus calculates a special checksum which uses the checksum field of PE files Optional Header and the file-stamp field of the Image File Header. If the file seems to be infected the virus closes the file. If not, the file is chosen for infection. Cabanas then closes the file, blanks the file attribute of the file with SetFileAttributeA API and saves the original attributes for later use. This means the virus is not stopped by the "Read Only" attribute. Then again, it opens and maps the possible host file in read/write mode.

Next it searches for the GetModuleHandleA, GetModuleHandleW and GetProcAddress API imports in the host Import Table and calculates pointers to the .idata section. Then it calls the routine which patches the virus image into the file.

This routine first checks that the .idata section has MEM_WRITE characteristics. If not it sets this flag on the section, but only if this section is not located in an executable area. This prevents the virus from turning on suspicious flags on the code section, triggered by some heuristic scanner.

Then it goes to the entry point of the image and replaces five bytes with a FAR JMP instruction which will point to the original end of the host. After that it checks the relocation table. This is because some relocations may overwrite the FAR JMP at the entry point. If the relocation table size is not zero the virus calls a special routine to search for such relocation entries in the .reloc area. It clears the relocation type on the relocation record if it points into the FAR JMP area, thus this relocation will not take into account by the loader. The routine also marks the relocation, thus Cabanas will be able to relocate the host later on. Then it crypts all the information which has to be encrypted in the virus body. Including the table which holds the original 5 bytes from the entry point and its location.

Next the virus calculates the special checksum for self checking purposes and saves this to the time stamp field of the PE header. When everything is ready, the virus calculates the full new size of the file and makes this value dividable by 101. The real virus code is around 3000 bytes only but the files will grow with more bytes, because of this. Cabanas has a very important trick here. The virus does not create a new section header to hold its code, but patches the last section header in the file (usually .reloc) to grow the section body large enough to store the virus code. This makes the infection less risky and less noticeable.

Then the virus changes the SizeOfImage field in the PE header to reflect the changes made to the last section in the file, then unmaps and closes the file. Next it truncates the file at the previously calculated size and restores the original time and date stamp. Finally Cabanas resets the original attribute of the file. When all the possible files have been checked for infection, Cabanas is ready to go memory resident.

Rebuild the host, Hook API functions and Go memory resident

The next phase is to rebuild the host program. The virus locates an internal parameter block which consists of the previously encrypted code from the host (5 bytes) and writes back the 5 original bytes at the entry point. After this, it relocates the code area if needed, by searching in the .reloc section for marked relocation entries. Next the virus hooks API functions and goes memory resident.

The API hooking technique is based on the manipulation of the Import Table. Since the host program holds the addresses of imported functions in its .idata section, all the virus has to do is to replace those addresses to point to its own API handlers.

To make those calculations easy, the virus opens and maps the infected program. Then it allocates memory for its per-process part. The virus allocates a 12232 bytes block and copies itself into this new allocated area. Then it searches for all the possible function names it wants to hook: GetProcAddress, GetFileAttributesA, GetFileAttributesW, MoveFileExA, MoveFileExW, _lopen, CopyFileA, CopyFileW, OpenFile, MoveFileA, MoveFileW, CreateProcessA, CreateProcessW, CreateFileA, CreateFileW, FindClose, FindFirstFileA, FindFirstFileW, FindNextFileA, FindNextFileW, SetFileAttrA, SetFileAttrW. Whenever it finds one of the latter APIs, it saves the original address to its own JMP table and replaces the .idata section's DWORD (which holds the original address of the API) with a pointer to its own API handlers. Finally the virus closes and unmaps the host and starts the application, by jumping into the original entry point in the code section.

Some Win32 applications however may not have imports for some of these file related APIs, they can rather retrieve their addresses by using GetProcAddress and call them directly, thus the virus would be unable to hook this calls. Not so fast. The virus also hooks GetProcAddress for a special purpose. GetProcAddress is used by most applications. When the application calls GetProcAddress the virus new handler first calls the original GetProcAddress to get the address of the requested API. Then it checks if the Module Handle parameter is from KERNEL32 and if the function is one of the KERNEL32 APIs that the virus wants to hook. If so, the virus returns a new API address which will point into its NewJMPTable. Thus the application will still get an address to the virus new handler in such cases as well.

Stealth and fast infection capabilities

Cabanas is a semi-stealth virus: during FindFirstFileA, FindFirstFileW, FindNextFileA and FindNextFileW, the virus checks for already infected programs. If the program is not infected the virus will infect it, otherwise it hides the file size difference by returning the original size for the host program. During this, the virus can see all the file names the application accesses and infects every single clean file.

Since the CMD.EXE (Command Interpreter of Windows NT) is using the above APIs during a DIR command, every non infected file will be infected (if the CMD.EXE was infected previously by Win32.Cabanas). The virus will infect files during every other hooked API request as well.

Apart from the encrypted API names strings, the virus also contains the following copyright message:

(c) Win32.Cabanas v1.0 by jqwerty/29A.


Win32.Cabanas is a very complex virus with several features new in Win32 based systems. It shows quite interesting techniques that can be used in the near future. It demonstrates that a Windows NT virus should not have any Windows 95 or Windows NT especific functionality in order to work on any Win32 system. The "per-process" residency technique also shows a portable viable solution to avoid known compatibility issues between Windows 95 and Windows NT respecting their low level resident driver implementations. Virus writers can use these techniques and their knowledge they have had on Windows 95 to come to a more robust platform. So far Win32.Cabanas has made this first step.

Who was Cabanas?

Gonzalo Cabanas used to be a daydream believer. We shared several thingz in comon, heard same R.E.M music style, wore the same ragged blue jeanz, and behaved like kidz everywhere we went together, putin tackz on the teacher's chair, stealin some classmate's lunch and so on. We even liked the same girlz, which explains why we sometimez ended up punchin each other's face from time to time. However, u could find us the next day, smoking around by the skoolyard as if nothin had ever hapened. We were the best friendz ever. I know this virus wont return him back to life, nor "will do him justice", however, i still wanted to somewhat dedicate this program in his honor.

By accessing, viewing, downloading or otherwise using this content you agree to be bound by the Terms of Use! aka