{"id":7,"date":"2006-07-10T07:00:19","date_gmt":"2006-07-10T12:00:19","guid":{"rendered":"http:\/\/www.nynaeve.net\/?p=7"},"modified":"2019-12-13T17:43:36","modified_gmt":"2019-12-13T22:43:36","slug":"sdbgext-extensions-part-2","status":"publish","type":"post","link":"http:\/\/www.nynaeve.net\/?p=7","title":{"rendered":"SDbgExt extensions – part 2."},"content":{"rendered":"

Last post, I discussed some of the major extensions available in SDbgExt<\/a>.\u00c2\u00a0 This post is a continuation that explains the remaining major\u00c2\u00a0\/ interesting extensions available in the extension library.<\/p>\n

\u00c2\u00a0Another set of extensions that may prove useful if you do frequent C++ development are the STL datastructures display functions.\u00c2\u00a0 These allow you to interpret many of the complicated STL container datastructures and format them in more understandable forms from the debugger.\u00c2\u00a0 At present, the extension DLL only understands the Visual C++ 7.0 \/ 7.1 STL structure layout (no support for VC6 or VC8 as of yet, sorry).\u00c2\u00a0 This complements the built-in WinDbg support for STL, which does not cover all of VC7 (or at least did not the last time I checked).\u00c2\u00a0 The SDbgExt STL type display functions do not rely on type information contained in symbols, so you can use them to help debug third party programs that you do not have symbols for.\u00c2\u00a0 However, some extensions will require you to have a bit of knowledge about the structures contained in an STL container (usually the size of a container item).\u00c2\u00a0 These extensions will work on local or remote 32-bit targets.<\/p>\n

The main functions that you might find useful in this grouping are these:<\/p>\n

!stlmap allows you to traverse an std::map (binary tree) and optionally dump some bytes from each of the key and value types.\u00c2\u00a0 Due to the layout of the std::map type, you will need to tell SDbgExt about the size of the key and value types.<\/p>\n

!stlset allows you to traverse an std::set (binary tree) optionally dump some bytes from each of value types.\u00c2\u00a0 It is very similar to the !stlmap extension, except that it works on std::set structures and thus only needs information about a value type and not an additional key type.<\/p>\n

!stllist and !stlvector allow you to display the contents of an std::list or std::vector, respectively.\u00c2\u00a0 Optionally, you may provide the size of an element to dump some bytes from each element to the debugger.<\/p>\n

!stlstring and !stlwstring allow you to display std::string and std::wstring structures.\u00c2\u00a0 If you are displaying very long strings (>16K characters), then you will need to provide a second argument specifying the maximum number of characters to display.\u00c2\u00a0 This limit is always capped at 64K characters.<\/p>\n

Most of the STL datastructures traversal functions have only minimal protection against damaged or corrupted datastructures.\u00c2\u00a0 If you attempt to use them on a datastructure that is broken (perhaps it has a link that references itself, causing an infinite loop), then you will need to break out of the extension with Ctrl-C or Ctrl-Break depending on which debugger you use.\u00c2\u00a0 To ensure that your system remains responsive enough to have the option of breaking out, SDbgExt will lower its priority to at least normal (WinDbg runs at high priority by default) temporarily, for the duration of the call to the extension (the original priority is restored before the extension returns).<\/p>\n

The last major category of functions supported by SDbgExt are those that are related to Windows UI debugging.\u00c2\u00a0 These extensions generally always require a live 32-bit target on the local computer in order to function (no remote debugging).\u00c2\u00a0 They\u00c2\u00a0work by directly querying internal window structures or by calling user32\/gdi32 APIs about a particular UI object.\u00c2\u00a0 These can be used as a handy replacement for Spy++, which has a nasty tendancy to break badly (and break every GUI application on the same desktop with it) when it encounters a GUI program that is frozen in the debugger.<\/p>\n

The !hwnd\u00c2\u00a0extension is the primary UI debugging extension supported by SDbgExt.\u00c2\u00a0 It will dump many of the interesting attributes about a window given its handle (HWND) to the debugger console.\u00c2\u00a0 Additionally, it can be used to enumerate the active windows on the current thread.\u00c2\u00a0 This extension is particular useful for programs that store things like class object pointers at GWLP_USERDATA or DWLP_USERDATA, which are normally hard to get at from WinDbg.<\/p>\n

The !getprop extension can be used to enumerate window properties associated with a particular window, or to query a\u00c2\u00a0single specific\u00c2\u00a0window property associated with a particular window.\u00c2\u00a0 These are useful if a program stores information (like a class object pointer) in a window property and you need to get at it from the debugger, which is something that you cannot easily do from WinDbg normally.<\/p>\n

The !msg extension will display information about a MSG structure given a pointer to it.\u00c2\u00a0 It has a limited built in set of message names for some of the most common standard window messages.\u00c2\u00a0 It will also display information about the window with which the window message is associated with (if any).<\/p>\n

Finally, there are a couple of misc. functions that SDbgExt supports which don’t fit cleanly into any specific category.\u00c2\u00a0 Many of these are niche extension that are only useful for very specific scenarios.<\/p>\n

The !switchdesk extension will switch the active desktop for the computer hosting the debugger.\u00c2\u00a0 This can be useful if you are debugging a full screen DirectX program using a GUI debugger on an alternate desktop and a console debugger in full screen mode connected to the GUI debugger using remote debugging on the same desktop as the program being debugged.<\/p>\n

The !lmx extension will allow you to view the loaded module list in the various forms that the loader maintains it (in-load-order, in-memory-order, in-initialization-order).\u00c2\u00a0 When used on kernel targets, there is only one loaded module list, so the list identification parameter is unused in that usage case.<\/p>\n

!findwfptr (courtsey of skape<\/a>) allows you to scan the address space of the debuggee for function pointers that are located in writable memory.\u00c2\u00a0 It willl work on all target types.\u00c2\u00a0 For live targets, it can also optionally place breakpoints at all of the functions pointed to by pointers residing in writable memory.\u00c2\u00a0 This extension is useful if you are auditing a program for potential security risks; many of the static addresses (i.e. global variables)\u00c2\u00a0in standard system DLLs that contain function pointers have been changed to encode the pointer values based on a random cookie to prevent exploits from overwriting them to gain control over the program.\u00c2\u00a0 This extension can help you identify which function pointers might be used by an attacker to compromise your program when used in conjunction with certain types of security flaws.<\/p>\n

!cmpmem allows you to compare ranges of memory over time, with the ability to exclude modified ranges.\u00c2\u00a0 This is particularly useful if you want to watch a data structure (or even the global variables of an entire module) and quickly determine what changes when a particular operation happens in the context of the debuggee.\u00c2\u00a0 For example, if you are trying to reverse engineer a function and want to understand some of the side effects it has on data structures or global variables, this function can help quickly identify modified areas without requiring you to analyze the entire function in a disassembler.<\/p>\n

\u00c2\u00a0That’s all for this series.\u00c2\u00a0 There are a couple of extensions that I didn’t mention, but they are either very obvious or not generally useful enough to be worth mentioning.\u00c2\u00a0 The online help (!help) provides basic syntax and a very brief description about all extensions supported by SDbgExt, so you can find parameter information about all of the extension I mentioned there.<\/p>\n","protected":false},"excerpt":{"rendered":"

Last post, I discussed some of the major extensions available in SDbgExt.\u00c2\u00a0 This post is a continuation that explains the remaining major\u00c2\u00a0\/ interesting extensions available in the extension library. \u00c2\u00a0Another set of extensions that may prove useful if you do frequent C++ development are the STL datastructures display functions.\u00c2\u00a0 These allow you to interpret many […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[2,8,5],"tags":[],"_links":{"self":[{"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=\/wp\/v2\/posts\/7"}],"collection":[{"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=7"}],"version-history":[{"count":2,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=\/wp\/v2\/posts\/7\/revisions"}],"predecessor-version":[{"id":702,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=\/wp\/v2\/posts\/7\/revisions\/702"}],"wp:attachment":[{"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=7"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=7"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=7"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}