Archive for February, 2011

How to config the Win32 Kernel Debugger

Thursday, February 24th, 2011

As mentioned here, one of the new features of the upcoming BinNavi 3.1 release, is the Win32 kernel debugger. This debugger enables you to perform dynamic analysis of Win32 kernel components. In this blog post I will describe how to configure your work environment to use the new debugger for BinNavi.
To debug kernel components with BinNavi, it is necessary to have a host system which runs BinNavi with the kernel debugger and a virtual machine which runs the code you want to analyse.
There are two ways for connecting your debugging system with the debugger. The first one is to use Virtual KD, which is the fastest solution, and the second one is to use the more generic, but slower WinDBG named pipe method.
It is recommended to use a virtual machine in combination with Virtual KD. Although other configurations are possible, they should only be chosen if Virtual KD can’t be used.

Configuration with Virtual KD

For this you need to install Virtual KD on the host system and on the guest vm, which will be used for debugging. After you downloaded the package and copied the target/vminstall.exe to your vm, you install Virtual KD by running the executable. Press the install button after checking if the parameters match the ones in the screenshot.

Now you can start the virtual machine monitor vmmon.exe (included in Virtual KD) on the host system and restart the debug virtual machine. The virtual machine monitor shows the pipename which is automatically created by the virtual monitor and is later used by the kernel debugger.

Configuration without Virtual KD

An alternative method is to use the standard com port via named pipes method in combination with vmware or a physical machine.

In case of using vmware, you need to go the settings of your virtual machine and add a new hardware. Choose as hardware ‘serial port’ with the name as ‘\\.\pipe\com_1’ and as additional options ‘This end is the server’ and ‘The other end is an application’.

Now you can start the virtual machine and edit the boot option to run the virtual machine with the debug option. These settings depend on your operating system:

For Windows XP:

You have to edit the boot.ini file of your virtual machine. For this you have to append the following line to your configuration file: ‘/debug /debugport=com1/baudrate=115200’.

If you want to do debug a physical machine you may want to change this parameter to suit your needs.

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="normal boot" /noexecute=optin /fastdetect
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="debug boot" /noexecute=optin /fastdetect /debug /debugport=com1 /baudrate=115200

You must reboot your vm for the changes to take effect.

For Windows Vista and Windows 7:

You have to use the bcedit command to change the boot option:

At first start a cmd shell with admin privileges, then use the following command to get the ID

bcdedit /v

then make a copy of the normal entry:

bcdedit /copy {ID} /d "kernel debug"

and enable kernel debug on it with the following command:

bcdedit /debug {ID} on

You must reboot your vm for the changes to take effect. For more information please have a look at
http://www.microsoft.com/whdc/driver/tips/Debug_Vista.mspx

Configuration in BinNavi

The next step is to load your device driver using the usual step into the BinNavi database. This procedure is explained in more detail here. After the module is successfully loaded, you have to create a new debugger and assign it to the module. The default port is 2222 which can be changed. After this is done you can run the windbg debug client using the command line:

windbgclient32.exe -p 2222 com:port=\\.\pipe\kd_WindowsXPSP2,baud=115200,pipe

This results in listening on the default debug port and connecting to the name pipe ‘kd_WindowsXPSP2’. Now you can open the module in BinNavi by selecting a call graph or flow graph and switch to the debug view (crtl+d). To connect to the selected debugger just press the start debugger button and wait until the debugger is loaded. In the last step you have to choose the right device driver you want to debug in the dialog.

After all steps are done you can start with your normal work flow to analyse the module. This includes using the trace mode for differential debugging and setting breakpoints on interesting functions.
Happy debugging!

Posted in BinNavi | 1 Comment »

VxClass 1.5

Tuesday, February 15th, 2011

Today, we release a new version of our malware clustering solution: zynamics VxClass 1.5[1].

Compared to the previous release (VxClass 1.3)  and aside from fixing tons of bugs, we improved version 1.5 with new and upgraded system software, updated the BinDiff-based differ component and finally switched to IDA Pro 6.0.

Here are some more things we changed:

  • Updated the base system to the new Debian 6.0 (“Squeeze”)
  • Upgraded to Python 2.7.1 for VxClass base code
  • Upgraded to IDA Pro 6.0 and IDAPython 1.4.3, pefile 1.2.10-96
  • Updated the diffing engine to the newest BinDiff version
  • Performance improvements when using VxClass in a cluster
  • Huge performance improvements: A single machine can now easily process 8000 samples a day.
  • New top-10 most similar visualization (more below)

And of course this release also includes the signature generation component Thomas blogged about here, here and here.

With improved performance, mining the data of a VxClass system that contains tens of thousands of malware samples provides more and more insight. Unfortunately, up until now, this has been more difficult than necessary. For example, answering questions like “What are the 10 most-similar malware samples for this particular sample?” usually meant writing custom Python scripts that access the built-in XMLRPC interface.
Starting with this release, we will continue to add more visualization options for the data in the system. We start off simple with the top 10 most-similar and Venn diagram visualizations.

Showing the top 10 most-similar samples for a malware binary

When using the “family tree” applet that has been present in VxClass since the first release, another “caveat” of being able to process tens of thousands of samples becomes apparent: humans cannot visually process several thousand clusters organized in a graph. Thus, the next release will contain an alternate visualization for the “family tree”. I’ll leave the details to another blog post.

All existing customers within their support periods will receive an e-mail regarding the upgrade in the next few days.

[1] Following the naming tradition of Ubuntu, VxClass releases are code-named with an alliteration. This release is code-named “exploited emu” which follows after version 1.3’s “malicious monkey”.

Posted in VxClass | No Comments »

BinDiff 3.2.1… fun!

Tuesday, February 1st, 2011

Hi there. I am one of the developers working on VxClass and the signature generation component in particular. However, working in a small company such as zynamics also means I get to do tons of other stuff, like preparing installer packages and other behind-the-scenes work.
So, in my first post I have the pleasure to announce a new version of our binary comparison tool: BinDiff 3.2.1. As the version number implies, this is mostly a bugfix only release, but with one important difference: As of now, all customers that place an order for BinDiff, automatically receive Debian GNU/Linux packages as well as the familiar Windows Installer package. Supported Debian-based distributions include:

  • Debian 5.0 (“Lenny”)
  • Ubuntu 10.04 LTS (“Lucid Lynx”)

Please note that for the Linux packages, we only support using BinDiff with Hex-Rays IDA Pro 6.0. For the Windows version we support the three latest versions of IDA Pro (5.6, 5.7 and 6.0, respectively).

This is how BinDiff looks on Linux:

BinDiff 3.2.1 in IDA 6.0 (Qt) on Linux

BinDiff 3.2.1 GUI on Linux

You can order BinDiff over the usual channels: e-mail, the order form on our web site or your favourite reseller.

This concludes my first post here, have fun diffing!

Posted in BinDiff | 22 Comments »