Dan Griffin's Blog

Comments on security, PKI, smart cards, cryptography, and entrepreneurship.

I wanted to provide clearer instructions for the one of the Vista security sample code projects we recently did.  I’m referring to the Windows Filtering Platform demo which can be downloaded here (http://download.microsoft.com/download/f/1/2/f12dbbb5-d164-4e7c-b42d-aaca3efb85dc/WFPSample.EXE).  In summary, it shows how to build a packet inspection driver which uses context information passed from user mode. 

1.  Building the demo requires the latest Windows Driver Kit (formerly known as the DDK).  It’s a big download, available two ways (that I’m aware of):  either via an MSDN subscription or via http://connect.microsoft.com

For the latter, the connection is called "Windows Logo Kit (WLK), Windows Driver Kit (WDK), and Windows Driver Framework (WDF)". 

Once you’re registered, the current download link is (https://connect.microsoft.com/Downloads/DownloadDetails.aspx?SiteID=148&DownloadID=4606).  Once you’ve got the Driver Kit installed, run Start | All Programs | Windows Driver Kits | WDK 6000 | Build Environments | Windows Vista and Windows Server | Windows Vista and Windows Server Longhorn x86 Checked Build Environment.  In that command window, change to the WfpDemo directory from the extracted demo download package and type build.exe.

2.  I recommend deploying the driver on a test x86fre Vista machine.  To do so, copy the following files to a temporary directory on the target machine:  msnmed.sys, medit.exe, msnmed.inf.  On the target machine, open Explorer, right click on msnmed.inf, and select Install.  That will copy and register the driver.  Then run net start msnmed; the driver should then be loaded (if it wasn’t already).

3.  On the test Vista machine, install version 7.5 of MSN Messenger.  If you use a different version, you’ll need to double-check that the messenger application binary path isn’t different.  Otherwise, the custom filter installed by the demo won’t apply (it’s configured to be specific to a certain path/binary name).

4.  To run the demo, you’ll need access to two different Messenger accounts:  one to send messages (IMs) from the test machine, and one to receive the messages and view the changes made by the filter driver to the outbound data stream. 

On the test machine, in a command window, run medit.exe oldstring newstring.  What the demo will show is that, any time oldstring is typed into the messenger window where the driver is installed, it will be changed to newstring, which is what the recipient will see.  ‘Oldstring’ and ‘newstring’ can be anything, but they need to be the same length (otherwise, medit.exe will immediately return an error). 

After running the above, don’t close medit - the filters it installs are dynamic, and will be cleaned up when the medit process terminates. 

Now open the messenger client on the test machine and send a test chat to the other messenger account.  Use ‘oldstring’ in the messege.  Check the recipient’s messenger window and you should see the sender’s message, with ‘newstring’ instead of ‘oldstring’.  That’s the demo :)

5.  Regarding debugging the driver, if medit.exe succeeds in running the command above, and doesn’t terminate immediately with an error, then things should generally be working.  Aside from running a kernel debugger (which you should be doing anyway if you plan on digging into the driver in any detail), deeper debugging is available via WMI tracing. 

Copy \WinDDK\6000\tools\tracing\i386\TraceView.exe (and the chm help file …) from your Driver Kit installation to the test machine where the filter driver is installed.  You’ll need the current msnmed.pdb on the test machine as well.  Run TraceView.exe on the test machine, File | Create New Log Session | Add Provider | PDB.  Enter the full path of msnmed.pdb.  Click OK, then Next, then Set Flags and Level.  Double-click on Level and select Information.  Click OK, then Finish.  Now the TraceView window should show the full driver debug output when running scenarios as the test machine.  Unfortunately, we didn’t add any specific WMI tracing output for the new filter we added in this demo (i.e. above and beyond what the original DDK sample already implemented).

Permalink |

No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URL

Leave a comment