Mfartura's blog : Tip

Tip: Kernel Debugging a VPC Server

Marcelo Fartura — Wed, 20 Jun 2007 10:16:00 GMT

Here is little tip for you that want to practice kernel mode debugging but either don’t have 2 machine machines to play the TARGET and HOST roles or simply don’t want to play with (for any reason) with the old null modem serial cable used to connect the HOST to the TARGET: It’s possible to use a Virtual PC machine to play the TARGET role, so all you would need is the Virtual PC image correctly configured to boot up in DEBUG mode (through the regular boot.ini options - /DEBUG /DEBUGPORT=COM# /BAUDRATE=115200) and map its serial COM port to a named pipe.

How to do so:

Supposing you already have a Virtual PC image set up (it can be an image of Windows 2000, Windows XP or Windows 2003), you just need to follow the step by step list below:

1. Login as admin in the VPC image and edit the c:\boot.ini file to include a new boot up OS option as following:

A default boot.ini file will likely have the following content:

[boot loader]

timeout=3

default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS

[operating systems]

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect

Edit the boot.ini and add the highlighted line below:

[boot loader]

timeout=3

default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS

[operating systems]

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional – DEBUG" /fastdetect / DEBUG /DEBUGPORT=COM1 /BAUDRATE=115200

2. Before rebooting the VPC image, go the VPC console, select the option “Settings” under the menu “Edit”. Find the configuration item for the COM1 port, select the radio button “Named Pipe” and type the string \\.\pipe\COM1 as the picture below illustrates.

This VPC image (the virtual machine) will be the TARGET system, or the machine whose the kernel will be debugged. Your real machine (the one hosting the VPC image) will be the HOST machine or the one which will run the debugger that will be attached to the TARGET’s system kernel.

3. Start a Windbg (from the Debugging Tools For Windows) instance with the following command line options:

windbg -k com:pipe,port=\\.\pipe\COM1,resets=0,reconnect

The Windbg will open up it’s command window and will wait to connect through the named pipe mapped port as soon as VPC OS starts up. The picture below illustrates how the Windbg will start up with these command line parameters:

4. Now reboot the VPC image and select the new option you’ve included in the boot.ini in the step 1 of this procedure. During the boot process, as soon as the kernel gets loaded the Windbg will attach to it. All you need to do now if break the debugger at the point you want to start debugging and have fun J.

A Virus Infection: Contolling the Outbreak (tip)

Marcelo Fartura — Tue, 24 Oct 2006 08:48:00 GMT

This weekend I had the opportunity to work along our security specialists (from PSSSec group) in what we can call the hottest situation involving hundreds of production servers either stopped or severely impacted by a new variation of a worm. As a new variation, the AV signature file wasn't updated with the proper signature and once the first machine got inffected it immediately started spreading the worm accros the customer production environment...

Details like how the first machine got infected, how the worm spreads itself through the network or even which worm is the variation of, will be ommited here as this scenario will be usefull only to illustrate what the tip is about.

So, direct to the point:

While on site helping to control the situation, one of the steps in our action plan while the signature file for the AV was being built was to control the infection or in other words, stop the infected machines to keep infecting the others. Clean the machines was something we knew we wouldn't be able to accomplish unless we could build an AV engine overnight :)

We isolated the worm itself to 2 executable files and a DLL. The executables are dropped during the infection and a registry key is changed in order to load them whenever the machine is booted. They also run as Local System, so you can't just open the task manager, right click their processes, and select the "End process" option as this would cause a access denied. What you can do though, is to use the utility kill.exe together with the tlist.exe from Debugging Tools For Windows , build a script that will filter the tlist.exe's output trying to find the specific processes names and then run kill.exe to kill them, and then you use the at.exe command or the Task Scheduler to schedule such a script to run. By using the Task Scheduler service your script will run as Local System and should be able to kill the processes running under the same security context.

Ok, but this does not prevent the process to get spawned again (for instance in the next boot) and even deleting the registry entries that could cause that, since the AV is not effective, this machine can get infected again and you will never know when to run the script again to stop the worm's processes. We needed to find a way to prevent these specific processes to keep getting respawned...

So here is the tip for something you can use in different OS versions from Windows NT to Windows 2003 to accomplish that: There is a registry key called "Image File Execution Options" under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion which is normally used for debugging purposes. There is a specific string value that we can use to accomplish our demand of preventing the processes to run. It's the "Debugger" SZ value. This value is used to include a debugger that should launch the process whenever there is a demand for the OS to spawn it. For instance: If you create a key named "Calc.exe" under "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options" and add a SZ value called "Debugger" and set it to, for instance, a debugger like cdb.exe (Debugger = c:\debuggers\cdb.exe) the effect will be such that whenever you try to execute the program calc.exe (regardless of user and regardless of how) the debugger cdb.exe will be called instead and it will spawn the calc.exe itself within the debugger.

All right, so now we just need to be creative and find a way to, instead of run a debugger, just prevent the process to be spawned. Here is one way:

1. Create a registry key with the name of the process you want to prevent to execute. Ex.: calc.exe

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\calc.exe

2. Under this new key you've just created, create a SZ value called "Debugger" and set it to the following value:

SZ Debugger = "cmd.exe /c echo %time% %date% >> c:\ExecBlocked.log"

That's it. You don't need to restart anything or reboot the machine. From now on you will not only be unable to run calc.exe as whenever you try to do it the file ExecBlocked.log will get the attempt to execute recorded with the date/time information.

To enable the process the run again, simply remove the registry key.

Perfmon's counters output format (tip)

Marcelo Fartura — Thu, 14 Sep 2006 03:38:00 GMT

The System Monitor (Perfmon.exe) reports the data gathered through some of its objects and counters with no formatting and depending on what kind of counters are you looking at, or how tired you are, sometimes this can be confusing and even cause misinterpretation problems.

As an example, take the counter Processes::Virtual Bytes. We normally have MBytes or even more than 1GByte being reported, however the output is still reported in bytes with thousands separators. The following picture better illustrates this situation:

The tip to fix it is provided by the article KB300884 - How to: Display Comma Separators in Windows Performance Tool in Windows XP and after changing the registry as instructed in the article, the System Monitor's output will be like the picture below:

Depending on what problem you're troubleshooting you might want to use the Processes and Threads objects. When choosing which process or which thread within a process we want to monitor, the System Monitor does not report a important information called Process ID for processes and Thread ID for the threads. Instead the objects provide a separate counter named ID Process and ID Thread which are supposed to provide these information. So another good tip, that might save you some time, is to create the following registry DWORD values:

KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PerfProc\Performance

ProcessNameFormat = 2

ThreadNameFormat = 2

After restarting the System Monitor, the next time you need to use either the Process or Threads objects, they will appear followed by their ID information as illustrated in the pictures below:

Thank you Brian for the Tip!!!! It has been saving a lot of my time :)