Analyze -v

Viewing data structures is usually a critical part of any analysis. In WinDBG, there are several different ways in which you can inspect data structures. However, one of the most common ways is with the Display Type command, dt. On the surface dt is pretty simple, you specify a data structure name and WinDBG will show you the fields of the structure along with their offsets and types:

0: kd> dt nt!_ksemaphore
   +0x000 Header           : _DISPATCHER_HEADER
   +0x010 Limit            : Int4B

In addition, you can optionally specify an address to be interpreted as the specified type so that you can inspect the fields of the structure:

0: kd> dt nt!_ksemaphore 8a084120
   +0x000 Header           : _DISPATCHER_HEADER
   +0x010 Limit            : 0n1

Now that we have the basics down, let’s see some advanced usage of this command that will allow us to quickly and easily navigate any structure that we’re interested in.

Inspecting Structure Fields

In the above example, the standard dt output showed us two fields of the KSEMAPHORE structure: Header and Limit. If we knew beforehand that we only cared about the Limit field, we could specify an additional parameter to the dt command and limit the output to only show the Limit field:

0: kd> dt nt!_ksemaphore Limit
   +0x010 Limit : Int4B
0: kd> dt nt!_ksemaphore 8a084120 limit
   +0x010 Limit : 0n1

Note that the Header field itself was a data structure, though it wasn’t expanded in the standard dt output and it won’t be expanded if we limit the output to just show the Header field:

0: kd> dt nt!_ksemaphore header
   +0x000 Header : _DISPATCHER_HEADER
0: kd> dt nt!_ksemaphore 8a084120 Header
   +0x000 Header : _DISPATCHER_HEADER

However, you can use standard C syntax to inspect specific fields of the substructure:

0: kd> dt nt!_ksemaphore header.type
   +0x000 Header      :
      +0x000 Type        : UChar
 

In order to actually enumerate the fields of that structure we’re going to need to specify yet another parameter. Now, this is where the dt command syntax gets messy and inconsistent. There are, in fact, three different ways to expand substructures with the dt command: /r, ., and ->*. Let’s see when each of these are appropriate.

Structure Expansion With /r

The /r switch to the dt command is the, “recursively dump the subfields” switch. The switch takes a number between 1-9 to indicate the depth to which the command should traverse dumping structures. Using this method is only effective if you are not specifying a subfield of the structure. For example, these work as expected:

0: kd> dt nt!_ksemaphore /r1
   +0x000 Header           : _DISPATCHER_HEADER
      +0x000 Type             : UChar
      +0x001 Absolute         : UChar
      +0x002 Size             : UChar
      +0x003 Inserted         : UChar
      +0x004 SignalState      : Int4B
      +0x008 WaitListHead     : _LIST_ENTRY
   +0x010 Limit            : Int4B
0: kd> dt nt!_ksemaphore /r2 8a084120
   +0x000 Header           : _DISPATCHER_HEADER
      +0x000 Type             : 0x5 ''
      +0x001 Absolute         : 0 ''
      +0x002 Size             : 0x5 ''
      +0x003 Inserted         : 0 ''
      +0x004 SignalState      : 0n0
      +0x008 WaitListHead     : _LIST_ENTRY [ 0x898a0090 - 0x898a0090 ]
         +0x000 Flink            : 0x898a0090 _LIST_ENTRY [ 0x8a084128 - 0x8a084128 ]
         +0x004 Blink            : 0x898a0090 _LIST_ENTRY [ 0x8a084128 - 0x8a084128 ]
   +0x010 Limit            : 0n1

However, if you attempt to expand just the Header field, you’ll see that the switch is ignored:

0: kd> dt nt!_ksemaphore /r1 Header
   +0x000 Header : _DISPATCHER_HEADER
0: kd> dt nt!_ksemaphore /r1 8a084120 Header
   +0x000 Header : _DISPATCHER_HEADER

 In order to perform that type of expansion, we’ll need the . and ->* switches.

 Structure Expansion With .

In our last example, we were trying to only expand the Header field of the KSEMAPHORE structure but the /r switch was ineffective. In order to expand the embedded structure by name in that case, we need to follow the structure name with a period. This indicates to the engine that you would like to view only that member of the structure and you would like to expand it:

0: kd> dt nt!_ksemaphore 8a084120 Header.
   +0x000 Header  :
      +0x000 Type    : 0x5 ''
      +0x001 Absolute : 0 ''
      +0x002 Size    : 0x5 ''
      +0x003 Inserted : 0 ''
      +0x004 SignalState : 0n0
      +0x008 WaitListHead : _LIST_ENTRY [ 0x898a0090 - 0x898a0090 ]

In addition, you can keep adding additional periods to keep increasing the depth of the expansion:

0: kd> dt nt!_ksemaphore 8a084120 Header..
   +0x000 Header   :
      +0x000 Type     : 0x5 ''
      +0x001 Absolute : 0 ''
      +0x002 Size     : 0x5 ''
      +0x003 Inserted : 0 ''
      +0x004 SignalState : 0n0
      +0x008 WaitListHead :  [ 0x898a0090 - 0x898a0090 ]
         +0x000 Flink    : 0x898a0090 _LIST_ENTRY [ 0x8a084128 - 0x8a084128 ]
         +0x004 Blink    : 0x898a0090 _LIST_ENTRY [ 0x8a084128 - 0x8a084128 ] 

  Structure Expansion With ->*

In the above case, the period suffix was appropriate because the field of the structure that we cared about was an embedded structure, not a pointer to a structure. Let’s try that again with a pointer to a structure, such as the Dpc field of the KTIMER:

0: kd> dt nt!_ktimer b46c82a0
   +0x000 Header           : _DISPATCHER_HEADER
   +0x010 DueTime          : _ULARGE_INTEGER 0xd2`333b7e55
   +0x018 TimerListEntry   : _LIST_ENTRY [ 0x8a06fb10 - 0x80562628 ]
   +0x020 Dpc              : 0xb46c82e0 _KDPC
   +0x024 Period           : 0n0
0: kd> dt nt!_ktimer b46c82a0 Dpc
   +0x020 Dpc : 0xb46c82e0 _KDPC
0: kd> dt nt!_ktimer b46c82a0 Dpc.
   +0x020 Dpc  :
Cannot find specified field members.

Oops! That doesn’t work so hot…Instead, we need a different suffix to the field name: ->* (no, I’m not joking, that’s really the syntax ). Taking our previous example:

0: kd> dt nt!_ktimer b46c82a0 Dpc->*
   +0x020 Dpc   :
      +0x000 Type  : 0n19
      +0x002 Number : 0 ''
      +0x003 Importance : 0x1 ''
      +0x004 DpcListEntry : _LIST_ENTRY [ 0x0 - 0x0 ]
      +0x00c DeferredRoutine : 0xb46be385        void  rdbss!RxTimerDispatch+0
      +0x010 DeferredContext : (null)
      +0x014 SystemArgument1 : (null)
      +0x018 SystemArgument2 : (null)
      +0x01c Lock  : (null)�

There are, of course, lots of other things that can be done with the dt command as well. However, hopefully that clears up some confusion and motivates you to find some other interesting things in the docs!

Bonus Tip: Quick Access to Last Type Used

Before we leave, here’s one last quick tip about this command. The dt command always stores the last type inspected and gives you quick access to the previous type by accepting a period character for the type name. This is best explained with an example. So, let’s say we want to look at two KSEMAPHORE structures. We actually only need to type the entire type name out the first time, the second time we can save a keyboard and just use a period for the type name:

0: kd> dt nt!_ksemaphore 8a084120
   +0x000 Header           : _DISPATCHER_HEADER
   +0x010 Limit            : 0n1
0: kd> dt . 8a0281e0�
Using sym nt!_ksemaphore
   +0x000 Header           : _DISPATCHER_HEADER
   +0x010 Limit            : 0n2147483647

OK, so, I was shamed into updating my blog this week…Sorry for the long delay, though I can’t promise that it won’t happen again

I’ve talked about pseudo registers and interesting ways to use them before, but I’ve failed to mention one other nice feature about them: some pseudo registers are typed when using the C++ evaluator. Specifically, the @$thread, @$proc, @$teb, and @$peb registers are typed to be their appropriate data structure. This means that when using these pseudo registers in a C++ expression, you can just reference whatever fields you want directly as if they are pointers.

So, for example, if I want to inspect the TopLevelIrp field of the current thread (which is a very strange field and a discussion of its own for another day), I can just do the following:

0: kd> ??@$thread->TopLevelIrp
unsigned long 0

Or maybe I want to see the command line that was used to launch the current process. In that case, I can just do the following:

0: kd> ??@$peb->ProcessParameters->CommandLine
struct _UNICODE_STRING
 "windbg.exe  -z C:\Windows\livekd.dmp"
   +0x000 Length           : 0x48
   +0x002 MaximumLength    : 0x4a
   +0x004 Buffer           : 0x003b1c8a  "windbg.exe  -z C:\Windows\livekd.dmp"

Pretty handy and avoids having to do some otherwise nasty scripting.

Note that you can read more about C++ expressions in this article from The NT Insider.

In my previous post I asked you to find the issue in the following script:

as Host 192.168.1.51
as Port 6969

sx- -c “!load winext\\MSEC.dll;!exploitable -bestormhost:Host-bestormport:Port” sov

So in this post I’ll solve the mystery…

Whenever I have a problem like this, I like to break it down into something simpler so that I can verify the result myself before declaring victory. In this case, the script is using a debugger extension DLL and command that aren’t part of the standard WinDBG package, so my first idea was to simplify the script and just have the script do the following:

as Host 192.168.1.51
as Port 6969

.echo Host Port

If you save the above script to a file script.txt and execute the following command:

$$><c:\scripts\script.txt

You will get a surprising result: No output! Nada, zip, zero, zilch:

How can that be? The answer lies in the documentation for as and $$><.  First, from the as docs:

If you do not use any switches, the as command uses the rest of the line as the alias equivalent.

OK, so as sets the remainder of the line (up to the newline) to be the alias equivalent. Now, from the $$>< docs:

 The $>< and $$>< tokens open the script file, replace all carriage returns with semicolons, and execute the resulting text as a single command block.

So, as sets the entire line after the alias name to be the alias and $$>< turns the entire script into a single line. Hmmm…Let’s check the aliases after the script is run:

Aha! Now it’s clear what’s going on, that first as command ended up eating the entire script and turning it into an alias for Host!

This is why the aS command exists. That command allows you to specify a quoted string to set the alias to, which avoids this type of confusion:

aS Host "192.168.1.51"
aS Port "6969"

.echo Host Port

However, before giving this script a try we have a couple of other refinements that we can make to it. First off, while it may appear to work in some cases, you should always wrap aliases in the alias interpreter command ${}. In that case, our .echo command should be:

.echo ${Host} ${Port}

In addition, whenever I define my aliases I also like to wrap them in the alias interpreter command with the /v: switch, which deliberately shuts off the alias interpreter. This prevents you from recursively defining the alias in cases where your script is run for multiple invocations:

aS ${/v:Host} "192.168.1.51"
aS ${/v:Port} "6969"

Putting it all together, we can now save the following in a text file and execute it:

aS ${/v:Host} "192.168.1.51"
aS ${/v:Port} "6969"

.echo ${Host} ${Port}

D’oh! Still not there! What’s the problem this time?

Faithful readers will remember the previous post on using WinDBG aliases, in which we discovered that aliases are not interpreted until some kind of block statement is reached. Because there are no block statements in the above script, the aliases aren’t interpreted until the script has finished running. Thus our .echo statement just shows us the literal string value that we passed it. In order to fix this final issue we simply need to add a .block directive after we have defined the aliases:

aS ${/v:Host} "192.168.1.51"
aS ${/v:Port} "6969"

.block {
    .echo ${Host} ${Port}
}

Using what I learned from my simplified script, this is the final solution that I submitted to the reader which ended up solving the issue:

aS ${/v:Host} "192.168.1.51"
aS ${/v:Port} "6969"

.block {

    sx- -c “!load winext\\MSEC.dll;!exploitable -bestormhost:${Host}-bestormport:${Port}” sov

}

A reader sent me a question (snoone at this domain) because their WinDBG script wasn’t working properly. Here’s the script and the problem:

I am trying to do this (inside a windbg script):

===
as Host 192.168.1.51
as Port 6969

sx- -c “!load winext\\MSEC.dll;!exploitable -bestormhost:Host-bestormport:Port” sov
===

But the Host and Port aren’t being interpreted rather they are being passed as is

There are two scripting bugs in here, can you spot them? I’ll have a follow up post this week to explain the issues and name a winner if there is one. Your prize for being the winner? Absolutely nothing! I do run this blog at a loss you know

WinDBG commands and scripts can get messy. Real messy. One of my major goals in life is to always write my WinDBG scripts such that the next person would be able to pick them up and make fixes or adjustments if needed, which is why I always turn to aliases when I’m writing anything but the most trivial scripts.

Aliases are simple: they’re a string substitution mechanism that you can use in your debugging sessions and scripts. I’ve shown you an alias here before, though now we’ll cover how to use aliases more effectively in a more general way.

No big surprise here, but understanding aliases comes down to three things: creating aliases, using aliases, and deleting aliases. In order to create aliases, all you need to do is use the as or aS command. Both commands take an alias to create as well as the string that should be substituted for the alias. The difference between the two is subtle, so I’ll try to untangle that here.

If you use the as command, everything after the alias name up to the newline is included in the alias definition. We can see the results of that here if we use the al command to list the aliases after we’re done:

0: kd> as FooAlias This is all kinds of stuff ; .echo Bar
0: kd> al
  Alias            Value
 -------          -------
 FooAlias         This is all kinds of stuff ; .echo Bar

Note that the semicolon is not used as a delimiter here. Alternatively, the aS command stops at semicolons so you get different results if you try the above with aS:

0: kd> aS FooAlias This is all kinds of stuff ; .echo Bar
Bar
0: kd> al
  Alias            Value
 -------          -------
 FooAlias         This is all kinds of stuff 

aS also has another nice feature in that you can enclose the alias string in quotes, making what goes into the alias explicit. Everything in between the quotation marks will be entered as the alias and the command will not stop at semicolons:

0: kd> aS FooAlias "This is all kinds of stuff ; .echo Bar"
0: kd> al
  Alias            Value
 -------          -------
 FooAlias         This is all kinds of stuff ; .echo Bar

For this reason aS is my preferred command for creating aliases. I recommend that you read the documentation for the as and aS commands as there are other interesting options to the command that I’m specifically ignoring (e.g. you can set an alias to the contents of an environment variable).

Once you’ve created an alias, it’s time to use it as part of an expression. This is where the alias interpreter command ${} comes into play. Any string put in between the braces will go through string substitution if it is an alias, so for example:

0: kd> aS Ping "Pong"
0: kd> .echo ${Ping}
Pong

The intepreter also has some nifty switches to it, for example the /d switch which checks to see if the alias is defined or not. If it is defined, the expression evaluates to 1 otherwise it evaluates to 0:

0: kd> aS Ping "Pong"
0: kd> .echo ${/d:Ping}
1
0: kd> .echo ${/d:BadAlias}
0

This is how we can check for the presense of arguments to scripts run with the $$>a< command, which creates aliases for each argument supplied. There is also the /v switch, which shuts the evaluator off and returns the literal string passed to the interpreter. This is handy if you want to display or use the name of the alias and not the contents. More details about the alias interpreter and its switches can be found in the documentation.

The last thing to know about aliases relates to their use in WinDBG scripts. One thing you must remember is that aliases are not expanded until a new block is entered. New blocks can be created with the various control flow tokens (e.g. .if, .while, .do, etc.) and arbitrarily with the .block token. This can have unexpected results if you’re not aware of it. Let’s take a brain dead script:

aS AliasTest "This is a test"

.echo ${AliasTest}

The first time you run this you will get some unexpected output:

0: kd> $$><c:\dumps\aliastest.wbs
${AliasTest}

As you can see, the alias was not properly expanded. However, if you check the alias list you will see that it is indeed there:

0: kd> al
  Alias            Value�
 -------          -------
 AliasTest        This is a test

The problem is that without a block statement, the aliases were not evaluated until after the script ran. We can fix this by putting an artificial block in the script file:

aS AliasTest "This is a test"

$$ Force any previous aliases to be evaluated.
.block
{
    .echo ${AliasTest}
}

 This time we end up with what we expected:

0: kd> $$><c:\dumps\aliastest.txt
This is a test

Lastly, let’s delete our aliases that we’ve created. This can be done with the ad command, which will delete a specific alias or all aliases if passed an asterisk. There is a trick here though: beware alias expansion! If you’re not careful, the alias interpreter will pick up the alias name that you’re trying to delete and do a string substitution. The best way to avoid this is to use the /v switch to the interpreter, which will force it to shut off alias expansion:

aS AliasTest "This is a test"

$$ Force any previous aliases to be evaluated.
.block
{
    .echo ${AliasTest}
}

ad ${/v:AliasTest}

That’s it for now…Try using aliases in your scripts and commands and see if they help you out at all. If you want some inspiration, you can look at the scripts that I’ve posted here previously for examples on how I use aliases:

Undocumented !process flags and switches

Finding image load and process notification callbacks

Finding registered Configuration Manager (i.e. registry) callbacks