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:
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:
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:
(sudo) nbd-client -d /dev/nbd0
NOTE: Edited to remove some content I want to test further.