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
}
