NBDServer – WindowsTechs.com

A project I read about a while back really caught my attention, but I hadn’t had a good chance to try it out till recently. Jeff Bryner (@p0wnlabs) created NBDServer and describes it as a “A DFIR/forensic take on nbdsrvr by Folkert van Heusden.”

In essence, NBDServer allows you to set up a server on a Windows machine (XP, Win 7, Win 2008) and then connect to it from a Linux client. The client configures the Windows server as a read-only network block device, allowing you to mount the device on the client like a local disk, image it across the network or run other forensic tools on the device. It is also possible to use this tool in conjunction with the Volatility winpmem utility to image the Windows system RAM across the network to your client.

Running NBDServer is simple. There is no real setup, so all you have to do is download the ZIP file, extract the contents and place them on the Windows machine you wish to work with. You’ll need to run the program from an Administrative command prompt (gasp! a command line program!) if using Windows Vista, 7, 2008, etc. I’ll come back to the mechanics of running NBDServer in a moment, but first let’s talk about setting up the Linux client.

The Linux half of this setup, known as nbd-client, available from it’s page on Sourceforge and is apparently created and maintained by Wouter Verhelst. Download the nbd-client package (currently version 3.2) to your Linux workstation and install it using the typical ./configure && make && make install. I installed it to the new Kali Linux and didn’t have to account for any missing dependencies, but your mileage may vary on a different distro. Once installed run “modprobe nbd” to initialize the new device prior to attempting to connect with the server.

To test the setup, I ran it from several different configurations. The first test used a Kali Linux virtual machine and a Windows XP Pro virtual machine on the same host. After that, I used two physical machines, being Kali Linux installed to hard drive on one pc and Windows 7, 64-bit on the other. Finally, I connected between the Windows XP Pro vm and the physical Kali Linux box. I tested the ability to connect and remain connected, as well as mounting remote drives and imaging disks and RAM via the network. I won’t detail every result from each separately, as they were all essentially the same. I will cover imaging RAM separately a little later in this post.

To begin simulating a response to a Windows machine, I connected my Linux box to a network share which the subject Windows pc could also connect to. I copied the nbdserver.exe to a folder on the share and then opened the share on the Windows machine (x: drive on this machine) and copied the nbdserver to the desktop. On the Win 7 pc, I opened an Administrative command prompt and navigated to the nbdserver location. I reviewed the available options from the README which include:

Usage:

NBDServer.exe v3.0
 -c     Client IP address to accept connections from
 -p     Port to listen on (60000 by default)
 -f     File to serve ( \\.\PHYSICALDRIVE0 or \\.\pmem for example)
 -n     Partition on disk to serve (0 if not specified)
 -w     Enable writing (disabled by default)
 -d     Enable debug messages
 -q     Be Quiet..no messages
 -h     This help text

 -f option supports names like the following: 
  \\.\PHYSICALDRIVE0    raw drive partition access along with -n option
  \\.\C:                volume access (no need for -n option)
  \\.\HarddiskVolume1   volume access (no need for -n option)
  afile.dd              serve up the contents of 'afile.dd' via nbd.
  \\.\pmem              access the pmem memory driver from volatility

On the first attempt, I wanted to connect to the system drive on the Win 7 machine and mount it in Linux. The IP address for the Windows box was 192.168.2.157 and the Linux IP was 192.168.2.197. So, my command line was as such:

nbdserver.exe -c 192.168.2.197 -f \\.\PHYSICALDRIVE0 -n0

This instructs the server to connect to the client IP and serve up the first partition on drive 0. I hit enter and the program started, though all you see is the cursor drop to the next line and sit there flashing. No news is good news at this point.

I moved over to the Linux pc to start the client. You may need to use sudo when running it. The command for starting the client is as follows:

modprobe nbd

followed by

(sudo) nbd-client 192.168.2.157 60000 /dev/nbd0

This starts the client, tells it to look for the server on 192.168.2.157, use

port 60000 and create the new network block device as /dev/nbd0.

Upon executing the above commands, the connection was successfully established as evidenced by messages displayed on both machines command lines. The Windows side just reports a successful connection to the client IP. The client showed the size of the new device in megabytes and bytes, as well as the block size.

I next ran the fls tool from the Sleuth Kit to generate a quick timeline on the new block device like this:

fls -f ntfs -m C: -r /dev/nbd0 > test.fls

This worked with no problem, so my next test was to mount the device in Linux. I typed the following command:

mount -t ntfs-3g -o rw,show_sys_files,streams_interface=windows /dev/nbd0 /mnt/nbd

You may have noticed I included “rw” for read/write instead of “ro” for read-only. I wanted to test and make sure that nbdserver really was only giving me read-only access to the disk, regardless of how I mounted it. I created a text file using the touch command while in the mounted Windows user directory, then opened it and added some text to it. I save it and type ls, seeing it was listed among the files in the directory. I looked over to the real Windows machine to see if the file was there, but it wasn’t. Back on the Linux side, I typed rm -rf * for everything in the current directory and typed ls, showing an empty directory. However, looking at the real folder on the Windows machine showed nothing was added and nothing was deleted.

I issued a umount command to unmount the device, then disconnected from the server with this command:

(sudo) nbd-client -d /dev/nbd0

A quick ctrl-C on the Windows side killed the server. I then re-connected and again mounted the system drive, finding all files were where they were supposed to be and no additional files had been created. The nbdserver/client setup appears to create and delete files on your command, but nothing actually changes.

Using the same methods described already, I also accessed a USB flash drive. I was able to mount and imag it across the network with no issues.

As I mentioned above, it’s also possible to image RAM on the Windows system via the network with nbdserver. In addition to the server, you also need the latest version of winpmem from the awesome Volatility project. The current winpmem.exe version is 1.4.1.

Prior to starting the server, it is necessary to load the winpmem driver. You can do this manually, but there’s really no need. The winpmem executable works very well and is invoked by typing:

winpmem_1.4.exe -l (that’s a lowercase L, not a number 1)

If you see no errors after running that, you should be ready to continue. Start your nbdserver as before, but this time you’ll change what you’re telling the server to make available to the client. Your new command line will look something like:

nbdserver.exe -c 192.168.2.197 -f \\.\pmem

Over on the client, you can pretty much type the same thing you did before. You can add the -b option to designate the block size also. Here’s an example:

nbd-client 192.168.2.157 60000 /dev/nbd1 -b 1024

You can then use your favorite version of dd, dc3dd, dcfldd, etc, to image the RAM device like this:

dc3dd if=/dev/nbd1 of=./physmem.raw (name it whatever you want)

From there, you can use Volatility to work with your RAM image. Just to make sure I got a good image, I ran the Volatility kdbgscan plugin on the ram image. It reported correct information, so I knew I was in good shape.

The only issue I ran into imaging RAM involved the 64-bit Win 7 machine. Imaging memory on the XP Pro machine worked without a hitch. However, I found the 64-bit machine would lock up and then spontaneously reboot when the imaging reached 3.5GB of the 12GB total. I plan to contact Volatility and let them know and will be happy to provide any sample data to help figure out what went wrong.

Overall, I would call this a huge success. Except for the 64-bit RAM imaging issue, I experienced no problems I couldn’t attribute to user error. If you find yourself in need of a tool like this and don’t have to money or time to obtain a commerical product like F-Response, I think you’ll find you can accomplish what you need with NBDServer.

NOTE: Edited to remove some content I want to test further.