Vanja Svajcer, Cisco
With its ability to use the operating system symbols and recognise many, even undocumented, system structures, WinDbg is a powerful tool and effectively the only debugger used to analyse kernel mode malware and inspect objects kept internally by Windows in a live debugging session or by analysing the full memory dump.
Unfortunately, the WinDbg learning curve has been traditionally steep, due to a large number of often unintuitive debugging commands, rudimentary user interfaces and arcane scripting syntax.
Over the years there have been several more and less successful attempts to make WinDbg scripting simpler for the user, with the most widely accepted interface being the pyKd Python extension. Still, the WinDbg scripting remained far from being user friendly.
Developers behind Debugging Tools for Windows have been aware of WinDbg limitations for some time and recently they put a lot of effort into making WinDbg easier for the user. They introduced the new GUI in WinDbg Preview (available through Windows Store) but also added a new Debugger Object Model, with dx command to inspect it, together with NatVis visualisation specification XML language, and LINQ queries which allow the user to filter the results of the dx debugging command.
With the Debugger Object Model, they exposed many of the operating system objects tracked internally by the debugger such as processes, threads, handles, stacks and others through a user friendly hierarchical namespace. Users can simply inspect Debugger.Sessions.First().Processes to enumerate all processes in the current session.
This research is a part of a longer term effort to make kernel debugging and manual analysis more widely practised by malware researchers.