

If your VM is 64-bit and you want to debug remotely:.If your VM is 32-bit and you want to debug remotely:.If your VM is 64-bit and you want to debug locally:.If your VM is 32-bit and you want to debug locally:.Add one of the following lines to the end of the file, based on preference.Right-click on the *.vmx file and "Open with" your favorite text editor.Find the "Working directory" text field and copy the string to your clipboard.Ensure that you are on the "Options" tab. Select "Edit virtual machine settings".If it's currently active, power it off via the menu bar: "VM" then "Power" then "Shut Down Guest" (or Ctrl+E). Ensure that the VM is currently not running.If the "Library" pane is missing, you can restore it by selecting "View" then "Customize" and choosing "Library" (or hit F9). VMs should be listed in the "Library" pane on the left of the GUI.Select the VM you wish to enable GDB stub debugging on within VMware.The second part of this tutorial (loading kernel symbols) assumes you're running a Windows 64-bit VM (AMD64).This can be any OS supported by VMware such as Ubuntu.My host and guest OS are both running Windows 圆4 3 (Version 1703). These do not have to be the same versions of Windows. A Windows operating system installed on your host and guest (VM).

You can use either the Linux or Windows build of VMware.Unfortunately, VMware Player (entirely free for non-commercial use) does not expose the GDB stub interface.A copy of VMware Workstation (free 30-day trial).This article goes over how to setup VMware's GDB stub and how to connect to it using IDA Pro's GDB debugger. Together these make for a very powerful combo. IDA Pro, the defacto disassembler that most reverse engineers have, includes a GDB debugger. VMware has built in support for remote debugging of virtual machines running inside it through a GDB stub. In situations like this, you need to bust out the heavy tools. An example of such is trying to troubleshoot the runtime logic of PatchGuard (Microsoft's Kernel Patch Protection). Sometimes you'll run into a situation that you can't analyze with a traditional kernel debugger like WinDbg.
