## Wednesday, January 28, 2015

### My vimrc - Vim, Part 1

I'm feeling lazy.  So here's my vimrc.  Behold:

## _vimrc

syn on
colors koehler

set ic
set incsearch
set hls

set nu
set nowrap

set sw=4
set ts=4

set ai
set bs=2

set tw=0
set colorcolumn=80

set nobackup

autocmd FileType python   set tabstop=4|set shiftwidth=4|set expandtab

## Fin

So there's part one.  Part two is forthcoming, and will include more slick stuff -- hackin' up binaries, scripting, writing shellcode...  Stay tuned.

## Tuesday, January 20, 2015

### Windows man pages

If you're a UNIX or Linux person, you know Windows lacks man pages.  So man up and make some.

Create a directory and add it to your path.  Call it man, help, or whatever.

Every time you run into a command whose usage and arguments you need to know, run it with the /? switch and redirect its output into a file in that help directory.

FOR /? > %USERPROFILE%\help\for.txt


Now you've got a file in your path that says this:

Runs a specified command for each file in a set of files.

FOR %variable IN (set) DO command [command-parameters]

%variable  Specifies a single letter replaceable parameter.
(set)      Specifies a set of one or more files.  Wildcards may be used.
command    Specifies the command to carry out for each file.
command-parameters
Specifies parameters or switches for the specified command.

To use the FOR command in a batch program, specify %%variable instead
...


Then, the next time you need help on the for command, hit Win+R, type for.txt, and press Enter.  The saved help will pop up immediately in Notepad, because you added the help directory (or whatever you called it) to your path.  You can also use it to stash past examples if you're running or scripting particularly complex commands.

Presto.  Man pages.  Now quit yer whining.

## Sunday, January 18, 2015

### This One Weird Trick the Visual Studio Team Doesn't Want You to Know!

I find it fascinating that most Windows boxes (these days, I can almost say all of them) have CLR compilers sitting around on their hard drives.  This would make it possible for people to experiment with C# and VB.NET without downloading squat...  But Microsoft forgot to do one thing: set up some file associations.  So this is a write-up on how to set them up in a quick and dirty fashion on any computer so that you can experiment with C# and VB.NET without having to download Visual Studio.

I don't like Visual Studio anyway, probably because I don't work on enterprise stuff.  I shamelessly admit that my codebase is a collection of cheap hacks, and my goal is to be able to crack open an editor, vomit out fifty or a thousand lines of code, execute my tests, and get on with my day.  I also get a smug sense of satisfaction and independence from eschewing an IDE, kind of like choosing to drive a manual transmission car.  (Why don't I use Linux, then?  Quiet, you.  It's because of software requirements.)

So, with no further ado, I present:

## Visual Stu-DIY-o

For the impatient, here is the quick and dirty TL;DR:

assoc .cs=CSharpSourceFile
ftype CSharpSourceFile=%WINDIR%\Microsoft.NET\Framework\v4.0.30319\csc.exe %1


But your .NET compiler might not be located there, or your code warnings and errors may zip by and disappear, or your executable may not get built, or you may have wanted to program VB.NET, et cetera.  If you care about such things, then go through the exercise of locating your compiler, creating a friendly compiler script, and associating that with your source files.  Read on for more.

### Find your .NET compiler of choice

You're really just confirming what version you have.  You're doing this because you want to be sure the files exist before you copy and paste the script below.  Fortunately, this is easy, because it's in your path:

1. Hit Win+R (to get the run dialog)
2. Type Microsoft.NET
3. Leap of faith: press Enter
4. Browse to the Framework\v4.0.30319 directory
5. Note the absolute path to csc.exe (hint: hit ALT+D, hit End, finish off that directory name with a backslash, and start typing csc, and it will let you auto-complete the path in the address bar; copy this address for later).

A little note: I use the Framework (and not Framework64) directory because I want my MSIL to run in 32- and 64-bit environments.  For my normal projects, I use .NET version 4.0, and for software that must be deployed to mixed and potentially un-maintained platforms (if I told you why, I'd have to kill you), I target .NET 2.0.  Lastly, I use C#, but you don't have to.  At this point, if you want to locate vbc.exe instead (That's the VB.NET Compiler), go ahead and replace csc with vbc.  I won't judge you.  Just remember to actually replace what I put in the script below with the path to vbc.

At this point, we could set the file association directly with the compiler, as in the "TL;DR" section above, but if you double-click your .cs (or .vb) files, and your source code has warnings or errors, a mysterious black box will appear and disappear before you have a chance to review and fix them.  That's why you're going to bother with the next step:

### Write a quickie script

Choose a place where this script will live.  Make a "util" or "bin" or "scripts" directory somewhere in your user profile if you don't already have one.  Open Notepad, copy and paste what is below (replace the path to csc if you are targeting a different .NET version, architecture, compiler, etc.), and save it as something.  I chose buildcs4.cmd.  In the Save As dialog, under "Save as type", don't forget to select "All Files (*.*)" so that it does not "helpfully" append the .TXT file extension for you, thus neutering your command script.  Here's my version:

@ECHO OFF
%WINDIR%\Microsoft.NET\Framework\v4.0.30319\csc.exe %*
PAUSE


The PAUSE command is there so you can see the warnings before the script closes.  You can't use an IF ERRORLEVEL command to pause for warnings, because the compiler only returns 1 or greater if there are errors, not if there are warnings, so that is why I include an unconditional PAUSE.  %* tells the command interpreter to pass along all the arguments from the command line.  This is how the filename you double-click will be passed to the C# compiler (or VB.NET compiler, if that's your predilection).

### Finally, make the file association

Open an administrative command prompt and invoke these three incantations:

assoc .cs=CSharpSourceFile
ftype CSharpSourceFile=%USERPROFILE%\path\to\buildcs4.cmd %1


These define a filetype, set a file association, and add an "Edit" context menu command, respectively.  For more background on all that, type ASSOC /?FTYPE /?, and REG /? on the command-line.

## Taking it for a Spin

If you want a test, here's a nice C# sample you can paste into notepad.  I think the traditional hello-world example is pretty boring, so here's something to spice up someone's life:

using System;
using System.Windows.Forms;

class mbox
{
static public void Main()
{
MessageBox.Show(
"Delete C:\\ - are you sure?",
"Confirmation",
MessageBoxButtons.OK,
MessageBoxIcon.Warning
);
}
}


Now save that as hello.cs, and double-click it to compile.  Run the resulting hello.exe to see the result.

Right-click hello.cs and choose Edit when you want to mess about some more.  Aaaaaand, we're done.

## Tuesday, January 13, 2015

### Windows su and sudo

Wherein I describe a marginal hack for creating su and sudo utilities for Windows.

Frequently I want to get right to work adjusting services configuration with sc.exe.  Or, I might not even need a command prompt in order to figure out what I need -- sometimes I just want to run SysInternals' Process Explorer as an administrator so I can read the thread information and get on with my life.  In these instances, it usually breaks my concentration to now have to go open the system32 folder, locate cmd.exe, right-click it, and click Run as administrator.

Wouldn't it be nice to just be able to hit Win+R (to invoke the Run dialog) and type:

su

...or...

sudo procexp

?

I think so.  And to that end, here is how to set that up.

## Elevated Command Prompt (su)

Open a directory that is in your path.  For example, hit Win+R to get the Run dialog, type . (that is a dot), and press return -- most likely, your user profile directory will open.

Right-click an empty area in this directory and click New > Shortcut.

In the location editbox, type %COMSPEC% (which is an environment variable that expands to the location of cmd.exe):

Click Next.  In the name editbox, type su:

Click Finish.  Now, right-click the new file, su.lnk (it will appear as simply su if you do not have Windows Explorer configured to display file extensions).  Under the Start in editbox, you may choose to type %USERPROFILE% or another location so that you start out in the directory of your choosing instead of C:\Windows\System32:

Click the Advanced...  button.  Check the Run as administrator checkbox.  Click OK twice.

Once this is done, if you created the shortcut in a directory that is in your path, then you should be able to hit Win+R, type su, press Enter, acknowledge the UAC dialog, and immediately have an elevated command prompt.

## Elevated Single Command (sudo)

For sudo, you will need a shortcut that can accept a parameter to be run as an elevated command.  Copy and paste the shortcut from above, renaming it sudo.  Right-click the shortcut and in the Target editbox, type %COMSPEC% /c start ""

Don't neglect the pair of double quotes -- I'll explain later.  Save the shortcut, and now you can hit Win+R, type sudo procexp (assuming SysInternals' Process Explorer is in your path) and spawn a privileged instance of Process Explorer without having to go find the executable, right-click on it, and select "Run as Administrator".

There you have it.  The su and sudo commands, for Windows.

## A Digression

Okay, you might already know that cmd.exe /c will run the command interpreter and execute the command that is specified after the /c switch.  But you might be wondering why the pair of double quotes is necessary after the START command.  As with everything else in Windows, it is because the command interpreter and its minions are made of pain.

If you don't specify these empty quotes, then some day you're going to run sudo followed by something surrounded in quotes.  That day, you will have to go manually start your privileged whatever-the-hell-you-were-doing, because the start command interprets the first quoted string it sees as a title to be displayed in the console window hosting the command interpreter.  So, on that day, start will swallow your argument to sudo and never find any actual command to run.  Then, it will exit immediately, leaving you wondering when the hell tcpview is going to pop up.  Did you have a late night, tcpview?  Are you coming in to work today?  No.  The START command ruined everything.  Because that's what Windows commands do.  They ruin everything.

If you don't believe me, take a look at the first few lines of the help output from the START /? command:

Starts a separate window to run a specified program or command.

START ["title"] [/D path] [/I] [/MIN] [/MAX] [/SEPARATE | /SHARED]
[/LOW | /NORMAL | /HIGH | /REALTIME | /ABOVENORMAL | /BELOWNORMAL]
[/NODE ] [/AFFINITY ] [/WAIT] [/B]
[command/program] [parameters]

"title"     Title to display in window title bar.
`

It's subtle, isn't it?  And because the actual help for this command is over a hundred lines long, it might take you a while to put two and two together.

Just be glad we're having this conversation so you can move on with your life.  Speaking of which, I've got some sudo commands to run.  Peace.