Winbagility is a tool that gives you ability to connect WinDbg on non /DEBUG Windows x64 systems. Winbagility simulates a debugged kernel. It retrieves over the STUB for some essentials information (KDBG, KPCR…) and forward these informations to WinDbg over KD.
PyFDP is a Python extension used to communicate with the FDP (Fast Debugging Protocol) hypervisor-based debugging server used in the Winbagility project. Winbagility introduced an instrumented version of VirtualBox which can be used to implement a sthealth debugger via Virtual Machine introspection and runtime analysis. While Winbagility simply connect the FDP server to Windbg in order to debug a Windows VM as if the guest was launch with /DEBUG option activated, anyone can write a FDP client. PyFDP expose the FDP client side by wrapping the DLL’s exports via ctypes, enabling any Python program to script a VM debugging session.
Setting Up Network Debugging of a Virtual Machine – KDNET
This topic describes how to configure a kernel debugging connection to a Hyper-V virtual machine (VM).[…]
Time Travel Debugging is now available in WinDbg Preview
We are excited to announce that Time Travel Debugging (TTD) features are now available in the latest version of WinDbg Preview. About a month ago, we released WinDbg Preview which provides great new debugging user experiences. We are now publicly launching a preview version of TTD for the first time and are looking forward to your feedback.[…]
As I hear, TTD has been used at Microsoft internally for years, just now getting this feature out to the public. Though they are not identical in implementation, GDB has had reverse execution for a while.
New WinDbg available in preview!
We are excited to announce a preview version of a brand new WinDbg. We’ve updated WinDbg to have more modern visuals, faster windows, a full-fledged scripting experience, built with the easily extensible debugger data model front and center. I’ll start this by saying that WinDbg Preview is using the same underlying engine as WinDbg today, so all the commands, extensions, and workflows you’re used to will still work just as they did before.
Windbg always had restrictions in what UI widgets it could use, since Windbg was used to debug those same UI widgets (OLE, COM, etc.) and had to work even those widgets did not work.
(WordPress renders the MSDN blog URL strangely, if you can’t click on that, click on the URL in Alex’s twtter.)
Binary Ninja plugin for Voltron integration.
* Synchronise the selected instruction in Binary Ninja with the instruction pointer in the debugger
* Mark breakpoints that are set in the debugger in Binary Ninja
* Set and delete breakpoints in the debugger from Binary Ninja
The Windows kernel debugger needs to operate even when some device drivers fail, and for other reasons, the debugger can’t use the normal Windows drivers for remoting the debugger over serial, network, USB, Firewire (1394), so the debugger needs to write it’s own driver and do other hacks to remote itself. In the beginning, serial was the only requirement, but later faster cables were needed, like USB and 1394.
Well, it looks like Firewire is fading away, Microsoft has removed 1394 support from the mainstream release of the kernel debugger, only keeping it in the WDK build. Also, AFAIK, this is the first time the Windows debugger is being built separately like this.
Microsoft recently released a new Windows Windbg debugger extension called MEX. It has a variety of features, dozens of commands for many of Microsoft’s products. It appears to have been removed from the download site for a while, but it is up now, at least for the moment.
There’s a copy of the MEX help usage listed here:
MWR Labs has a new blog post on using Python with Windbg, the Microsoft Windows system debugger.
(I wish Microsoft would properly integrate Python to Windbg, instead of requiring third parties to do so.)
If you have not looked at Voltron, by Jim Fear, please check it out, it is quite powerful:
Voltron is an extensible debugger UI toolkit written in Python. It aims to improve the user experience of various debuggers (LLDB, GDB, VDB and WinDbg) by enabling the attachment of utility views that can retrieve and display data from the debugger host. By running these views in other TTYs, you can build a customised debugger user interface to suit your needs. Voltron does not aim to be everything to everyone. It’s not a wholesale replacement for your debugger’s CLI. Rather, it aims to complement your existing setup and allow you to extend your CLI debugger as much or as little as you like. If you just want a view of the register contents in a window alongside your debugger, you can do that. If you want to go all out and have something that looks more like OllyDbg, you can do that too.
ret-sync stands for Reverse-Engineering Tools synchronization. It’s a set of plugins that help to synchronize a debugging session (WinDbg/GDB/LLDB/OllyDbg2/x64dbg) with IDA disassembler. The underlying idea is simple: take the best from both worlds (static and dynamic analysis).
From debuggers and dynamic analysis we got:
local view, with live dynamic context (registers, memory, etc.)
built-in specialized features/API (ex: Windbg’s !peb, !drvobj, !address, etc.)
From IDA and static analysis we got:
macro view over modules
code analysis, signatures, types, etc.
fancy graph view
persistent storage of knowledge within IDBs
Pass data (comment, command output) from debugger to disassembler (IDA)
Multiple IDBs can be synced at the same time allowing to easily trace through multiple modules
No need to deal with ALSR, addresses are rebased on-the-fly
IDBs and debugger can be on different hosts
ret-sync is a fork of qb-sync that I developed and maintained during my stay at Quarkslab.
Windbg is Microsoft’s Windows system debugger (both user-mode and kernel-mode), which has the ability to load third party extensions. I just noticed some Windbg extensions that Intel has created. One enables Windbg to work over JTAG, the other enables support for Intel PT:
The “Intel Debug Extensions for WinDbg” consists of two sets of debugger extensions:
1) Intel Debug Extensions for WinDbg for IA JTAG debugging (IA JTAG) enables the connection of WinDbg to a target over the JTAG. The server acts as a mediator and forwards the calls from WindDbg* to the IPC interface and back.
2) Intel Debug Extensions for WinDbg for Intel Processor Trace (Intel PT) is designed to help WinDbg users by extending their debugging tool set with execution tracing. The extension allows for easy setup of Intel PT by abstracting hardware configuration and then reconstructing and displaying execution flow from the collected trace data. It will integrate with other WinDbg* features like symbolization and high-level source display. Intel PT is a new technology for low-overhead execution tracing. It facilitates debugging a program by exposing an accurate and detailed trace of the program’s activity, and its triggering and filtering capabilities help identifying and isolating the relevant program executions. Intel PT records information about software execution on each hardware thread using dedicated hardware facilities. After execution completes, a software can process the recorded trace data and reconstruct the exact program flow.
BIOS / UEFI firmware: With firmware that is Intel PT-aware, you can set up an Intel PT-specific memory allocation. In this case, the firmware allocates a dedicated memory area and reserves it in a memory map for further use. Operating systems will recognize this reserved memory range and will not use it. When firmware reserves a memory region for Intel PT, it also configures the Intel PT output MSRs accordingly and indicates that Intel PT output configuration is ready to be used. The extension will recognize this setup. No further configuration (from user’s side) is required.
I presume these extensions are only available as part of the commercial-only Intel System Studio product. If you use Windbg, you may want to try to get these extensions, they sound useful.
Andrey Bazhan has announced Memory Explorer, a new tool for DbgKit, a fancy add-on to Microsoft’s Windbg debugger. If you do Windows debugging or forensic analysis, you might want to check this out.
It looks like Microsoft has updated Windbg for Windows 10, one of the new features is support of Visual Studio’s NatVis expression model:
dx (Display NatVis Expression) – Describes the new dx debugger command, which displays object information using the NatVis extension model and LINQ support.
New commands that work with the NatVis visualization files in the debugger environment.
.nvlist (NatVis List)
.nvload (NatVis Load)
.nvunload (NatVis Unload)
.nvunloadall (NatVis Unload All)
Andrey Bazhan has released version 1.3 of DbgKit, a GUI extension to WinDbg, the Microsoft Windows system debugger, included in the “Debugging Tools for Windows” package. Given that most Windbg extensions are command line, a GUI extension to Windbg is fairly impressive!
“DbgKit is the first GUI extension for Debugging Tools for Windows (WinDbg, KD, CDB, NTSD). It will show you hierarchical view of processes and detailed information about each process including its full image path, command line, start time, memory statistics, vads, handles, threads, security attributes, modules, environment variables and more.”